526互联

Spring 事务快速上手

发布时间 2023-12-30 15:57:53作者: 残城碎梦

Spring事务与数据库事务关系

spring事务本质上使用数据库事务，而数据库事务本质上使用数据库锁，所以spring事务本质上使用数据库锁，开启spring事务意味着使用数据库锁。

spring事务是对数据库事务的封装，最后本质的实现还是在数据库，如果数据库不支持事务，spring的事务是不起作用的。数据库的事务简单来说，只有开启、回滚和关闭。

spring对数据库事务的包装，原理上就是拿一个数据连接，根据spring的事务配置，操作这个数据连接对数据库进行事务开启、回滚或关闭操作。但是spring除了实现这些，还配合spring的传播行为对事务进行了更广泛的管理。

spring事务会回滚同一事务中的所有数据库操作，本质上是回滚同一数据库连接上的数据库操作。

Spring事务传播机制

Spring的事务传播机制定义：

public enum Propagation {
    REQUIRED(0),
    SUPPORTS(1),
    MANDATORY(2),
    REQUIRES_NEW(3),
    NOT_SUPPORTED(4),
    NEVER(5),
    NESTED(6);

    private final int value;

    private Propagation(int value) {
        this.value = value;
    }

    public int value() {
        return this.value;
    }
}

REQUIRED

REQUIRED是Spring默认的传播机制。如果当前存在事务，则加入该事务；如果当前没有事务，则创建一个新事务。

REQUIRED传播机制最常用的情况是在一个事务中进行多个操作，要么全部成功，要么全部失败。如果其中一个操作失败，整个事务都将被回滚。

SUPPORTS

SUPPORTS传播机制表示当前方法如果在一个事务中被调用，则加入该事务；否则，以非事务的方式运行。

SUPPORTS传播机制适用于对事务要求不高的操作，例如读取操作。

MANDATORY

MANDATORY传播机制表示当前方法必须在一个事务中被调用，否则将抛出异常。

MANDATORY传播机制适用于在需要事务的情况下调用方法。

REQUIRES_NEW

REQUIRES_NEW传播机制表示当前方法必须开启一个新事务运行，如果当前存在事务，则挂起该事务。

REQUIRES_NEW传播机制适用于对事务要求较高的操作，例如更新操作。

NOT_SUPPORTED

NOT_SUPPORTED传播机制表示当前方法不应该在事务中运行，如果存在事务，则挂起该事务。

NOT_SUPPORTED传播机制适用于对事务没有要求的操作，例如日志记录等。

NEVER

NEVER传播机制表示当前方法不应该在事务中运行，如果存在事务，则抛出异常。

NEVER传播机制适用于禁止在事务中运行的操作，例如安全检查等。

NESTED

NESTED传播机制表示当前方法必须在一个嵌套事务中运行，如果当前存在事务，则在该事务内开启一个嵌套事务；如果当前没有事务，则创建一个新事务。

NESTED传播机制适用于需要分步操作的场景，例如订单中创建订单和订单项的操作。

在实际应用中，我们需要根据具体业务场景选择合适的事务传播机制。例如，对于对事务要求不高的读取操作，可以选择SUPPORTS传播机制；对于更新操作，可以选择REQUIRES_NEW传播机制。

除了事务传播机制，Spring还提供了事务隔离级别和超时设置等事务管理功能，可以更加细粒度地控制事务。例如，可以根据业务需求选择适当的事务隔离级别，避免数据不一致等问题；也可以设置事务超时时间，避免长时间占用数据库资源。

Spring事务隔离级别

事务的隔离级别是通过锁的机制实现的（这里的锁指的是数据库锁），事务的隔离级别是数据库开发商根据业务逻辑的实际需要定义的一组锁的使用策略。

Spring的隔离级别定义：

public enum Isolation {
    DEFAULT(-1),
    READ_UNCOMMITTED(1),
    READ_COMMITTED(2),
    REPEATABLE_READ(4),
    SERIALIZABLE(8);

    private final int value;

    private Isolation(int value) {
        this.value = value;
    }

    public int value() {
        return this.value;
    }
}

默认隔离级别（Default）

使用数据库默认的隔离级别。不同的数据库可能有不同的默认隔离级别，一般为读已提交（Read Committed）或可重复读（Repeatable Read）。

读未提交（Read Uncommitted）

最低的隔离级别，允许一个事务读取另一个事务尚未提交的数据。这种隔离级别可能导致脏读（Dirty Read），即读取到未提交的数据。

读已提交（Read Committed）

保证一个事务只能读取到已经提交的数据。这种隔离级别可以避免脏读，但可能会导致不可重复读（Non-repeatable Read），即在同一个事务中，多次读取同一数据可能得到不同的结果。

可重复读（Repeatable Read）

保证一个事务在执行期间多次读取同一数据时，能够得到一致的结果。这种隔离级别可以避免脏读和不可重复读，但可能会导致幻读（Phantom Read），即在同一个事务中，多次查询同一范围的数据可能得到不同的结果。

可串行化（Serializable）

最高的隔离级别，确保事务之间完全隔离，避免脏读、不可重复读和幻读。这种隔离级别通过对事务进行串行化执行来实现，性能较低。

在Spring中，可以通过在@Transactional注解中设置isolation属性来指定事务的隔离级别。例如：

@Transactional(isolation = Isolation.READ_COMMITTED)
public void doSomething() {}

需要注意的是，选择合适的事务隔离级别需要根据具体的业务场景和需求来决定。较低的隔离级别可以提高并发性能，但可能会引入数据一致性问题；较高的隔离级别可以保证数据的一致性，但可能会降低并发性能。在使用事务时需要权衡隔离级别和性能的关系，选择适合的隔离级别。

Spring事务失效场景

事务不生效

访问权限问题

java的访问权限主要有四种：private、default、protected、public，它们的权限从左到右，依次变大。

但如果我们在开发过程中，把有某些事务方法，定义了错误的访问权限，就会导致事务功能出问题，例如：

@Service
public class UserService {
    @Transactional
    private void add(UserModel userModel) {
        saveData(userModel);
        updateData(userModel);
    }
}

我们可以看到add方法的访问权限被定义成了private，这样会导致事务失效，spring要求被代理方法必须是public的。

在AbstractFallbackTransactionAttributeSource类的computeTransactionAttribute方法中有个判断，如果目标方法不是public，则TransactionAttribute返回null，即不支持事务。

方法用final修饰

有时候，某个方法不想被子类重新，这时可以将该方法定义成final的。普通方法这样定义是没问题的，但如果将事务方法定义成final，例如：

@Service
public class UserService {

    @Transactional
    public final void add(UserModel userModel){
        saveData(userModel);
        updateData(userModel);
    }
}

我们可以看到add方法被定义成了final的，这样会导致事务失效。

因为spring事务底层使用了aop，也就是通过jdk动态代理或者cglib，帮我们生成了代理类，在代理类中实现的事务功能。

但如果某个方法用final修饰了，那么在它的代理类中，就无法重写该方法，添加事务功能。

注意：如果某个方法是static的，同样无法通过动态代理，变成事务方法。

方法内部调用

有时候我们需要在某个Service类的某个方法中，调用另外一个事务方法，比如：

@Service
public class UserService {

    @Autowired
    private UserMapper userMapper;

    @Transactional
    public void add(UserModel userModel) {
        userMapper.insertUser(userModel);
        updateStatus(userModel);
    }

    @Transactional
    public void updateStatus(UserModel userModel) {
        doSameThing();
    }
}

我们看到在事务方法add中，直接调用事务方法updateStatus。从前面介绍的内容可以知道，updateStatus方法拥有事务的能力是因为spring aop生成代理了对象，但是这种方法直接调用了this对象的方法，所以updateStatus方法不会生成事务。

由此可见，在同一个类中的方法直接内部调用，会导致事务失效。

那么问题来了，如果有些场景，确实想在同一个类的某个方法中，调用它自己的另外一个方法，该怎么办呢？

新加一个Service方法

这个方法非常简单，只需要新加一个Service方法，把@Transactional注解加到新Service方法上，把需要事务执行的代码移到新方法中。具体代码如下：

@Servcie
public class ServiceA {
    @Autowired
    prvate ServiceB serviceB;

    public void save(User user) {
        queryData1();
        queryData2();
        serviceB.doSave(user);
    }
}

@Servcie
public class ServiceB {

    @Transactional(rollbackFor=Exception.class)
    public void doSave(User user) {
        addData1();
        updateData2();
    }

}

该Service类中注入自己

如果不想再新加一个Service类，在该Service类中注入自己也是一种选择。具体代码如下：

@Servcie
public class ServiceA {
    @Autowired
    prvate ServiceA serviceA;

    public void save(User user) {
        queryData1();
        queryData2();
        serviceA.doSave(user);
    }

    @Transactional(rollbackFor=Exception.class)
    public void doSave(User user) {
        addData1();
        updateData2();
    }
}

可能有些人可能会有这样的疑问：这种做法会不会出现循环依赖问题？

不会，spring ioc内部的三级缓存保证了它，不会出现循环依赖问题。

通过AopContent类

在该Service类中使用AopContext.currentProxy()获取代理对象。

上面的方法2确实可以解决问题，但是代码看起来并不直观，还可以通过在该Service类中使用AopContext获取代理对象，实现相同的功能。具体代码如下：

@Servcie
public class ServiceA {
    public void save(User user) {
        queryData1();
        queryData2();
        ((ServiceA)AopContext.currentProxy()).doSave(user);
    }

    @Transactional(rollbackFor=Exception.class)
    public void doSave(User user) {
        addData1();
        updateData2();
    }
}

未被spring管理

在我们平时开发过程中，有个细节很容易被忽略。即使用spring事务的前提是：对象要被spring管理，需要创建bean实例。

通常情况下，我们通过@Controller、@Service、@Component、@Repository等注解，可以自动实现bean实例化和依赖注入的功能。

如果有一天，你匆匆忙忙的开发了一个Service类，但忘了加@Service注解，比如：

//@Service
public class UserService {

    @Transactional
    public void add(UserModel userModel) {
        saveData(userModel);
        updateData(userModel);
    }    
}

从上面的例子，我们可以看到UserService类没有加@Service注解，那么该类不会交给spring管理，所以它的add方法也不会生成事务。

多线程调用

在实际项目开发中，多线程的使用场景还是挺多的。如果spring事务用在多线程场景中，会有问题吗？

@Slf4j
@Service
public class UserService {

    @Autowired
    private UserMapper userMapper;
    @Autowired
    private RoleService roleService;

    @Transactional
    public void add(UserModel userModel) throws Exception {
        userMapper.insertUser(userModel);
        new Thread(() -> {
            roleService.doOtherThing();
        }).start();
    }
}

@Service
public class RoleService {

    @Transactional
    public void doOtherThing() {
        System.out.println("保存role表数据");
    }
}

从上面的例子中，我们可以看到事务方法add中，调用了事务方法doOtherThing，但是事务方法doOtherThing是在另外一个线程中调用的。

这样会导致两个方法不在同一个线程中，获取到的数据库连接不一样，从而是两个不同的事务。如果想doOtherThing方法中抛了异常，add方法也回滚是不可能的。

如果看过spring事务源码的朋友，可能会知道spring的事务是通过数据库连接来实现的。当前线程中保存了一个map，key是数据源，value是数据库连接。

private static final ThreadLocal<Map<Object, Object>> resources = new NamedThreadLocal<>("Transactional resources");

我们说的同一个事务，其实是指同一个数据库连接，只有拥有同一个数据库连接才能同时提交和回滚。如果在不同的线程，拿到的数据库连接肯定是不一样的，所以是不同的事务。

表不支持事务

众所周知，在mysql5之前，默认的数据库引擎是myisam。

它的好处就不用多说了：索引文件和数据文件是分开存储的，对于查多写少的单表操作，性能比innodb更好。

有些老项目中，可能还在用它。

在创建表的时候，只需要把ENGINE参数设置成MyISAM即可：

CREATE TABLE `category` (
    `id` bigint NOT NULL AUTO_INCREMENT,
    `one_category` varchar(20) COLLATE utf8mb4_bin DEFAULT NULL,
    `two_category` varchar(20) COLLATE utf8mb4_bin DEFAULT NULL,
    `three_category` varchar(20) COLLATE utf8mb4_bin DEFAULT NULL,
    `four_category` varchar(20) COLLATE utf8mb4_bin DEFAULT NULL,
    PRIMARY KEY (`id`)
) ENGINE=MyISAM AUTO_INCREMENT=4 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin

myisam好用，但有个很致命的问题是：不支持事务。 

如果只是单表操作还好，不会出现太大的问题。但如果需要跨多张表操作，由于其不支持事务，数据极有可能会出现不完整的情况。

此外，myisam还不支持行锁和外键。

所以在实际业务场景中，myisam使用的并不多。在mysql5以后，myisam已经逐渐退出了历史的舞台，取而代之的是innodb。

有时候我们在开发的过程中，发现某张表的事务一直都没有生效，那不一定是spring事务的问题，最好确认一下你使用的那张表，是否支持事务。

未开启事务

有时候，事务没有生效的根本原因是没有开启事务。

如果你使用的是springboot项目，那么你很幸运。因为springboot通过DataSourceTransactionManagerAutoConfiguration类，已经默默的帮你开启了事务。

你所要做的事情很简单，只需要配置spring.datasource相关参数即可。

但如果你使用的还是传统的spring项目，则需要在applicationContext.xml文件中，手动配置事务相关参数。如果忘了配置，事务肯定是不会生效的。

具体配置如下信息：

<!-- 配置事务管理器 --> 
<bean class="org.springframework.jdbc.datasource.DataSourceTransactionManager" id="transactionManager"> 
    <property name="dataSource" ref="dataSource"></property> 
</bean> 
<tx:advice id="advice" transaction-manager="transactionManager"> 
    <tx:attributes> 
        <tx:method name="*" propagation="REQUIRED"/>
    </tx:attributes> 
</tx:advice> 
<!-- 用切点把事务切进去 --> 
<aop:config> 
    <aop:pointcut expression="execution(* com.susan.*.*(..))" id="pointcut"/> 
    <aop:advisor advice-ref="advice" pointcut-ref="pointcut"/> 
</aop:config> 

默默的说一句，如果在pointcut标签中的切入点匹配规则，配错了的话，有些类的事务也不会生效。 

事务不回滚

错误的传播特性

其实，我们在使用@Transactional注解时，是可以指定propagation参数的。

如果我们在手动设置propagation参数的时候，把传播特性设置错了，比如：

@Service
public class UserService {

    @Transactional(propagation = Propagation.NEVER)
    public void add(UserModel userModel) {
        saveData(userModel);
        updateData(userModel);
    }
}

我们可以看到add方法的事务传播特性定义成了Propagation.NEVER，这种类型的传播特性不支持事务，如果有事务则会抛异常。

目前只有这三种传播特性才会创建新事务：REQUIRED，REQUIRES_NEW，NESTED。

自己吞了异常

事务不会回滚，最常见的问题是：开发者在代码中手动try...catch了异常。比如：

@Slf4j
@Service
public class UserService {
    @Transactional
    public void add(UserModel userModel) {
        try {
            saveData(userModel);
            updateData(userModel);
        } catch (Exception e) {
            log.error(e.getMessage(), e);
        }
    }
}

这种情况下spring事务当然不会回滚，因为开发者自己捕获了异常，又没有手动抛出，换句话说就是把异常吞掉了。

如果想要spring事务能够正常回滚，必须抛出它能够处理的异常。如果没有抛异常，则spring认为程序是正常的。

手动抛了别的异常

即使开发者没有手动捕获异常，但如果抛的异常不正确，spring事务也不会回滚。

@Slf4j
@Service
public class UserService {

    @Transactional
    public void add(UserModel userModel) throws Exception {
        try {
            saveData(userModel);
            updateData(userModel);
        } catch (Exception e) {
            log.error(e.getMessage(), e);
            throw new Exception(e);
        }
    }
}

上面的这种情况，开发人员自己捕获了异常，又手动抛出了异常：Exception，事务同样不会回滚。

因为spring事务，默认情况下只会回滚RuntimeException（运行时异常）和Error（错误），对于普通的Exception（非运行时异常），它不会回滚。

自定义了回滚异常

在使用@Transactional注解声明事务时，有时我们想自定义回滚的异常，spring也是支持的。可以通过设置rollbackFor参数，来完成这个功能。

但如果这个参数的值设置错了，就会引出一些莫名其妙的问题，例如：

@Slf4j
@Service
public class UserService {

    @Transactional(rollbackFor = BusinessException.class)
    public void add(UserModel userModel) throws Exception {
        saveData(userModel);
        updateData(userModel);
    }
}

如果在执行上面这段代码，保存和更新数据时，程序报错了，抛了SqlException、DuplicateKeyException等异常。而BusinessException是我们自定义的异常，报错的异常不属于BusinessException，所以事务也不会回滚。

即使rollbackFor有默认值，但阿里巴巴开发者规范中，还是要求开发者重新指定该参数。

这是为什么呢？

因为如果使用默认值，一旦程序抛出了Exception，事务不会回滚，这会出现很大的bug。所以，建议一般情况下，将该参数设置成：Exception或Throwable。

嵌套事务回滚多了

public class UserService {

    @Autowired
    private UserMapper userMapper;

    @Autowired
    private RoleService roleService;

    @Transactional
    public void add(UserModel userModel) throws Exception {
        userMapper.insertUser(userModel);
        roleService.doOtherThing();
    }
}

@Service
public class RoleService {

    @Transactional(propagation = Propagation.NESTED)
    public void doOtherThing() {
        System.out.println("保存role表数据");
    }
}

这种情况使用了嵌套的内部事务，原本是希望调用roleService.doOtherThing方法时，如果出现了异常，只回滚doOtherThing方法里的内容，不回滚 userMapper.insertUser里的内容，即回滚保存点。。但事实是，insertUser也回滚了。

why?

因为doOtherThing方法出现了异常，没有手动捕获，会继续往上抛，到外层add方法的代理方法中捕获了异常。所以，这种情况是直接回滚了整个事务，不只回滚单个保存点。

怎么样才能只回滚保存点呢？

@Slf4j
@Service
public class UserService {

    @Autowired
    private UserMapper userMapper;

    @Autowired
    private RoleService roleService;

    @Transactional
    public void add(UserModel userModel) throws Exception {

        userMapper.insertUser(userModel);
        try {
            roleService.doOtherThing();
        } catch (Exception e) {
            log.error(e.getMessage(), e);
        }
    }
}

可以将内部嵌套事务放在try/catch中，并且不继续往上抛异常。这样就能保证，如果内部嵌套事务中出现异常，只回滚内部事务，而不影响外部事务。

Spring多线程事务解决方案

多线程事务场景以及解决思路

多线程事务场景举例

对批量操作进行性能优化时会用到多线程来并行处理，从而提高运行效率。而时有业务要求保证批量操作事务的一致性，但不同线程所对应的是不同的事务，这就无法通过Spring提供的注解@Transactional来保证线程间的事务一致性。这也是Spring事务失效的一种情况。

线程间不是同一个事务。

因为数据库连接Connection以及Spring事务的参数（事务名、事务是否只读、事务传播行为等）是保存在ThreadLocal中，不同的线程中保存的Connection是不同的，所以数据库层面对于不同的连接就无法满足事务。

解决思路（分布式事务2PC）

既然Spring提供的声明式事务注解@Transactional无法满足多线程间的事务一致性，那可以试试通过编程式事务的方式来解决。主要思路：每个线程都开启各自的事务，待所有线程的业务执行完成，统一提交或回滚。

我的解决方案参考分布式事务2PC（Two-phase commit protocol），中文叫二阶段提交。需要注意的是2PC是同步阻塞协议，各个线程需要等待所有的线程执行完成后才能进行下一步操作，在使用线程池执行任务时，如果线程池的最大线程数小于任务列表的数量，就会发生“死锁”，即获取到线程的任务阻塞等待没有获取线程的任务执行完成，而没有获取线程的任务会在阻塞队列中等待空闲线程的调用。这种情况需要使用一阶段的超时机制来“解开”，超时机制会发送回滚命令，线程池收到后进行回滚，但这种情况任务始终无法提交，再次提交结果依然是等到超时再回滚。在使用中需要结合具体业务来对线程池参数以及数据库连接池参数进行合理的设置。

具体的实现步骤：

  1. 我们可以在每个线程执行完成后先不提交，而是等待其他线程的执行结束。
  2. 如果某一个线程执行失败，则把标志位设为false。
  3. 判断标志位是否为true，如果是说明所有的线程都执行成功了，提交每个事务；否则回滚每个事务。

代码实现

这里封装成了一个工具类，通过方法execute(List runnableList, Executor executor)传入任务列表和线程池，我的代码实现不具备任务编排的能力，有需要可以结合CompletableFuture类自己实现一个。

/**
 * 多线程事务管理器
 * 基于分布式事务思想，采用2PC（Two-phase commit protocol）协议
 * 解决基于线程池的多线程事务一致性问题
 */
@Slf4j
public class MultiThreadingTransactionManager {

    /**
     * 事务管理器
     */
    private final PlatformTransactionManager transactionManager;

    /**
     * 超时时间
     */
    private final long timeout;

    /**
     * 时间单位
     */
    private final TimeUnit unit;

    /**
     * 一阶段门闩，(第一阶段的准备阶段)，当所有子线程准备完成时（除“提交/回滚”操作以外的工作都完成），countDownLatch的值为0
     */
    private CountDownLatch oneStageLatch = null;

    /**
     * 二阶段门闩，(第二阶段的执行执行)，主线程将不再等待子线程执行，直接判定总的任务执行失败，执行第二阶段让等待确认的线程进行回滚
     */
    private final CountDownLatch twoStageLatch = new CountDownLatch(1);

    /**
     * 是否提交事务，默认是true（当任一线程发生异常时，isSubmit会被设置为false，即回滚事务）
     */
    private final AtomicBoolean isSubmit = new AtomicBoolean(true);

    /**
     * 构造方法
     *
     * @param transactionManager 事务管理器
     * @param timeout            超时时间
     * @param unit               时间单位
     */
    public MultiThreadingTransactionManager(PlatformTransactionManager transactionManager, long timeout, TimeUnit unit) {
        this.transactionManager = transactionManager;
        this.timeout = timeout;
        this.unit = unit;
    }

    /**
     * 线程池方式执行任务，可保证线程间的事务一致性
     *
     * @param runnableList 任务列表
     * @param executor     线程池
     * @return
     */
    public boolean execute(List<Runnable> runnableList, ExecutorService executor) {

        // 排除null值
        runnableList.removeAll(Collections.singleton(null));

        // 属性初始化
        init(runnableList.size());

        // 遍历任务列表并放入线程池
        for (Runnable runnable : runnableList) {
            // 创建线程
            Thread thread = new Thread() {
                @Override
                public void run() {
                    // 如果别的线程执行失败，则该任务就不需要再执行了
                    if (!isSubmit.get()) {
                        log.info("当前子线程执行中止，因为线程事务中有子线程执行失败");
                        oneStageLatch.countDown();
                        return;
                    }
                    // 开启事务
                    TransactionStatus transactionStatus = transactionManager.getTransaction(new DefaultTransactionDefinition());
                    try {
                        // 执行业务逻辑
                        runnable.run();
                    } catch (Exception e) {
                        // 执行体发生异常，设置回滚
                        isSubmit.set(false);
                        log.error("线程{}:业务发生异常,执行体:{}", Thread.currentThread().getName(), runnable);
                    }
                    // 计数器减一
                    oneStageLatch.countDown();
                    try {
                        //等待所有线程任务完成，监控是否有异常，有则统一回滚
                        twoStageLatch.await();
                        // 根据isSubmit值判断事务是否提交，可能是子线程出现异常，也有可能是子线程执行超时
                        if (isSubmit.get()) {
                            // 提交
                            transactionManager.commit(transactionStatus);
                            log.info("线程{}:事务提交成功,执行体:{}", Thread.currentThread().getName(), runnable);
                        } else {
                            // 回滚
                            transactionManager.rollback(transactionStatus);
                            log.info("线程{}:事务回滚成功,执行体:{}", Thread.currentThread().getName(), runnable);
                        }
                    } catch (InterruptedException e) {
                        e.printStackTrace();
                    }
                }
            };
            executor.execute(thread);
        }

        /**
         * 主线程担任协调者，当第一阶段所有参与者准备完成，oneStageLatch的计数为0
         * 主线程发起第二阶段，执行阶段（提交或回滚）,根据
         */
        try {
            // 主线程等待所有线程执行完成，超时时间设置为五秒
            oneStageLatch.await(timeout, unit);
            long count = oneStageLatch.getCount();
            System.out.println("countDownLatch值：" + count);
            // 主线程等待超时，子线程可能发生长时间阻塞，死锁
            if (count > 0) {
                // 设置为回滚
                isSubmit.set(false);
                log.info("主线线程等待超时,任务即将全部回滚");
            }
            twoStageLatch.countDown();
        } catch (InterruptedException e) {
            e.printStackTrace();
        }

        // 返回结果，是否执行成功，事务提交即为执行成功，事务回滚即为执行失败
        return isSubmit.get();
    }

    /**
     * 初始化属性
     *
     * @param size 任务数量
     */
    private void init(int size) {
        oneStageLatch = new CountDownLatch(size);
    }
}

有以下两点注意：

  • 2PC是同步阻塞协议，各个任务会等待所有的任务完成准备阶段才能进一步执行，所以在使用中一定要给任务列表提供充足的空闲线程，比如任务列表长度为8，线程池最大线程数不能小于8，否则会使其中的几个任务得不到执行，而其他线程会一直进行等待。即使有一阶段超时处理，事务也始终得不到提交。
  • 如果你的任务是对数据库进行操作，需要考虑数据库连接是否充足，线程等待过程中不会释放数据库连接，如果Connection不够，即使任务被线程池调度执行，也会阻塞在获取数据库连接中，同样会发生“死锁”。

事务@Transactional与自定义环绕aop执行顺序

众所周知，spring声明式事务是基于AOP实现的，那么，如果我们在同一个方法自定义多个AOP，我们如何指定他们的执行顺序呢？

网上很多答案都是指定order，order越小越是最先执行，这种也不能算是错，但有些片面。

配置AOP执行顺序的三种方式：

1）通过实现org.springframework.core.Ordered接口

@Component 
@Aspect 
@Slf4j 
public class MessageQueueAopAspect1 implements Ordered{@Override 
    public int getOrder() { 
        // TODO Auto-generated method stub 
        return 2; 
    } 
}

2）通过注解

@Component
@Aspect
@Slf4j
@Order(1) 
public class MessageQueueAopAspect1{ 
    //... 
}

3）通过配置文件

<aop:config expose-proxy="true"> 
    <aop:aspect ref="aopBean" order="0">  
        <aop:pointcut id="testPointcut" expression="@annotation(xxx.xxx.xxx.annotation.xxx)"/>  
        <aop:around pointcut-ref="testPointcut" method="doAround" />  
    </aop:aspect>  
</aop:config>

我们在同一个方法上加以下两个AOP，看看究竟

@Component 
@Aspect 
@Slf4j 
public class MessageQueueAopAspect1 implements Ordered{ 

    @Resource(name="actionMessageProducer") 
    private IProducer<MessageQueueInfo> actionProducer;   

    @Pointcut("@annotation(com.xxx.annotation.MessageQueueRequire1)") 
    private void pointCutMethod() { 
    } 

    //声明前置通知 
    @Before("pointCutMethod()") 
    public void doBefore(JoinPoint point) { 
        log.info("MessageQueueAopAspect1:doBefore"); 
        return; 
    } 

    //声明后置通知 
    @AfterReturning(pointcut = "pointCutMethod()", returning = "returnValue") 
    public void doAfterReturning(JoinPoint point,Object returnValue) { 
        log.info("MessageQueueAopAspect1:doAfterReturning"); 
    } 

    //声明例外通知 
    @AfterThrowing(pointcut = "pointCutMethod()", throwing = "e") 
    public void doAfterThrowing(Exception e) { 
        log.info("MessageQueueAopAspect1:doAfterThrowing"); 
    } 

    //声明最终通知 
    @After("pointCutMethod()") 
    public void doAfter() { 
        log.info("MessageQueueAopAspect1:doAfter"); 
    } 

    //声明环绕通知 
    @Around("pointCutMethod()") 
    public Object doAround(ProceedingJoinPoint pjp) throws Throwable { 
        log.info("MessageQueueAopAspect1:doAround-1"); 
        Object obj = pjp.proceed(); 
        log.info("MessageQueueAopAspect1:doAround-2"); 
        return obj; 
    } 

    @Override 
    public int getOrder() { 
        return 1001; 
    } 
} 
@Component 
@Aspect 
@Slf4j 
public class MessageQueueAopAspect2 implements Ordered{ 

    @Resource(name="actionMessageProducer") 
    private IProducer<MessageQueueInfo> actionProducer;   

    @Pointcut("@annotation(com.xxx.annotation.MessageQueueRequire2)") 
    private void pointCutMethod() { 
    } 


    //声明前置通知 
    @Before("pointCutMethod()") 
    public void doBefore(JoinPoint point) { 
        log.info("MessageQueueAopAspect2:doBefore"); 
        return; 
    } 

    //声明后置通知 
    @AfterReturning(pointcut = "pointCutMethod()", returning = "returnValue") 
    public void doAfterReturning(JoinPoint point,Object returnValue) { 
        log.info("MessageQueueAopAspect2:doAfterReturning"); 
    } 

    //声明例外通知 
    @AfterThrowing(pointcut = "pointCutMethod()", throwing = "e") 
    public void doAfterThrowing(Exception e) { 
        log.info("MessageQueueAopAspect2:doAfterThrowing"); 
    } 

    //声明最终通知 
    @After("pointCutMethod()") 
    public void doAfter() { 
        log.info("MessageQueueAopAspect2:doAfter"); 
    } 

    //声明环绕通知 
    @Around("pointCutMethod()") 
    public Object doAround(ProceedingJoinPoint pjp) throws Throwable { 
        log.info("MessageQueueAopAspect2:doAround-1"); 
        Object obj = pjp.proceed(); 
        log.info("MessageQueueAopAspect2:doAround-2"); 
        return obj; 
    } 

    @Override 
    public int getOrder() { 
        return 1002; 
    } 
} 
@Transactional(propagation=Propagation.REQUIRES_NEW) 
@MessageQueueRequire1 
@MessageQueueRequire2 
public PnrPaymentErrCode bidLoan(String id){ 
    //... 
}

看看执行效果：

从上面的测试我们看到，确实是order越小越是最先执行，但更重要的是最先执行的最后结束。

这个不难理解，Spring AOP就是面向切面编程，什么是切面，画一个图来理解下：

由此得出：spring aop就是一个同心圆，要执行的方法为圆心，最外层的order最小。从最外层按照AOP1、AOP2的顺序依次执行doAround方法，doBefore方法。然后执行method方法，最后按照AOP2、AOP1的顺序依次执行doAfter、doAfterReturn方法。也就是说对多个AOP来说，先before的，一定后after。

如果我们要在同一个方法事务提交后执行自己的AOP，那么把事务的AOP order设置为2，自己的AOP order设置为1，然后在doAfterReturn里边处理自己的业务逻辑。

大事务问题

在使用spring事务时，有个让人非常头疼的问题，就是大事务问题。

通常情况下，我们会在方法上@Transactional注解，增加事务功能，比如：

@Service
public class UserService {

    @Autowired 
    private RoleService roleService;

    @Transactional
    public void add(UserModel userModel) throws Exception {
        query1();
        query2();
        query3();
        roleService.save(userModel);
        update(userModel);
    }
}

@Service
public class RoleService {

    @Autowired 
    private RoleService roleService;

    @Transactional
    public void save(UserModel userModel) throws Exception {
        query4();
        query5();
        query6();
        saveData(userModel);
    }
}

但@Transactional注解，如果被加到方法上，有个缺点就是整个方法都包含在事务当中了。

上面的这个例子中，在UserService类中，其实只有这两行才需要事务：

roleService.save(userModel);
update(userModel);

在RoleService类中，只有这一行需要事务：

saveData(userModel);

现在的这种写法，会导致所有的query方法也被包含在同一个事务当中。

如果query方法非常多，调用层级很深，而且有部分查询方法比较耗时的话，会造成整个事务非常耗时，而从造成大事务问题。

Spring事务快速上手

声明式事务

xml方式

配置事务通知，确定为哪个/哪些方法配置事务

配置事务切入，确定切入点（哪个类）

注解方式

启用事务：在xml中启用或者在配置类上添加@EnableTransactionManagement注解

<!-- 事务管理器 -->
<bean id="tracnsactionManager" class="org.springframework.jdbc.datasource.DataSourceTransactionManager">
    <property name="dataSource" ref="datasource"></property>
</bean>

<!-- 启用事务注解 -->
<tx:annotation-driven transaction-manager="tracnsactionManager"/>

在需要使用事务的方法上增加@Transactional注解，但是需要牢记事务失效的场景。

编程式事务

Spring还提供了另外一种创建事务的方式，即通过手动编写代码实现的事务，我们把这种事务叫做：编程式事务。

Spring框架提供了两种编程式事务管理方式，通过使用：

  • TransactionTemplate
  • PlatformTransactionManager

使用事务模板类TransactionTemplate和TransactionCallback事务回调类

TransactionTemplate采用了和Spring中其他模板类如JdbcTemplate类似的方式。使用回调的方式（将应用代码从必须执行样板文件获取和释放事务资源中解放出来）产生意图驱动的代码，在你的代码中你只需聚焦于做你想做的。

以下是两个示例：

public class SimpleService implements Service {

    // single TransactionTemplate shared amongst all methods in this instance
    private final TransactionTemplate transactionTemplate;

    // use constructor-injection to supply the PlatformTransactionManager
    public SimpleService(PlatformTransactionManager transactionManager) {
        this.transactionTemplate = new TransactionTemplate(transactionManager);
    }

    public Object someServiceMethod() {
        return transactionTemplate.execute(new TransactionCallback() {
            // the code in this method executes in a transactional context
            public Object doInTransaction(TransactionStatus status) {
                updateOperation1();
                return resultOfUpdateOperation2();
            }
        });
    }
}

如果没有返回值的话，可以使用TransactionCallbackWithoutResult更简洁：

transactionTemplate.execute(new TransactionCallbackWithoutResult() {
    @Override
    protected void doInTransactionWithoutResult(TransactionStatus status) {
        try {
            repayConfirm(dataSourceKey, resultDto);
        } catch (Exception e) {
            logger.error("确认还款处理数据失败:" , e);
            throw new BusinessException(e);
        }
    }
});
  • org.springframework.transaction.support.TransactionTemplate 操作事务模板类
  • org.springframework.transaction.support.TransactionCallback 事务回调，在该回调中可以编写自己的代码
  • org.springframework.transaction.support.TransactionCallbackWithoutResult Spring中自带的一个事务回调实现抽象类

事务回调中的代码可以调用TransactionStatus的 setRollbackOnly()方法回滚事务：

transactionTemplate.execute(new TransactionCallbackWithoutResult() {

    protected void doInTransactionWithoutResult(TransactionStatus status) {
        try {
            updateOperation1();
            updateOperation2();
        } catch (SomeBusinessException ex) {
            status.setRollbackOnly();//回滚事务
        }
    }
});

你可以指定TransactionTemplate的事务设置（例如传播行为、隔离级别、超时设置或者其他的设置），如：

transactionTemplate.setIsolationLevel(TransactionDefinition.ISOLATION_READ_UNCOMMITTED);
transactionTemplate.setTimeout(30); // 30 seconds

使用PlatformTransactionManager

我们也可以使用org.springframework.transaction.PlatformTransactionManager直接管理你的应用。为此，请通过bean引用将使用的PlatformTransactionManager的实现传递给bean。然后，通过使用TransactionDefinition和TransactionStatus对象，你可以初始化事务、回滚、提交。

DefaultTransactionDefinition def = new DefaultTransactionDefinition();
// 显示指定事务名称
def.setName("SomeTxName");
def.setPropagationBehavior(TransactionDefinition.PROPAGATION_REQUIRED);

TransactionStatus status = txManager.getTransaction(def);
try {
    // 执行业务逻辑代码
}
catch (MyException ex) {
    txManager.rollback(status);
    throw ex;
}
txManager.commit(status);

Spring事务监听器、事务绑定的事件

从Spring4.2开始，一个事件的监听器可以绑定到事务的各个阶段。典型的示例就是在事务成功处理完成后处理事件。

当事务结果对监听器很重要的时候，这个特点可以使得事务处理更灵活。

你可以使用@EventListener注解注册一个常规的事件监听器。如果你想将其绑定到事务中去，则使用@TransactionEventListener。默认情况下，是绑定到commit阶段的。

以下示例展示了该概念，假设组件发布了一个订单创建的事件，并且我们希望定义一个监听器，该监听器应该只在发布事件的事务提交成功后才处理该事件。

@Component
public class MyComponent{
    @TransactionalEventListener
    public void handleOrderCreatedEvent(CreationEvent<Order> creationEvent){
        //...
    }
}

@TransactionalEventListener注解暴露了一个事务阶段的属性。可以让你自定义绑定到事务的某个阶段。TransactionPhase枚举类指定了有效的事务阶段值：

  • BEFORE_COMMIT : 事务提交之前
  • AFTER_COMMIT ： 事务提交成功之后。默认值。
  • AFTER_ROLLBACK ： 事务回滚。
  • AFTER_COMPLETION : 事务完成（包含回滚、或者提交完成）。

如果没有事务运行，监听器则不会被调用，因为不能遵守所需的事务语义。但是你可以通过设置fallbackExecution属性为true来覆盖其行为。

推荐编程式事务管理

相较于@Transactional注解声明式事务，我更建议大家使用，基于TransactionTemplate的编程式事务。主要原因如下：

  1. 避免由于spring aop问题，导致事务失效的问题。
  2. 能够更小粒度的控制事务的范围，更直观。

建议在项目中少使用@Transactional注解开启事务。但并不是说一定不能用它，如果项目中有些业务逻辑比较简单，而且不经常变动，使用@Transactional注解开启事务开启事务也无妨，因为它更简单，开发效率更高，但是千万要小心事务失效的问题。