根本原因是Executors封装的无界队列（如LinkedBlockingQueue容量为Integer.MAX_VALUE）和无上限线程数（Integer.MAX_VALUE）易引发OOM与线程爆炸，且隐藏关键参数、默认拒绝策略不可控，违背显式配置与可观测性原则。
阿里规范不推荐用 Executors 创建线程池，根本原因不是它“写错了”，而是它把关键风险藏得太深——用起来方便，出事却很猛。
无界队列导致内存持续上涨
像 newFixedThreadPool 和 newSingleThreadExecutor 内部都用了 LinkedBlockingQueue() 无参构造，队列容量是 Integer.MAX_VALUE（约 21 亿）。这等于默认开了个“无限缓冲区”：
- 下游响应变慢、数据库卡顿、缓存击穿时，任务照常入队，不会拒绝
- 每个待执行的
Runnable对象携带闭包变量、堆栈上下文，持续占用堆内存 - 积压几十万任务后，
OutOfMemoryError: Java heap space很可能直接让服务宕机
线程数失控引发系统过载
newCachedThreadPool 和 newScheduledThreadPool 的最大线程数设为 Integer.MAX_VALUE，问题在于：
- 高并发下新任务不断到来，线程池会持续新建线程（哪怕旧线程刚空闲）
- 每个线程默认占 1MB 栈空间，1000 个线程就吃掉 1GB 内存
- CPU 频繁切换上下文，系统响应迟滞，甚至出现假死
参数黑盒削弱可观测性与治理能力
Executors 把所有配置封装成“一行代码”，开发者看不到也改不了：
立即学习“Java免费学习笔记（深入）”；
- 拒绝策略固定为
AbortPolicy，异常若未捕获，任务静默丢失 - 线程名全是
pool-1-thread-1这类默认命名，多线程池共存时日志无法区分来源 - 没法设置
allowCoreThreadTimeOut、自定义ThreadFactory或有界队列等关键能力
违背“显式优于隐式”的工程原则
阿里强调：线程池是核心资源，行为必须可预期、可监控、可治理。用 ThreadPoolExecutor 显式传参，倒逼开发者思考：
- 我这个业务每秒大概多少任务？平均耗时多久？该配多少核心线程？
- 用什么队列？
ArrayBlockingQueue（有界）还是SynchronousQueue（不缓存）？ - 队列满了怎么办？选
CallerRunsPolicy回压，还是记录指标告警？ - 线程名要不要带上业务标识？要不要设置守护线程或优先级？
