线程池队列瞬间挤满主因是异常被静默吞掉导致任务滞留、重试、等待。需重点排查网关层空捕获RuntimeException、异步回调异常未抛出、无效重试、资源未释放及定时任务未cancel等问题，并结合日志与监控定位真实失败点。
线程池队列瞬间挤满，往往不是并发突增，而是异常处理逻辑“悄悄卡住”了任务生命周期。关键要盯住那些被静默吞掉的 runtimeexception——它们让本该失败退出的任务继续滞留、重试、等待，最终把队列撑爆。
检查网关层空捕获或弱处理的 RuntimeException
分布式网关中，Filter、GlobalExceptionHandler、FallbackHandler 是高危区。重点排查：
- 是否写了
catch (RuntimeException e) { log.warn("忽略异常", e); }这类无动作兜底——TimeoutException、ServiceUnavailableException 等一被捕获就失去失败信号，任务不会中断，仍占队列槽位 - 是否把所有运行时异常都统一 fallback 成“默认成功响应”，导致下游已熔断，上游还在持续发请求
- 是否在异步回调（如
CompletableFuture.thenApply）里捕获异常后未返回或未抛出，造成链路“悬空”
确认异常是否触发了失控重试
捕获异常后立刻重试，是队列爆炸的加速器：
- 查看重试配置：是否对
ExecutionException、ConnectException这类网络异常也启用重试？这类异常重试大概率无效，只会生成更多排队任务 - 检查重试逻辑是否嵌套在异步回调中——一次失败触发新
submit()，新任务再失败又触发下一轮，形成“任务雪球” - 验证是否设置了最大重试次数和指数退避；没有退避的 3 次重试，等于单个请求变成 4 个并发提交
验证线程是否因异常分支卡在阻塞态
异常没被处理，但资源没释放，线程就会卡死在 WAITING/TIMED_WAITING：
- 用
jstack <pid>抓快照，筛选状态为WAITING on java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject的网关工作线程 - 检查 HTTP 客户端（OkHttp/HttpClient）在异常路径中是否漏调
response.close()或entity.consumeContent()，连接池耗尽会拖慢全部后续请求 - 异步定时任务中，捕获异常后是否忘了
cancel()对应的ScheduledFuture，导致底层线程一直等超时
用日志+监控交叉定位真实失败点
不要只看“有没有异常日志”，要看“异常发生后任务有没有真正结束”：
- 在关键 Filter 的
doFilter开头和结尾打 TRACE 日志，对比发现大量请求有开头没结尾——说明卡在中间某步异常分支 - 监控
ThreadPoolExecutor.getQueue().size()和getActiveCount()变化节奏：若队列暴涨但活跃线程数不变，大概率是任务提交后没执行完就挂起（比如卡在连接等待） - 结合下游服务 P95 延迟和熔断状态，反推上游是否在“明知下游已不可用”的情况下仍在重试或转发
