Spring boot @Transactionnal重叠式不好的做法？

Spring Boot中的@Transactionnal注解用于标记一个方法或类需要进行事务管理。当一个方法被标记为@Transactionnal时，Spring会在方法执行前开启一个事务，并在方法执行后根据方法的执行结果决定是提交事务还是回滚事务。

重叠式的@Transactionnal注解是指在一个方法中嵌套使用多个@Transactionnal注解，例如在一个方法A中调用了另一个带有@Transactionnal注解的方法B。这种做法是不好的，原因如下：

1. 性能问题：每个@Transactionnal注解都会开启一个新的事务，嵌套使用多个@Transactionnal注解会导致事务的嵌套，增加了事务管理的开销，降低了性能。
2. 死锁风险：嵌套使用多个@Transactionnal注解可能会导致死锁的风险。当多个事务同时竞争相同的资源时，如果事务的提交和回滚顺序不当，就可能导致死锁的发生。
3. 代码可读性差：重叠式的@Transactionnal注解会使代码变得复杂，可读性差。阅读代码时很难理解每个事务的边界和作用。

为了避免重叠式的@Transactionnal注解带来的问题，可以采取以下做法：

1. 尽量避免在一个方法中嵌套使用多个@Transactionnal注解，尽量将事务的边界划分清楚，使每个方法只负责一个事务。
2. 如果确实需要在一个方法中调用另一个带有@Transactionnal注解的方法，可以考虑将被调用的方法提取为一个独立的服务方法，并在该方法上添加@Transactionnal注解，然后在调用方法中调用该服务方法。
3. 合理设计事务的传播行为，使用适当的事务传播属性来控制事务的边界和作用范围。

总之，重叠式的@Transactionnal注解是一种不好的做法，会带来性能问题、死锁风险和代码可读性差等问题。在使用@Transactionnal注解时，应该避免重叠式的使用，合理划分事务的边界，提高代码的可读性和性能。