Spring事务管理：@Transactional注解深度解析与实战

丁香医生

1. Spring事务管理基础认知

在Java企业级应用开发中，事务管理是保证数据一致性的关键技术。Spring框架通过统一的事务抽象层，为开发者提供了简洁而强大的事务控制能力。我经历过多个金融级项目，深刻体会到合理使用事务对系统稳定性的重要性。

Spring事务管理主要分为两种模式：

编程式事务：通过TransactionTemplate或PlatformTransactionManager直接控制事务边界
声明式事务：通过AOP代理实现，业务代码与事务管理解耦

实际开发中，95%的场景都会选择声明式事务，因为它具有以下优势：

业务代码保持纯净，不受事务管理代码污染
通过配置即可调整事务行为，维护成本低
统一的事务管理策略，避免团队成员各自实现

重要提示：声明式事务的底层实现基于Spring AOP，这意味着只有public方法才能被事务代理拦截，这是很多新手容易踩的坑。

2. @Transactional注解深度解析

2.1 基本使用姿势

最简单的使用方式就是在方法上添加@Transactional注解：

java复制@Transactional
public void transferMoney(Long fromId, Long toId, BigDecimal amount) {
    accountMapper.debit(fromId, amount);
    accountMapper.credit(toId, amount);
}

这个转账方法会默认启用事务，如果任一SQL执行失败，整个操作都会回滚。但要注意几个关键特性：

默认只对RuntimeException和Error回滚
方法必须是public的
自调用问题（后面会详细说明）

2.2 核心属性详解

2.2.1 事务传播机制

传播行为是事务最复杂的部分，也是面试高频考点。我们通过实际案例来理解：

java复制@Service
public class OrderServiceImpl implements OrderService {
    @Autowired
    private InventoryService inventoryService;
    
    @Transactional
    public void createOrder(OrderDTO orderDTO) {
        // 主事务逻辑
        orderMapper.insert(orderDTO);
        
        // 调用库存服务
        try {
            inventoryService.deductStock(orderDTO.getSkuId(), orderDTO.getQuantity());
        } catch (BusinessException e) {
            // 库存不足不影响订单创建
            log.warn("库存不足", e);
        }
    }
}

@Service
public class InventoryServiceImpl implements InventoryService {
    @Transactional(propagation = Propagation.REQUIRES_NEW)
    public void deductStock(String skuId, int quantity) {
        // 独立事务逻辑
        inventoryMapper.reduceStock(skuId, quantity);
    }
}

这里使用了REQUIRES_NEW传播行为，使得库存扣减：

会挂起当前订单事务
开启新事务执行
执行完毕后恢复原事务

这样即使库存扣减失败，订单记录仍然可以保存，符合业务需求。

2.2.2 隔离级别选择

Spring支持标准SQL隔离级别，默认使用数据库默认级别。在MySQL中建议这样配置：

java复制@Transactional(isolation = Isolation.REPEATABLE_READ)
public void concurrentUpdate(Long id) {
    // 可重复读能防止不可重复读问题
    User user = userMapper.selectById(id);
    // ...业务处理
}

不同隔离级别的适用场景：

READ_UNCOMMITTED：几乎不用
READ_COMMITTED：Oracle默认，适合大多数OLTP
REPEATABLE_READ：MySQL默认，适合需要事务内一致读
SERIALIZABLE：性能差，特殊场景使用

2.2.3 其他重要属性

timeout：防止长事务，建议设置为3-5秒
readOnly：查询方法设置为true可优化性能
rollbackFor：指定需要回滚的业务异常
noRollbackFor：指定不需要回滚的系统异常

3. 实战中的坑与解决方案

3.1 自调用失效问题

这是最常见的问题场景：

java复制@Service
public class UserServiceImpl implements UserService {
    
    public void batchCreate(List<User> users) {
        users.forEach(this::createUser); // 自调用事务失效！
    }
    
    @Transactional
    public void createUser(User user) {
        userMapper.insert(user);
    }
}

解决方案有三种：

将事务方法拆分到另一个Service
通过ApplicationContext获取代理对象
使用AspectJ模式替代动态代理

推荐方案1，保持代码清晰：

java复制@Service
@RequiredArgsConstructor
public class UserFacadeService {
    private final UserService userService;
    
    public void batchCreate(List<User> users) {
        users.forEach(userService::createUser);
    }
}

3.2 异常处理不当

错误示范：

java复制@Transactional
public void processOrder(Order order) {
    try {
        orderMapper.insert(order);
        inventoryService.deduct(order);
    } catch (Exception e) {
        log.error("处理失败", e); // 吞掉异常导致事务不会回滚！
    }
}

正确处理方式：

java复制@Transactional(rollbackFor = Exception.class)
public void processOrder(Order order) throws BusinessException {
    try {
        orderMapper.insert(order);
        inventoryService.deduct(order);
    } catch (BusinessException e) {
        log.error("业务异常", e);
        throw e; // 重新抛出
    }
}

3.3 大事务问题

典型反模式：

java复制@Transactional
public void complexBusiness(Long id) {
    // 1. 查询数据
    List<Item> items = queryItems(id);
    
    // 2. 远程调用
    ThirdResult result = thirdPartyClient.call(items);
    
    // 3. 计算处理
    Report report = heavyCalculate(result);
    
    // 4. 保存结果
    saveReport(report);
}

优化方案：

将远程调用移出事务
拆分大方法为多个小事务
使用异步+事件驱动架构

4. 高级应用技巧

4.1 多数据源事务管理

当项目使用多个数据源时，需要特殊配置：

java复制@Configuration
public class TransactionConfig {
    @Bean
    @Primary
    public PlatformTransactionManager primaryTxManager(DataSource dataSource) {
        return new DataSourceTransactionManager(dataSource);
    }
    
    @Bean
    public PlatformTransactionManager secondaryTxManager(@Qualifier("secondaryDS") DataSource dataSource) {
        return new DataSourceTransactionManager(dataSource);
    }
}

@Service
public class CrossDatabaseService {
    @Transactional("primaryTxManager")
    public void primaryOperation() {
        // 操作主库
    }
    
    @Transactional("secondaryTxManager")
    public void secondaryOperation() {
        // 操作从库
    }
}

4.2 事务事件监听

Spring支持事务事件监听，非常有用：

java复制@Component
@RequiredArgsConstructor
public class TransactionListener {
    private final EventPublisher eventPublisher;
    
    @TransactionalEventListener(phase = TransactionPhase.AFTER_COMMIT)
    public void afterCommit(OrderCreatedEvent event) {
        // 事务提交后发送消息
        eventPublisher.publish(event);
    }
}

4.3 性能优化建议

合理设置事务超时时间
只读查询使用@Transactional(readOnly=true)
避免在事务中进行远程调用
大结果集处理考虑分页或游标
使用HikariCP等高性能连接池

5. 源码级原理剖析

理解Spring事务的实现机制有助于深度排查问题：

代理创建：通过BeanPostProcessor在初始化阶段创建代理
拦截链：MethodInterceptor链中包含TransactionInterceptor
事务管理：PlatformTransactionManager协调具体事务操作
资源绑定：TransactionSynchronizationManager管理线程绑定的资源

关键源码片段：

java复制// TransactionInterceptor核心逻辑
public Object invoke(MethodInvocation invocation) throws Throwable {
    TransactionInfo txInfo = createTransactionIfNecessary(tm, txAttr, joinpointIdentification);
    try {
        Object retVal = invocation.proceed();
        commitTransactionAfterReturning(txInfo);
        return retVal;
    } catch (Throwable ex) {
        completeTransactionAfterThrowing(txInfo, ex);
        throw ex;
    }
}

6. 最佳实践总结

经过多个项目实践，我总结出以下经验：

事务粒度：保持事务方法功能单一，避免大事务
异常处理：明确指定rollbackFor，不要吞掉异常
传播行为：理解每种传播行为的适用场景
性能考量：只读操作标记readOnly，设置合理超时
测试验证：编写集成测试验证事务行为

典型配置示例：

java复制@Transactional(
    propagation = Propagation.REQUIRED,
    isolation = Isolation.READ_COMMITTED,
    timeout = 3,
    rollbackFor = BusinessException.class,
    noRollbackFor = SystemException.class
)
public void businessOperation() {
    // 业务逻辑
}

最后提醒：事务不是银弹，分布式系统还需要考虑最终一致性方案如Saga、TCC等模式。