Spring ThreadPoolTaskExecutor响应时间突增且请求中断问题排查

1. 任务嵌套提交导致线程池资源耗尽 #

你的sendObject方法已经用@Async("executor")标记，意味着整个方法会被提交到指定线程池执行，但方法内部又调用了executor.execute(() -> {...})，相当于每个请求会生成N个额外任务（N为items集合的大小）。当QPS达到1100rpm时，实际进入线程池的任务量会是1100*N，远超过线程池的承载能力，很快就会把线程池和队列占满，新任务无法被处理，导致响应时间急剧拉长。

2. 线程池队列配置缺失（无界队列引发内存溢出） #

当前配置只设置了corePoolSize和maxPoolSize，但未指定队列容量。Spring的ThreadPoolTaskExecutor默认使用LinkedBlockingQueue，默认容量为Integer.MAX_VALUE（无界队列）：

• 核心线程数占满后，新任务会被放入无界队列，不会触发线程池扩容到maxPoolSize
• 任务持续积压会导致内存占用飙升，引发频繁GC甚至OOM，最终导致服务响应停滞

3. 业务方法无超时控制引发线程阻塞 #

item.send(object)如果是调用外部服务（如HTTP请求、数据库操作）且未设置超时时间，一旦外部服务响应缓慢或不可用，执行该任务的线程会长期处于阻塞状态，无法释放回线程池。随着阻塞线程增多，线程池可用资源被耗尽，新任务无法执行。

4. 未配置拒绝策略且未处理任务提交异常 #

默认拒绝策略为AbortPolicy，当线程池和队列都满时，会直接抛出RejectedExecutionException。若代码未捕获该异常，会导致任务提交失败，甚至引发上层调用异常，最终导致服务停止处理请求。

5. 线程池初始化方式不当 #

手动调用initialize()可能引发重复初始化问题，若该方法被多次调用（如Spring上下文刷新时），会导致线程池状态异常，影响任务执行。Spring的ThreadPoolTaskExecutor作为Bean时，无需手动调用initialize()，容器会自动处理生命周期。

• 移除sendObject方法内部的executor.execute调用，@Async已足够将整个方法提交到线程池执行
• 配置有界队列，比如setQueueCapacity(2000)，结合核心线程数和最大线程数平衡任务排队与线程扩容
• 为item.send(object)添加超时控制，避免线程长期阻塞
• 配置合适的拒绝策略，比如setRejectedExecutionHandler(new ThreadPoolExecutor.CallerRunsPolicy())，让调用线程临时处理任务，避免任务直接丢失
• 移除手动的initialize()调用，交由Spring容器管理线程池生命周期

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