spring事务传播机制共有七种，包括required（默认）、supports、mandatory、requires_new、not_supported、never和nested，各自决定了事务方法调用时的事务边界与执行方式；隔离级别包括default、read_uncommitted、read_committed、repeatable_read和serializable，用于控制并发事务间的数据可见性与一致性；选择时需根据业务需求、数据一致性要求及并发性能进行权衡；使用时可通过@transactional注解或xml配置实现声明式事务管理，也可通过transactiontemplate或platformtransactionmanager实现编程式事务管理；常见事务失效原因包括自调用问题、异常处理不当、方法非public等，需针对性解决。
Spring事务传播机制和隔离级别是控制多个事务方法相互调用时，事务如何传递和隔离的关键。简单来说，传播机制决定了当一个事务方法调用另一个事务方法时，新方法是加入现有事务，还是开启一个新事务；隔离级别则定义了多个并发事务之间的数据可见性和相互影响程度。
Spring事务传播机制和隔离级别是保证数据一致性和并发性能的重要手段。
Spring事务传播机制有哪些？
Spring定义了七种传播行为，每种行为都影响着事务的边界和作用范围：
立即学习“Java免费学习笔记（深入）”；
- REQUIred (默认): 如果当前存在事务，则加入该事务；如果当前没有事务，则创建一个新的事务。这是最常用的传播行为。
- SUPPORTS: 如果当前存在事务，则加入该事务；如果当前没有事务，则以非事务方式继续执行。
- MANDATORY: 如果当前存在事务，则加入该事务；如果当前没有事务，则抛出异常。
- REQUIRES_NEW: 无论当前是否存在事务，都创建一个新的事务。如果当前存在事务，则将当前事务挂起。
- NOT_SUPPORTED: 以非事务方式执行操作，如果当前存在事务，则将当前事务挂起。
- NEVER: 以非事务方式执行，如果当前存在事务，则抛出异常。
- NESTED: 如果当前存在事务，则创建一个嵌套事务，作为当前事务的一个保存点。如果当前没有事务，则创建一个新的事务。
选择合适的传播行为取决于具体的业务场景。例如，一个核心的业务方法通常使用REQUIRED，而一些辅助方法，如日志记录，可能使用SUPPORTS或NOT_SUPPORTED。REQUIRES_NEW通常用于需要独立事务控制的操作，例如，在主事务失败后仍然需要执行的操作。NESTED适用于需要回滚部分操作的情况，例如，在一个大的事务中，某个子操作可能会失败，但我们不希望整个事务都回滚。
Spring事务隔离级别有哪些？
Spring事务隔离级别定义了并发事务之间相互隔离的程度，防止出现脏读、不可重复读和幻读等问题。
- DEFAULT: 使用数据库默认的隔离级别。不同数据库的默认隔离级别可能不同。
- READ_UNCOMMITTED: 允许读取尚未提交的数据。可能导致脏读。
- READ_COMMITTED: 只能读取已提交的数据。可以防止脏读，但可能出现不可重复读。
- REPEATABLE_READ: 在同一个事务中多次读取同一数据，结果应该一致。可以防止脏读和不可重复读，但可能出现幻读。
- SERIALIZABLE: 提供最高的隔离级别。强制事务串行执行，可以防止脏读、不可重复读和幻读。
隔离级别越高，并发性能越低。READ_UNCOMMITTED并发性能最高，但数据一致性最差。SERIALIZABLE数据一致性最好，但并发性能最差。大多数数据库默认使用READ_COMMITTED或REPEATABLE_READ。选择合适的隔离级别需要在数据一致性和并发性能之间进行权衡。例如，对于对数据一致性要求极高的场景，可以使用SERIALIZABLE。对于并发量高，但允许一定程度数据不一致的场景，可以使用READ_COMMITTED。
如何在Spring中使用事务传播机制和隔离级别？
可以通过@Transactional注解来配置事务传播机制和隔离级别。
import org.springframework.transaction.annotation.Transactional; @Service public class MyService { @Transactional(propagation = Propagation.REQUIRED, isolation = Isolation.READ_COMMITTED) public void myMethod() { // 业务逻辑 } @Transactional(propagation = Propagation.REQUIRES_NEW) public void anotherMethod() { // 业务逻辑 } }
@Transactional注解可以应用于类或方法。应用于类时，该类的所有public方法都将具有事务特性。propagation属性指定传播行为，isolation属性指定隔离级别。
除了使用@Transactional注解，还可以使用XML配置来配置事务传播机制和隔离级别。
<tx:advice id="txAdvice" transaction-manager="transactionManager"> <tx:attributes> <tx:method name="myMethod" propagation="REQUIRED" isolation="READ_COMMITTED"/> <tx:method name="anotherMethod" propagation="REQUIRES_NEW"/> </tx:attributes> </tx:advice> <aop:config> <aop:pointcut id="myPointcut" expression="execution(* com.example.MyService.*(..))"/> <aop:advisor advice-ref="txAdvice" pointcut-ref="myPointcut"/> </aop:config>
XML配置更加灵活，可以对不同的方法应用不同的事务配置。
Spring事务管理中常见的坑有哪些？
在使用Spring事务管理时，可能会遇到一些问题。
- 自调用问题: 如果一个方法内部调用自己的另一个@Transactional方法，事务传播机制可能失效。这是因为Spring的AOP代理机制导致的。解决方法是将内部调用改为从spring容器中获取Bean，然后调用其方法。
- 异常处理不当: Spring事务默认只对RuntimeException及其子类进行回滚。如果抛出Checked Exception，事务不会回滚。可以通过@Transactional注解的rollbackFor属性指定需要回滚的异常类型。
- 数据库连接未正确关闭: 如果数据库连接未正确关闭，可能导致连接池耗尽，影响系统性能。可以使用try-with-resources语句或Spring的TransactionTemplate来确保数据库连接正确关闭。
- 长事务: 长事务会占用数据库资源，影响系统并发性能。应该尽量避免长事务，将大事务拆分成多个小事务。
理解这些常见的坑，可以帮助我们更好地使用Spring事务管理，避免出现意外问题。
如何选择合适的事务传播行为和隔离级别？
选择合适的事务传播行为和隔离级别需要根据具体的业务场景进行权衡。
- 考虑业务需求: 是否需要事务？是否需要独立的事务？是否需要回滚部分操作？
- 考虑数据一致性要求: 是否允许脏读、不可重复读或幻读？
- 考虑并发性能: 是否需要支持高并发？
一般来说，对于核心的业务方法，应该使用REQUIRED传播行为和READ_COMMITTED或REPEATABLE_READ隔离级别。对于辅助方法，可以使用SUPPORTS或NOT_SUPPORTED传播行为。对于需要独立事务控制的操作，可以使用REQUIRES_NEW传播行为。对于需要回滚部分操作的情况，可以使用NESTED传播行为。
在实际开发中，可以先选择一个合适的传播行为和隔离级别，然后进行测试，观察系统的性能和数据一致性是否满足要求。如果性能不满足要求，可以尝试降低隔离级别。如果数据一致性不满足要求，可以尝试提高隔离级别。
Spring事务失效的常见原因及解决方案
Spring事务失效可能由多种原因引起，以下是一些常见情况及相应的解决方案：
- 未被Spring管理的Bean: 确保使用了@Component, @Service, @Repository等注解将Bean纳入Spring容器管理。
- 方法不是public: Spring AOP是基于代理实现的，只能代理public方法。
- 自调用问题: 如前所述，内部调用@Transactional方法会导致事务失效。解决方案是注入Bean，通过Bean调用方法。
- 异常被捕获: 如果在@Transactional方法中捕获了异常，且没有重新抛出，Spring将认为事务已经成功完成，不会进行回滚。应该在捕获异常后重新抛出，或者使用TransactionAspectSupport.currentTransactionStatus().setRollbackOnly()手动设置回滚。
- 错误的传播行为: 选择了错误的传播行为可能导致事务没有被正确传播。例如，使用NOT_SUPPORTED会导致方法在非事务环境下执行。
- 数据库不支持事务: 某些数据库可能不支持事务，或者事务功能未开启。
- 使用了错误的隔离级别: 某些隔离级别可能导致数据不一致，或者出现死锁。
- 数据源配置错误: 检查数据源配置是否正确，包括URL、用户名、密码等。
排查事务失效问题需要仔细分析代码和配置，并结合日志进行调试。
如何使用编程式事务管理？
除了声明式事务管理，Spring还提供了编程式事务管理，允许开发者手动控制事务的边界。
可以使用TransactionTemplate或PlatformTransactionManager来实现编程式事务管理。
使用TransactionTemplate:
import org.springframework.transaction.TransactionStatus; import org.springframework.transaction.support.TransactionCallbackWithoutResult; import org.springframework.transaction.support.TransactionTemplate; @Service public class MyService { @Autowired private TransactionTemplate transactionTemplate; public void myMethod() { transactionTemplate.execute(new TransactionCallbackWithoutResult() { @Override protected void doInTransactionWithoutResult(TransactionStatus status) { // 业务逻辑 // 如果发生异常，可以使用status.setRollbackOnly()手动设置回滚 } }); } }
使用PlatformTransactionManager:
import org.springframework.transaction.PlatformTransactionManager; import org.springframework.transaction.TransactionDefinition; import org.springframework.transaction.TransactionStatus; import org.springframework.transaction.support.DefaultTransactionDefinition; @Service public class MyService { @Autowired private PlatformTransactionManager transactionManager; public void myMethod() { TransactionDefinition def = new DefaultTransactionDefinition(); TransactionStatus status = transactionManager.getTransaction(def); try { // 业务逻辑 transactionManager.commit(status); } catch (Exception e) { transactionManager.rollback(status); } } }
编程式事务管理更加灵活，可以精细地控制事务的边界，但代码也更加复杂。一般来说，声明式事务管理更常用，只有在需要特殊控制事务边界的情况下才会使用编程式事务管理。
