阿里巴巴禁用Executors创建线程池，核心原因是其封装的无界队列（如LinkedBlockingQueue）和无上限线程数（Integer.MAX_VALUE）易引发OOM和线程爆炸，且隐藏关键参数、默认拒绝策略不可控，违背显式配置与可观测性原则。
阿里巴巴禁用 Executors 创建线程池，核心原因不是它“不能用”，而是它在生产环境中容易引发不可控的资源耗尽风险——尤其是内存溢出（OOM）和线程爆炸，且掩盖了关键配置细节，削弱系统可观测性与稳定性。
无界队列导致任务无限堆积
像 newFixedThreadPool 和 newSingleThreadExecutor 内部使用的是 LinkedBlockingQueue 无参构造，队列容量为 Integer.MAX_VALUE（约 21 亿）。这意味着：
- 当任务提交速度远超处理速度（如下游服务慢、突发流量），任务持续入队，不触发拒绝机制；
- 每个待执行任务对象（含闭包变量、堆栈上下文）都占用堆内存；
- 积压数万甚至百万任务后，极易触发
OutOfMemoryError: Java heap space，整个应用崩溃。
无上限线程创建引发系统过载
newCachedThreadPool 和 newScheduledThreadPool 的最大线程数设为 Integer.MAX_VALUE，问题在于：
- 高并发下新任务不断到来，线程池会持续新建线程（即使旧线程空闲未回收）；
- 每个线程默认分配 1MB 栈空间，1000 个线程就占用 1GB 栈内存；
- 线程过多加剧 CPU 上下文切换开销，导致系统响应迟滞甚至假死。
参数黑盒 + 默认策略不可控
Executors 封装了所有参数，开发者看不到也改不了：
立即学习“Java免费学习笔记（深入）”；
- 拒绝策略固定为
AbortPolicy（抛RejectedExecutionException），异常若未捕获，任务静默丢失； - 线程工厂使用默认名称（如
pool-1-thread-1），多线程池共存时无法区分日志来源； - 无法启用
allowCoreThreadTimeOut等高级特性，也无法设置合理的 keep-alive 时间或有界队列。
违背“显式优于隐式”的工程原则
阿里强调：线程池是重要基础设施，其行为必须可预期、可监控、可治理。通过 ThreadPoolExecutor 显式传参，强制开发者思考：
- 这个业务是 CPU 密集型还是 IO 密集型？该配多少核心线程？
- 队列类型选
ArrayBlockingQueue还是SynchronousQueue？容量设多少？ - 超负荷时该丢弃、降级、还是让调用方自己执行（
CallerRunsPolicy）？ - 线程名要不要带上业务标识？要不要统一设置守护状态或优先级？
