线程池活跃线程数等于最大线程数，队列却为空，说明什么问题
解读
这是国内面试官在性能/高并发方向最爱“挖坑”的考点，表面问现象，实则考察对 JDK 线程池运行模型、拒绝策略触发条件、上下游背压关系以及监控指标口径的综合理解。
“活跃线程数 == maximumPoolSize”且“队列 size == 0”同时出现，说明线程池已处于“满线程且零积压”的瞬时状态。此时若 QPS 仍持续进来，下一步就会直接进入拒绝策略；若 QPS 突然下降，则线程会在 keepAliveTime 后回收。
很多候选人只背过“先排队后开线程”就草率回答“线程池刚启动”或“任务执行太快”，忽略了以下关键点：
- 国内主流监控（CAT、SkyWalking、阿里云 ARMS）里“活跃线程”指的是“当前正在执行 task 的 worker 数量”，不包含空闲线程；
- 队列空不代表没有流量，而是流量刚好被最大线程全部吃掉；
- 如果拒绝策略被触发，监控里往往先看到异常飙升而不是队列堆积，极易误判为“应用代码异常”而非“线程池打满”。
因此，面试官想听到的是：你能不能把“现象—原因—风险—验证—优化”一口气闭环，并且给出可落地的国产化监控与治理方案。
知识点
- ThreadPoolExecutor 运行流程：core → queue → max → reject。
- 活跃线程数（ActiveCount）与 maximumPoolSize 相等，且 workQueue.size() == 0，说明线程池已扩容到上限，任务被瞬时消费，队列无积压。
- 拒绝策略触发条件：当 ActiveCount == maximumPoolSize 且 queue 也满 时才会 reject；当前 queue 为空，仅说明“尚未 reject”，但已处于 reject 临界点。
- 国内常见监控口径差异：
- 活跃线程：正在 run 的 worker；
- 池大小（PoolSize）：当前总 worker 数（含空闲）；
- 队列容量：剩余可提交数，不是已使用数。
- 背压传递：上游仍按原 QPS 打入，下一秒即可将队列打满并触发拒绝，造成“无队列堆积却大面积报错”的诡异场景。
- 排查工具：
- jstack 连续三次采样，观察是否大量线程堆在同一业务方法；
- Arthas 的 thread –state 查看 WAITING/BLOCKED 分布；
- 阿里云 APM 的“线程池治理”插件可直接给出“拒绝次数”指标。
- 优化方向：
- 横向扩容 Pod/实例，降低单池压力；
- 调大 maximumPoolSize（需评估 CPU 上下文切换损耗）；
- 将队列改为 ResizableLinkedBlockingQueue（美团开源实现）实现动态伸缩；
- 引入信号量或限流组件（Sentinel、Hystrix）做入口背压，避免线程池成为瓶颈。
答案
这一现象说明线程池已扩容到最大线程数，并且任务被瞬时执行完毕，导致队列里没有等待任务；此时线程池处于“高负载但无积压”的临界状态，随时可能触发拒绝策略。
产生原因通常是：
- 瞬时 QPS 突增，任务提交速率 ≈ 最大线程处理速率；
- 单任务执行时间极短，任务在队列里“一闪而过”，监控采样刚好抓到空队列；
- 队列容量设置过大，导致线程池优先开线程到上限，而队列尚未有机会堆积。
潜在风险： - 下一秒若 QPS 继续升高，队列会迅速填满并触发拒绝，造成大面积报错；
- 若任务依赖下游 RT 突然升高，线程会被快速占满，队列再空也救不了 SLA；
- 拒绝策略若采用 AbortPolicy，会直接抛 RejectedExecutionException，前端感知为 500/502，影响用户体验。
验证步骤： - 连续 5 秒采集 ActiveCount、PoolSize、QueueSize、RejectCount，确认是否持续处于“max+0+0”；
- 用 Arthas 跟踪任务提交速率：ognl ‘@com.demo.config.ThreadPoolConfig@executor.getQueue().size()’；
- 压测脚本以 110% 当前 QPS 再跑 3 分钟，观察是否出现拒绝异常。
优化措施： - 评估业务 CPU 利用率，若 <60%，可上调 maximumPoolSize 20% 并降低 keepAliveTime 到 30s，避免峰值后线程长时间驻留；
- 接入 Sentinel，对入口流量按单机 80% 最大处理能力限流，保证线程池永远有 20% 余量；
- 采用“线程池治理”中间件（如美团 DynamicTp、阿里 Hippo）实现热更新参数，无需重启发布；
- 若任务为 IO 密集型，改用“协程”模型（京东 JSF 的异步化改造）或 Reactor 线程池，减少线程数开销。
总结：线程池“满线程+空队列”不是健康状态，而是“下一秒就要拒绝”的黄色预警，必须结合拒绝次数、任务 RT、CPU 利用率综合判断，并通过限流、扩容、动态参数治理等手段把风险前移。
拓展思考
- 如果监控里看到“队列持续爆满但活跃线程数始终等于 coreSize”，又是哪类问题？
答：任务 IO 耗时大，线程被阻塞在下游，池规模只到 coreSize 就不再扩容，导致队列堆积。此时应优先提升 coreSize 或把任务改为异步非阻塞。 - 国内金融场景下，线程池拒绝策略几乎不允许抛异常，如何设计兜底？
答：采用“CallerRunsPolicy + 告警”组合，让调用线程自己跑任务，牺牲部分 RT 但保证请求不丢失；同时通过 Prometheus + 钉钉群 10 秒内告警，触发动态扩容。 - 在 Kubernetes 环境，线程池参数如何与 HPA 联动？
答：把“ActiveCount/maximumPoolSize”作为自定义指标暴露给 Prometheus Adapter，当比值 >0.9 持续 30s，HPA 自动扩容 Pod 副本，实现线程池—容器—节点三层弹性。