线程池生产问题多表现为“慢”“卡”“丢任务”，诊断需结合线程状态（waiting/blocked）、核心指标（活跃数、队列长、拒绝数）、配置陷阱（无界队列、过大maximumpoolsize等）及动态验证手段（arthas、调参、换拒绝策略）。
线程池在生产环境出问题，往往不是“崩了”，而是“慢了”“卡了”“丢任务了”——表面平静，背后堆积如山。诊断的关键不是猜，而是看真实运行态：线程在哪卡着？任务堆在哪？资源撑到哪条线？
一、先看线程状态：有没有大量 WAITING 或 BLOCKED？
这是最直观的信号。用 jstack -l
- 状态为 WAITING（on object monitor） 的线程数量是否远超核心线程数？说明任务提交快、执行慢，线程都在等队列取任务；
- 出现多个线程在 java.util.concurrent.ThreadPoolExecutor$Worker.run 里阻塞在 getTask()，基本坐实线程池“吃不饱”或“撑不住”；
- 有线程长期 BLOCKED 在锁上（比如 synchronized 方法或 ReentrantLock），可能不是线程池本身问题，而是任务内部存在锁竞争，拖慢整体吞吐。
二、盯住三个核心指标：活跃数、队列长度、拒绝数
这些数字藏在线程池的 JMX 接口或 Micrometer 暴露的监控端点里，比代码配置更真实：
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
- ActiveCount 长期等于 corePoolSize，且 QueueSize 持续上涨 → 核心线程不够用，或任务执行太慢；
- QueueSize 接近甚至超过 queueCapacity → 队列即将满，再压任务就会触发拒绝策略；
- RejectedExecutionCount 非零且持续增长 → 拒绝策略已生效，要立刻查是任务突增、线程池缩容，还是拒绝策略本身太激进（比如用了 AbortPolicy 却没兜底日志）。
三、检查配置陷阱：常见“看着对，实际错”的地方
很多故障源于参数组合不合理，而非单个值错误：
- 无界队列 + 小 corePoolSize（如 LinkedBlockingQueue(Integer.MAX_VALUE) + core=2）→ 任务全堆在队列里，内存涨、延迟高、OOM 风险大；
- maximumPoolSize 过大（比如设成 1000）→ 高并发时瞬间拉起大量线程，CPU 上下文切换开销反超收益，系统反而更卡；
- keepAliveTime 太短（如 1 秒）→ 线程刚建好就销毁，频繁创建销毁抵消了池化优势；
- 拒绝策略没做可观测：用默认 AbortPolicy，异常被吞掉，日志里只有一行 “Task rejected”，根本不知道哪个业务提交了什么任务。
四、动态验证与快速止损技巧
线上不能只看不动，有些动作可立即缓解：
- 用 Arthas thread -n 10 查 CPU 占用最高的前 10 个线程，确认是不是线程池 Worker 在空转或死等；
- 临时调大 corePoolSize（通过 Spring 的 @RefreshScope 或直接 setCorePoolSize()）观察队列是否回落，验证是否真缺线程；
- 把拒绝策略临时换成 CallerRunsPolicy，让调用方自己执行任务——虽会拖慢上游，但能防止任务丢失，并暴露真实负载压力点；
- 对关键线程池加 afterExecute 钩子，记录每个任务耗时、异常，不用改业务代码就能拿到执行画像。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
