线程池效率需从吞吐、响应、资源占用和稳定性四维综合评估，核心指标包括任务吞吐量、响应时间（含长尾）、线程利用率和拒绝率，并需结合任务类型（CPU/IO/混合）合理配置参数及工具链定位瓶颈。
线程池效率不能只看“快不快”，得从吞吐、响应、资源占用和稳定性四个维度综合判断。单靠跑一次任务测耗时，容易误判真实瓶颈。
核心指标必须同时监控
只盯一个数会漏掉关键问题：
- 任务吞吐量：单位时间完成多少任务，反映整体处理能力。下降可能意味着线程阻塞或队列积压
- 任务响应时间：包含排队等待 + 实际执行，平均值和长尾（如95分位）都要看。响应突增往往先于吞吐下降
- 线程利用率：活跃线程数 ÷ 总线程数。持续低于50%说明线程闲置；长期100%则大概率是核心线程数不够或任务执行太慢
- 拒绝率：被拒绝任务占比。非零值说明流量已超承载能力，需检查队列容量和拒绝策略是否合理
测试设计要覆盖典型场景
不同任务类型对线程池压力差异极大：
- CPU密集型任务（如图像压缩、数值计算）：重点观察CPU使用率和上下文切换次数。线程数过多反而因频繁切换拖慢整体速度
- IO密集型任务（如HTTP调用、数据库查询）：关注线程等待时间和队列堆积情况。此时可适当提高线程数，但需防止内存溢出
- 混合型任务：最贴近生产实际。建议按业务比例配置，例如70% IO + 30% CPU，避免用纯模拟任务代替真实链路
工具链要能定位具体瓶颈
光有数字不够，得知道“卡在哪”：
立即学习“Java免费学习笔记（深入）”；
- 用jstack抓取线程堆栈，确认是否存在大量
BLOCKED或WAITING状态线程 - 用jconsole或JMC实时查看线程池的
getActiveCount、getQueueSize、getCompletedTaskCount等运行时指标 - 对自定义线程池做埋点，比如包装
execute()方法，记录任务入队时间、开始执行时间、结束时间，生成分布直方图
避免常见配置陷阱
很多性能问题其实源于初始设置不合理：
-
别用无界队列：如
LinkedBlockingQueue默认容量是Integer.MAX_VALUE，任务积压会直接引发OOM - 慎设过大的maximumPoolSize：超过系统承载能力后，线程争抢CPU、内存、锁资源，吞吐不升反降
-
corePoolSize不能拍脑袋定：CPU密集型建议设为
CPU核心数+1；IO密集型可设为2~4倍CPU核心数，但必须配合压测验证
