我这些年排过不少线上数据问题其中有相当一批都指向同一个现象spring事务管理里同一个Service类中非事务方法调用事务方法结果那个Transactional就像被注释掉了一样异常抛了数据却照样进了库。最典型的场景是某订单模块里在一个非事务的orderHandle()方法里直接调用了本类的updateStock()方法后者标了Transactional(rollbackFor Exception.class)可并发一上来库存扣成负数、流水重复落账查日志发现事务管理器压根没参与。要解决这种事务失效问题核心思路就一句话让事务方法从代理对象上被调用而不是从this上被调用。本篇就给3种成熟的解决方法每种都会写清原理、实现和踩坑点顺带把同类问题的一整套排查方法也整理出来。适合对Spring有一定掌握、正在写业务代码或维护老系统的开发同学。如果你只是刚接触事务前面的原理部分也能帮你建立整体认识。1. 事务为什么会失效先弄懂代理机制后面才不踩坑1.1 事务注解是靠“代理对象”生效的Spring的事务管理不是直接改你那个方法字节码而是基于AOP。Spring容器启动时会为标注了事务注解的Bean生成一个代理对象。你从容器里拿到的实际上是这个代理而不是你写的那个类的原始实例。外部代码调用时调用关系大概是这样的外部对象持有的是代理Bean调用进入代理代理触发TransactionInterceptor拦截器在方法执行前开启事务在方法返回或抛异常时提交/回滚真正的方法体才被执行。也就是说Transactional要生效有一个隐藏前提调用必须从代理对象入口进去。1.2 为什么同一个类里直接调用就失效问题恰恰出在“直接从代理入口进去”这步。同一个Service类内部非事务方法调用本类事务方法时代码里写的其实是this.transactionMethod()。this是当前实例是原始对象不是Spring生成的代理。调用直接落在原始对象的方法上跳过了代理TransactionInterceptor根本没机会介入事务自然就不存在。我用个前台类比公司前台值班人员看到所有外部来访都登记但内部员工串门是不需要经过前台的内部互相招呼一声就行。Spring的代理就是那个前台外部调用是来访者必然过前台、有登记开事务而同类的this调用是内部串门直接把人放过去了。很多同学在事务方法里打日志、加断点发现方法确实执行了但事务就是没开。原因很简单——执行者就不是代理对象。1.3 类内部调用的几种变形本质都一样实际代码里“失效”往往有很多变体先列出来对号入座非事务方法直接调用本类事务方法事务方法A调用本类事务方法BB的事务失效A的事务还在但B的回滚边界不独立通过this调用加了Transactional也没有用方法被private或final修饰代理无法增强也会失效事务方法内try-catch吞掉异常事务感知不到失败也会失效。我见过很多人前脚刚解决了“一个类里调用失效”后脚又摔在“事务方法内部自己调自己”上。核心就一个Spring代理只能在外部调用时帮忙内部调用挡不住。2. 方法一注入自身代理让非事务方法改调代理对象2.1 最直接的做法AutowiredLazy既然失效原因是this调用第一个解法非常直观别用this用Spring容器里那个代理“自己”。在类里注入一个当前类型的Bean然后非事务方法通过这个注入的Bean去调事务方法Service public class OrderService { Autowired Lazy private OrderService self; public void handleOrder(String orderId) { // 业务逻辑 self.updateStock(orderId); // 走代理事务生效 } Transactional(rollbackFor Exception.class) public void updateStock(String orderId) { // 扣库存、写流水 } }这里有两个细节值得展开。第一个是为什么加Lazy。Spring在初始化OrderService时需要先构造原始对象赋值self字段。但self的类型是同一个类它的依赖还需要完整的、带事务增强的代理对象。如果不加Lazy会出现Bean创建阶段的循环依赖原始对象还没生成完就要注入这个类的代理代理又依赖原始对象构造。加了Lazy后Spring先注入一个延迟代理占位等真正调用self.updateStock()时才去容器里拿完整代理循环依赖问题直接绕开。第二个是必须用self不能再写this。很多同事改成了Autowired private OrderService self;但调用处仍然写this.updateStock()等于白改。记住凡是调用事务方法一律从self上走。2.2 更稳的变体构造器注入 ObjectProvider有人说字段注入不够优雅代码规范要求用构造器注入。那就在构造器上处理Service public class OrderService { private final OrderService self; public OrderService(Lazy OrderService self) { this.self self; } public void handleOrder(String orderId) { self.updateStock(orderId); } Transactional(rollbackFor Exception.class) public void updateStock(String orderId) { // 事务逻辑 } }Lazy放在构造器参数上效果和字段注入版本一致但避免了Autowired字段注入的坏味道测试类构造时也方便。如果你不想在构造器里处理还有一种做法是用ObjectProvider延迟获取Service public class OrderService { private final ObjectProviderOrderService selfProvider; public OrderService(ObjectProviderOrderService selfProvider) { this.selfProvider selfProvider; } public void handleOrder(String orderId) { OrderService proxy selfProvider.getObject(); proxy.updateStock(orderId); } }ObjectProvider注入进来时不会立即创建完整代理调用getObject()才拿Bean。平时业务方法里不需要频繁拿这个方案性能开销也可以忽略。2.3 这个方案的坑代理没生成时调用会怎样加了Autowired Lazy之后如果事务方法所在的类因为某种原因没有生成代理self注入进来的还是原始对象。那用了self也照样失效。所以写完要验证代理对象确实存在验证方法我放到第6章统一讲。这里先记结论只要这个Service被Spring管理、事务注解写在了public方法上、事务功能开启EnableTransactionManagementself拿到的就是CGLIB代理。我自己在实际项目里最常用的是Lazy 构造器注入那一版改动量最小对原有代码结构几乎零冲击新老项目都能直接上。3. 方法二从容器中取代理 Bean想怎么调都行3.1ApplicationContext手动取Bean第二种思路是既然拦截器只对代理对象生效那就主动从Spring容器里把当前类的代理Bean取出来再调用事务方法。Service public class OrderService { Autowired private ApplicationContext applicationContext; public void handleOrder(String orderId) { OrderService proxy applicationContext.getBean(OrderService.class); proxy.updateStock(orderId); } Transactional(rollbackFor Exception.class) public void updateStock(String orderId) { // 事务逻辑 } }这段代码的效果和方法一是等价的区别在于我们不依赖“自我注入”的特殊处理而是显式地向容器查询Bean。这么写有一个额外好处你可以灵活选择从哪个容器Bean上取。如果项目里有AOP增强、多数据源切换、灰度逻辑等方法内部还能根据上下文去applicationContext里按名称取特定代理比如getBean(orderService)。缺点是类里多了一个ApplicationContext依赖耦合了Spring容器。我见过一个架构比较乱的老项目一个Service里注入ApplicationContext已经是常态那用这个方案反而能统一风格。但从代码整洁度看ApplicationContext这种全局容器对象能少注入就少注入。3.2ObjectProvider从容器取Bean的优雅写法如果觉得每调一次就getBean有点重可以考虑用ObjectProvider这是Spring 4.3以后提供的能力专门用来延迟获取BeanService public class OrderService { private final ObjectProviderOrderService selfProvider; public OrderService(ObjectProviderOrderService selfProvider) { this.selfProvider selfProvider; } public void handleOrder(String orderId) { selfProvider.getObject().updateStock(orderId); } }ObjectProvider本身在OrderService初始化时就会被注入但它并不立刻触发目标代理的创建调用getObject()时才从容器里拿。相比原生ApplicationContext它把“获取Bean”这件事收窄到了当前Service自身耦合度低了不少也方便测试时mock。3.3 注意点别图省事自己new一个实例出来这个方案最大的坑是有人在方法里写了这样的代码OrderService service new OrderService(); service.updateStock(orderId);这种写法等于手动绕过了Spring容器new出来的对象完全脱离Spring管理Transactional必然失效连AOP都碰不到。排查时看到这种代码直接改掉就好。无论是用ApplicationContext.getBean()还是ObjectProvider拿到的都是Spring容器接管后的代理对象。判断标准只有一个这个对象是不是容器给的。自己new的永远不具备事务能力。4. 方法三AopContext.currentProxy()原地获取当前代理4.1 先打开exposeProxy开关第三种方案是Spring专门为内部调用准备的AopContext.currentProxy()。它的原理是在代理执行方法时把“当前正在执行代理”保存到一个ThreadLocal里。这样即使方法内部写的是this调用我们也可以从AopContext这个上下文中取出当前代理再通过代理去调用事务方法。这个功能默认是关闭的因为ThreadLocal本身有性能开销和线程管理负担。要先在配置类上显式开启Configuration EnableTransactionManagement EnableAspectJAutoProxy(exposeProxy true) public class AppConfig { }如果你用的是Spring Boot又不想写Configuration类也可以在启动类上直接加EnableAspectJAutoProxy(exposeProxy true)。XML老项目则是在aop:aspectj-autoproxy expose-proxytrue/里配置。4.2 调用代码长这样开启开关后在非事务方法里这样写Service public class OrderService { public void handleOrder(String orderId) { OrderService currentProxy (OrderService) AopContext.currentProxy(); currentProxy.updateStock(orderId); } Transactional(rollbackFor Exception.class) public void updateStock(String orderId) { // 事务逻辑 } }AopContext.currentProxy()返回的是当前代理对象把它强转成OrderService再调用updateStock()事务管理器就会按要求介入。这个方案看起来最“优雅”——不用额外注入self也不用往容器里查来查去调用点上一行搞定。4.3 这个方案的边界条件必须记清楚第一exposeProxy开关没打开时调用AopContext.currentProxy()会抛异常Cannot find current proxy。遇到这个报错优先去查配置有没有开。第二AopContext.currentProxy()只能在工作线程中调用。如果你把事务方法提交到异步线程池、Async方法里再调用ThreadLocal里的代理对象在线程切换后就找不到了一样会抛异常或拿到null。第三强转类型要注意代理类型。默认CGLIB代理下currentProxy()强转成自己的Service类是没问题的如果是JDK动态代理比如某个类实现了接口强转成实现类可能失败要强转成接口类型。不过Spring Boot默认proxyTargetClass true绝大多数场景是CGLIB实务中这个问题出现不多但最好心里有数。这个方案性能上略低于直接注入self因为每次调用都要走一次ThreadLocal读取。在极端的低延迟场景建议优先用方法一。我会在章节末尾放一个对比表方便你按团队情况选。5. 另外两条更干脆的路拆类和编程式事务标题承诺了3种方法前面三个属于“同一个Service类里做文章”。但做技术方案选型时我还想多给你两条路因为在实际项目里它们往往比前三种更省事、更抗造。5.1 拆成两个Service从结构上根治如果允许微调类结构最彻底的办法就是把事务方法拆到另一个Service类里Service public class OrderService { private final OrderTxService orderTxService; public OrderService(OrderTxService orderTxService) { this.orderTxService orderTxService; } public void handleOrder(String orderId) { // 非事务业务逻辑 orderTxService.updateStock(orderId); } }Service public class OrderTxService { Transactional(rollbackFor Exception.class) public void updateStock(String orderId) { // 扣库存、写流水 } }跨类调用天然经过代理事务一定生效不存在this绕过的问题。而且职责边界更清晰负责事务的、很重的一些写操作集中到一个事务Service里非事务逻辑留在原Service。缺点是会多一个类、多一层调用项目偏小的时候会显得有点重。如果代码重构负担不大我个人强烈推荐优先考虑这个方案。它不靠任何“技巧”是从设计上消灭了失效的可能。5.2 编程式事务TransactionTemplate完全绕开代理还有一种做法是绕开注解事务直接使用编程式事务。TransactionTemplate不需要代理介入你告诉它“这段逻辑就是一个事务”它就给你开一个。不会有自调用问题也不会在private、final方法上翻车。Service public class OrderService { private final TransactionTemplate transactionTemplate; public OrderService(TransactionTemplate transactionTemplate) { this.transactionTemplate transactionTemplate; } public void handleOrder(String orderId) { transactionTemplate.executeWithoutResult(status - { // 扣库存 // 写流水 }); } }优点是绝对可靠不依赖AOP开没开、代理存不存在缺点是事务边界没那么优雅回调里的代码量大时缩进层级很深可读性一般。另外编程式事务的连接绑定、回滚规则都需要自己管理对事务原理不熟的话容易埋坑。我的经验是小范围、局部需要事务的方法用TransactionTemplate完全够但大面积业务都要事务拆类或注解代理方案维护起来更舒服。5.3 三种方案横向对比方案实现成本侵入性是否依赖代理推荐场景坑点自注入代理(Lazy)低低依赖但正常可满足老项目快速修复必须加Lazy注意调用对象容器取Bean低中依赖项目已有ApplicationContext不要new注意容器类型AopContext.currentProxy()低低依赖且必须exposeProxytrue调用点分散、不想改字段线程切换失效、开关忘开如果让我给一个选型次序新项目优先拆类老代码急于修复优先自注入代理既有事务边界又不想动类结构的用AopContext真正要死磕可靠性的用编程式事务。6. 自调用之外的常见失效原因排查解决自调用问题之后很多人以为万事大吉结果事务还是没生效。这里单独整理一个排查清单我曾经靠这几条帮项目组解决过好几个“假失效”问题。6.1 一次性排查清单序号检查项说明1类是否被Spring管理是否标了Service/Component组件扫描是否覆盖2事务方法是否publicprivate方法AOP增强不了事务失效3是否final方法CGLIB不能覆写final方法4事务开关是否开启是否有EnableTransactionManagement5数据源事务管理器是否配置多数据源场景要指定transactionManager6调用入口是否是代理自调用、new对象、静态方法调用都是雷区7异常是否正常向上抛try-catch吞异常后事务不会回滚8回滚规则是否符合预期默认只对RuntimeException和Error回滚这8条里第6条就是本文核心第7和第8条在业务代码里出现频率也极高。6.2 怎么确认当前调用的是代理对象排查时最想确认的就是“当前实例到底是不是代理”。在非事务方法里加一行临时日志log.info(class name {}, this.getClass().getName());如果输出里带了$$SpringCGLIB$$、EnhancerBySpringCGLIB之类的字样说明当前对象已经是代理事务应该能生效。如果输出的就是com.example.OrderService这种原始类名基本可以断定是代理被绕过了。更稳妥的办法是借助Spring提供的判断工具boolean isAopProxy AopUtils.isAopProxy(this);再配合断点观察或者调用AopUtils.getTargetClass(this)查看目标类型都很直观。这个方法在调试自调用问题时特别管用能直接区分是“代理生成问题”还是“调用入口问题”。6.3 异常被吞掉的回滚陷阱有一种极其隐蔽的失效事务方法内部自己处理了异常。Transactional(rollbackFor Exception.class) public void updateStock(String orderId) { try { // 扣库存 } catch (Exception e) { log.error(扣库存失败, e); // 没有往外抛 } // 后续继续执行 }事务拦截器判断回滚的依据是“方法是否抛出指定异常”。你在方法内部把异常吃了框架根本看不到异常它认为方法正常返回于是提交事务。数据照常写进去日志里却能看到一条error级别的扣库存失败这种问题排查起来很迷惑。正确做法有两种要么不捕获让异常自然抛出去要么捕获记录后重新抛出throw new RuntimeException(e)或者显式调用TransactionAspectSupport.currentTransactionStatus().setRollbackOnly()标记回滚。我实际处理过一个线上案例一个批量导入功能事务方法循环处理每一条数据单条失败时被catch后打了日志最后整个事务提交了导入文件里一半好数据一半坏数据全被写了进去。改法就是catch中重新抛出业务异常事务立刻回归正常。写在最后的一点心得这些事务失效技巧说到底都在处理同一个问题Spring事务是基于代理的代理只对外部调用生效。只要把这个底层机制刻在脑子里遇到Transactional不生效你会比其他同事更快定位到调用链路上而不是一头扎进配置里瞎试。我在实际项目里的常规操作是修复时先用自注入代理那一版快速止血然后在代码评审或重构阶段把它往“拆类”方向收敛。既要短期解决问题又不让这种“自我调用代理”的模式在代码库里到处开花否则以后维护的人看到一堆self.xxx()还是得回头啃一遍AOP原理。最后再分享一个小技巧写完事务相关代码别只看单测通过最好在测试环境构造一个并发场景两端同时扣一个相同库存数据对不上就说明事务根本没生效。很多事务问题在低并发下是一点看不出来的但线上流量一来立刻原形毕露。