Spring嵌套事务捕获异常后主事务仍回滚，如何兼顾性能处理？

这是Spring事务传播机制里非常常见的“踩坑点”，我来给你捋清楚为啥会这样，以及除了REQUIRES_NEW之外的其他思路：

为啥捕获了异常还是会回滚？ #

默认情况下，Spring的@Transactional传播行为是Propagation.REQUIRED——意思是如果当前已经存在事务，就加入这个事务；如果没有，才新建一个。

在你的代码里，AService.methodOne开启了一个事务，BService.methodTwo的事务会直接加入到这个已有事务中。当methodTwo抛出RuntimeException时（这是Spring事务默认触发回滚的异常类型），不管外层有没有捕获这个异常，Spring的事务管理器已经把整个事务标记为必须回滚的状态了。哪怕你后续执行了aRepo.save(new A())，最后事务提交的时候，因为之前已经被标记回滚，所有操作都会被撤销。

可选的解决方案 #

1. 移除BService.methodTwo的@Transactional注解 #

看你的示例代码，methodTwo里并没有任何数据库操作，只是抛出异常——这种情况下它根本不需要事务啊！直接去掉它的@Transactional，整个问题就解决了：

@Service
public class BService{
    // 去掉@Transactional，不再加入外层事务
    public void methodTwo(){
        if(true) throw new RuntimeException();
    }
}

这样methodTwo抛出的异常只会被外层捕获，不会影响methodOne的事务状态，aRepo.save就能正常提交。

2. 调整BService.methodTwo的事务回滚规则 #

如果methodTwo确实需要事务，但你希望它抛出异常时只回滚自己的操作，不标记整个外层事务回滚，可以用noRollbackFor属性：

@Service
public class BService{
    @Transactional(noRollbackFor = RuntimeException.class)
    public void methodTwo(){
        if(true) throw new RuntimeException();
    }
}

这个配置会告诉Spring：即使methodTwo抛出RuntimeException，也不要触发事务回滚。不过要注意：如果methodTwo里有数据库操作，这些操作也不会回滚，所以得确保业务逻辑允许这种情况。

3. 改用REQUIRES_NEW（权衡性能） #

你提到的Propagation.REQUIRES_NEW确实会开启一个独立的新事务，它的开销主要来自于新事务的创建和提交/回滚，但在大多数业务场景下，这种性能损耗是可以接受的——除非这个方法被极高频率地调用（比如每秒上千次）。如果你的业务逻辑必须让methodTwo的事务独立回滚，同时不影响外层，这也是合理的选择：

@Service
public class BService{
    @Transactional(propagation = Propagation.REQUIRES_NEW)
    public void methodTwo(){
        if(true) throw new RuntimeException();
    }
}

总结 #

优先检查BService.methodTwo是否真的需要事务——如果不需要，直接移除注解是最简单高效的方案。如果必须保留事务，根据业务逻辑选择noRollbackFor或者REQUIRES_NEW即可。

内容的提问来源于stack exchange，提问作者the-red-paintings