线程池性能瓶颈需结合线程状态、队列行为、锁竞争与cpu使用率综合判断：cpu偏低但负载高说明线程阻塞或空转；响应恶化+拒绝异常增多提示队列积压或拒绝策略过激；jstack重点查blocked成群、waiting卡在gettask()、死锁自动提示；arthas用thread -n5、thread -b快速定位高cpu和阻塞线程；再反推corepoolsize过小、无界队列、keepalivetime过短等配置问题。
Java线程池性能瓶颈往往藏在线程行为和资源调度细节里，不靠工具很难直观察觉。关键不是堆栈本身，而是如何把线程状态、任务队列行为、锁竞争和CPU使用率串起来看。
识别线程池是否真成了瓶颈
线程池出问题，通常不是“慢”，而是“表现反常”：
- 系统负载升高，但CPU利用率始终上不去（比如长期卡在30%~50%），说明线程可能大量阻塞或空转，没真正干活
- 响应时间随并发增长快速恶化，且拒绝任务数陡增，可能是workQueue堆积严重或拒绝策略激进
- 用jstat观察GC频率正常，但VisualVM里线程数持续攀升、RUNNABLE线程却很少，大概率是任务被压在队列里“躺平”
- 日志中频繁出现
java.util.concurrent.RejectedExecutionException，说明线程池已无力承接新任务
jstack是线程栈分析的起点，但得会读关键信息
执行jstack <pid> > dump.txt</pid>后，重点盯三类线索：
-
BLOCKED线程成群出现：查找相同
waiting to lock地址的线程，它们正争抢同一把锁——这是典型的锁竞争瓶颈 -
大量线程处于WAITING/TIMED_WAITING：看堆栈末尾是否停在
LockSupport.park、Object.wait或Thread.sleep；若都卡在ThreadPoolExecutor.getTask()，说明工作线程在队列取不到任务，空等 -
死锁自动标出：jstack末尾会单独列出
Found 1 deadlock.段落，直接给出持锁/等待锁的线程和具体锁对象
用Arthas快速定位耗时线程与热点方法
比起手动翻dump文件，Arthas更适配线上排查：
-
thread -n 5：列出CPU占用最高的5个线程，立刻看到哪个线程在狂占资源 -
thread <id></id>：对高CPU线程单独抓栈，定位到具体哪行代码在循环或IO阻塞 -
thread -b：一键检测当前是否存在阻塞线程（如synchronized锁等待） - 配合
watch命令监控关键方法入参与返回值，验证是否因某些参数导致处理异常缓慢
结合线程池参数反推配置合理性
看到问题线程后，回头检查ThreadPoolExecutor构造参数：
- 如果大量线程处于
WAITING on java.util.concurrent.ThreadPoolExecutor$Worker，且corePoolSize设得太小，说明核心线程不够用，任务被迫排队 - 若
workQueue是LinkedBlockingQueue且无界，而dump中看到几百个线程在getTask()挂起，基本可断定队列积压严重，应改用有界队列+合理拒绝策略 -
keepAliveTime过短，会导致高峰过后线程频繁销毁重建，上下文切换开销明显——观察jstat -gc中YGC频率是否异常升高
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
