1. 事务概述

所谓"事务"是指要做的所做的事情，在计算机术语中是指访问并可能更新数据库中各种数据项的一个程序执行单元(unit)。事务通常由高级数据库(操纵语言或编程语言（如SQL，C++或Java）书写的用户程序的执行所引起，并用形如begin transaction和end transaction语句（或函数调用）来界定。事务由事务开始(begin transaction)和事务结束(end transaction)之间执行的全体操作组成。

1.1 Spring事务的基本原理

Spring事务的本质其实就是数据库对事务的支持，没有数据库的事务支持，spring是无法提供事务功能的。Spring只提供统一事务管理接口，具体实现都是由各数据库自己实现，数据库事务的提交和回滚是通过binlog或者undo log实现的。Spring会在事务开始时，根据当前环境中设置的隔离级别，调整数据库隔离级别，由此保持一致。
对于纯JDBC操作数据库，想要用到事务，可以按照以下步骤进行：

（1）获取连接 Connection con = DriverManager.getConnection()

（2）开启事务con.setAutoCommit(true/false);

（3）执行CRUD

（4）提交事务/回滚事务 con.commit() / con.rollback();

（5）关闭连接 conn.close();
使用Spring的事务管理功能后，我们可以不再写步骤 2 和 4 的代码，而是由Spirng 自动完成。那么Spring是如何在我们书写的 CRUD 之前和之后开启事务和关闭事务的呢？解决这个问题，也就可以从整体上理解Spring的事务管理实现原理了。下面简单地介绍下，注解方式为例子

（1）配置文件开启注解驱动，在相关的类和方法上通过注解@Transactional标识。

（2）spring 在启动的时候会去解析生成相关的bean，这时候会查看拥有相关注解的类和方法，并且为这些类和方法生成代理，并根据@Transaction的相关参数进行相关配置注入，这样就在代理中为我们把相关的事务处理掉了（开启正常提交事务，异常回滚事务）。

（3）真正的数据库层的事务提交和回滚是通过binlog或者redo log实现的。

2. Spring事务机制

所有的数据访问技术都有事务处理机制，这些技术提供了API用来开启事务、提交事务来完成数据操作，或者在发生错误的时候回滚数据。

而Spring的事务机制是用统一的机制来处理不同数据访问技术的事务处理。Spring的事务机制提供了一个PlatformTransactionManager接口，不同的数据访问技术的事务使用不同的接口实现，如表所示。

数据访问技术及实现

1635383687525.png
1635383772756.png

在程序中定义事务管理器的代码如下：

@Bean 
public PlatformTransactionManager transactionManager() { 

    JpaTransactionManager transactionManager = new JpaTransactionManager(); 
    transactionManager.setDataSource(dataSource()); 
    return transactionManager; 
}

2.1 声明式事务

Spring支持声明式事务，即使用注解来选择需要使用事务的方法，它使用@Transactional注解在方法上表明该方法需要事务支持。这是一个基于AOP的实现操作。

@Transactional 
public void saveSomething(Long  id， String name) { 
    //数据库操作 
}

在此处需要特别注意的是，此@Transactional注解来自org.springframework.transaction.annotation包，而不是javax.transaction。

AOP 代理的两种实现：

• jdk是代理接口，私有方法必然不会存在在接口里，所以就不会被拦截到；
• cglib是子类，private的方法照样不会出现在子类里，也不能被拦截。

Java动态代理

具体有如下四步骤：

（1）通过实现 InvocationHandler 接口创建自己的调用处理器；

（2）通过为 Proxy 类指定 ClassLoader 对象和一组 interface 来创建动态代理类；

（3）通过反射机制获得动态代理类的构造函数，其唯一参数类型是调用处理器接口类型；

（4）通过构造函数创建动态代理类实例，构造时调用处理器对象作为参数被传入。

GCLIB代理

cglib（Code Generation Library）是一个强大的，高性能，高质量的Code生成类库。它可以在运行期扩展Java类与实现Java接口。

• cglib封装了asm，可以在运行期动态生成新的class（子类）。
• cglib用于AOP，jdk中的proxy必须基于接口，cglib却没有这个限制。

原理区别：

java动态代理是利用反射机制生成一个实现代理接口的匿名类，在调用具体方法前调用InvokeHandler来处理。而cglib动态代理是利用asm开源包，对代理对象类的class文件加载进来，通过修改其字节码生成子类来处理。

（1）如果目标对象实现了接口，默认情况下会采用JDK的动态代理实现AOP

（2）如果目标对象实现了接口，可以强制使用CGLIB实现AOP

（3）如果目标对象没有实现了接口，必须采用CGLIB库，spring会自动在JDK动态代理和CGLIB之间转换

如果是类内部方法直接不是走代理，这个时候可以通过维护一个自身实例的代理。

@Service
public class PersonServiceImpl implements PersonService {
    @Autowired
    PersonRepository personRepository;

    // 注入自身代理对象，在本类内部方法调用事务的传递性才会生效
    @Autowired
    PersonService selfProxyPersonService;

    /**
     * 测试事务的传递性
     *
     * @param person
     * @return
     */
    @Transactional
    public Person save(Person person) {
        Person p = personRepository.save(person);
        try {
            // 新开事务 独立回滚
            selfProxyPersonService.delete();
        } catch (Exception e) {
            e.printStackTrace();
        }
        try {
            // 使用当前事务 全部回滚
            selfProxyPersonService.save2(person);
        } catch (Exception e) {
            e.printStackTrace();
        }
        personRepository.save(person);

        return p;
    }

    @Transactional
    public void save2(Person person) {
        personRepository.save(person);
        throw new RuntimeException();
    }

    @Transactional(propagation = Propagation.REQUIRES_NEW)
    public void delete() {
        personRepository.delete(1L);
        throw new RuntimeException();
    }
}

3. Spring事务属性

上面讲到的事务管理器接口PlatformTransactionManager通过getTransaction(TransactionDefinition definition)方法来得到事务，这个方法里面的参数是TransactionDefinition类，这个类就定义了一些基本的事务属性。
那么什么是事务属性呢？事务属性可以理解成事务的一些基本配置，描述了事务策略如何应用到方法上。事务属性包含了5个方面，如图所示：

wps1.jpg

TransactionDefinition接口内容如下：

public interface TransactionDefinition {
    int getPropagationBehavior(); // 返回事务的传播行为
    int getIsolationLevel(); // 返回事务的隔离级别，事务管理器根据它来控制另外一个事务可以看到本事务内的哪些数据
    int getTimeout();  // 返回事务必须在多少秒内完成
    boolean isReadOnly(); // 事务是否只读，事务管理器能够根据这个返回值进行优化，确保事务是只读的} 

3.1 事务传播行为

事务的第一个方面是传播行为（propagation behavior）。当事务方法被另一个事务方法调用时，必须指定事务应该如何传播
传播行为****含义PROPAGATION_REQUIRED表示当前方法必须运行在事务中。如果当前事务存在，方法将会在该事务中运行。否则，会启动一个新的事务PROPAGATION_SUPPORTS表示当前方法不需要事务上下文，但是如果存在当前事务的话，那么该方法会在这个事务中运行PROPAGATION_MANDATORY表示该方法必须在事务中运行，如果当前事务不存在，则会抛出一个异常PROPAGATION_REQUIRED_NEW表示当前方法必须运行在它自己的事务中。一个新的事务将被启动。如果存在当前事务，在该方法执行期间，当前事务会被挂起。如果使用JTATransactionManager的话，则需要访问TransactionManagerPROPAGATION_NOT_SUPPORTED表示该方法不应该运行在事务中。如果存在当前事务，在该方法运行期间，当前事务将被挂起。如果使用JTATransactionManager的话，则需要访问TransactionManagerPROPAGATION_NEVER表示当前方法不应该运行在事务上下文中。如果当前正有一个事务在运行，则会抛出异常PROPAGATION_NESTED表示如果当前已经存在一个事务，那么该方法将会在嵌套事务中运行。嵌套的事务可以独立于当前事务进行单独地提交或回滚。如果当前事务不存在，那么其行为与PROPAGATION_REQUIRED一样。注意各厂商对这种传播行为的支持是有所差异的。可以参考资源管理器的文档来确认它们是否支持嵌套事务

3.2 事务隔离级别

事务的第二个维度就是隔离级别（isolation level）。隔离级别定义了一个事务可能受其他并发事务影响的程度。

在典型的应用程序中，多个事务并发运行，经常会操作相同的数据来完成各自的任务。并发虽然是必须的，但可能会导致一下的问题。

· 脏读（Dirty reads）——脏读发生在一个事务读取了另一个事务改写但尚未提交的数据时。如果改写在稍后被回滚了，那么第一个事务获取的数据就是无效的。

· 不可重复读（Nonrepeatable read）——不可重复读发生在一个事务执行相同的查询两次或两次以上，但是每次都得到不同的数据时。这通常是因为另一个并发事务在两次查询期间进行了更新。

· 幻读（Phantom read）——幻读与不可重复读类似。它发生在一个事务（T1）读取了几行数据，接着另一个并发事务（T2）插入了一些数据时。在随后的查询中，第一个事务（T1）就会发现多了一些原本不存在的记录。

• ISOLATION_DEFAULT：这是个 PlatfromTransactionManager 默认的隔离级别，

  使用数据库默认的事务隔离级别。

• ISOLATION_READ_UNCOMMITTED：读未提交，允许另外一个事务可以看到这个

  事务未提交的数据。

• ISOLATION_READ_COMMITTED：读已提交，保证一个事务修改的数据提交后才

  能被另一事务读取，而且能看到该事务对已有记录的更新。

• ISOLATION_REPEATABLE_READ：可重复读，保证一个事务修改的数据提交后才

  能被另一事务读取，但是不能看到该事务对已有记录的更新。

• ISOLATION_SERIALIZABLE：一个事务在执行的过程中完全看不到其他事务对数据

  库所做的更新。

3.3 只读

事务的第三个特性是它是否为只读事务。如果事务只对后端的数据库进行该操作，数据库可以利用事务的只读特性来进行一些特定的优化。通过将事务设置为只读，你就可以给数据库一个机会，让它应用它认为合适的优化措施。

3.4 事务超时

为了使应用程序很好地运行，事务不能运行太长的时间。因为事务可能涉及对后端数据库的锁定，所以长时间的事务会不必要的占用数据库资源。事务超时就是事务的一个定时器，在特定时间内事务如果没有执行完毕，那么就会自动回滚，而不是一直等待其结束。

3.5 回滚规则

事务五边形的最后一个方面是一组规则，这些规则定义了哪些异常会导致事务回滚而哪些不会。默认情况下，事务只有遇到运行期异常时才会回滚，而在遇到检查型异常时不会回滚（这一行为与EJB的回滚行为是一致的） 。但是你可以声明事务在遇到特定的检查型异常时像遇到运行期异常那样回滚。同样，你还可以声明事务遇到特定的异常不回滚，即使这些异常是运行期异常。 

3.6 总结

对于项目中需要使用到事务的地方，我建议开发者还是使用spring的TransactionCallback接口来实现事务，不要盲目使用spring事务注解，如果一定要使用注解，那么一定要对spring事务的传播机制和隔离级别有个详细的了解，否则很可能发生意想不到的效果。