executors 提供的三种快捷线程池均存在严重隐患：newfixedthreadpool 因无界队列易导致 oom；newcachedthreadpool 可能因无限创建线程耗尽栈内存；newsinglethreadexecutor 存在单点失效和无界队列双重风险，三者均缺乏可控性与可观测性，生产环境应手动构造 threadpoolexecutor。
Executors 提供了三种最常用的快捷线程池创建方式：newFixedThreadPool、newCachedThreadPool 和 newSingleThreadExecutor。它们写起来简单，但线上几乎不建议直接使用——不是功能不行，而是默认参数埋了严重隐患。
newFixedThreadPool：无界队列导致任务堆积OOM
它本质是固定大小的线程池，核心线程数 = 最大线程数，用的是 无界 LinkedBlockingQueue（容量为 Integer.MAX_VALUE）。
- 任务提交快、处理慢时（比如下游接口响应变长），任务全堆在队列里，堆内存持续上涨，最终 OOM
- 线程数被锁死，无法弹性扩容，突发流量只能排队，响应延迟不断升高
- 常见于定时任务、MQ 消费等“生产稳定但消费易抖动”的场景
newCachedThreadPool：无限建线程引发栈内存溢出
核心线程数为 0，最大线程数为 Integer.MAX_VALUE，搭配 SynchronousQueue（不存任务，只做移交）。
Java JDK 25
下载
Java JDK 25 来自 OpenJDK 官方归档，版本为 JDK 25，本条下载地址已指向官方 Windows x64 zip 安装包直链，适合调试旧项目或兼容旧版 Java 运行环境。
- 每来一个新任务，若没有空闲线程，就立即新建线程
- 高并发或短时流量尖峰下，线程数量爆炸式增长，JVM 线程栈内存迅速耗尽
- 系统可能抛出
java.lang.OutOfMemoryError: unable to create new native thread
newSingleThreadExecutor：单点失效 + 无界队列双重风险
表面看是“安全”的单线程池，实际有两处硬伤：
- 底层仍是无界 LinkedBlockingQueue，任务积压一样会导致内存暴涨
- 内部线程一旦因未捕获异常退出，整个池就瘫痪，后续所有任务永久阻塞，且无日志提示
- 返回类型是 FinalizableDelegatedExecutorService，无法转型为 ThreadPoolExecutor，也就没法调用
getPoolSize()、getQueue().size()等关键监控方法
这三类线程池的共同问题是：参数固化、行为不可控、拒绝策略单一、缺乏可观测性。生产环境必须改用 ThreadPoolExecutor 手动构造，显式控制核心线程数、最大线程数、有界队列容量和拒绝策略。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
