生产环境禁用Executors.newFixedThreadPool()，因其使用无界LinkedBlockingQueue导致任务堆积引发OOM；应手动构造ThreadPoolExecutor，显式设置有界队列、拒绝策略（如CallerRunsPolicy）和命名线程工厂。
Executors.newFixedThreadPool() 在生产环境禁用，核心问题不是线程数失控，而是任务在队列中无限堆积导致堆内存耗尽。
无界队列是 OOM 的直接推手
该方法底层使用 LinkedBlockingQueue，且未指定容量——等价于 new LinkedBlockingQueue(Integer.MAX_VALUE)。它看起来“有界”，但实际容量大到等同于无界。
- 当任务提交速度持续高于处理速度（如下游响应变慢、数据库延迟升高），新任务不会被拒绝，而是不断入队
- 每个待执行的 Runnable 往往携带完整请求上下文：HTTP body、DTO 对象图、SQL 参数等，单个任务常占数百 KB
- 积压几千个任务就可能吃掉 1GB+ 堆内存，JVM 报
java.lang.OutOfMemoryError: Java heap space
工厂方法屏蔽关键控制能力
Executors 封装过度，把本该显式决策的参数全设为“默认”，导致风险不可见、不可控：
- 无法设置有界队列容量，不能对积压任务设硬性上限
- 无法自定义拒绝策略，默认
AbortPolicy直接抛异常，线上缺乏缓冲和降级手段 - 无法传入命名的
ThreadFactory，线程名统一为pool-X-thread-Y，排查时难以定位归属模块 - 不暴露
ThreadPoolExecutor实例，无法调用getQueue().size()或getActiveCount()做运行时监控
生产环境应手动构造 ThreadPoolExecutor
替代方案必须显式声明三要素：线程数边界、队列容量、拒绝行为。推荐配置模式如下：
- 队列类型选 ArrayBlockingQueue，容量设具体值（如
new ArrayBlockingQueue(256)） - 拒绝策略优先用
CallerRunsPolicy：让提交线程自己执行任务，天然实现反压限流 - 线程工厂建议命名，例如
new ThreadFactoryBuilder().setNameFormat("order-async-%d").build() - 核心线程数与最大线程数可设为相同值（保持固定规模），但务必配合有界队列与合理拒绝策略
其他 Executors 方法同样存在类似风险
不只是 newFixedThreadPool，整个 Executors 工具类在生产中都应规避：
-
newCachedThreadPool：最大线程数为Integer.MAX_VALUE，配合SynchronousQueue，高并发下疯狂创建线程，极易触发栈溢出或 CPU 打满 -
newSingleThreadExecutor：同样基于无界队列，且包装为FinalizableDelegatedExecutorService，无法转型、无法监控、异常后线程静默死亡 -
newScheduledThreadPool：底层延迟队列 + 无界任务队列，定时任务堆积时一样会 OOM
