FixedThreadPool在任务积压时响应下降的根本原因不是线程不足，而是其“固定线程+无界队列”组合缺失背压机制，导致请求持续涌入、消费停滞、队列无限堆积，最终引发响应时间飙升和OOM。
FixedThreadPool 在任务积压时响应速度下降，根本原因不是线程不够用，而是它“看似稳定、实则失敏”的执行模型把压力全转嫁给了内存和等待时间。
队列无界 + 线程固定 = 响应时间不可控
FixedThreadPool 默认使用 LinkedBlockingQueue（容量为 Integer.MAX_VALUE），配合固定数量的线程（corePoolSize == maximumPoolSize）。这意味着：
- 新任务永远能提交成功，不会触发拒绝策略
- 线程数不会随负载增加而扩容
- 一旦任务处理变慢（比如 IO 阻塞、外部依赖延迟），线程被长时间占用，消费能力断崖式下跌
- 而上游请求照常涌入，全部堆进队列，等待时间线性甚至指数增长
举个常见场景：
立即学习“Java免费学习笔记（深入）”；
- 原来每个任务耗时 100ms，10 个线程吞吐约 100 QPS
- P99 接口突然变慢到 2s，单线程每秒只能处理 0.5 个任务
- 10 个线程总吞吐跌到 5 QPS，但每秒仍进 80 个请求 → 每秒净积压 75 个
- 30 秒后队列已有 2250+ 任务，平均等待时间超 45 秒
线程没满，但系统已卡
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
监控上看很“平静”：活跃线程数恒为 10，CPU 使用率不高，也没有 RejectedExecutionException。
真实问题是：
- 所有新请求都在排队，RT 持续拉升
- 每个待执行任务携带对象（DTO、上下文、JSON）占几百 KB 内存
- 队列越长，GC 越频繁，JVM 堆压力越大，最终可能 OOM
它不减速，也不报警，只是默默拖垮响应
FixedThreadPool 不会因为队列变长而限流、降速或反馈瓶颈。它没有背压机制，调用方完全感知不到下游已堵死。用户看到的是“接口越来越慢”，而不是“服务不可用”，问题定位反而更难。
关键不在线程数，而在队列有没有边界感
去掉无界队列，换成 ArrayBlockingQueue(200)，再配 CallerRunsPolicy：
- 队列满时，由业务线程自己执行任务，天然降低提交速率
- 立刻暴露瓶颈，避免雪崩式堆积
- 结合
queue.size()指标，能快速定位是哪个模块的任务在卡住
不复杂但容易忽略
