getPoolSize是诊断非核心线程回收失效的首选指标，因其直接反映线程池当前存活线程总数，可明确识别高于核心线程数的残留非核心线程。

getPoolSize 返回的是线程池当前实际存在的线程总数，包括核心线程和非核心线程，是排查「非核心线程未按预期回收」问题最直接、最关键的指标。

为什么 getPoolSize 是诊断非核心线程回收失效的首选指标

非核心线程是否被回收，不能只看 getActiveCount() 或任务队列大小，而必须观察线程池内部真实存活的线程数。因为：

• getActiveCount() 只反映「正在执行任务」的线程，无法区分是核心还是非核心线程，更无法体现空闲线程是否残留
• getPoolSize() 是唯一能告诉你「此刻线程池里到底还活着几个线程」的公开方法
• 当负载下降后，若 getPoolSize() 长期高于 getCorePoolSize()，就说明非核心线程未被回收——这是回收失效的明确信号

实战中如何用 getPoolSize 定位回收异常

在定时监控脚本或健康检查端点中，持续采集并比对以下三组值：

• 当前线程数：getPoolSize()
• 配置的核心线程数：getCorePoolSize()
• 历史最大线程数：getLargestPoolSize()

典型异常模式：

• 高峰期后，getPoolSize() 稳定在 8，但 getCorePoolSize() = 4 → 多出 4 个非核心线程未释放
• getLargestPoolSize() = 12，而当前 getPoolSize() = 12 且持续 5 分钟以上 → 扩容后完全没收缩
• keepAliveTime 设为 60 秒，但 3 分钟后 getPoolSize() 仍 > getCorePoolSize() → 回收机制未触发

结合队列行为判断回收阻塞原因

非核心线程不回收，往往不是代码 bug，而是被工作队列“卡住”。需同步检查：

• getQueue().size() 是否长期 > 0？即使无新任务提交，若队列中仍有待处理任务，所有线程（含非核心）都会保持活跃等待取任务
• 使用 SynchronousQueue 时，getQueue().size() 恒为 0，此时 getPoolSize() 居高不下，大概率是任务提交速率 > 处理速率，导致线程持续创建
• 若队列已空（size == 0）但 getPoolSize() 仍 > getCorePoolSize()，则需检查：是否设置了 allowCoreThreadTimeOut(true)（影响核心线程）、线程内任务是否发生 I/O 阻塞未退出 run() 方法

一个可落地的监控检查逻辑示例

在日志或告警规则中嵌入如下判断：

• 如果 getPoolSize() > getCorePoolSize() 且持续超过 keepAliveTime × 2（例如 120 秒），触发「非核心线程回收延迟」告警
• 如果 getPoolSize() == getMaximumPoolSize() 且 getQueue().size() > 0，说明线程池已打满且任务积压，需立即干预
• 对比 getLargestPoolSize() 和当前 getPoolSize()：差值长期为 0，说明扩容后零收缩，配置或负载模型可能不合理