Spring事务解析

一、事务回滚失效的常见场景

@Transactional注解看似简单，但在实际使用中易因配置或代码逻辑问题导致回滚失效，以下是6种高频失效场景及原因分析：

方法非public修饰：Spring AOP（面向切面编程）的动态代理机制仅拦截public方法，非public方法（如private、protected）上的@Transactional注解会被忽略，事务完全不生效；
同一类内自调用问题：若在同一类中，方法A直接调用本类标注@Transactional的方法B，由于调用方是目标对象本身而非Spring生成的代理对象，AOP无法拦截方法B的调用，事务配置失效；
异常被捕获但未重新抛出：若方法内捕获了异常（如try-catch），但未在catch块中重新抛出异常（如throw new RuntimeException()），Spring无法感知异常发生，会认为事务执行成功，不会触发回滚；
抛出的异常非RuntimeException/Error：Spring事务默认仅对RuntimeException（运行时异常）和Error（错误）触发回滚，对检查型异常（如IOException、SQLException）不回滚，需通过@Transactional(rollbackFor = 异常类.class)显式指定；
配置了不回滚的异常类型：若通过@Transactional(noRollbackFor = 异常类.class)配置了"不回滚的异常"，当方法抛出该异常时，即使是RuntimeException，事务也不会回滚；
数据库引擎不支持事务：事务的实现依赖数据库引擎，若使用MyISAM引擎（MySQL默认引擎之一），由于其本身不支持事务，Spring事务配置再正确也无法生效，需切换为InnoDB引擎。

事务传播模式定义了多个标注@Transactional的方法相互调用时，事务的传递规则------核心解决"子方法是否加入父方法事务、如何独立控制事务"的问题。Spring提供7种传播模式，以下是最常用的5种核心模式：

REQUIRED（默认模式）：若父方法A已有事务，子方法B直接加入A的事务，两者共用一个事务；若A没有事务，B则新建一个独立事务；
REQUIRES_NEW：无论父方法A是否有事务，子方法B都会新建一个独立事务，A的事务会被挂起。A与B的事务完全隔离，互不影响（如A回滚不会导致B回滚，反之亦然）；
NESTED：若父方法A有事务，子方法B会在A的事务内创建一个"嵌套子事务"（通过数据库保存点实现，有独立回滚边界）；若A没有事务，B则新建事务。嵌套子事务依赖父事务，父事务回滚时子事务也会回滚，但子事务单独回滚不会影响父事务；
SUPPORTS：若父方法A有事务，子方法B加入A的事务；若A没有事务，B则以非事务方式执行（无事务保护）；
MANDATORY：子方法B必须在父方法A的事务内执行，若A没有事务，B会直接抛出IllegalTransactionStateException异常，强制要求父事务存在。

实际开发中，REQUIRED、REQUIRES_NEW、NESTED是最易混淆的三种模式，其核心差异体现在"事务独立性"与"回滚影响范围"上：

REQUIRED vs REQUIRES_NEW：前者子事务与父事务是同一个事务，回滚相互影响（父滚则子滚，子滚则父滚）；后者是两个独立事务，回滚互不影响（典型场景：订单创建失败回滚，但日志记录事务独立提交，避免日志丢失）；
NESTED vs REQUIRES_NEW：NESTED的子事务依赖父事务（父事务回滚，子事务必回滚），子事务是父事务的一部分；REQUIRES_NEW的子事务完全独立于父事务（父事务回滚，子事务不受影响），两者是平行关系。

Spring事务传播行为的底层实现，本质是数据库连接（Connection）的"复用/新建"策略------同一事务内的所有操作，必须保证使用同一个Connection，否则无法保证事务的原子性（要么全成，要么全败）。具体实现逻辑如下：

REQUIRED传播行为：子方法直接复用父方法的Connection，加入父事务的事务上下文，所有操作在同一个Connection中执行，提交/回滚由父事务统一控制；
REQUIRES_NEW传播行为：子方法会新建一个独立的Connection，开启新事务，同时将父事务的Connection挂起；子事务执行完成后，再恢复父事务的Connection继续执行，两个事务的Connection完全独立；
隔离级别与数据一致性：数据库层面通过"事务隔离级别"（如Read Uncommitted、Read Committed、Repeatable Read、Serializable）保证数据一致性，Spring事务的隔离级别默认跟随数据库（MySQL默认是Repeatable Read，可避免不可重复读问题）。Spring事务传播行为是"Connection的管理策略"，而隔离级别是"同一事务内数据可见性的规则"，两者共同保障事务安全。

仅添加@Transactional注解无法保证事务生效，需满足以下5个必要条件，缺一不可：

数据源支持事务：数据库引擎必须支持事务（如MySQL InnoDB、Oracle），MyISAM等不支持事务的引擎会导致事务失效；
事务管理器配置正确：需在Spring配置类中声明事务管理器（如DataSourceTransactionManager），并绑定数据源（确保事务管理器与操作的数据源一致）；
同一事务内使用同一个Connection：Spring通过ThreadLocal将Connection绑定到当前线程，确保同一线程内的所有数据库操作复用同一个Connection，这是事务原子性的核心保障；
Connection关闭自动提交：事务执行前，Spring会自动将Connection的autoCommit属性设为false（关闭自动提交），避免每执行一条SQL就自动提交，确保所有操作统一提交/回滚；
无手动关闭Connection：Connection的创建、提交、回滚、关闭需由Spring事务管理器统一管理，若手动调用connection.close()，会导致事务管理器无法控制Connection，事务失效。

声明式事务（@Transactional）虽便捷，但需遵循以下实践规范，避免踩坑：

方法必须是public：严格遵守public修饰符要求，非public方法的事务配置无效；
避免内部调用：禁止同一类内方法自调用（如A调用本类B），若需实现类似逻辑，可通过Spring上下文获取当前类的代理对象，再调用目标方法（如applicationContext.getBean(本类.class).B()）；
明确异常回滚类型：若方法抛出检查型异常（如IOException），需通过rollbackFor显式指定回滚的异常类型（如@Transactional(rollbackFor = IOException.class)），避免回滚失效；
合理选择隔离级别：不盲目追求高隔离级别，高隔离级别（如Serializable）会通过加锁降低数据库并发性能，大多数业务场景使用默认的Repeatable Read即可；
谨慎选择传播行为：避免滥用REQUIRES_NEW，过多独立事务会增加数据库连接开销和锁竞争压力；核心业务（如订单创建、支付）优先使用REQUIRED，确保事务一致性；日志记录、非核心数据插入等场景可使用REQUIRES_NEW，避免核心事务回滚影响非核心操作。