生产环境禁止使用Executors工厂类，因其默认配置存在无界队列（如LinkedBlockingQueue容量为Integer.MAX_VALUE）和线程数失控（如newCachedThreadPool最大线程数为Integer.MAX_VALUE）两大致命缺陷，易引发OOM或系统宕机；正确做法是手动创建ThreadPoolExecutor，显式配置核心线程数、最大线程数、有界队列、拒绝策略、线程工厂等七大参数。
Executors工厂类确实方便，但生产环境基本不该用。它封装了线程池创建逻辑，适合学习、测试或极低并发的内部工具脚本；一旦涉及真实业务流量、资源受限或稳定性要求，就必须绕过它，手动构造ThreadPoolExecutor。
哪些场景还能谨慎用Executors？
不是完全禁用，而是严格限定使用边界：
-
本地开发调试：比如写个Demo验证异步逻辑，或单元测试中启动临时线程池，用
newFixedThreadPool(2)省事无妨 - 离线批处理脚本：运行一次、不长期驻留、无并发压力的后台小任务（如日志清洗、配置生成），且明确知道任务量可控
- 嵌入式或资源极度宽松环境：比如内网管理后台、单机桌面应用，QPS＜10、内存充足、无SLA要求
为什么Executors默认配置在生产中是“定时炸弹”？
问题不在API本身，而在它隐藏的关键参数设计——全部绑定无界队列或失控线程数：
-
newFixedThreadPool(n)和newSingleThreadExecutor()底层用的是LinkedBlockingQueue，容量为Integer.MAX_VALUE，任务堆积即OOM -
newCachedThreadPool()不设最大线程上限，突发请求可能瞬间拉起数百线程，CPU打满、上下文切换爆炸 -
newScheduledThreadPool(n)的队列也是无界，混入非定时任务会拖垮整个调度器 - 所有默认线程池都缺失显式拒绝策略，队列满或线程超限时直接抛异常，无法降级或兜底
替代方案：三步写出安全可用的线程池
不用背源码，按实际需求填好七个参数即可：
立即学习“Java免费学习笔记（深入）”；
- 定核心线程数：IO密集型可设为 CPU核数×2～3；纯计算任务建议 CPU核数+1
- 设最大线程数：通常不超过核心数的2倍，避免过度争抢CPU和内存
-
配有界队列：例如
new LinkedBlockingQueue(200)，容量根据平均任务耗时和吞吐预估，宁小勿大 -
选拒绝策略：高优先级任务用
CallerRunsPolicy（由调用方线程执行）；可丢弃场景用AbortPolicy或自定义日志记录 -
加线程工厂：至少命名线程，便于排查（如
new ThreadFactoryBuilder().setNameFormat("biz-async-%d").build()）
容易被忽略的收尾与监控要点
线程池不是创建完就万事大吉：
-
必须显式关闭：Spring环境下用
@PreDestroy调用shutdown()；非托管环境确保JVM退出前触发 -
捕获任务异常：不要依赖线程池自动处理，每个
Runnable或Callable里包一层 try-catch，防止未捕获异常导致线程静默终止 -
暴露基础指标：定期采集
getActiveCount()、getQueue().size()、getCompletedTaskCount()，接入Prometheus或日志告警 -
避免阻塞操作：线程池内禁止调用
Thread.sleep()、数据库长查询、外部HTTP同步等待——这些会把线程卡死，等效于减少可用线程数
