阿里禁止用Executors创建线程池，核心原因是其默认配置易引发OOM、线程爆炸和监控失能；必须手动通过ThreadPoolExecutor显式设置7个参数，强制开发者权衡corePoolSize、有界队列、自定义线程工厂与拒绝策略。
阿里禁止用 Executors 创建线程池，核心原因不是它“不能用”，而是它的默认配置在生产环境中极易引发系统性风险——内存溢出、线程爆炸、监控失能。手动通过 ThreadPoolExecutor 构造，本质是把控制权交还给开发者，强制你直面每个关键参数的取舍。
无界队列埋下OOM隐患
newFixedThreadPool 和 newSingleThreadExecutor 内部使用的是 LinkedBlockingQueue，且未指定容量，等效于 new LinkedBlockingQueue(Integer.MAX_VALUE)。这意味着：任务持续提交但处理缓慢时，队列无限堆积，JVM堆内存被迅速吃尽。
- 比如促销下单接口每秒涌入5000请求，而线程池仅10个线程、单个订单处理耗时200ms，理论每秒最多处理50个——其余4950个任务全进队列，1分钟就积压近30万任务
- 这类问题不会立刻报错，而是悄无声息地拖慢GC、升高Full GC频率，最终触发
java.lang.OutOfMemoryError: Java heap space
线程数失控导致资源耗尽
newCachedThreadPool 和 newScheduledThreadPool 的 maximumPoolSize = Integer.MAX_VALUE，配合极短的空闲回收时间（60秒），在外部依赖延迟或抖动时，会瞬间创建成千上万个线程。
- 一个HTTP调用因网络波动响应从100ms升至3s，原有线程来不及释放，新任务不断触发新线程创建
- 线程本身占用栈内存（默认1MB），1000个线程就消耗1GB栈空间；加上上下文切换开销，CPU使用率飙升，系统假死
拒绝策略与线程工厂不可控
Executors 创建的线程池固定采用 AbortPolicy（抛异常）和默认线程工厂，既无法感知任务被拒，也难以定位问题线程。
立即学习“Java免费学习笔记（深入）”；
- 默认线程名形如
pool-1-thread-1，多个线程池混用时，日志中无法区分来源 - 没有设置拒绝策略时，任务被丢弃不通知，业务逻辑静默失败，排查成本极高
- 无法启用
allowCoreThreadTimeOut等高级特性，灵活性严重受限
手动创建的关键参数必须显式声明
用 ThreadPoolExecutor 构造时，7个参数缺一不可，倒逼你思考真实场景：
- corePoolSize / maximumPoolSize：按CPU密集型（≈核数+1）或IO密集型（可设为核数×2~4）估算
-
workQueue：优先选
ArrayBlockingQueue并设合理容量（如200），杜绝无界风险 -
threadFactory：用
ThreadFactoryBuilder命名线程，如order-process-pool-%d -
handler：高可用场景推荐
CallerRunsPolicy（由提交线程自己执行），避免丢任务
