排查线程池饥饿需验证“变量请求是否在队列里饿死”，盯住队列积压、活跃满载、空闲归零三项指标，结合jstack确认阻塞点，并交叉验证GC与下游延迟排除干扰。

排查大规模并发容器内因活跃核心数错配引发的线程池饥饿，关键不是“看线程够不够”，而是验证“变量请求是否在队列里饿死”。这类问题常发生在 Spring @Async、CompletableFuture.supplyAsync 或自定义异步上下文初始化场景中，尤其当租户ID、TraceId、配置快照等轻量变量需在线程池中完成首次加载时。

盯住三个实时指标：队列积压 + 活跃满载 + 空闲归零

在容器流量上升过程中，每秒采集一次线程池运行态：

• pool.getQueue().size()：若从 0 突增至 100+ 并持续不降，说明任务无法及时消费
• pool.getActiveCount() == pool.getCorePoolSize()：长期恒等于核心数（如一直是5），且无波动，代表没有线程空闲出来处理新请求
• pool.getPoolSize() - pool.getActiveCount() == 0：空闲线程数始终为 0，哪怕最大线程数设得很高，也说明扩容机制未触发（因 keepAliveTime 未到或队列未满）

用 jstack 快速确认“全员堵在等待链上”

在超时集中发生时执行：jstack | grep -A3 "pool-.*-thread"，重点观察：

• 是否所有 pool-1-thread-N 线程都处于 WAITING on java.util.concurrent.LinkedBlockingQueue？这是线程在 getTask() 中阻塞，说明队列有任务但没线程取——反常，因为核心线程应常驻
• 是否有大量线程停在 at java.util.concurrent.CompletableFuture.get(CompletableFuture.java:2725) 或 allOf.join()？表明外层任务正同步等待内层异步结果，而内层任务卡在队列里
• 是否存在 waiting to lock 或 locked ？排除锁竞争干扰；若无锁信息，更支持“纯调度不足”判断

区分真饥饿和假瓶颈：交叉验证 GC 与下游延迟

别被日志里的 “timeout=200ms” 带偏。执行两组命令交叉比对：

• jstat -gc 1000 3：连续三次查看 GC 次数与耗时。若 YGC/FGC 频率低、单次耗时
• curl -s http://localhost:8080/actuator/metrics/process.uptime（或对应健康端点）：确认应用本身未重启或长时间停顿
• 检查下游调用日志（如 Redis、配置中心）：若 GET tenant-config 耗时普遍 TenantHolder.resolve() 却报 380ms，说明耗时不在远程调用，而在排队等待执行

容器环境特别注意：资源限制放大错配效应

在 Kubernetes 或 Docker 中，CPU limit（如 500m）会强制 throttling，使线程调度延迟升高，进一步加剧“本可执行却排不上队”的现象：

• 查容器 CPU throttling：kubectl top pod --containers + kubectl describe pod 看 cpuThrottledPeriods
• 若存在明显 throttling，即使 corePoolSize=10，实际能并发执行的线程可能只有 3～4 个——此时应同步调高 CPU limit 或降低 corePoolSize 避免虚假饱和
• 避免在容器中使用 Executors.newCachedThreadPool()：其无上限特性在资源受限下极易触发 OOM 或调度雪崩