Spring事务本质是AOP代理+TransactionManager协作链：通过动态代理包裹方法，利用ThreadLocal绑定事务上下文，按传播行为决策连接复用与同步状态，并在异常或正常时触发回滚或提交，最终依赖数据库连接池与隔离级别落地执行。
Java事务管理面试，现在早就不考“@Transactional加在哪”这种表面问题了。面试官真正想确认的是：你能不能从注解一路看到Spring AOP代理、事务同步管理器、数据库连接绑定、传播行为决策，甚至异常回滚的时机和边界。下面这四块，是2026年大厂高频追问的核心。
一、@Transactional不是魔法，它背后是一整套AOP+TransactionManager协作链
Spring事务本质是基于AOP的声明式代理。当你标注@Transactional，Spring会在运行时生成代理对象（JDK动态代理或CGLIB），把方法调用包裹进一个环绕通知。关键流程是：
- 前置：根据事务属性（如propagation、isolation）创建TransactionInfo，绑定当前线程的TransactionSynchronizationManager
- 执行目标方法：invocation.proceedWithInvocation()
- 异常时：调用completeTransactionAfterThrowing()，按rollbackFor规则决定是否回滚
- 正常返回：调用commitTransactionAfterReturning()，提交事务
- 无论成功失败，finally中都会cleanupTransactionInfo，清理ThreadLocal里的上下文
注意：事务上下文靠ThreadLocal维护，所以异步线程（比如new Thread()或@Async）默认不继承事务——这不是bug，是设计使然。
二、事务失效的5个典型场景，每个都对应底层机制断点
失效不是注解没起作用，而是事务上下文根本没建立或中途丢失。常见原因：
立即学习“Java免费学习笔记（深入）”；
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 自调用失效：类内无代理的方法直接调用另一个@Transactional方法，绕过了AOP拦截器
- 非public方法：Spring AOP只对public方法织入，private/protected方法加了注解也无效
- 异常被吞：try-catch捕获了异常但没抛出，事务切面感知不到异常，不会触发回滚
- 错误的异常类型：默认只对RuntimeException及其子类回滚，检查型异常（如IOException）需显式配置rollbackFor
- 数据库引擎不支持事务：比如MySQL用MyISAM表，即使加了@Transactional，commit也毫无意义
三、事务传播行为不是背概念，要能画出嵌套调用时的连接与同步状态流转
Propagation.REQUIRED是默认值，但它的真实含义是：“如果有活跃事务就加入，没有就新建”。面试官常拿两层service调用让你画状态图：
- 外层无事务 → 内层开启新事务 → 外层结束提交，内层跟着提交
- 外层有事务 → 内层复用同一Connection → 外层回滚，内层也必须回滚（哪怕内层自己try-catch）
- Propagation.REQUIRES_NEW：内层一定新建独立事务，挂起外层事务，各自提交/回滚互不影响
- Propagation.NESTED：JDBC支持savepoint的场景下，内层是外层的子事务，可单独回滚到savepoint而不影响外层
关键细节：Connection是否复用、TransactionSynchronization是否注册、挂起时的资源快照怎么保存——这些才是拉开差距的地方。
四、事务与连接池、数据库隔离级别的联动，才是线上问题的根源
事务行为最终落地在JDBC Connection上。很多“事务不生效”的问题，其实是连接池或数据库配置导致的：
- HikariCP默认autoCommit=true，如果手动设为false又忘了commit，连接会一直占用且不释放
- MySQL默认隔离级别是REPEATABLE READ，但Spring声明的ISOLATION_READ_COMMITTED不会自动生效，得看数据库实际配置
- 脏读/幻读复现不了？可能因为测试时单线程执行，没模拟并发；也可能因为InnoDB的间隙锁（gap lock）让幻读表现成“锁等待”
- 事务超时：不仅@Transactional(timeout=5)起作用，Druid/Hikari也有maxWait、connectionTimeout等参数，它们共同决定“卡住的事务”何时被强制中断
真正有经验的候选人，会把@Transactional、DataSource、Connection、MySQL隔离级别、锁机制这几层串起来讲，而不是孤立背定义。
