生产事故：报销系统的"幽灵提交"

2024年末的一个雪夜，某公司报销平台突然瘫痪。客服反馈：创建报销单时系统频繁提示"数据异常"，但重启服务后又恢复正常。技术团队紧急排查日志发现，Redis的自增操作返回了null值，导致分布式ID生成失败。根源直指@Transactional注解的错误使用——开发人员将事务注解标注在了private方法上，导致事务"裸奔"，最终引发数据库连接池耗尽。

案例来源：CSDN博客《什么?Spring官方推荐的@Transational还能导致生产事故?》

为什么private方法上的@Transactional会失效？

动态代理的"视力盲区"

Spring事务的实现依赖AOP动态代理，而private方法就像"密室里的悄悄话"，代理对象根本"听不见"。

代理流程解析：

1. 客户端调用orderService.createOrder()时，实际访问的是Spring生成的代理对象
2. 代理对象先开启事务，再调用目标对象的真实方法
3. private方法直接通过this调用，完全绕过代理对象

JDK与CGLIB的双重验证

Spring会根据目标类是否实现接口选择代理方式，但两种方式都无法代理private方法：

• JDK动态代理：只能代理接口方法，private方法不在接口中定义
• CGLIB代理：通过继承生成子类，但无法重写private方法

事务失效的五大"陷阱"与解决方案

陷阱一：方法访问权限问题

// 错误示例
@Service
public class UserService {
    @Transactional
    private void createUser(User user) { // private方法事务失效
        userMapper.insert(user);
    }
}

// 正确示例
@Service
public class UserService {
    @Transactional
    public void createUser(User user) { // public方法事务生效
        userMapper.insert(user);
    }
}

陷阱二：自调用导致代理失效

// 错误示例
@Service
public class OrderService {
    public void processOrder(Order order) {
        this.createOrder(order); // 自调用不经过代理
    }
    
    @Transactional
    public void createOrder(Order order) {
        orderMapper.insert(order);
    }
}

// 正确示例
@Service
public class OrderService {
    @Autowired
    private OrderService selfProxy; // 注入自身代理对象
    
    public void processOrder(Order order) {
        selfProxy.createOrder(order); // 通过代理调用
    }
    
    @Transactional
    public void createOrder(Order order) {
        orderMapper.insert(order);
    }
}

陷阱三：异常类型不匹配

Spring默认只回滚RuntimeException及其子类，需通过rollbackFor属性显式指定受检异常：

@Transactional(rollbackFor = Exception.class) // 捕获所有异常回滚
public void transferMoney(Account from, Account to, BigDecimal amount) throws IOException {
    from.deduct(amount);
    to.add(amount);
    throw new IOException("网络异常"); // 此时事务会回滚
}

陷阱四：传播行为配置不当

常见传播行为对比：

陷阱五：数据库引擎不支持事务

确保MySQL表使用InnoDB引擎：

-- 正确配置
CREATE TABLE `user` (
  `id` bigint NOT NULL AUTO_INCREMENT,
  `name` varchar(255) DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

事务传播行为实战分析

以订单创建和日志记录为例，不同传播行为的执行结果：

场景模拟：

@Service
public class OrderService {
    @Autowired private LogService logService;
    
    @Transactional // REQUIRED(默认)
    public void createOrder(Order order) {
        orderMapper.insert(order);
        logService.recordLog(order.getId()); // 调用REQUIRES_NEW方法
    }
}

@Service
public class LogService {
    @Transactional(propagation = Propagation.REQUIRES_NEW)
    public void recordLog(Long orderId) {
        logMapper.insert(new Log(orderId, "订单创建成功"));
    }
}

执行结果：

• 订单创建失败时，订单数据回滚
• 日志记录独立提交，不受订单事务影响

最佳实践与性能优化

1. 控制事务粒度：只在必要方法上添加@Transactional，避免长事务
2. 合理设置传播行为：日志、审计等操作使用REQUIRES_NEW
3. 手动控制事务：复杂场景使用TransactionTemplate

// 编程式事务控制
transactionTemplate.execute(status -> {
    try {
        // 业务逻辑
        return true;
    } catch (Exception e) {
        status.setRollbackOnly();
        return false;
    }
});

4. 监控事务状态：通过TransactionSynchronizationManager查看当前事务信息

总结

Spring事务失效问题本质是对AOP代理机制的理解不足。开发中需牢记：

• @Transactional仅对public方法生效
• 避免同一类中自调用事务方法
• 显式指定rollbackFor属性
• 根据业务场景选择合适的传播行为

通过本文介绍的原理分析和实战案例，希望能帮助开发者避开事务管理的"雷区"，构建更健壮的分布式系统。