Spring Boot 3.3.13下TransactionTemplate意外加入未知事务的排查咨询
看起来你遇到了一个挺棘手的事务传播问题——独立线程池里的任务居然意外加入了一个长时间运行的事务，从pg_stat_activity和线程栈的信息来看，确实指向TaskRunner的工作线程。结合你给出的代码和Spring Boot 3.3.13的环境，我整理了几个实际生产中踩过类似坑的排查方向：
1. HikariCP连接池的连接复用“后遗症”
这是最常见的原因：HikariCP会高效复用数据库连接，如果某个线程使用连接后没有正确提交/回滚事务，连接回到池里时事务还处于活跃状态，后续线程拿到这个连接就会自动加入该事务。
结合你的代码排查：
- 检查是否有其他地方使用同一个数据源时，存在事务未正确关闭的情况——比如某个事务被挂起但没恢复，或者手动操作
Connection时忘记commit/rollback，又或者try-with-resources没正确包裹事务操作。 - 重点盯
taskRepository.deleteWithSelectNextTasksToExecute方法内部：是否有异常被吞掉，导致Spring事务管理器没收到结束信号，最终连接带着活跃事务回到池里？
排查建议：
开启HikariCP的DEBUG日志（在application.yml里加logging.level.com.zaxxer.hikari=DEBUG），观察连接的获取、释放和事务状态；同时在deleteWithSelectNextTasksToExecute的入口和出口加日志，打印当前事务的状态。
2. TransactionTemplate默认传播行为的“隐形坑”
你用的transactionTemplate.executeWithoutResult默认事务传播行为是Propagation.REQUIRED——如果当前线程已经存在事务，就直接加入；没有才新建。那问题来了：你的独立工作线程怎么会有已存在的事务？
结合你的代码排查：
虽然TaskRunner的线程池是自己用ThreadPoolExecutor创建的，但要确认：
- 线程工厂创建的线程是否被Spring的上下文传递机制污染？比如有没有其他地方用
RequestContextHolder或者自定义线程本地变量，把事务上下文意外传递到了这个线程池的线程里？ - 外部调用
runWorker的外层while循环，本身会不会是在一个事务上下文里执行的？如果外层线程有活跃事务，会不会通过某种隐性方式传递到工作线程？
排查建议：
在executeTask方法的最开头加一行日志：
log.debug("Worker thread {} has active transaction: {}", Thread.currentThread().getName(), TransactionSynchronizationManager.isActualTransactionActive());
如果打印结果是true，说明工作线程在进入TransactionTemplate之前就已经有活跃事务了，那就要追查这个事务上下文的来源。
3. 线程本地变量的泄漏
Spring的事务上下文存在TransactionSynchronizationManager的线程本地变量里。线程池的线程是复用的，如果之前的任务没有清理线程本地变量，后续任务就会拿到残留的事务上下文。
结合你的代码排查：
你的executeTask方法里捕获了所有异常，但要检查：
transactionTemplate.executeWithoutResult执行完成后，Spring是否正确清理了线程本地变量？有没有可能commandBus.execute内部手动操作了线程本地变量，导致事务上下文没有被清理？- 有没有其他AOP切面在这个线程上做了操作，导致线程本地变量残留？
排查建议：
在executeTask的开头和结尾都打印线程本地变量的内容：
log.debug("Before execute - thread local resources: {}", TransactionSynchronizationManager.getResourceMap()); // 原有逻辑 log.debug("After execute - thread local resources: {}", TransactionSynchronizationManager.getResourceMap());
如果结尾的日志里还有事务相关的资源，说明存在泄漏。可以临时在executeTask最后加一行TransactionSynchronizationManager.clear()测试，看看问题是否消失（注意这只是测试，不要直接上线，要找到根源）。
4. 临时验证方案：强制新建事务
可以先修改TransactionTemplate的传播行为，强制它新建事务，看看是否还会加入长事务。修改代码：
// 在使用transactionTemplate之前设置传播行为 transactionTemplate.setPropagationBehavior(TransactionDefinition.PROPAGATION_REQUIRES_NEW); transactionTemplate.executeWithoutResult(transactionStatus -> { List<DelayedTask> tasks = taskRepository.deleteWithSelectNextTasksToExecute(amountOfTasksToSelect, Instant.now()); // 原有逻辑 });
如果改了之后问题消失，那就能确定之前的问题是工作线程加入了已存在的事务，再顺着上面的方向排查根源即可。
另外，也可以检查PostgreSQL的idle_in_transaction_session_timeout设置，这个参数控制空闲事务的超时时间，默认可能比较长（甚至不超时），如果设置成300秒（5分钟），可以避免长事务持续4小时的情况，也能帮助快速定位问题。
