Spring Boot中启用Tomcat阻塞线程检测的弊端及最佳实践咨询

你在Spring Boot中启用的这个Tomcat阀，虽然能自动终止超时线程，但也存在不少需要注意的问题：

• 误杀合法长耗时请求：如果阈值设置得偏低，那些本身就需要长时间运行的合法业务（比如大报表生成、批量数据处理）会被误判为阻塞线程直接终止，不仅导致请求失败，还可能引发数据半处理的不一致状态。
• 资源泄漏隐患：线程被强制中断后，如果业务代码没正确处理InterruptedException，手里持有的数据库连接、文件句柄、分布式锁等资源可能没法正常释放，时间长了会造成资源耗尽，拖垮服务。
• 阻塞根因排查困难：线程被自动终止后，原本的阻塞现场直接被破坏，要是没提前配置阀的日志记录线程栈，你根本没法知道线程到底是卡在IO、锁还是第三方调用上，没法从根源解决阻塞问题。
• 服务稳定性受影响：频繁中断线程会拉高请求失败率，影响用户体验；而且Tomcat线程池需要不断创建新线程补位，线程的创建销毁会带来额外性能开销，降低服务整体吞吐量。
• 触发业务重复执行：如果你的业务有重试机制，被中断的请求可能会被重试逻辑重复执行，导致重复扣款、重复提交数据这类业务异常。

另外提个实用建议：这个阀更适合作为应急兜底手段，核心还是要通过监控定位阻塞根源（比如慢SQL、第三方服务超时），阈值设置一定要结合业务实际耗时来调整，同时记得开启阀的线程栈日志功能，方便后续排查问题。

内容的提问来源于stack exchange，提问作者Akkave