阿里规范不推荐用Executors创建线程池，因其隐藏关键参数导致无界队列引发OOM、线程数失控造成系统过载、默认策略不可控难以定位问题，强制显式构造ThreadPoolExecutor以明确责任。
阿里规范不推荐用 Executors 创建线程池，核心不是它“写错了”，而是它把关键风险参数藏得太深，让开发者在不知不觉中踩坑。
无界队列导致内存持续上涨
像 newFixedThreadPool(10) 和 newSingleThreadExecutor() 内部用的是 LinkedBlockingQueue 无参构造，队列容量是 Integer.MAX_VALUE（约 21 亿）。这等于没有容量限制：
- 下游服务响应变慢、数据库查询卡顿、缓存击穿时，任务提交速度远超处理速度
- 任务对象连同闭包变量、调用栈一起堆在内存里，每积压几万任务就可能吃掉上百 MB 堆空间
- OOM 不是“会不会发生”，而是“什么时候发生”——一旦触发，整个应用直接崩溃
线程数失控引发系统过载
newCachedThreadPool() 和 newScheduledThreadPool(5) 的最大线程数设为 Integer.MAX_VALUE：
- 高并发瞬间涌入大量任务，线程池不断新建线程，哪怕旧线程还没回收
- 每个线程默认分配 1MB 栈空间，1000 个线程就占 1GB 栈内存，操作系统线程资源迅速见底
- CPU 频繁做上下文切换，吞吐下降、延迟飙升，服务看起来“活着”，实则无法响应
默认策略不可控，问题难定位
Executors 封装了所有配置，开发者看不到也改不了：
立即学习“Java免费学习笔记（深入）”；
- 拒绝策略固定是
AbortPolicy，异常若没捕获，任务静默丢失，日志里连痕迹都没有 - 线程名全是
pool-1-thread-1这类通用编号，多个线程池混用时，出问题根本分不清是谁干的 - 没法启用
allowCoreThreadTimeOut，没法配合理的存活时间，也没法换有界队列或优先级队列
强制显式构造是为了责任前置
用 ThreadPoolExecutor 手动创建，必须填满 7 个参数：
- 你得想清楚：核心线程要几个？最多能扩到多少？空闲多久回收？
- 你得选队列：是定长的
ArrayBlockingQueue，还是同步交接的SynchronousQueue？ - 你得定拒绝策略：是丢老任务（
DiscardOldestPolicy），还是让调用方自己跑（CallerRunsPolicy）？ - 你还得自定义线程工厂，给线程起有意义的名字，方便监控和排查
