分布式网关线程池队列挤满的根源常是异常处理失当：滥用空catch或仅打日志捕获runtimeexception会掩盖真实失败，导致任务滞留、重试失控、资源不释放、阻塞等待及全局处理器干扰线程生命周期。
分布式网关中线程池队列挤满，表面看是资源耗尽，但根源常藏在异常处理逻辑里。滥用 catch (RuntimeException e) 会导致任务无法及时失败、重试失控、下游阻塞被掩盖，最终反向压垮上游线程池。排查需跳出“调大线程数”的惯性，聚焦异常捕获如何扭曲了任务生命周期。
检查异常捕获是否掩盖了真实失败点
网关层大量使用空 catch 或仅打日志的 RuntimeException 捕获，会让本该快速失败的任务继续滞留在线程池中：
- 比如 RPC 调用超时抛出
TimeoutException（继承 RuntimeException），若被静默吞掉，任务不会中断，而是继续执行后续无意义逻辑或进入重试循环 - 下游服务熔断后返回
ServiceUnavailableException，若被 catch 后只记录 WARN 日志却不终止当前任务，该任务仍占用工作者线程和队列槽位 - 检查所有网关 Filter、GlobalExceptionHandler、FallbackHandler 中对
RuntimeException的处理——是否统一做了“兜底重试”或“默认返回”，而未区分业务异常与系统异常
确认异常捕获是否触发了隐式重试放大
捕获运行时异常后主动发起重试（尤其是无退避、无上限的重试），会成倍放大任务提交压力：
- 一个因下游慢导致的
ExecutionException被捕获，立即重试 3 次 → 单个请求生成 4 个新任务，全部进入同一异步线程池 - 重试逻辑嵌套在异步回调中（如 CompletableFuture.handle），每次失败都触发新 submit，形成任务雪球
- 查看网关重试配置：是否对所有 RuntimeException 默认启用重试？是否限制了最大重试次数和指数退避？是否忽略网络类异常（如 ConnectException）这类重试无意义的场景？
验证线程是否因异常处理卡在阻塞等待
捕获异常后未释放资源或未正确关闭连接，会导致线程长期处于 WAITING/TIMED_WAITING 状态：
- HTTP 客户端（如 OkHttp、Apache HttpClient）在异常分支中未调用
response.close()或entity.consumeContent()，连接未归还连接池，后续请求排队等待连接 - 异步回调中捕获异常后忘记 cancel 对应的
ScheduledFuture或CompletableFuture，底层线程持续等待超时或条件满足 - 用
jstack抓取线程快照，筛选出状态为WAITING on java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject或TIMED_WAITING (parking)的网关工作线程，检查其栈顶是否落在异常处理后的资源等待逻辑中
审查全局异常处理器是否干扰线程池生命周期
Spring Cloud Gateway 等框架的 GlobalFilter 或 WebExceptionHandler 若错误地将异常转为同步响应并阻塞主线程，会影响整个异步调度链路：
- 在
WebExceptionHandler中调用exchange.getResponse().writeWith(...)前未判断是否已提交响应，导致写操作阻塞在 Netty EventLoop 线程上 - 自定义
RoutePredicateFactory中捕获异常后返回Mono.error()，但未用onErrorResume正确降级，致使 Mono 订阅链挂起，占用 Reactor 线程 - 确认所有异常处理器是否运行在 I/O 线程（如 Netty 的 NioEventLoop）而非业务线程池；若混用，会导致业务线程池被 I/O 阻塞间接拖慢
