“加个@Transactional就完事了”——这句话我在代码评审里见过太多次，每次都得花半小时解释为什么它可能是错的。Java 事务这套东西，表面上看是框架帮你包了一层，实际上从数据库连接、AOP 代理、线程绑定到异常类型判断，每一环都能让事务悄无声息地失效，而且失效的时候往往不报错，数据该脏还是脏，等到对账出问题才被发现。这篇文章我想把 Java 事务从底往上捋一遍：事务到底是怎么落到一根数据库连接上的，注解是怎么被翻译成代理调用的，七种传播行为各自对应什么样的真实业务，以及那些让人抓狂的“注解加了但没生效”该怎么一步步排查。不管你是刚接触 Spring Boot 不久，还是写了几年业务代码但一直没深究过这块，应该都能从中找到能直接抄作业的部分。
1. 一个注解背后的三层机制：为什么@Transactional经常“假生效”
1.1 事务的物理载体：同一根连接上的连续操作
先把框架放一边，想想数据库层面事务是什么。你打开一个客户端，执行BEGIN，然后 update、insert、delete，最后COMMIT。这一串操作之所以能作为一个整体，是因为它们跑在同一根 TCP 连接上，数据库服务端为这根连接维护了一个会话级的事务上下文。换一根连接，就是另一个事务，彼此看不见对方未提交的修改，也谈不上一起回滚。
这个认知特别重要。Java 里所有事务框架干的事，本质上都是在解决“怎么保证这一批操作复用同一根连接，并且在合适的时机 commit 或者 rollback”。声明式事务也不例外，它做的事情是把“取连接、绑连接、开事务、执行、提交/回滚、释放连接”这一套模板代码用 AOP 包起来，让你只写业务。所以当你怀疑事务没生效时，第一个该问的问题永远是：这几条 SQL 真的跑在同一根连接上吗？大部分疑难杂症，答案都藏在这个问题里。
框架内部靠TransactionSynchronizationManager这个类做连接与线程的绑定，底层是一个ThreadLocal<Map<DataSource, ConnectionHolder>>。方法进入事务时把连接塞进当前线程，方法执行期间所有 DAO 调用都从这个 ThreadLocal 里取，取不到才去连接池新拿。这就解释了为什么事务天然不跨线程——你在事务方法里new Thread()去写库，子线程的 ThreadLocal 是空的，它会去连接池另拿一根，跟主线程的事务毫无关系。异步任务、线程池、CompletableFuture里做写操作，全部踩这个坑。
1.2 AOP 代理：注解只有落在代理对象上才算数
Spring 声明式事务的实现基础是代理。容器启动时，它会扫描所有 Bean，发现有方法（或类）标了@Transactional，就给这个 Bean 生成一个代理对象放到容器里，你@Autowired注入拿到的是代理，不是原始对象。调用代理方法时，代理先开事务，再反射调用原始对象的目标方法，最后提交或回滚。
代理有两种生成方式：目标类实现了接口走 JDK 动态代理，没实现接口走 CGLIB 生成子类。两种方式有个共同点——代理对象只拦截从外部进来的调用。这句话是理解所有失效场景的钥匙。代理的invoke方法里写的是“开事务 → 调目标方法 → 提交”，如果你在目标方法内部用this.b()调另一个带注解的方法b()，这个调用根本不经过代理，b()上的注解就是一行注释，事务自然不存在。
我见过一个真实案例：某订单服务在createOrder()里调this.deductStock()，两个方法都标了@Transactional，开发以为扣库存是独立事务，结果库存扣减失败时整个订单一起回滚，跟预期完全相反。后来把deductStock挪到另一个 Bean 里才解决。这类问题不会报错，日志里也看不出异常，只能靠对机制的理解去发现。
1.3 自调用失效的三种绕法及其代价
知道原因之后，解法就有得选了，但每种都有代价，得看场景挑。
最直接的是拆类：把需要独立事务的方法挪到另一个 Service 里注入进来调用。这种方式最干净，不依赖任何框架特性，缺点是要多维护一个类，有时候纯粹为了事务拆类会让代码组织显得别扭。
第二种是注入自身：@Autowired private OrderService self;，然后self.deductStock()。Spring 允许自注入（默认允许循环依赖的情况下），拿到的就是代理对象。这种写法在 Spring Boot 2.6 之后要注意循环依赖默认被禁了，得开spring.main.allow-circular-references，不太优雅。
第三种是AopContext：在启动类或配置类上加@EnableAspectJAutoProxy(exposeProxy = true)，然后代码里写((OrderService) AopContext.currentProxy()).deductStock()。这种方式不用拆类也不用自注入，但代码里出现了对 AOP 基础设施的强依赖，单元测试时如果没有代理上下文会直接抛异常，可测性变差。
我的经验是：短期救火用 AopContext，长期重构拆类。自注入这种写法我一般不推荐，它把循环依赖这个隐患埋进了容器启动流程里，出问题时排查成本很高。另外还有个偏门解法是把方法声明成public并且通过ApplicationContext拿 Bean 再调，本质和自注入一样，没必要。
2. 传播行为不是背出来的：七个值对应哪些真实业务
2.1 REQUIRED 与 REQUIRES_NEW：一个退款场景的推演
传播行为这块，面试题里背七个值谁都会，但落到代码里能不能选对，完全是另一回事。我用一个退款场景把最常用的两个值讲透。
假设退款流程分三步：写退款单、调外部渠道退款、更新订单状态。如果整个方法标REQUIRED（默认值），三步在同一个事务里，渠道调用失败抛异常，退款单和订单状态一起回滚，干净利落。但渠道调用是远程 HTTP，可能超时几十秒，这段时间数据库事务一直开着，行锁不释放，并发高的时候能把连接池耗干。
这时候有人会想：把“调用渠道”这一步改成REQUIRES_NEW，让它独立事务。问题来了——REQUIRES_NEW会挂起当前事务，从连接池另拿一根连接开新事务。如果外层事务已经持有某行的锁，内层新事务再去更新同一行，就会自己把自己锁死，等锁超时。这个坑我在一个支付对账系统里亲眼见过，日志里全是Lock wait timeout exceeded，查了两天才定位到是嵌套事务导致的死锁。
所以REQUIRES_NEW的正确用法是：内外层操作的数据不重叠，且内层失败不应该影响外层已完成的动作。比如“记录操作审计日志”这种，日志写失败不该让主业务回滚，用REQUIRES_NEW就合适——前提是日志表和业务表没有行级冲突。
2.2 NESTED 的保存点机制与它容易翻车的地方
NESTED是最容易被误解的一个。它不像REQUIRES_NEW那样另开连接，而是在当前事务里打一个保存点（savepoint），内层失败时回滚到保存点，外层还能继续。听起来很美好，但它有两个硬性前提：数据库支持保存点（MySQL InnoDB 支持，Oracle 支持，某些数据库不支持），以及数据源必须配JdbcTransactionManager或DataSourceTransactionManager，用 JTA 的话行为会不一样。
还有个细节，NESTED内层抛异常被外层 catch 住之后，如果不显式处理，外层事务在提交时可能仍然报UnexpectedRollbackException。原因是内层回滚到保存点这个动作，在某些驱动实现里会把连接的“只回滚”标记打上，外层提交时发现标记还在就抛异常。稳妥的做法是内层方法用REQUIRES_NEW隔离，或者在外层捕获异常后确认事务状态。
我把七个传播行为整理成一张表，方便对照：
| 传播行为 | 当前有事务 | 当前无事务 | 典型场景 |
|---|---|---|---|
| REQUIRED | 加入 | 新建 | 绝大多数业务方法 |
| SUPPORTS | 加入 | 非事务执行 | 只读查询，可有可无 |
| MANDATORY | 加入 | 抛异常 | 强制要求上游开事务的内部方法 |
| REQUIRES_NEW | 挂起后新建 | 新建 | 审计日志、独立补偿记录 |
| NOT_SUPPORTED | 挂起后非事务执行 | 非事务执行 | 大批量导入，避免长事务 |
| NEVER | 抛异常 | 非事务执行 | 明确不允许事务的场景 |
| NESTED | 保存点嵌套 | 等同 REQUIRED | 可部分回滚的子流程 |
2.3 只读事务不是摆设，但很多人用错了
@Transactional(readOnly = true)这个配置，我观察下来两极分化：一类人从不用，一类人到处加。它的实际作用有三层：一是给数据库驱动一个提示，MySQL 会把连接设为只读模式，某些情况下能触发优化；二是 Hibernate 这类 ORM 会跳过脏检查（dirty checking），不再为实体维护快照，查询大结果集时内存和 CPU 都能省一截；三是告诉团队“这个方法不该写库”，是一种契约。
但它有个容易踩的点：只读事务里如果真写了库，MySQL 默认不会报错，只是把写操作当成普通语句执行，事务语义就乱了。所以别指望它当保险用。另外，readOnly只在方法级别生效，类级别标了之后方法级别可以覆盖，但很多团队不知道这个优先级，导致类上全局只读、某个写方法忘了覆盖，线上出现“数据莫名写不进去”的怪现象。
3. 事务失效的排查链路：从现象到根因的完整复盘
3.1 第一步永远是确认代理到底生成了没有
遇到“事务没生效”，别急着改代码，先确认代理存在。最土但最有效的办法是在启动日志里开logging.level.org.springframework.transaction=DEBUG，看方法调用时有没有打印Creating new transaction或者Participating in existing transaction。一行日志就能区分是“代理没生成”还是“代理生成了但事务没开”。
如果没有这行日志，往下查三类原因：类没被 Spring 管理（忘了@Service，或者被new出来的）、方法是private或final（CGLIB 无法覆写 final 方法，private 方法代理拦不到）、类本身是final的（CGLIB 无法继承）。这几种情况有个共同特征——不报错，静默失效。我建议在 CI 里加一条静态检查规则，扫出“标了@Transactional但不是 public 的方法”，能提前拦掉一批问题。
还有一种隐蔽情况：类实现了接口，注入时用的是接口类型，但方法注解只标在实现类上。JDK 动态代理是基于接口的，接口方法上没有注解，某些旧版本 Spring 会读不到。现在的版本处理得更智能了，但为了稳妥，注解统一标在实现类的方法上最保险。
3.2 异常被吞掉，事务自然不知道该回滚
事务回滚的触发条件是方法向外抛出未捕获的异常。代理在invoke里包了 try-catch，只有异常冒泡到代理层，它才会执行 rollback。所以下面这段代码的事务是无效的：
@Transactional public void createOrder(Order order) { try { orderMapper.insert(order); inventoryService.deduct(order.getSkuId()); } catch (Exception e) { log.error("下单失败", e); // 异常被吞了，代理层感知不到 } }deduct失败后异常被 catch 住，方法正常返回，代理认为一切顺利，直接 commit。订单插进去了，库存没扣，数据不一致。这个坑的可怕之处在于它看起来“很健壮”——有 try-catch，有日志，代码评审时很容易被放过。
正确做法是要么不 catch 让它抛出去，要么 catch 之后重新抛一个运行时异常。如果确实需要记录日志，捕获后throw new BizException(...)是标准姿势。
第二个坑是异常类型不匹配。@Transactional默认只对RuntimeException和Error回滚，受检异常（Exception的直接子类里非运行时的那部分）不回滚。你写了个自定义的CheckedBizException extends Exception，抛出去之后事务照样提交。解决办法是显式声明@Transactional(rollbackFor = Exception.class)，这条我建议作为团队规范写进代码模板，无脑加上，成本为零收益很大。
3.3 多数据源和连接不一致导致的静默失效
微服务架构下多数据源很常见，@DS注解、动态数据源、AbstractRoutingDataSource这些方案用起来方便，但跟事务配合时容易翻车。
核心矛盾在于：事务开启时连接已经绑定到 ThreadLocal 了，而路由数据源是在取连接的那一刻根据上下文决定用哪个库。如果事务先开、数据源后切，事务里的所有操作都会跑在第一个库里，切库动作形同虚设。反之如果先切库再开事务，倒是能对上，但代码里顺序稍微写错就出问题。
我遇到过的典型症状是：读主库写从库，事务里读到了旧数据；或者两个库的操作本该各自回滚，结果一个回滚一个提交。排查方法是在每个数据源操作前后打印DataSourceContextHolder.get()的值，看它跟实际连接的库是否一致。更彻底的做法是让事务管理器和数据源绑定关系在配置层面就明确，别在业务代码里动态切。
还有一种情况是用了 MyBatis-Plus 的多数据源插件，但事务管理器还是单数据源的，这种配置下事务只对默认库生效，其他库的操作是自动提交的。这个坑藏得深，配置类里两行代码的差异，行为完全不同。
3.4 一张速查清单，贴在手边随时用
排查事务问题我习惯按这个顺序过一遍，命中率很高：
| 检查项 | 命令/方法 | 命中症状 |
|---|---|---|
| 代理是否生成 | 开 DEBUG 日志看Creating new transaction | 无日志 = 代理没生效 |
| 是否自调用 | 检查this.xxx()调用 | 注解在内部方法上失效 |
| 方法是否 public | 看方法签名 | private/final 无法代理 |
| 异常是否被吞 | 搜 try-catch 块 | 不回滚 |
| 异常类型 | 看rollbackFor配置 | 受检异常不回滚 |
| 引擎是否支持 | show table status看 Engine | MyISAM 无事务 |
| 数据源切换时机 | 打印路由上下文 | 操作跑错库 |
提示：MySQL 的 MyISAM 引擎不支持事务，建表时如果没指定
ENGINE=InnoDB，默认在某些老版本配置下会是 MyISAM，这时候注解加得再对也没用。上线前统一检查一遍表的引擎，ALTER TABLE xxx ENGINE=InnoDB能补上。
4. 隔离级别与锁：并发扣库存时你到底在防什么
4.1 四种隔离级别分别挡住什么问题
隔离级别这个概念，教科书上讲得抽象，落到“扣库存”这种具体场景就好理解了。两个事务同时扣同一件商品的库存，stock = 10，各自执行update stock set num = num - 1 where id = 1，如果不做任何隔离控制，可能卖出 11 件。隔离级别和锁机制就是干这个的。
四种级别对应的问题：
| 隔离级别 | 脏读 | 不可重复读 | 幻读 | MySQL 默认 |
|---|---|---|---|---|
| READ UNCOMMITTED | 可能 | 可能 | 可能 | 否 |
| READ COMMITTED | 不会 | 可能 | 可能 | 否 |
| REPEATABLE READ | 不会 | 不会 | InnoDB 通过间隙锁基本避免 | 是 |
| SERIALIZABLE | 不会 | 不会 | 不会 | 否 |
MySQL 的 InnoDB 默认用REPEATABLE READ，Oracle 和 PostgreSQL 默认READ COMMITTED。这个差异在跨库迁移或者团队技术栈切换时经常引发问题：同样的代码在 MySQL 上跑得好好的，迁到 Oracle 上出现不可重复读，同一个事务里查两次余额不一样。
REPEATABLE READ的实现靠 MVCC（多版本并发控制），事务开始时拍一个快照，后续读都基于这个快照，所以看不到别的事务的提交。但快照读只对普通 SELECT 生效，update、delete、select ... for update走的是当前读，会去读最新版本，这就引出了间隙锁和死锁那一堆事。
4.2 乐观锁与悲观锁在事务里的分工
光靠数据库隔离级别防并发超卖，性能代价太大。实际业务里一般是悲观锁和乐观锁二选一，配合事务使用。
悲观锁就是select ... for update，在事务里锁住目标行，别人想改得排队。优点是简单可靠，缺点是并发度低、容易死锁。用的时候有个细节：一定要走索引，如果where条件没命中索引，InnoDB 会锁全表（准确说是锁所有扫描到的行加上间隙），并发场景下直接雪崩。我见过一个秒杀接口因为for update的条件字段没建索引，压测时 QPS 掉到个位数。
乐观锁是加版本号，update ... where id = ? and version = ?，更新影响行数为 0 就说明被人抢先了，重试或者报错。优点是并发度高、不占用数据库锁，缺点是要处理重试逻辑，高冲突场景下重试率会很高。
选型上我的经验是：读多写少、冲突概率低用乐观锁；写多冲突高、短事务用悲观锁。库存扣减这种场景，如果用了 Redis 预扣减，数据库层的乐观锁就够；如果是直接怼数据库，悲观锁更稳妥。两种方式都必须放在事务里，for update离开事务就失效了，乐观锁的“查询版本号 + 更新”如果不在一个事务里，中间可能被别人改掉。
4.3 长事务的隐性代价，比你想的严重
一个事务从BEGIN到COMMIT的时长，直接决定了它持有锁的时长。长事务的危害不止是锁等待，还有三个容易被忽略的副作用。
第一是undo log 膨胀。InnoDB 的 MVCC 靠 undo log 保存历史版本，长事务会让 undo log 无法清理，磁盘占用持续增长，严重时触发ibdata空间告警。第二是主从延迟。大事务在主库上执行很久，binlog 一次性同步到从库，从库回放需要同样长的时间，读写分离的读库可能读到落后几分钟的数据。第三是连接池耗尽。每个长事务占一根连接，并发一上来连接池见底，后续请求全部阻塞在获取连接那一步，表现为接口整体超时。
避免长事务的实操手段：把远程调用、文件 IO、大批量循环这些操作从事务里挪出去；批量插入分批提交，每批 500 到 1000 条；能拆成多个短事务的绝不合成一个。监控上可以在数据库侧查information_schema.innodb_trx，看trx_started超过一定阈值的事务，提前预警。
5. 编程式事务：注解搞不定的那些场景
5.1 TransactionTemplate 比注解更可控的地方
声明式事务方便，但它有个结构性限制：事务边界等于方法边界。一个方法里如果只有中间三行需要事务，前后还有别的操作，注解就没法精确控制。这时候该上TransactionTemplate。
@Autowired private TransactionTemplate transactionTemplate; public void processBatch(List<Order> orders) { for (Order order : orders) { // 每条订单一个独立事务，一条失败不影响其他 transactionTemplate.execute(status -> { orderMapper.insert(order); inventoryService.deduct(order.getSkuId()); return null; }); } }这段代码如果用@Transactional标在processBatch上，整批是一个事务，一条失败全批回滚。用TransactionTemplate包在循环里，粒度就精确到单条。批量导入、批量对账这类场景，这个差别很关键。
TransactionTemplate还能灵活地设置回滚条件。比如你想根据返回值决定是否回滚：
transactionTemplate.execute(status -> { int affected = orderMapper.updateStatus(orderId, "PAID"); if (affected == 0) { status.setRollbackOnly(); // 手动标记回滚 } return affected; });这种“业务判断决定回滚”的逻辑，注解方式很难表达，setRollbackOnly是编程式事务的杀手锏。
5.2 什么时候该放弃声明式事务
除了粒度和回滚条件，还有几种场景声明式事务力不从心。
需要精细控制传播行为又不想污染注解的：比如一个方法在 90% 的调用里用REQUIRED，在 10% 的调用里需要REQUIRES_NEW，注解写死了改不了，编程式可以按调用方传参决定。
事务里要执行回调或者事件发布的：Spring 的@TransactionalEventListener能解决一部分，但它依赖事务同步机制，遇到非事务上下文就失效。编程式事务里可以手动控制提交后再发事件，逻辑更清晰。
需要在一个方法里开多个独立事务的：比如“先写主表，主表写成功后异步写日志表”，异步那部分用REQUIRES_NEW会挂起主事务，用TransactionTemplate新开一个更直观。
5.3 分布式事务的边界：什么时候该停下来想想
单库事务靠数据库，跨库跨服务就得上分布式事务方案了。这块内容能写一本书，我这里只讲判断标准——什么时候真的需要分布式事务，什么时候是过度设计。
我见过太多团队在压根不需要强一致的场景上硬上分布式事务框架，结果复杂度飙升、性能暴跌，最后业务方还抱怨慢。判断标准其实很简单：这笔数据不一致，能不能靠事后对账 + 补偿修回来？能修回来的，就别上强一致，用本地消息表 + 定时补偿这套轻量方案，成本低、可观测性好。修不回来、且不一致会造成资金损失或者合规问题的，才值得上两阶段提交或者 TCC 这类方案。
还有一点：分布式事务的复杂度跟参与方数量呈指数关系。两个服务之间的事务还好控制，五个以上基本就是灾难现场。设计阶段就该尽量把事务边界收敛在一个服务内，跨服务的操作靠状态机 + 幂等来保证最终一致，这比事后救火省事得多。
还有个小技巧值得分享：不管用哪种分布式事务方案，每个参与方的接口都要做成幂等。网络抖动导致的重试是常态，幂等做不好，补偿逻辑会把你拖进更深的坑。幂等的实现方式，唯一索引、状态机校验、Redis 去重都行，选一种顺手的一直用下去。
我个人在实际项目里的体会是，Java 事务这块最难的从来不是记住七个传播行为或者四种隔离级别，而是建立“事务边界”这个意识。每写一个写库的方法，先问自己三件事：这个方法的事务边界在哪、失败了该回滚哪些数据、并发时会不会互相踩。这三问答清楚了，注解怎么写、传播行为怎么选，都是水到渠成的事。反过来，边界没想清楚，注解加得再花哨也只是心理安慰。
