FixedThreadPool生产环境禁用，因其使用无界LinkedBlockingQueue导致任务无限堆积、内存持续增长直至OOM；应手动构造ThreadPoolExecutor，显式配置有界队列、拒绝策略（如CallerRunsPolicy）和命名线程工厂。
FixedThreadPool 在生产环境上线，确实相当于埋下了一颗静默爆炸的 OOM 定时炸弹——它不靠线程数暴涨触发崩溃，而是靠任务在内存里“安静堆积”，直到堆空间彻底耗尽。
无界队列不是“容量大”，是“没有刹车”
Executors.newFixedThreadPool(n) 底层用的是 LinkedBlockingQueue，且未指定容量，等价于 new LinkedBlockingQueue(Integer.MAX_VALUE)。这不是“能装很多”的优势，而是彻底放弃对任务积压的约束：
- 只要核心线程全忙，新任务就无条件入队，不拒绝、不限速、不告警
- 每个 Runnable 或 FutureTask 对象常携带完整业务上下文：HTTP 请求体、DTO 图、数据库参数、日志上下文等，单个任务轻松占用几百 KB 堆内存
- 下游响应延迟 2 秒 → 每秒净增 90 个待处理任务 → 10 分钟后队列超 5 万个任务 → 堆内存直接吃掉 2GB+，Full GC 频繁但回收无效
崩得悄无声息：CPU 低、线程稳、内存却一路狂飙
典型故障现象不是服务卡死或线程爆满，而是监控上出现矛盾信号：
- Pod 内存使用从 2GB 缓慢爬升至 8GB+，但 CPU 始终低于 30%
- FixedThreadPool 自身活跃线程数稳定在 corePoolSize（如 10），看起来“一切正常”
- 自定义指标显示队列长度峰值突破 20 万，Tomcat 线程池接近阈值，但问题根源不在 Web 层
- 日志中反复出现 java.lang.OutOfMemoryError: Java heap space，MAT 分析直指 LinkedBlockingQueue.elementData 占据 90% 堆
真正安全的替代方案：手动构造 + 三要素闭环
禁用 Executors 不是为了增加复杂度，而是把关键控制权拿回来。必须显式声明以下三项：
- 有界队列：用 ArrayBlockingQueue 替代 LinkedBlockingQueue，容量设合理值（如 256 或 1024），硬性截断无限堆积
- 拒绝策略：优先选 CallerRunsPolicy，让提交线程自己执行任务，天然实现反压；避免默认 AbortPolicy 导致上游无感知失败
- 可监控、可命名：传入自定义 ThreadFactory（如 setNameFormat("order-async-%d")），并保留 ThreadPoolExecutor 引用，以便调用 getQueue().size()、getActiveCount() 接入 Prometheus 实时观测
顺手清理连带隐患
只换队列还不够，这些常伴生的问题也得一并堵住：
- CompletableFuture.supplyAsync() 必须传自定义线程池，否则默认走 ForkJoinPool.commonPool，一个慢 IO 就拖垮整个公共池
- 任务中用了 ThreadLocal，务必在 finally 块中 remove()，否则线程复用导致上下文残留、内存泄漏加剧 OOM
- 拒绝策略生效后，上层必须有兜底逻辑（如降级返回、异步落库重试），不能让 500 错误直接穿透到用户端
