线程池性能这事儿，很多人的第一反应是“反赌就行”，但真要落到生产环境里，光看一个指标是远远不够的。必须从吞吐、响应、资源占用和稳定性四个维度综合评估，才算得上科学。单靠跑一次任务测个耗时，很容易被表面数字骗过去。

那么，具体盯哪些数字才能抓到问题的本质？

核心指标必须同时监控

别指望只抓一个指标就能交差——每个数背后都藏着一个潜在的坑：

• 任务吞吐量：单位时间内能处理多少任务，直接反映整体处理能力。一旦出现下降，通常意味着线程阻塞或队列已经开始堆积。
• 任务响应时间：注意，这不光是实际执行时间，还包括排队等待的时间。平均值要看，长尾（比如95分位）更要看——很多时候响应突然变慢，往往比吞吐量下降更早预警。
• 线程利用率：活跃线程数除以总线程数。持续低于50%说明线程在摸鱼；长期100%的话，要么核心线程数设少了，要么任务执行本身太慢。
• 拒绝率：被拒绝的任务占比。一旦出现非零值，说明流量已经超过承载能力，得回头检查队列容量和拒绝策略是否合理。

测试设计要覆盖典型场景

不同任务类型对线程池的压榨方式完全不同，测试场景如果太脱离实际，结果基本没有参考价值：

• CPU密集型任务（如图像压缩、数值计算）：这时候要重点盯着CPU使用率和上下文切换次数。线程开多了反而会因为频繁切换拖慢整体速度，适得其反。
• IO密集型任务（如HTTP调用、数据库查询）：关注点要转向线程等待时间和队列堆积情况。适当提高线程数可以提升吞吐，但也得防着内存溢出。
• 混合型任务：最接近生产环境。建议按业务比例来配置，比如70% IO加30% CPU，千万别用纯模拟任务代替真实链路，否则压测数据跟线上表现完全是两回事。

工具链要能定位具体瓶颈

光会看仪表盘还不够，问题卡在哪儿得能精准找到：

• 用jstack抓线程堆栈，确认有没有大量BLOCKED或WAITING状态的线程。
• 用jconsole或JMC实时查看线程池的getActiveCount、getQueueSize、getCompletedTaskCount等运行时指标。
• 如果用的是自定义线程池，建议做一层埋点——包装execute()方法，记录任务入队、开始执行、结束这三个时间点，再生成分布直方图，瓶颈一目了然。

避免常见配置陷阱

很多性能问题其实都源于配置阶段埋下的雷：

• 别用无界队列：比如LinkedBlockingQueue默认容量是Integer.MAX_VALUE，任务一积压，OOM分分钟找上门。
• 慎设过大的maximumPoolSize：超过系统承载能力后，线程之间抢CPU、抢内存、抢锁资源，吞吐量不升反降。
• corePoolSize不能拍脑袋定：CPU密集型建议CPU核心数+1；IO密集型可以设到2~4倍CPU核心数，但必须配合压测验证，不能光靠公式推算。