类上标注@Transactional时@Autowired修饰的Setter方法被纳入事务范围的风险及原因解析

这个问题其实挺典型的——很多人一开始会以为在类上标注@Transactional就能一劳永逸地给所有业务方法加上事务支持，但没注意到这个注解的作用范围是所有public方法，包括你用来注入jdbcTemplate的Setter方法。这种做法会引发几个关键问题：

1. 不必要的数据库资源浪费 #

Spring的事务机制依赖于数据库连接的绑定：当进入事务方法时，Spring会从连接池获取一个连接并绑定到当前线程，方法执行完毕后才会释放连接。而你的Setter方法只是完成依赖注入，完全不需要操作数据库，给它加上事务纯粹是浪费连接资源。

在应用启动阶段，容器会批量初始化Bean并调用Setter注入依赖，这时候大量无意义的事务会占用连接池中的连接，甚至可能导致连接池耗尽，影响其他正常业务请求的处理。

2. 潜在的事务传播行为异常 #

Spring事务有多种传播特性（比如REQUIRED、REQUIRES_NEW等），默认是REQUIRED——如果当前线程已经有事务，就加入该事务；如果没有，就新建一个。

如果你的Setter方法在某个已有事务的上下文里被调用（比如某些复杂的Bean初始化流程），它会意外地加入到这个事务中，可能导致事务边界混乱。比如，Setter注入过程中的微小异常可能会触发整个事务的回滚，而这完全不是你期望的结果。

3. 初始化阶段的异常放大风险 #

如果Setter方法在事务中执行，万一注入过程出现异常（比如jdbcTemplate本身配置错误、数据库连接失败），事务会触发回滚操作。但这个事务本身没有任何业务操作，回滚不仅毫无意义，还可能干扰Spring容器的初始化流程，导致Bean加载失败的原因被掩盖，增加排查难度。

4. 违背事务的单一职责原则 #

事务的核心作用是包裹有状态的业务逻辑操作（比如数据库增删改），而依赖注入属于Bean的初始化流程，完全不属于业务逻辑范畴。把Setter纳入事务范围会让代码的意图变得模糊，其他开发者看到Setter上有事务时会产生困惑，不利于代码的维护和迭代。

怎么解决？ #

有几个比较优雅的解决方案：

• 只在业务方法上标注@Transactional：去掉类上的注解，只给method1()到methodN()这些真正需要事务的方法加上@Transactional，精准控制事务范围。
• 用构造注入代替Setter注入：Spring官方更推荐构造注入的方式，构造方法在Bean实例化时被调用，此时事务代理还未生成，类上的@Transactional不会影响构造方法。
• 排除Setter方法的事务：如果一定要在类上保留@Transactional，可以给Setter方法加上@Transactional(propagation = Propagation.NOT_SUPPORTED)，强制该方法不运行在事务中。

内容的提问来源于stack exchange，提问作者Sergey Zh.