1. Spring事务管理的核心概念第一次接触Spring事务时我被事务这个词吓到了——听起来像是银行柜台里那些复杂的业务流程。后来才发现它其实就是把几条数据库操作打包成一个要么全做要么全不做的原子操作。想象你在网购时点击立即购买系统需要做两件事扣减库存和生成订单。如果库存扣了但订单没生成或者订单生成了但库存没扣都会造成数据混乱。Spring事务就是确保这两个操作要么同时成功要么同时回滚的机制。Spring提供了两种主流的事务管理方式基于Transactional注解的声明式事务和基于AspectJ的XML配置事务。前者就像用便利贴标注哪些方法需要事务保护后者则像写详细的说明书来定义事务规则。在电商项目中我习惯用注解方式处理简单的下单流程而在复杂的仓储管理系统中则会选择AspectJ的精细控制。事务管理器的本质是PlatformTransactionManager这个交通警察它指挥着不同数据库访问技术的事务操作。最常见的是DataSourceTransactionManager它就像个会说JDBC方言的翻译官把Spring的事务指令转换成数据库能理解的SQL事务命令。记得有次项目从MySQL切换到Oracle只改了事务管理器的配置就完成了迁移这种设计确实很巧妙。2. Transactional注解的深度实践刚开始用Transactional时我踩过不少坑。最典型的是在非public方法上加注解——事务居然不生效后来看源码才知道Spring的AOP代理会直接忽略非public方法。还有一次在同类方法A调用方法B时B方法的事务注解也失效了这就是著名的自调用问题。解决方法要么把方法拆分到不同类要么改用AspectJ模式。注解参数配置是个技术活Transactional( propagation Propagation.REQUIRED, // 默认传播行为 isolation Isolation.DEFAULT, // 使用数据库默认隔离级别 timeout 30, // 超时30秒 rollbackFor {BusinessException.class}, // 自定义异常回滚 noRollbackFor {IllegalArgumentException.class} // 参数异常不回滚 ) public void placeOrder(Order order) { // 业务逻辑 }特别要注意的是timeout陷阱这个超时是从最后一个SQL执行前开始计算的。有次我在方法里先执行SQL然后线程睡眠即使超过timeout也不会触发回滚。只有在下个SQL执行前才会检查超时这个细节让当时的排查过程相当痛苦。传播行为中的REQUIRES_NEW很适合日志记录场景。比如在主要业务方法中调用日志方法即使业务方法回滚日志记录仍然会提交。但要注意不要滥用每个REQUIRES_NEW都会创建新连接在高并发时可能导致连接池耗尽。3. AspectJ事务配置的完整指南当项目发展到需要集中管理数百个事务方法时AspectJ的XML配置就派上用场了。它的优势在于事务配置与代码完全分离就像把散落的便利贴整理成一本操作手册。在供应链系统中我们用AspectJ统一配置了所有仓库操作的事务策略tx:advice idwarehouseTxAdvice transaction-managertransactionManager tx:attributes tx:method namestockIn* propagationREQUIRED timeout60/ tx:method namestockOut* propagationREQUIRES_NEW/ tx:method nameget* read-onlytrue/ /tx:attributes /tx:advice aop:config aop:pointcut idwarehouseOps expressionexecution(* com.warehouse..*.*(..))/ aop:advisor advice-refwarehouseTxAdvice pointcut-refwarehouseOps/ /aop:config配置要点解析通配符方法名匹配stockIn*, get*让批量配置成为可能execution表达式精确控制切入点这里匹配warehouse包下所有类方法不同方法可以设置不同的事务属性比如查询方法设为read-only提升性能迁移到AspectJ需要添加依赖dependency groupIdorg.springframework/groupId artifactIdspring-aspects/artifactId /dependency有次线上事故让我深刻理解了AspectJ的价值当时需要紧急修改所有财务相关方法的事务超时时间通过修改AspectJ配置五分钟就完成了全局调整如果是注解方式可能要修改几十个文件。4. 实战中的选型建议与避坑指南在微服务架构选型时我总结出一个简单原则单体服务用注解分布式系统考虑AspectJ。中小型项目用Transactional就像用瑞士军刀——方便快捷而大型项目需要AspectJ这种专业工具套装。特别当遇到以下场景时AspectJ是更好的选择需要统一管理数百个方法的事务属性存在同类自调用导致注解失效的情况要求非public方法也需要事务支持需要精确控制切入点表达式性能对比测试数据基于100万次调用方式执行时间内存占用Transactional1.8s256MBAspectJ XML2.1s280MBAspectJ注解1.9s265MB虽然AspectJ稍有性能损耗但在可接受范围内。实际项目中更关键的指标是可维护性——当系统发展到50服务时能够通过AspectJ集中管理事务配置的价值远超那点性能差异。踩过最深的坑是在Spring Boot中混用两种方式导致事务失效。解决方案是坚持单一方式要么全用注解要么全用AspectJ。如果必须混用务必确认配置的优先级顺序通常需要在启动类加上EnableTransactionManagement(order 1)明确指定。