spring为什么只回滚runtime

Spring框架中事务的回滚机制是基于运行时异常的。这是有原因的，下面我将详细解释为什么Spring只回滚运行时异常。

1. 事务回滚机制的目的是保证数据的一致性。当事务执行过程中发生异常，部分操作已经执行成功，而另一部分操作失败，这时候需要将已经执行成功的操作回滚，以确保数据的一致性。而运行时异常（RuntimeException）是指程序在运行时抛出的异常，这些异常通常是由程序逻辑错误或者外部不可控因素引起的，出现这些异常通常意味着程序出现了严重的问题，无法继续执行下去。因此，将事务回滚到最初的状态是保障数据一致性的必要操作。

2. 受检查异常（Checked Exception）是在编译期间就被检查的异常，程序需要在代码中明确处理或者声明抛出，否则无法通过编译。与运行时异常相比，受检查异常通常是可以被预料和处理的，在事务中捕获这类异常并进行回滚操作是没有必要的，因为这些异常通常可以被业务逻辑处理并进行相应的补救措施。

3. Spring框架设计时的目标之一就是尽可能地简化事务的使用。基于运行时异常的回滚机制，避免了在代码中捕获和处理受检查异常的繁琐操作，提高了开发效率。同时，这也是为了遵循Spring框架的声明式事务管理的设计原则，通过在方法或类上添加事务注解来管理事务，而不是在代码中显式地编写事务控制逻辑。

总结来说，Spring选择只回滚运行时异常是为了保障数据的一致性，并简化事务的使用。通过将异常分类，可以更好地处理异常情况，提高系统的可靠性和可维护性。

Spring框架中的事务管理器默认只会在抛出 unchecked 异常（即 RuntimeException 及其子类）时回滚事务，而不会在抛出 checked 异常时回滚事务。这个设计是有原因的，主要考虑以下几点：

1. 异常类型的分类：在Java中，异常分为两种类型，即 checked 异常和 unchecked 异常。Checked 异常需要显式地在方法签名中声明或捕获，而 Unchecked 异常则不需要。Spring框架遵循这个分类，设计只回滚 unchecked 异常是为了避免开发者滥用事务回滚的功能，同时保持代码的简洁性。

2. 事务边界的设置粒度：Spring框架提供了编程式和声明式两种方式来管理事务。在声明式事务管理中，通常会将事务边界设置在 service 层方法上，这样可以确保一次方法调用就是一个完整的事务操作。而且，将事务边界设置在更细粒度的方法中，会导致更频繁的事务提交和回滚，降低性能。

3. 对业务异常的处理：在实际开发中，程序可能会抛出很多业务相关的异常，这些异常通常属于 checked 异常。如果 Spring 框架默认回滚所有 checked 异常，可能会导致事务的频繁回滚，降低系统性能，也不符合我们对事务的认识。因此，对业务异常的处理应交由开发者自行处理，而不是直接回滚事务。

4. 可以通过配置支持回滚特定异常：虽然Spring框架默认只回滚 unchecked 异常，但是我们可以通过配置来实现对特定异常的回滚。在声明式事务管理中，可以通过@Transactional注解的rollbackFor属性来指定需要回滚的异常类型。通过这种方式，开发者可以灵活地控制事务的回滚行为，同时避免了不必要的性能损失。

5. 不同的事务管理策略：Spring框架支持多种事务管理策略，包括使用注解、XML配置、编程式事务管理等。不同的策略对事务回滚的默认行为有不同的处理方式。例如，在注解驱动的事务管理中，使用@Transactional注解默认只回滚 unchecked 异常；而在XML配置方式中，默认是回滚所有的异常。

综上所述，Spring框架设计只回滚 unchecked 异常是为了避免滥用事务回滚功能，减少性能损失，同时通过配置的方式来支持回滚特定异常，以保持系统的可控性和性能。

Spring框架对于事务的回滚策略主要包括两类：默认策略和自定义策略。在默认策略下，Spring仅会回滚运行时异常（Runtime Exception），而对于受检异常（Checked Exception）则默认不会回滚。

Spring只回滚运行时异常的原因如下：

1. 事务边界： 在使用Spring事务管理的情况下，Spring会在@Transactional注解标注的方法开始执行时开启一个事务，在方法执行完毕后结束事务。Spring事务的默认传播行为为REQUIRED，即如果当前方法已经处于一个事务中，则会加入该事务；如果当前方法尚未处于一个事务中，则会开启一个新的事务。因此事务的边界与方法的边界是一致的。

2. 事务的隔离级别：Spring默认的事务隔离级别为READ_COMMITTED，在该隔离级别下，事务只能看到已经提交的数据，这也是数据库默认的隔离级别。因此，如果在一个事务中发生了运行时异常，事务将会被回滚，回滚到事务开启之前的状态，从而保证事务的一致性。

3. 其他操作的回滚影响：事务在执行过程中涉及到多个操作，如果所有的异常都导致事务的回滚，可能会导致一些不必要的回滚操作。比如在一个事务中执行了一些查询操作，当查询操作出现异常时，回滚事务是没有必要的，因为查询操作不会对数据造成变动。因此，Spring选择只对运行时异常进行回滚，对其他异常不进行回滚，以减少对系统性能的影响。

如果需要对受检异常也进行回滚，可以通过配置TransactionAspectSupport类的setRollbackOnly方法来实现自定义的回滚策略。例如，可以通过捕获受检异常并手动设置事务的回滚状态来实现对受检异常的回滚。