阿里规范不推荐用Executors创建线程池，因其默认无界队列易致OOM、线程数无上限引发系统过载、参数黑盒削弱可观测性；应显式使用ThreadPoolExecutor，明确配置队列容量、线程数及拒绝策略以保障生产稳定性。
阿里规范不推荐用 Executors 创建线程池，核心不是它“写错了”，而是它把关键风险藏得太深——默认配置在高并发、慢依赖或突发流量下极易引发线上事故。
无界队列导致内存持续膨胀
像 newFixedThreadPool(10) 和 newSingleThreadExecutor() 内部用的是 LinkedBlockingQueue() 无参构造，队列容量为 Integer.MAX_VALUE（约 21 亿）。这等于没有容量限制：
- 当下游响应变慢（如数据库超时、RPC延迟），任务提交速度远高于消费速度，任务就不断进队；
- 每个待执行的
Runnable对象携带闭包变量、堆栈上下文等，会持续占用堆内存； - 积压几万甚至几十万个任务后，
OutOfMemoryError: Java heap space很快出现，整个应用挂掉。
线程数无上限引发系统过载
newCachedThreadPool() 和 newScheduledThreadPool(5) 的最大线程数设为 Integer.MAX_VALUE：
- 高并发场景下，只要队列没任务、又有新请求，就会不停新建线程；
- 每个线程默认分配约 1MB 栈空间，1000 个线程就吃掉 1GB 内存；
- 线程过多还会加剧 CPU 上下文切换，服务响应变卡甚至假死。
参数黑盒削弱可观测性与可控性
Executors 封装了所有细节，开发者看不到也改不了：
立即学习“Java免费学习笔记（深入）”；
- 拒绝策略固定为
AbortPolicy，异常若未捕获，任务静默丢失，毫无告警； - 线程名是默认的
pool-1-thread-1，多个线程池混用时日志无法区分来源； - 无法启用
allowCoreThreadTimeOut、无法自定义ThreadFactory、不能设合理keepAliveTime或有界队列。
显式构造才是生产级实践
用 ThreadPoolExecutor 手动创建，强制你思考每个参数的实际意义：
- 选
ArrayBlockingQueue或带容量的LinkedBlockingQueue，让队列满时及时触发拒绝策略； - 设合理的
corePoolSize和maximumPoolSize，避免线程爆炸； - 搭配
CallerRunsPolicy或自定义拒绝逻辑，把压力反馈给上游； - 用带业务标识的
ThreadFactory，方便监控和排查问题。
本质上，阿里规约要的不是“更复杂的写法”，而是把资源契约暴露出来，让每个线程池都可评估、可监控、可兜底。
