java中executors工厂类不推荐在生产环境直接使用，因其默认配置缺乏可控性：fixedthreadpool和singlethreadexecutor使用无界队列易oom；cachedthreadpool线程数失控致栈溢出与假死；拒绝策略、线程名、监控能力均不可定制。
Java 中 Executors 工厂类创建线程池的主要风险不是线程不安全，而是默认配置缺乏可控性，容易引发系统级故障。它用“一行代码”的便利掩盖了关键参数决策，导致资源失控、内存溢出和问题难定位。
无界队列导致内存溢出（OOM）
newFixedThreadPool 和 newSingleThreadExecutor 底层使用 LinkedBlockingQueue，容量为 Integer.MAX_VALUE，本质是无界队列。当任务提交速率持续高于执行速率时，待处理任务在堆内存中无限堆积。
- 例如：10 个线程处理耗时 2 秒的任务，每秒提交 100 个任务 → 每秒净增 90 个积压任务 → 几分钟内队列对象达数十万
- 结果：频繁 Full GC，最终触发
OutOfMemoryError - 同理，
newScheduledThreadPool使用的DelayedWorkQueue也是无界结构，定时任务若阻塞（如 HTTP 调用未设超时），后续任务持续积压
线程数量失控引发系统假死
newCachedThreadPool 的核心设计存在致命组合：核心线程数为 0、最大线程数为 Integer.MAX_VALUE、队列为 SynchronousQueue（不缓存任务）。
- 高并发瞬间涌入时，线程池会疯狂创建新线程，而非排队等待
- 每个线程默认占用约 1MB 栈空间，创建 2000 个线程即消耗 2GB 栈内存
- 大量线程加剧 CPU 上下文切换开销，系统响应迟滞甚至假死
- Linux 系统默认单进程线程数限制通常为 1024，极易触达上限而抛
java.lang.OutOfMemoryError: unable to create native thread
拒绝策略与线程工厂不可控
所有 Executors 创建的线程池均采用默认配置，业务无法感知或干预关键行为：
- 拒绝策略固定为
AbortPolicy：任务被拒时直接抛RejectedExecutionException，若未捕获，业务逻辑静默失败 - 线程名统一为
pool-1-thread-1类格式，多个线程池混用时，日志中无法区分任务来源 - 无法启用
allowCoreThreadTimeOut等高级特性，灵活性严重受限 -
newSingleThreadExecutor返回的是FinalizableDelegatedExecutorService包装类，无法转型为ThreadPoolExecutor，失去监控（如getPoolSize()）、动态调参和主动关闭能力
参数隐式设定掩盖真实负载特征
工厂方法隐藏了对任务类型、系统资源和业务 SLA 的判断过程，开发者容易套用“经验公式”而忽略实际瓶颈：
- CPU 密集型任务（如加解密）设过多线程，反而增加上下文切换损耗
- IO 密集型任务（如远程调用）未考虑平均等待时间与工作时间比，线程数设置过低或过高
- 混合型任务（查库 + 计算）强行共用一个池，慢任务拖垮快任务
- 缺少队列容量、存活时间、拒绝策略等显式声明，上线后无法根据压测数据迭代优化
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
