Spring的事务机制详解：3个核心原理让你面试不再卡壳
面试被问到 Spring 事务隔离级别时，你是不是脑子一片空白？明明用了 @Transactional，为什么数据还是不一致？别慌，今天我们把 Spring 事务的底层逻辑拆碎了讲，从 JDBC 连接池到 AOP 拦截器，带你彻底搞懂这套机制。掌握这些最佳实践，不仅能应付面试，更能解决生产环境中的脏读、幻读难题。
一句话原理：基于代理的 JDBC 事务控制
Spring 事务的核心本质，是对 JDBC Connection 对象的状态管理。它通过 AOP 动态代理，在目标方法执行前后插入事务控制逻辑，将业务代码的执行包裹在 Connection 的 commit 和 rollback 之间。这不是魔法，而是对 Java 标准事务 API 的优雅封装。
类比解释：餐厅服务员的“订单打包”流程
想象你是一家餐厅的服务员（Spring 事务管理器），顾客点了一桌菜（业务代码）。服务员不会每做一道菜就端给顾客，而是等所有菜做完，统一检查无误后（验证逻辑），再一次性打包送到前台（Commit）。如果中间发现某道菜没做熟（抛出异常），服务员会立刻通知厨房全部重新做，而不是把做好的端走（Rollback）。
关键在于：服务员手里只有一个托盘（JDBC Connection）。如果托盘满了或者被其他服务员抢走了，他就没法完成打包。这就是为什么我们需要理解 Spring 是如何持有和管理这个“托盘”的。
源码剖析：TransactionInterceptor 如何拦截你的方法
Spring 事务的实现核心在于 TransactionInterceptor。当你的服务类被标记为 @Transactional 时，Spring 容器会为其创建一个代理对象。当你调用该方法时，实际执行的是代理对象的逻辑。
// 简化版的 TransactionInterceptor 核心逻辑
public Object invoke(MethodInvocation invocation) throws Throwable {// 1. 获取当前方法的事务属性（隔离级别、传播行为等）TransactionAttribute txAttr = getTransactionAttributeSource().getTransactionAttribute(invocation.getMethod());// 2. 如果方法没有事务属性，直接执行原方法if (txAttr == null) {return invocation.proceed();}// 3. 开启事务：从 DataSource 获取 Connection，并绑定到当前线程TransactionStatus status = transactionManager.getTransaction(txAttr);try {// 4. 执行业务逻辑Object result = invocation.proceed();// 5. 提交事务：调用 Connection.commit()transactionManager.commit(status);return result;} catch (Throwable ex) {// 6. 回滚事务：调用 Connection.rollback()transactionManager.rollback(status);throw ex;}
}这段伪代码揭示了真相：Spring 并没有修改你的业务代码，它只是在你的代码外面套了一层“壳”。这个壳负责管理 Connection 的生命周期。
流程描述：从方法调用到数据库落盘
让我们跟踪一次典型的事务执行流程，看看数据是如何从内存流向磁盘的：代理拦截：调用 userService.save()，请求被 JdkDynamicProxy 或 CGLIB 代理拦截。
属性解析：TransactionInterceptor 读取 @Transactional 注解，解析出 propagation=REQUIRED，isolation=DEFAULT。
获取连接：DataSourceTransactionManager 从连接池（如 HikariCP）中获取一个 Connection 对象。
绑定线程：该 Connection 被放入 ThreadLocal 中，确保当前线程内的所有 DAO 操作都使用同一个连接。这是理解“事务内共享连接”的关键。
执行 SQL：MyBatis 或 JPA 执行 SQL 时，会从 ThreadLocal 中取出这个 Connection，而不是重新从连接池获取。
状态判断：方法执行完毕，无异常，调用 connection.commit()。
释放资源：Connection 归还连接池，ThreadLocal 清除引用。关键点：如果在第 5 步中，你手动调用了 connection.commit()，那么第 6 步的 Spring 事务提交就会失效，因为数据库层面已经提交了。这就是很多开发者踩坑的地方。
实战验证：为什么你的事务失效了？
在真实项目中，事务失效是最常见的问题。以下三个场景，你能识别出几个？
场景一：自调用失效
@Service
public class OrderService {public void createOrder() {// 这里的调用不会触发事务，因为 this 是原始对象，不是代理对象this.validateStock(); }@Transactionalpublic void validateStock() {// 业务逻辑}
}原因：Spring 事务基于代理，this 指向的是原始对象，没有经过 AOP 拦截。
解决方案：注入自身代理，或使用 AopContext.currentProxy()。
场景二：异常被吞掉
@Transactional
public void pay() {try {deductBalance();} catch (Exception e) {log.error(支付失败, e);// 异常被捕获，没有抛出，Spring 认为方法执行成功}
}原因：Spring 默认只对未检查异常（RuntimeException）和 Error 进行回滚。如果异常被 try-catch 吞掉，Spring 无法感知错误。
解决方案：在 @Transactional 中指定 rollbackFor = Exception.class，或者在 catch 块中手动标记回滚 TransactionAspectSupport.currentTransactionStatus().setRollbackOnly()。
场景三：非 public 方法
@Transactional
void updateStatus() {// 业务逻辑
}原因：Spring 事务默认只拦截 public 方法。虽然 CGLIB 可以代理 public 和非 public 方法，但 Spring 的 AnnotationTransactionAttributeSource 默认只识别 public 方法上的注解。
解决方案：将方法改为 public，或自定义 TransactionAttributeSource。
进阶技巧：隔离级别与并发控制
在市政公用工程中，涉及资金结算、资源分配等场景，数据一致性要求极高。理解事务隔离级别至关重要。隔离级别
脏读
不可重复读
幻读
适用场景READ_UNCOMMITTED
是
是
是
几乎不用，性能最高但风险最大READ_COMMITTED
否
是
是
通用场景，Oracle 默认REPEATABLE_READ
否
否
是
MySQL 默认，通过 MVCC 解决大部分并发问题SERIALIZABLE
否
否
否
极高一致性要求，性能最低注意：MySQL InnoDB 在 REPEATABLE_READ 级别下，通过 Next-Key Locking 机制，实际上避免了大部分幻读问题。但如果你使用的是 MyISAM 引擎或特定数据库，隔离级别的表现可能不同。
最佳实践建议：短事务原则：事务应尽可能短，避免在事务内进行远程调用（RPC/HTTP），这会长时间占用数据库连接，导致连接池耗尽。
只读优化：对于查询操作，使用 @Transactional(readOnly = true)，Spring 可以对此进行优化，如使用主从库的从库查询。
传播行为：默认使用 REQUIRED。如果方法不需要事务，明确使用 NOT_SUPPORTED 或 SUPPORTS，避免不必要的事务开销。底层细节：JDBC 规范与 Spring 的映射
根据 JDBC 规范（RFC 相关标准虽不直接定义 JDBC，但遵循类似的连接管理思想，具体参考《Java Database Connectivity Reference Manual》），Connection 对象是事务的载体。Spring 的 PlatformTransactionManager 接口定义了一组标准方法，将底层数据库的差异抽象化。
例如，HibernateTransactionManager 和 JtaTransactionManager 都实现了这个接口，但内部实现不同。JTA（Java Transaction API）支持跨数据源的事务，适用于分布式系统。而在单体应用中，JDBC 事务管理器更为轻量高效。
在市政公用工程系统中，如果涉及多个微服务（如计费服务、工单服务、资源服务），可能需要引入 JTA 或分布式事务方案（如 TCC、Saga）。但此时，Spring 的本地事务管理依然是基础，每个微服务内部仍需保证自身数据的一致性。
总结与互动
Spring 事务不是黑盒，它是 AOP、JDBC 连接管理和异常处理的完美结合。理解代理机制、线程绑定的 Connection、以及异常传播路径，是掌握事务最佳实践的关键。
在实际开发中，不要迷信框架，要清楚每一步发生了什么。当你再次面对“为什么事务没生效”的问题时，你能从代理、异常、方法可见性三个维度快速定位问题，这才是真正的技术深度。
你在项目里踩过这个坑吗？比如事务嵌套导致的意外回滚，或者连接池泄露？评论区聊聊你的经历，我们一起避坑。
