每日一道面试题 07：为什么不建议使用 Executors 创建线程池？生产环境如何正确定义 ThreadPoolExecutor？
一、先说结论
- Executors 本质上是快捷工具，不是生产级方案
- 它提供的
FixedThreadPool、SingleThreadPool、CachedThreadPool都存在严重的资源风险 - 生产环境必须手动 new ThreadPoolExecutor (...)，自己控制队列、线程数、拒绝策略
二、Executors 到底有什么坑？（深度考点）
1. FixedThreadPool / SingleThreadPool
Executors.newFixedThreadPool(n);- 内部使用无界队列
LinkedBlockingQueue（默认容量 Integer.MAX_VALUE） - 任务无限堆积，会导致OOM 内存溢出
2. CachedThreadPool
Executors.newCachedThreadPool();- 最大线程数
Integer.MAX_VALUE - 高并发下会无限创建线程，导致线程爆炸、CPU 打满、OOM
3. ScheduledThreadPool
- 延迟队列 + 无界队列
- 同样存在任务堆积风险
一句话总结：Executors 屏蔽了资源控制，把风险隐藏起来，流量一高直接崩。
三、生产环境正确写法
ThreadPoolExecutor executor = new ThreadPoolExecutor( 5, // corePoolSize 10, // maximumPoolSize 60L, // keepAliveTime TimeUnit.SECONDS, new ArrayBlockingQueue<>(100), // 有界队列，控制任务量 new ThreadFactoryBuilder() .setNameFormat("biz-pool-%d") .build(), new ThreadPoolExecutor.CallerRunsPolicy() // 拒绝策略 );为什么这样写才安全？
- 用 ArrayBlockingQueue 有界队列限制最大任务数，不会无限堆积 OOM
- 手动指定核心线程、最大线程避免无限制创建线程
- 自定义线程工厂方便日志定位、问题排查
- 明确拒绝策略流量超负载时，服务不崩，而是优雅降级
四、核心参数如何合理设置？
- CPU 密集型：核心线程数 = CPU 核心数 + 1
- IO 密集型（接口调用、DB、Redis）：核心线程数 = CPU 核心数 * 2~4
- 队列大小：根据接口耗时 + 单机 QPS 估算队列过大 = 响应慢；队列过小 = 频繁拒绝
- 拒绝策略优先用：
CallerRunsPolicy（让调用方执行，不丢任务）- 高可用系统可自定义拒绝策略：记录日志 + 告警 + 持久化
五、面试官追问：你平时怎么用？
标准高分回答：
项目里统一使用手动new ThreadPoolExecutor定义线程池，禁止用 Executors。根据业务是 IO 密集还是 CPU 密集设置线程数，使用有界队列防止 OOM，自定义线程名方便排查，配合 CallerRunsPolicy 避免任务丢失，同时对线程池进行监控，活跃线程、队列堆积、拒绝次数都接入告警。