后端事务处理

在Java EE开发里，尤其是Spring框架大行其道的今天，事务管理基本离不开@Transactional这个注解。这玩意儿用起来是真方便，往方法上一贴，好像就万事大吉了。但这里头的坑，谁踩谁知道。先说个最基础的，这个注解加在哪儿？是类上还是方法上？我见过有兄弟图省事，直接甩在类上，结果呢，有些查询方法根本不需要事务，也跟着开了事务，平白浪费资源。所以啊，一般建议是精细点，放在具体需要事务管理的方法上。

再说说事务的传播机制（Propagation），这个可是面试常客，也是实际开发中容易迷糊的地方。默认的REQUIRED，意思是如果当前没有事务，就新建一个，如果有，就加入。这个最常用，但也得看场景。比如你在一个事务方法A里，调用了另一个事务方法B，B用的是REQUIRED，那它就会乖乖加入A的事务，共进退。但要是B用了REQUIRES_NEW，那就另起炉灶了，它会挂起A的事务，自己新开一个，这两个事务互不相干，B成功了，即使A后面失败了回滚，B也不会回滚。这个特性适合用在记录日志这种场景，日志不能因为主业务失败就不记了，对吧？

还有个REQUIRED_NEW的坑，你可得留神。它在内部方法调用时会失效！啥意思？如果你在同一个Service类里，方法A（没加@Transactional）调用了方法B（加了@Transactional(propagation = Propagation.REQUIRES_NEW)），这时候B的事务是不会生效的，它还是会跟着A在一个事务里跑。为啥？因为Spring的事务管理是基于AOP代理的，你内部调用，走的是目标对象本身，绕过了代理对象，注解自然就失效了。解决办法嘛，要么把B方法抽到另一个Service里，要么就在A方法里通过ApplicationContext自己获取代理对象再来调用B。

然后就是隔离级别（Isolation），这个主要是为了解决并发事务可能带来的脏读、不可重复读、幻读这些问题。默认用的数据库的默认级别，一般是READ_COMMITTED。大部分业务场景这个级别够用了。但有些对数据一致性要求极高的，比如金融账户余额，你可能得用到REPEATABLE_READ甚至SERIALIZABLE。不过级别越高，性能开销越大，锁竞争越激烈，所以得权衡。我之前就遇到过，一个报表统计业务，用了SERIALIZABLE，结果并发一上来直接卡死，后来降到REPEATABLE_READ，加了些业务层的乐观锁，才搞定。

回滚规则（rollbackFor）也是个要注意的地方。默认只回滚RuntimeException和Error。你要是代码里抛了个Exception，或者自定义的业务异常（继承自Exception），事务是不会回滚的！你得在注解里明确指定，比如@Transactional(rollbackFor = Exception.class)。这个坑栽进去的人可不少，代码看着没问题，异常也抛了，就是数据没回滚，排查半天才发现是这里没配置对。

最后，事务方法里尽量不要处理耗时的操作，比如发HTTP请求、读写文件、调用远程服务啥的。为啥？因为事务打开期间，数据库连接是占着的，你这些外部操作一慢，数据库连接就长时间不释放，很容易把连接池撑爆，导致整个应用卡死。这类操作，最好在事务提交之后再异步去处理。

总而言之，事务用起来简单，真想用好，得把它的脾气摸透。不同的传播行为、隔离级别，用在合适的业务场景，才能既保证数据一致性，又不至于把系统搞垮。平时写代码多留个心眼，特别是复杂业务流里，画个事务边界图，理清调用关系，能省去很多不必要的麻烦。