Spring事务注解@Transactional在多线程下的坑：一次真实踩坑记录与解决方案

Spring事务注解@Transactional在多线程下的深度解析与实战解决方案

1. 问题背景：当多线程遇上声明式事务

在分布式系统和高并发场景成为主流的今天，Java开发者对Spring框架的事务管理机制早已驾轻就熟。@Transactional注解以其声明式的简洁性，成为大多数业务方法的首选事务管理方式。然而，当这个看似简单的注解遇到多线程环境时，却可能引发一系列令人费解的行为。

最近在一个任务调度系统中，我们遇到了一个典型场景：用户提交任务后可以随时取消，取消操作需要完成状态更新、记录删除和消息通知三个步骤。为了保证数据一致性，我们自然地为cancel方法添加了@Transactional注解。测试时发现，在特定时间窗口内取消任务会导致重复通知——这正是多线程与事务机制交互产生的典型问题。

核心矛盾点在于：

• 事务的提交发生在方法执行完成后
• 锁的释放也发生在方法执行完成后
• 但在这两个"完成后"之间存在微妙的时序关系

@Transactional
public synchronized void cancelTask(Long taskId) {
    Task task = taskRepository.findById(taskId);
    if (task != null) {
        updateStatus(task);
        taskRepository.delete(task);
        notifyService.sendCancellation(task.getUserId());
    }
}

2. 问题本质：事务提交与锁释放的竞态条件

2.1 事务的幕后工作机制

Spring的声明式事务基于AOP实现，其执行流程可以简化为：

1. 方法调用前：开启事务
2. 方法执行中：业务逻辑运行
3. 方法返回后：提交事务
4. 方法异常时：回滚事务

这个流程在单线程环境下完美运作，但在高并发场景下就可能出现问题。关键在于：锁的释放和事务的提交虽然都发生在方法执行完成后，但它们的顺序并不确定。

2.2 典型问题场景重现

假设两个线程A和B几乎同时调用cancelTask方法：

1. 线程A获取锁，开始执行方法
2. 线程A完成所有数据库操作，但事务尚未提交
3. 线程A释放锁
4. 线程B立即获取锁，查询数据库
5. 由于线程A的事务未提交，线程B仍能看到被删除的记录
6. 线程B也执行删除和通知操作
7. 最终两个事务先后提交，导致重复操作

时间线对比：