Spring事务核心是用AOP代理+ThreadLocal绑定Connection实现ACID：原子性靠try-catch回滚，一致性靠业务与约束协同，隔离性与持久性由数据库保障；失效主因是代理未生效（如自调用、非public方法）或上下文丢失（如多线程、异常被捕获）。
Java 中事务管理的面试题，核心不是背定义，而是讲清“为什么这么设计”和“哪里容易出错”。回答时紧扣数据库事务本质（ACID）与 Spring 封装逻辑（AOP + ThreadLocal + Connection 绑定）两条主线，就能稳住大部分问题。
事务的 ACID 怎么理解才不空泛？
别只复述概念，用转账场景串起来说：
- 原子性：扣 A 账户、加 B 账户必须一起成功或一起失败。Spring 通过在方法前后加 try-catch，异常时调用 rollback 实现；底层靠 JDBC 的 connection.setAutoCommit(false) 控制。
- 一致性：不是 Spring 保证的，是业务逻辑 + 数据库约束共同保障。比如外键、check、唯一索引，还有你写在 service 层的校验（如余额不能为负）。Spring 的事务只管“执行过程不中断”，不管“业务是否合理”。
- 隔离性：由数据库实现，Spring 不参与。MySQL 默认 Repeatable Read，靠 MVCC（undo log + readview）+ 间隙锁解决幻读；Oracle 默认 Read Committed，只靠 MVCC。
- 持久性：依赖数据库的 redo log 刷盘机制。Spring commit 后只是把 SQL 发给数据库，真正落盘是 MySQL 自己控制的。
@Transactional 失效的典型场景有哪些？
本质是代理失效或事务上下文没绑定成功，常见有五类：
- 方法不是 public —— Spring AOP 代理默认只拦截 public 方法；
- 自调用（this.method()）—— 没走代理对象，事务注解不生效；
- 异常被 catch 吞掉且没主动 throw —— Spring 只对未捕获的 RuntimeException 和 Error 回滚；
- 同一类中非事务方法调用事务方法 —— 仍是 this 调用，绕过代理；
- 事务方法抛出的是 checked 异常（如 IOException），但没在 @Transactional 中配置 rollbackFor。
传播行为（propagation）怎么选？
关键看“当前有没有事务”以及“要不要共享事务上下文”：
立即学习“Java免费学习笔记（深入）”；
- REQUIRED（默认）：有就加入，没有就新建。适合绝大多数业务方法；
- REQUIRES_NEW：总是新建事务，挂起当前事务。适合日志记录、消息发送等需要独立提交的子操作；
- NESTED：嵌套事务，支持 savepoint 回滚。MySQL 不原生支持，需开启 allowNestedTransactions；
- SUPPORTS：有就加入，没有就不开事务。适合纯查询方法，避免无谓开销；
- NOT_SUPPORTED：挂起当前事务，以非事务方式运行。适合发邮件、调外部 HTTP 接口等不涉及 DB 的操作。
隔离级别和脏读/不可重复读/幻读怎么对应？
记住一句话：隔离级别是数据库能力，Spring 只负责把设置传下去（如 isolation = Isolation.REPEATABLE_READ）。
- Read Uncommitted：能看到别人未提交的数据 → 允许脏读；
- Read Committed：只能读已提交数据 → 防脏读，但两次读可能不同（B 更新后提交）→ 不可重复读；
- Repeatable Read：第一次读取后，该行被加锁或生成快照 → 防脏读、不可重复读，但 B 插入新行仍可见 → 幻读；
- Serializable：全表加读锁或串行执行 → 所有问题都防，但性能最差。
MySQL InnoDB 的 Repeatable Read 通过 next-key lock（行锁 + 间隙锁）在多数场景下也避免了幻读，但严格来说，标准 SQL 定义中它并不解决幻读。
