绕过AOP代理的深层原理与解决方案)
“线上上了个单据审核接口第一次调就发现事务没生效回滚没执行脏数据都进去了。排查了好半天才发现问题根本不在数据库配置而是出在一个特别基础但又特别容易踩的坑Spring 事务在自调用场景下失效。”这是我最近处理的一个支付类核心模块的真实经历。项目的代号叫 JoyAI里面有个订单创建服务代码里一个方法调用另一个带事务注解的方法用this.method()写的。当时第一反应是数据源没配对后来脑子里过了一遍 Spring AOP 代理的原理才意识到this.method()调用的是目标对象自身的方法根本不会经过 AOP 代理事务切面自然就插不上手。这个问题非常适合所有在 Spring 生态里写业务代码的朋友参考尤其是用了Transactional但一直没深究过它到底是怎么生效的人。这篇文章我想把整个排查过程、底层原理、实测验证和最后采用的解决方案完整写出来顺便帮大家梳理清楚什么情况下事务会失效、为什么this.method()会绕过代理、以及有哪些稳妥的修复手段。1. 问题复盘从一次线上数据异常说起先说项目背景。JoyAI 这套系统里我负责一个对账模块负责从第三方接口拉取结算数据然后批量写入本地库。写入过程需要保证“要么全部成功要么全部回滚”所以很自然地在外层加上了Transactional。线上第一次跑完发现明细表和汇总表的数据对不上少了好几条但程序没报任何异常。这不对劲因为代码逻辑里如果某条数据校验失败会直接抛出RuntimeException理论上整个批次都应该回滚才对。可实际情况是部分数据写进去了部分没有出现了“半截事务”的典型现场。1.1 现象日志里没有任何回滚痕迹第一件事就是看日志。正常情况下事务回滚时Spring 会打印类似Rolling back transaction或Initiating transaction commit这类逻辑但我翻遍了本批次日志发现连Creating new transaction都没有出现过也没有任何事务管理器的参与记录。再仔细看调用链发现负责写入明细的方法是被同一个类的内部方法调用过来的用的还是最朴素的this.insertDetail()写法。看到这里我心里已经大概有数了但还是决定把理论再验证一遍再动手改。顺带提一嘴排查这类问题有一个好习惯先确认异常有没有被吞掉再确认事务管理器有没有参与最后才是检查代理有没有生效。日志顺序往往能告诉你一切。1.2 初步怀疑把锅甩给数据源配置按照常规排查思路事务不生效最容易被怀疑的就是数据源没配置好或者EnableTransactionManagement没加。于是我先检查了启动类确认EnableTransactionManagement存在数据库连接池配置也正常事务管理器明确指向了主数据源。排除掉这一层之后才把目光放回到调用方式上。这里有个小经验分享遇到事务失效最好先在心里过一遍“三步曲”——配置对不对、异常类型对不对、调用链路有没有经过代理。绝大多数事务失效问题都逃不出这三类原因而自调用就属于典型的第三种。1.3 定位this.method()是问题核心定位到具体代码时看到的结构大概是这样的Service public class SettleOrderService { public void batchCreate(ListOrderDTO orders) { for (OrderDTO order : orders) { this.createSingle(order); } } Transactional(rollbackFor Exception.class) public void createSingle(OrderDTO order) { // 写主表 // 写明细表 // 校验不通过则抛异常 } }batchCreate内部循环调用了this.createSingle()而createSingle上面的Transactional注解并没有生效。原因就是 Spring 的事务功能是通过 AOP 代理实现的this拿到的是原始对象不是代理对象。只有从外部容器里获取到的 Bean或者通过Autowired注入到其他类里的 Bean才是被切面包裹后的代理对象。这一步确认之后问题定位就算完成了。接下来需要对 Spring 的代理机制做深入分析把“为什么自调用会绕过代理”这个问题彻底讲透。2. 深入原理Spring AOP 代理与事务生效的前提条件要用大白话解释清楚自调用为什么会失效得先搞清楚 Spring 创建 Bean 的时候到底做了什么。默认情况下Spring 容器中存放的并不是你写的那个普通业务对象而是一个代理对象。这个代理对象会“包裹”原始对象在方法调用前、后插入额外逻辑。当容器把一个 bean 注入到另一个 bean 中时注入的其实是代理对象。所以外部调用带Transactional的方法时实际上是先走代理再走到原始方法。事务就是在这个“额外逻辑”里开启和提交回滚的。2.1 JDK 动态代理与 CGLIB 的区别Spring 的代理机制有两种实现方式代理方式适用条件特点JDK 动态代理目标类实现了至少一个接口基于接口代理生成代理类实现相同接口CGLIB 代理目标类未实现接口或配置强制使用生成目标类的子类重写非 final 方法在 JoyAI 项目里SettleOrderService是纯类没有实现任何接口所以 Spring 默认会用 CGLIB 生成一个子类代理。这个代理子类重写了createSingle()方法在方法前后挂载事务拦截器。你可以把this理解成“站在对象内部看自己”它指向的是那个未经过任何包装的原始实例。而外部持有的 bean 引用指向的是 CGLIB 生成的子类两者根本不是同一个对象。用this调用方法等于绕过了代理子类直接执行原始逻辑事务拦截器完全不会被触发。2.2 为什么外部调用和内部调用行为完全不同为了让自己彻底理解我做了一个极简的类比假设你请了一个助理代理对象所有外部访客都必须经过助理登记才能见到你。但你自己早上出门时难道还要助理给你自己登记一遍吗this.method()就是这个道理你自己调用自己根本不会找助理。Spring 容器中的 Bean 相当于“你本人 助理”的合体外部依赖注入的是助理这个角色但从类内部看this永远都只代表你本人。所以即使createSingle()标注了Transactional在没有代理的环境下直接调用它就是一个普普通通的原生方法。2.3 验证如何确认目标对象确实被代理了我写了一段验证代码来确认自己的判断Autowired private SettleOrderService orderService; public void checkProxy() { System.out.println(orderService.getClass().getName()); // 输出类似: com.xxx.SettleOrderService$$EnhancerBySpringCGLIB$$abc123 System.out.println(orderService instanceof SettleOrderService); // 输出: true因为 CGLIB 子类属于 SettleOrderService 类型 }如果类名里带着$$EnhancerBySpringCGLIB$$就说明容器里装的确实是代理对象。外部通过orderService.createSingle()调用时走的确实是代理方法Transactional才能生效。反之在类内部用this.createSingle()调用时this指向的类名应该就是原始的SettleOrderService没有增强痕迹问题一目了然。这里补充一个知识点如果项目使用了EnableTransactionManagement但类本身没有接口Spring 会优先选择 CGLIB。而如果配置了proxyTargetClass false且类没有接口就无法生成代理事务同样会静默失效。这类配置问题比自调用还要隐蔽我建议大家在项目初始化时先加一个代理状况检查。3. 事务切面的完整原理拆解Transactional 到底在什么时机起作用搞懂了代理机制还需要再进一步理解事务切面本身的执行流程这样你才能在设计接口时主动避开各种坑。3.1 TransactionInterceptor 的工作流程在 Spring 中真正干活的事务切面是TransactionInterceptor。它实现了 AOP 的方法拦截逻辑核心流程大致是这样检查当前方法是否配置了事务属性。检查当前线程是否已经存在活动事务如果没有就创建一个新的。执行业务方法。如果方法正常返回则提交事务。如果方法抛出异常则根据rollbackFor配置决定是否回滚。这整个流程都是在代理方法中完成的。也就是说业务方法只是被“包裹”的中间环节事务的开启和结束完全由代理控制。如果this.method()绕过代理那么这个流程中的“开启事务”、“提交/回滚”就永远不会执行相当于事务这块逻辑被完全跳过了。3.2 连接获取与“假装有事务”的陷阱这里还要提一个容易混淆的场景假设自调用方法内部执行了insertDetail()且执行过程中没有抛出任何异常那数据确实能写进数据库因为数据库认为每个单独的 SQL 操作本身就是一个隐式事务。但如果你在自调用方法内部先执行了插入再把连接归还到连接池整个方法执行期间就是一个“无事务包裹”的原生状态。如果业务方法中途抛了异常注意这个时候数据库已经完成了前面几步操作而 Spring 没有任何能力去回滚已经提交的语句。因为 Spring 只有在开启事务的情况下才会把连接绑定到当前线程的事务资源中并持有这个连接直到事务结束。自调用场景下每次 SQL 操作都是独立获取和释放连接没有全局协调者脏数据就这么出现了。3.3 异常处理对回滚行为的影响即使代理正常生效异常类型不对也会导致事务不生效。Transactional默认只在遇到RuntimeException和Error时回滚如果业务方法抛出的是受检异常比如Exception的子类默认是不会回滚的。所以在 JoyAI 的项目里我给事务注解特意加上了rollbackFor Exception.class确保所有异常都能触发回滚。在自调用失效的问题上需要额外注意的是如果内部方法自己捕获了异常并且没有重新抛出那即使代理正常事务拦截器也会认为方法执行成功从而提交事务。这种情况更隐蔽因为代码不会报错线上数据却会大规模出现不一致。我的习惯是写业务代码时对需要事务的批量操作尽量不在方法内部吞异常而是向外层抛出。3.4 编程式事务与声明式事务的本质差异Transactional属于声明式事务优点是无侵入缺点是过度依赖代理机制。而编程式事务直接通过TransactionTemplate控制事务边界不依赖代理适用于自调用或者设计比较复杂的场景。两者各有优劣我在后文解决方案部分会给出 JoyAI 项目中最终采用的办法。4. 实测验证复现自调用失效并对比三种修复方案为了确保结论准确我在本地搭了个最小化项目原型模拟 JoyAI 的结算场景分别测试了几种方案的实际效果。4.1 复现代码设计我建立了一张settle_record表设计了两条插入语句第一条成功第二条故意制造主键冲突验证第一条数据是否会被回滚。业务接口与实现代码大致如下Service public class SettleRecordService { public void selfInvoke() { insert(A001, 100); insert(A001, 200); // 故意造成主键冲突 } Transactional(rollbackFor Exception.class) public void insert(String recordNo, BigDecimal amount) { settleRecordDao.insert(new SettleRecord(recordNo, amount)); } }测试入口Component public class Runner implements ApplicationRunner { Autowired SettleRecordService service; public void run(ApplicationArguments args) { service.selfInvoke(); // 检查 settle_record 表是否有数据 } }运行之后查询表发现A001那条数据竟然留在表里了。按正常事务逻辑第二条插入触发主键冲突后第一条应该被回滚但此处没有。这说明自调用场景导致Transactional完全没有触发。4.2 方案一注入自身代理这个方案的核心思路是让类内部持有代理对象来调用。最常见写法是通过Lazy注入自己Service public class SettleRecordService { Autowired Lazy private SettleRecordService self; public void selfInvoke() { self.insert(A001, 100); self.insert(A001, 200); } }Lazy加在这里是为了避免循环依赖问题。当类内部注入自己的代理时Spring 需要先创建代理对象再注入到原始对象中如果不加Lazy在某些情况下会造成初始化顺序问题。实测结果事务正常开启第二条插入异常后第一条回滚了。这种方案改动非常小最容易落地但缺点是有一种“绕弯子”的感觉而且每一处自调用方法都要用self去调用容易遗忘。4.3 方案二使用 TransactionTemplate 编程式事务如果既不想注入代理又想让事务边界清晰可控可以在方法内部直接使用TransactionTemplateService public class SettleRecordService { private final TransactionTemplate transactionTemplate; public SettleRecordService(PlatformTransactionManager transactionManager) { this.transactionTemplate new TransactionTemplate(transactionManager); } public void selfInvoke() { transactionTemplate.execute(status - { insert(A001, 100); insert(A001, 200); return null; }); } }这种方案完全不依赖 AOP也不需要代理直接由TransactionTemplate开启事务并绑定连接。实测效果同样正常数据回滚干净利落。好处是逻辑直白不会因为调用方式而失效。缺点是需要手动编写事务边界代码如果一个类里有大量事务场景代码会逐步显得冗余。我个人在 JoyAI 项目中大量使用了这个方案尤其是在需要“事务包事务”场景下TransactionTemplate的传播行为控制反而比注解更直观而且没有任何代理心智负担。4.4 方案三将需要事务的方法拆分到其他 Bean另一种常见的办法是把带Transactional的方法挪到单独的 Spring Bean 中然后在原类中注入这个新 BeanService public class SettleRecordService { Autowired private SettleRecordWriter settleRecordWriter; public void selfInvoke() { settleRecordWriter.insertWithTransaction(A001, 100); settleRecordWriter.insertWithTransaction(A001, 200); } } Component public class SettleRecordWriter { Transactional(rollbackFor Exception.class) public void insertWithTransaction(String recordNo, BigDecimal amount) { // 插入逻辑 } }这个方案语义最清晰事务方法本身定义在一个干净的业务组件中任何外部调用者想触发事务都直接走代理没有this的问题。缺点是为了事务强行拆类类数量会变多尤其当系统已经很庞大的时候容易造成结构碎片化。4.5 方案横向对比与选型结论方案是否需要代理代码侵入性事务边界清晰度适用场景注入自身代理需要低一般小范围修改快速修复TransactionTemplate不需要中高复杂事务场景拆分事务 Bean需要低高系统架构分层明确时在 JoyAI 项目中我最终选择了“拆分事务 Bean 部分复杂场景用 TransactionTemplate”的组合方案。原因主要是结算模块对事务边界要求高代码量又大拆分后每个事务的职责一目了然后续维护成本低。而自身代理方案作为快速修复手段用在了几个应急场景中确实帮了大忙。这里要特别提醒不管用哪种方案事务本身的默认传播行为都是REQUIRED。也就是说如果外层已经存在事务内层加入已有事务如果不存在则新建。拆分 Bean 后多个带事务的方法相互调用它们的传播行为也需要认真考虑否则可能出现“事务过长”或“锁持有时间过久”的问题。5. 避开自调用之外的其他事务失效场景前面主要聊的是自调用带来的问题但排查过程中我也把 JoyAI 整个结算链路里所有跟事务相关的“坑”统一梳理了一遍很多问题从表面看是事务失效实际上各有各的原因。5.1 异常被吞掉导致“假提交”最常见的一种内部方法抛了异常但是调用方把异常 catch 住并记录日志继续执行后续流程。此时事务拦截器认为方法正常完成直接提交。从数据库结果看数据出现了“部分写入”却没有任何报错。很多线上脏数据就是这么来的。规避方法只有一个事务方法内部尽量不要自己捕获异常后不抛出。如果确实需要处理异常并继续执行后续逻辑那就不要依赖声明式事务而是改用编程式事务重画事务边界。5.2 多数据源下的事务管理器路由错乱如果项目引入了多个数据源比如读写分离或分库分表很容易出现“事务管理器没有指向实际使用的数据源”的情况。这样Transactional虽然触发了但是管理的是另一个数据源的连接业务 SQL 依然不在事务控制范围内。我的排查经验是在配置多数据源时为每个数据源分别定义DataSourceTransactionManager然后在Transactional中显式指定transactionManager比如Transactional(transactionManager masterTransactionManager)。Java Config 配置的时候最好给每个事务管理器起明确的名字避免 Spring 自动装配时匹配错误。5.3 方法可见性与 final 方法限制CGLIB 代理通过子类继承来增强方法private方法和final方法都无法被重写增强。因此把Transactional标在private方法上毫无意义标在final方法上同样不会触发代理。Spring 对这些情况通常也不会有明显错误提示属于静默失效。在 JoyAI 的代码规范里我要求所有事务方法必须是public且不允许final。另外类本身也要保持可继承状态不能因为某些性能优化习惯给 Service 类加上final修饰。5.4 同类 Bean 互相调用与接口代理的混淆如果使用了 JDK 动态代理而事务方法所在类实现了接口Spring 注入到其他类的是接口代理类型是接口子类。在类内部自行调用时如果通过实现类强转调用同样会绕过代理。这种场景容易迷惑人因为外部看代码是合法的接口调用内部却偷偷用了this。解决方向和自调用一致要么注入接口代理要么用编程式事务要么拆分 Bean。6. 最终落地JoyAI 项目事务模块的重构记录问题定位清楚方案也验证完毕之后我对 JoyAI 的结算模块做了一次系统性的重构。这里把关键动作写出来大家可以直接参考。6.1 统一事务边界设计按照业务行为我将结算相关的写操作划分为三种粒度粒度事务范围执行方式单条明细写入仅一条记录普通 DAO 插入不单独开事务单批次插入一批记录使用单独事务 Bean 方法调用跨多批次汇总多个批次整体最外层使用 TransactionTemplate 控制拆分后每个事务方法只负责自己的边界不再出现“一个 Service 内部调用一堆方法靠注解撑大局”的混乱结构。6.2 代码迁移样例原始实现里SettleOrderService内部自调用逻辑很多重构后我把涉及事务的写操作统一迁移到SettleWriterComponent public class SettleWriter { private final SettleRecordDao dao; public SettleWriter(SettleRecordDao dao) { this.dao dao; } Transactional(rollbackFor Exception.class) public void writeBatch(ListSettleRecord records) { for (SettleRecord record : records) { dao.insert(record); // 可能包含其他业务校验 // 校验失败会抛出 RuntimeException } } }原服务类只负责业务编排和调度不做底层写库。这样从架构上讲职责也更清晰。6.3 启动校验与回归验证重构完成后我添加了一个简单的启动校验组件用来扫描所有标记了Transactional的方法是否满足以下条件方法是public。方法所在类不是final。方法没有被final修饰。方法不在同一个类中被this调用。这种静态扫描无法 100% 覆盖所有情况但至少能在开发早期就拦住一部分低级问题比上线后靠脏数据反馈要高效得多。回归验证方面我重新跑了最初的最小化测试用例两条插入、第二个故意失败、确认数据库没有残留数据。测试通过之后又补了并发场景的压测确认在高并发下事务边界没有因为连接池竞争而变宽或变窄。7. 避坑守则这些经验比代码本身更值钱这个项目从头到尾踩了不少坑有些是自身设计问题有些是框架理解不够深入。我把最值得记住的经验整理成几条供大家参考。第一点永远不要信任Transactional的默认行为。默认只回滚RuntimeException和Error对受检异常不会回滚。如果项目里大量使用受检异常做业务控制流务必在注解上显式声明rollbackFor Exception.class。第二点排查事务问题时先看日志再改代码。重点找Creating new transaction、Participating in existing transaction、Rolling back这几类关键输出能快速判断事务到底有没有参与。没有这些日志就算代码写得再完美事务也是空中楼阁。第三点设计批量写入逻辑时尽量做到“一个事务对应一个有明确业务含义的入口”。不要把一堆细粒度方法都加上事务注解然后把它们串在一起这种做法非常容易在调用链中埋下自调用或者传播行为混乱的雷。先定义好事务边界再写实现代码次序不能反。第四点如果团队里新人较多强烈建议在项目里加入简单的 AOP 使用规范文档。我在 JoyAI 的工程文档里专门写了一节“事务方法调用注意事项”把this.method()的问题用示例代码写清楚每个新接手模块的人都会被要求先读这一节。别看内容简单它省下来的排查时间非常可观。第五点用TransactionTemplate时注意不要在一个大循环里反复开启新事务这样会造成连接频繁获取和释放性能极差。正确做法是把整批操作放一个execute回调中或者根据业务量合理分组。8. 个人经验与最后补充写到这里关于 Spring 自调用导致事务失效这件事其实核心就一句话Transactional是通过 AOP 代理生效的而this.method()绕过了代理。理解了这句话剩下的问题都能顺着推理出来。我在 JoyAI 项目的实际操作中深刻体会到一点对一个框架知其然很重要但知其所以然更重要。很多人抱怨 Spring 的事务“时灵时不灵”其实就是因为对代理机制缺乏完整认知。每次遇到事务问题不要急着搜代码片段先静下来想一想我这行代码到底是在调用代理对象还是在调用原始对象如果能把这个问题想明白后续遇到类似的缓存失效、异步注解失效、权限注解失效等问题时都能触类旁通。最后再分享一个小技巧排查代理问题时可以在代码里临时输出当前对象类型看类名是否带有EnhancerBySpringCGLIB或$Proxy字样。这不是生产环境的常规操作但作为本地调试手段却非常有效能让你在 30 秒内就确认代理到底有没有生效。希望这篇实录能帮你在 Spring 事务的深水里少踩几个暗礁。
“线上上了个单据审核接口第一次调就发现事务没生效回滚没执行脏数据都进去了。排查了好半天才发现问题根本不在数据库配置而是出在一个特别基础但又特别容易踩的坑Spring 事务在自调用场景下失效。”这是我最近处理的一个支付类核心模块的真实经历。项目的代号叫 JoyAI里面有个订单创建服务代码里一个方法调用另一个带事务注解的方法用this.method()写的。当时第一反应是数据源没配对后来脑子里过了一遍 Spring AOP 代理的原理才意识到this.method()调用的是目标对象自身的方法根本不会经过 AOP 代理事务切面自然就插不上手。这个问题非常适合所有在 Spring 生态里写业务代码的朋友参考尤其是用了Transactional但一直没深究过它到底是怎么生效的人。这篇文章我想把整个排查过程、底层原理、实测验证和最后采用的解决方案完整写出来顺便帮大家梳理清楚什么情况下事务会失效、为什么this.method()会绕过代理、以及有哪些稳妥的修复手段。1. 问题复盘从一次线上数据异常说起先说项目背景。JoyAI 这套系统里我负责一个对账模块负责从第三方接口拉取结算数据然后批量写入本地库。写入过程需要保证“要么全部成功要么全部回滚”所以很自然地在外层加上了Transactional。线上第一次跑完发现明细表和汇总表的数据对不上少了好几条但程序没报任何异常。这不对劲因为代码逻辑里如果某条数据校验失败会直接抛出RuntimeException理论上整个批次都应该回滚才对。可实际情况是部分数据写进去了部分没有出现了“半截事务”的典型现场。1.1 现象日志里没有任何回滚痕迹第一件事就是看日志。正常情况下事务回滚时Spring 会打印类似Rolling back transaction或Initiating transaction commit这类逻辑但我翻遍了本批次日志发现连Creating new transaction都没有出现过也没有任何事务管理器的参与记录。再仔细看调用链发现负责写入明细的方法是被同一个类的内部方法调用过来的用的还是最朴素的this.insertDetail()写法。看到这里我心里已经大概有数了但还是决定把理论再验证一遍再动手改。顺带提一嘴排查这类问题有一个好习惯先确认异常有没有被吞掉再确认事务管理器有没有参与最后才是检查代理有没有生效。日志顺序往往能告诉你一切。1.2 初步怀疑把锅甩给数据源配置按照常规排查思路事务不生效最容易被怀疑的就是数据源没配置好或者EnableTransactionManagement没加。于是我先检查了启动类确认EnableTransactionManagement存在数据库连接池配置也正常事务管理器明确指向了主数据源。排除掉这一层之后才把目光放回到调用方式上。这里有个小经验分享遇到事务失效最好先在心里过一遍“三步曲”——配置对不对、异常类型对不对、调用链路有没有经过代理。绝大多数事务失效问题都逃不出这三类原因而自调用就属于典型的第三种。1.3 定位this.method()是问题核心定位到具体代码时看到的结构大概是这样的Service public class SettleOrderService { public void batchCreate(ListOrderDTO orders) { for (OrderDTO order : orders) { this.createSingle(order); } } Transactional(rollbackFor Exception.class) public void createSingle(OrderDTO order) { // 写主表 // 写明细表 // 校验不通过则抛异常 } }batchCreate内部循环调用了this.createSingle()而createSingle上面的Transactional注解并没有生效。原因就是 Spring 的事务功能是通过 AOP 代理实现的this拿到的是原始对象不是代理对象。只有从外部容器里获取到的 Bean或者通过Autowired注入到其他类里的 Bean才是被切面包裹后的代理对象。这一步确认之后问题定位就算完成了。接下来需要对 Spring 的代理机制做深入分析把“为什么自调用会绕过代理”这个问题彻底讲透。2. 深入原理Spring AOP 代理与事务生效的前提条件要用大白话解释清楚自调用为什么会失效得先搞清楚 Spring 创建 Bean 的时候到底做了什么。默认情况下Spring 容器中存放的并不是你写的那个普通业务对象而是一个代理对象。这个代理对象会“包裹”原始对象在方法调用前、后插入额外逻辑。当容器把一个 bean 注入到另一个 bean 中时注入的其实是代理对象。所以外部调用带Transactional的方法时实际上是先走代理再走到原始方法。事务就是在这个“额外逻辑”里开启和提交回滚的。2.1 JDK 动态代理与 CGLIB 的区别Spring 的代理机制有两种实现方式代理方式适用条件特点JDK 动态代理目标类实现了至少一个接口基于接口代理生成代理类实现相同接口CGLIB 代理目标类未实现接口或配置强制使用生成目标类的子类重写非 final 方法在 JoyAI 项目里SettleOrderService是纯类没有实现任何接口所以 Spring 默认会用 CGLIB 生成一个子类代理。这个代理子类重写了createSingle()方法在方法前后挂载事务拦截器。你可以把this理解成“站在对象内部看自己”它指向的是那个未经过任何包装的原始实例。而外部持有的 bean 引用指向的是 CGLIB 生成的子类两者根本不是同一个对象。用this调用方法等于绕过了代理子类直接执行原始逻辑事务拦截器完全不会被触发。2.2 为什么外部调用和内部调用行为完全不同为了让自己彻底理解我做了一个极简的类比假设你请了一个助理代理对象所有外部访客都必须经过助理登记才能见到你。但你自己早上出门时难道还要助理给你自己登记一遍吗this.method()就是这个道理你自己调用自己根本不会找助理。Spring 容器中的 Bean 相当于“你本人 助理”的合体外部依赖注入的是助理这个角色但从类内部看this永远都只代表你本人。所以即使createSingle()标注了Transactional在没有代理的环境下直接调用它就是一个普普通通的原生方法。2.3 验证如何确认目标对象确实被代理了我写了一段验证代码来确认自己的判断Autowired private SettleOrderService orderService; public void checkProxy() { System.out.println(orderService.getClass().getName()); // 输出类似: com.xxx.SettleOrderService$$EnhancerBySpringCGLIB$$abc123 System.out.println(orderService instanceof SettleOrderService); // 输出: true因为 CGLIB 子类属于 SettleOrderService 类型 }如果类名里带着$$EnhancerBySpringCGLIB$$就说明容器里装的确实是代理对象。外部通过orderService.createSingle()调用时走的确实是代理方法Transactional才能生效。反之在类内部用this.createSingle()调用时this指向的类名应该就是原始的SettleOrderService没有增强痕迹问题一目了然。这里补充一个知识点如果项目使用了EnableTransactionManagement但类本身没有接口Spring 会优先选择 CGLIB。而如果配置了proxyTargetClass false且类没有接口就无法生成代理事务同样会静默失效。这类配置问题比自调用还要隐蔽我建议大家在项目初始化时先加一个代理状况检查。3. 事务切面的完整原理拆解Transactional 到底在什么时机起作用搞懂了代理机制还需要再进一步理解事务切面本身的执行流程这样你才能在设计接口时主动避开各种坑。3.1 TransactionInterceptor 的工作流程在 Spring 中真正干活的事务切面是TransactionInterceptor。它实现了 AOP 的方法拦截逻辑核心流程大致是这样检查当前方法是否配置了事务属性。检查当前线程是否已经存在活动事务如果没有就创建一个新的。执行业务方法。如果方法正常返回则提交事务。如果方法抛出异常则根据rollbackFor配置决定是否回滚。这整个流程都是在代理方法中完成的。也就是说业务方法只是被“包裹”的中间环节事务的开启和结束完全由代理控制。如果this.method()绕过代理那么这个流程中的“开启事务”、“提交/回滚”就永远不会执行相当于事务这块逻辑被完全跳过了。3.2 连接获取与“假装有事务”的陷阱这里还要提一个容易混淆的场景假设自调用方法内部执行了insertDetail()且执行过程中没有抛出任何异常那数据确实能写进数据库因为数据库认为每个单独的 SQL 操作本身就是一个隐式事务。但如果你在自调用方法内部先执行了插入再把连接归还到连接池整个方法执行期间就是一个“无事务包裹”的原生状态。如果业务方法中途抛了异常注意这个时候数据库已经完成了前面几步操作而 Spring 没有任何能力去回滚已经提交的语句。因为 Spring 只有在开启事务的情况下才会把连接绑定到当前线程的事务资源中并持有这个连接直到事务结束。自调用场景下每次 SQL 操作都是独立获取和释放连接没有全局协调者脏数据就这么出现了。3.3 异常处理对回滚行为的影响即使代理正常生效异常类型不对也会导致事务不生效。Transactional默认只在遇到RuntimeException和Error时回滚如果业务方法抛出的是受检异常比如Exception的子类默认是不会回滚的。所以在 JoyAI 的项目里我给事务注解特意加上了rollbackFor Exception.class确保所有异常都能触发回滚。在自调用失效的问题上需要额外注意的是如果内部方法自己捕获了异常并且没有重新抛出那即使代理正常事务拦截器也会认为方法执行成功从而提交事务。这种情况更隐蔽因为代码不会报错线上数据却会大规模出现不一致。我的习惯是写业务代码时对需要事务的批量操作尽量不在方法内部吞异常而是向外层抛出。3.4 编程式事务与声明式事务的本质差异Transactional属于声明式事务优点是无侵入缺点是过度依赖代理机制。而编程式事务直接通过TransactionTemplate控制事务边界不依赖代理适用于自调用或者设计比较复杂的场景。两者各有优劣我在后文解决方案部分会给出 JoyAI 项目中最终采用的办法。4. 实测验证复现自调用失效并对比三种修复方案为了确保结论准确我在本地搭了个最小化项目原型模拟 JoyAI 的结算场景分别测试了几种方案的实际效果。4.1 复现代码设计我建立了一张settle_record表设计了两条插入语句第一条成功第二条故意制造主键冲突验证第一条数据是否会被回滚。业务接口与实现代码大致如下Service public class SettleRecordService { public void selfInvoke() { insert(A001, 100); insert(A001, 200); // 故意造成主键冲突 } Transactional(rollbackFor Exception.class) public void insert(String recordNo, BigDecimal amount) { settleRecordDao.insert(new SettleRecord(recordNo, amount)); } }测试入口Component public class Runner implements ApplicationRunner { Autowired SettleRecordService service; public void run(ApplicationArguments args) { service.selfInvoke(); // 检查 settle_record 表是否有数据 } }运行之后查询表发现A001那条数据竟然留在表里了。按正常事务逻辑第二条插入触发主键冲突后第一条应该被回滚但此处没有。这说明自调用场景导致Transactional完全没有触发。4.2 方案一注入自身代理这个方案的核心思路是让类内部持有代理对象来调用。最常见写法是通过Lazy注入自己Service public class SettleRecordService { Autowired Lazy private SettleRecordService self; public void selfInvoke() { self.insert(A001, 100); self.insert(A001, 200); } }Lazy加在这里是为了避免循环依赖问题。当类内部注入自己的代理时Spring 需要先创建代理对象再注入到原始对象中如果不加Lazy在某些情况下会造成初始化顺序问题。实测结果事务正常开启第二条插入异常后第一条回滚了。这种方案改动非常小最容易落地但缺点是有一种“绕弯子”的感觉而且每一处自调用方法都要用self去调用容易遗忘。4.3 方案二使用 TransactionTemplate 编程式事务如果既不想注入代理又想让事务边界清晰可控可以在方法内部直接使用TransactionTemplateService public class SettleRecordService { private final TransactionTemplate transactionTemplate; public SettleRecordService(PlatformTransactionManager transactionManager) { this.transactionTemplate new TransactionTemplate(transactionManager); } public void selfInvoke() { transactionTemplate.execute(status - { insert(A001, 100); insert(A001, 200); return null; }); } }这种方案完全不依赖 AOP也不需要代理直接由TransactionTemplate开启事务并绑定连接。实测效果同样正常数据回滚干净利落。好处是逻辑直白不会因为调用方式而失效。缺点是需要手动编写事务边界代码如果一个类里有大量事务场景代码会逐步显得冗余。我个人在 JoyAI 项目中大量使用了这个方案尤其是在需要“事务包事务”场景下TransactionTemplate的传播行为控制反而比注解更直观而且没有任何代理心智负担。4.4 方案三将需要事务的方法拆分到其他 Bean另一种常见的办法是把带Transactional的方法挪到单独的 Spring Bean 中然后在原类中注入这个新 BeanService public class SettleRecordService { Autowired private SettleRecordWriter settleRecordWriter; public void selfInvoke() { settleRecordWriter.insertWithTransaction(A001, 100); settleRecordWriter.insertWithTransaction(A001, 200); } } Component public class SettleRecordWriter { Transactional(rollbackFor Exception.class) public void insertWithTransaction(String recordNo, BigDecimal amount) { // 插入逻辑 } }这个方案语义最清晰事务方法本身定义在一个干净的业务组件中任何外部调用者想触发事务都直接走代理没有this的问题。缺点是为了事务强行拆类类数量会变多尤其当系统已经很庞大的时候容易造成结构碎片化。4.5 方案横向对比与选型结论方案是否需要代理代码侵入性事务边界清晰度适用场景注入自身代理需要低一般小范围修改快速修复TransactionTemplate不需要中高复杂事务场景拆分事务 Bean需要低高系统架构分层明确时在 JoyAI 项目中我最终选择了“拆分事务 Bean 部分复杂场景用 TransactionTemplate”的组合方案。原因主要是结算模块对事务边界要求高代码量又大拆分后每个事务的职责一目了然后续维护成本低。而自身代理方案作为快速修复手段用在了几个应急场景中确实帮了大忙。这里要特别提醒不管用哪种方案事务本身的默认传播行为都是REQUIRED。也就是说如果外层已经存在事务内层加入已有事务如果不存在则新建。拆分 Bean 后多个带事务的方法相互调用它们的传播行为也需要认真考虑否则可能出现“事务过长”或“锁持有时间过久”的问题。5. 避开自调用之外的其他事务失效场景前面主要聊的是自调用带来的问题但排查过程中我也把 JoyAI 整个结算链路里所有跟事务相关的“坑”统一梳理了一遍很多问题从表面看是事务失效实际上各有各的原因。5.1 异常被吞掉导致“假提交”最常见的一种内部方法抛了异常但是调用方把异常 catch 住并记录日志继续执行后续流程。此时事务拦截器认为方法正常完成直接提交。从数据库结果看数据出现了“部分写入”却没有任何报错。很多线上脏数据就是这么来的。规避方法只有一个事务方法内部尽量不要自己捕获异常后不抛出。如果确实需要处理异常并继续执行后续逻辑那就不要依赖声明式事务而是改用编程式事务重画事务边界。5.2 多数据源下的事务管理器路由错乱如果项目引入了多个数据源比如读写分离或分库分表很容易出现“事务管理器没有指向实际使用的数据源”的情况。这样Transactional虽然触发了但是管理的是另一个数据源的连接业务 SQL 依然不在事务控制范围内。我的排查经验是在配置多数据源时为每个数据源分别定义DataSourceTransactionManager然后在Transactional中显式指定transactionManager比如Transactional(transactionManager masterTransactionManager)。Java Config 配置的时候最好给每个事务管理器起明确的名字避免 Spring 自动装配时匹配错误。5.3 方法可见性与 final 方法限制CGLIB 代理通过子类继承来增强方法private方法和final方法都无法被重写增强。因此把Transactional标在private方法上毫无意义标在final方法上同样不会触发代理。Spring 对这些情况通常也不会有明显错误提示属于静默失效。在 JoyAI 的代码规范里我要求所有事务方法必须是public且不允许final。另外类本身也要保持可继承状态不能因为某些性能优化习惯给 Service 类加上final修饰。5.4 同类 Bean 互相调用与接口代理的混淆如果使用了 JDK 动态代理而事务方法所在类实现了接口Spring 注入到其他类的是接口代理类型是接口子类。在类内部自行调用时如果通过实现类强转调用同样会绕过代理。这种场景容易迷惑人因为外部看代码是合法的接口调用内部却偷偷用了this。解决方向和自调用一致要么注入接口代理要么用编程式事务要么拆分 Bean。6. 最终落地JoyAI 项目事务模块的重构记录问题定位清楚方案也验证完毕之后我对 JoyAI 的结算模块做了一次系统性的重构。这里把关键动作写出来大家可以直接参考。6.1 统一事务边界设计按照业务行为我将结算相关的写操作划分为三种粒度粒度事务范围执行方式单条明细写入仅一条记录普通 DAO 插入不单独开事务单批次插入一批记录使用单独事务 Bean 方法调用跨多批次汇总多个批次整体最外层使用 TransactionTemplate 控制拆分后每个事务方法只负责自己的边界不再出现“一个 Service 内部调用一堆方法靠注解撑大局”的混乱结构。6.2 代码迁移样例原始实现里SettleOrderService内部自调用逻辑很多重构后我把涉及事务的写操作统一迁移到SettleWriterComponent public class SettleWriter { private final SettleRecordDao dao; public SettleWriter(SettleRecordDao dao) { this.dao dao; } Transactional(rollbackFor Exception.class) public void writeBatch(ListSettleRecord records) { for (SettleRecord record : records) { dao.insert(record); // 可能包含其他业务校验 // 校验失败会抛出 RuntimeException } } }原服务类只负责业务编排和调度不做底层写库。这样从架构上讲职责也更清晰。6.3 启动校验与回归验证重构完成后我添加了一个简单的启动校验组件用来扫描所有标记了Transactional的方法是否满足以下条件方法是public。方法所在类不是final。方法没有被final修饰。方法不在同一个类中被this调用。这种静态扫描无法 100% 覆盖所有情况但至少能在开发早期就拦住一部分低级问题比上线后靠脏数据反馈要高效得多。回归验证方面我重新跑了最初的最小化测试用例两条插入、第二个故意失败、确认数据库没有残留数据。测试通过之后又补了并发场景的压测确认在高并发下事务边界没有因为连接池竞争而变宽或变窄。7. 避坑守则这些经验比代码本身更值钱这个项目从头到尾踩了不少坑有些是自身设计问题有些是框架理解不够深入。我把最值得记住的经验整理成几条供大家参考。第一点永远不要信任Transactional的默认行为。默认只回滚RuntimeException和Error对受检异常不会回滚。如果项目里大量使用受检异常做业务控制流务必在注解上显式声明rollbackFor Exception.class。第二点排查事务问题时先看日志再改代码。重点找Creating new transaction、Participating in existing transaction、Rolling back这几类关键输出能快速判断事务到底有没有参与。没有这些日志就算代码写得再完美事务也是空中楼阁。第三点设计批量写入逻辑时尽量做到“一个事务对应一个有明确业务含义的入口”。不要把一堆细粒度方法都加上事务注解然后把它们串在一起这种做法非常容易在调用链中埋下自调用或者传播行为混乱的雷。先定义好事务边界再写实现代码次序不能反。第四点如果团队里新人较多强烈建议在项目里加入简单的 AOP 使用规范文档。我在 JoyAI 的工程文档里专门写了一节“事务方法调用注意事项”把this.method()的问题用示例代码写清楚每个新接手模块的人都会被要求先读这一节。别看内容简单它省下来的排查时间非常可观。第五点用TransactionTemplate时注意不要在一个大循环里反复开启新事务这样会造成连接频繁获取和释放性能极差。正确做法是把整批操作放一个execute回调中或者根据业务量合理分组。8. 个人经验与最后补充写到这里关于 Spring 自调用导致事务失效这件事其实核心就一句话Transactional是通过 AOP 代理生效的而this.method()绕过了代理。理解了这句话剩下的问题都能顺着推理出来。我在 JoyAI 项目的实际操作中深刻体会到一点对一个框架知其然很重要但知其所以然更重要。很多人抱怨 Spring 的事务“时灵时不灵”其实就是因为对代理机制缺乏完整认知。每次遇到事务问题不要急着搜代码片段先静下来想一想我这行代码到底是在调用代理对象还是在调用原始对象如果能把这个问题想明白后续遇到类似的缓存失效、异步注解失效、权限注解失效等问题时都能触类旁通。最后再分享一个小技巧排查代理问题时可以在代码里临时输出当前对象类型看类名是否带有EnhancerBySpringCGLIB或$Proxy字样。这不是生产环境的常规操作但作为本地调试手段却非常有效能让你在 30 秒内就确认代理到底有没有生效。希望这篇实录能帮你在 Spring 事务的深水里少踩几个暗礁。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
