Java中Executors工厂类不推荐在生产环境直接使用，因其默认线程池存在资源失控、OOM和任务堆积等设计缺陷：FixedThreadPool与SingleThreadExecutor使用无界队列易导致内存溢出；CachedThreadPool可能创建过多线程引发栈内存耗尽与上下文切换开销；ScheduledThreadPool的无界延迟队列在任务阻塞时会造成积压与内存泄漏；问题本质非线程安全，而是参数配置不合理导致系统稳定性风险。
Java中Executors工厂类**不推荐在生产环境直接使用**，主要原因在于其默认创建的线程池存在资源失控、OOM（内存溢出）和任务堆积等隐性风险，并非“线程安全”问题，而是**设计层面的合理性与可控性缺陷**。
FixedThreadPool 和 SingleThreadExecutor 的队列风险
这两个方法底层使用的是无界队列（LinkedBlockingQueue，容量为Integer.MAX_VALUE）。当任务提交速度持续大于执行速度时，队列会无限增长，最终耗尽堆内存。
- 例如：每秒提交100个耗时2秒的任务，但线程池只有5个核心线程 → 每秒净增90个待执行任务 → 几分钟内队列对象可达数十万，触发Full GC甚至OOM
- 解决方式：显式构造
ThreadPoolExecutor，使用有界队列（如ArrayBlockingQueue），并配置合理的拒绝策略（如AbortPolicy或自定义处理逻辑）
CachedThreadPool 的线程创建失控问题
该线程池允许创建多达Integer.MAX_VALUE个线程，且空闲60秒后才回收。在突发高并发场景下，可能瞬间创建数千线程，导致：
ScheduledThreadPool 的隐藏陷阱
Executors.newScheduledThreadPool(n)看似可控，但它内部使用的队列是无界的DelayedWorkQueue（基于堆的无界延迟队列）。如果调度任务执行缓慢或被阻塞，后续任务将持续积压，同样引发内存泄漏风险。
立即学习“Java免费学习笔记（深入）”；
- 典型场景：定时任务中调用未设超时的远程HTTP请求，某次网络卡顿导致后续所有延时任务排队等待
- 建议：对关键调度任务做超时控制 + 异常兜底；必要时改用
ScheduledThreadPoolExecutor并监控队列大小
为什么说“不是线程安全问题”？
Executors创建的线程池本身是线程安全的（如execute()、submit()可并发调用），问题出在**配置不合理导致的系统级稳定性风险**。它掩盖了对核心参数（核心线程数、最大线程数、队列类型与容量、拒绝策略）的主动决策过程。
- 新手易误以为“封装即安全”，忽视业务负载特征
- 团队协作中，隐式依赖默认行为，导致线上问题难以归因
- 微服务架构下，每个模块都用
Executors，整体线程和队列资源不可控
真正安全的做法是：根据业务吞吐量、任务类型（CPU密集型/IO密集型）、失败容忍度，手动构建ThreadPoolExecutor，明确每项参数含义，并配合监控（如ActiveCount、QueueSize、RejectedExecutionCount）。
