面试考察点
- 能否区分 Executors 工厂方法和手动构造。
- 能否准确描述“核心线程 → 队列 → 最大线程 → 拒绝”的流程。
- 能否根据 CPU 密集、IO 密集和任务可靠性选择参数。
核心答案
**一句话回答：**Java 可以通过 Executors 工厂方法、ThreadPoolExecutor、ScheduledThreadPoolExecutor 和 ForkJoinPool 创建不同类型的执行器；生产环境通常推荐手动构造 ThreadPoolExecutor，明确资源边界。
execute 的执行流程
提交任务后，ThreadPoolExecutor 会按顺序判断：
- 当前线程数小于
corePoolSize：创建核心线程执行任务，即使已有核心线程空闲。 - 核心线程已达到上限：尝试将任务放入
workQueue。 - 队列放不下且线程数小于
maximumPoolSize：创建非核心线程。 - 队列已满且线程数达到最大值：调用拒绝策略。
这意味着线程池不会一开始就把线程创建到最大值，队列容量会影响何时开始扩容。
七个核心参数
| 参数 | 作用 | 配置关注点 |
|---|---|---|
corePoolSize |
常驻核心线程数 | 任务的稳定处理能力 |
maximumPoolSize |
最大线程数 | 峰值并发和下游承载 |
keepAliveTime |
非核心线程空闲存活时间 | 峰值后的资源回收 |
workQueue |
保存等待任务 | 有界、容量、顺序 |
threadFactory |
创建和命名线程 | 线程名、优先级、异常处理 |
handler |
任务无法接收时的处理器 | 失败、降级或反压策略 |
ThreadPoolExecutor executor = new ThreadPoolExecutor(
8, 16, 60, TimeUnit.SECONDS,
new ArrayBlockingQueue<>(1000),
new NamedThreadFactory("order-worker"),
new ThreadPoolExecutor.CallerRunsPolicy()
);
队列策略如何影响线程池？
SynchronousQueue 不保存任务，适合直接移交，但可能造成线程快速增长；无界 LinkedBlockingQueue 会让任务持续排队，通常使最大线程数几乎不起作用；有界队列能给系统建立明确的内存和延迟上限，更适合核心业务。
队列不是越大越好。队列过大可能掩盖消费速度不足，最终带来更长延迟；队列过小又可能频繁触发拒绝。应该结合任务耗时、请求峰值和下游容量压测。
拒绝策略
AbortPolicy：抛出异常，适合必须让调用方感知失败的任务。CallerRunsPolicy：由提交任务的线程执行，形成自然反压。DiscardPolicy：静默丢弃，只适用于明确允许丢失的任务。DiscardOldestPolicy：丢弃队头任务后重试，适合旧任务价值较低的场景。
线程数怎么设置？
CPU 密集型任务通常从接近 CPU 核数开始；IO 密集型任务可以更高，但不能只套公式。应观察 CPU 使用率、上下文切换、队列长度、任务等待时间、拒绝次数和下游 RT。
线程池还应配置有意义的线程名、统一异常处理和关闭流程。应用停止时调用 shutdown()，必要时在超时后调用 shutdownNow()，不要让工作线程无限期存活。
Executors 为什么要谨慎？
工厂方法适合快速原型，但固定线程池和单线程池默认使用近似无界队列，缓存线程池的最大线程数也非常大。生产环境如果不明确边界，任务堆积或突发流量可能耗尽内存或线程资源。
参考资料
核心考点清单
- 提交后依次考虑核心线程、工作队列、最大线程和拒绝策略。
- 无界队列可能隐藏过载并最终 OOM；队列和线程数必须结合任务特征计算。
- 拒绝策略是系统背压设计的一部分，不能上线前才临时决定。
- 线程池必须命名、监控并优雅关闭，不应跨业务混用一个公共池。
高频追问与参考回答
追问：CPU 密集与 IO 密集线程数如何设置？
CPU 密集通常接近核数，IO 密集可根据等待时间比例适当增加。公式只是起点，最终要用生产任务模型压测，并观察 CPU、队列和下游容量。
追问：execute 和 submit 有什么区别？
execute 接收 Runnable，异常通常交给线程的未捕获异常处理器；submit 返回 Future，任务异常会封装在 Future 中，若从不 get 容易被忽略。
机制全景图
下面把「Java 线程池有几种创建方式？」从输入到结果压缩成一条可复述的主链路。面试时先用图建立全局坐标，再进入局部实现，能避免只背零散结论。
flowchart LR
A["任务提交"]
A --> B["判断核心线程"]
B --> C["进入有界队列"]
C --> D["扩容至最大线程"]
D --> E["执行拒绝策略"]
完整链路：从输入到结果
沿着「任务提交 → 判断核心线程 → 进入有界队列 → 扩容至最大线程 → 执行拒绝策略」观察输入、状态与输出，下面每个阶段都对应一个可以在源码、日志或系统表中验证的位置。
1. 任务提交
execute/submit 接收任务，submit 还会包装为 FutureTask，因此异常传播方式不同。
2. 判断核心线程
运行线程少于 corePoolSize 时优先创建核心线程，即使已有空闲线程也按实现状态判断。
3. 进入有界队列
核心线程满后任务先进入工作队列，队列类型决定排队、公平和内存风险。
4. 扩容至最大线程
队列满且线程数未达 maximumPoolSize 时再创建非核心线程，keepAliveTime 控制其回收。
5. 执行拒绝策略
线程与队列都饱和后触发拒绝策略，必须把过载反馈给调用方而不是静默丢任务。
源码与实现定位
| 入口 | 阅读重点 |
|---|---|
| ThreadPoolExecutor#execute | 核心线程→队列→最大线程→拒绝 |
| ThreadPoolExecutor#getTask | 取任务、超时回收和 worker 生命周期 |
源码或系统表应按上表顺序追踪：先确认入口实际走到哪条路径，再用运行时数据验证，而不是仅凭类名或配置推测。
参数配置与可复现实验
new ThreadPoolExecutor(16, 32, 60, SECONDS,
new ArrayBlockingQueue<>(500), factory,
new ThreadPoolExecutor.AbortPolicy());
按 Little 定律用到达率×服务时间估算在途量，再注入 5 倍峰值与慢下游，观察拒绝是否早于连接池耗尽。
验证步骤与预期结果
1. 固定输入和基线
先在没有故障注入的环境执行上述配置，固定数据规模、并发度、运行时版本和预热时间。以「队列等待 P99」为主基线，记录值应满足「<端到端预算 20%」；同时保存 活跃线程数、队列长度与等待时间，使后续变化能够回到同一时间轴比较。
2. 从实现入口确认路径
在「ThreadPoolExecutor#execute」确认请求确实进入「核心线程→队列→最大线程→拒绝」对应的实现，再沿「ThreadPoolExecutor#getTask」观察「取任务、超时回收和 worker 生命周期」。如果入口路径都未命中，就不应继续调整下游参数，而应先检查调用条件、版本或路由是否与假设一致。
3. 注入本文特有的失败模式
优先复现「无界队列掩盖过载直到 OOM」，并把单一变量逐级放大，直到「队列等待 P99」越过「超过 50%」。随后再分别验证「任务异常被 submit 的 Future 吞住」和「多个线程池共同耗尽同一下游连接池」，三类故障分开执行，避免多个变量同时变化而无法归因。
4. 执行止损和根因修复
第一轮只应用「有界队列+显式拒绝」，确认它能控制影响范围；第二轮应用「分离 CPU 与阻塞任务池」，验证核心链路恢复；最后落实「线程数受下游连接数约束」，消除同类问题再次出现的条件。每一步都保留变更前后数据，不用“感觉变快了”替代测量。
5. 通过退出条件
实验只有同时满足三项才算通过：「队列等待 P99」回到「<端到端预算 20%」、「active/max」回到「稳态留 30% 余量」、「拒绝率」回到「平时 0、峰值可控」，并且业务结果差异为零。若性能恢复但结果不一致，仍应视为失败；若指标恢复后很快再次越线，则说明只完成了临时止损，没有消除根因。
量化基线
| 指标 | 样例基线/口径 | 风险线 | 结论 |
|---|---|---|---|
| 队列等待 P99 | <端到端预算 20% | 超过 50% | 任务已过期 |
| active/max | 稳态留 30% 余量 | 持续 100% | 线程不足或下游慢 |
| 拒绝率 | 平时 0、峰值可控 | 无告警增长 | 过载未反馈 |
这些数值是实验口径或示例告警线，不是可复制到所有系统的固定答案；上线阈值应由本系统稳态、峰值和故障演练共同确定。
事故复盘：接口高峰期线程池队列持续增长
服务使用无界 LinkedBlockingQueue，maximumPoolSize 实际失效，慢下游让任务不断排队，最终超时与堆占用一起上升。改为按下游容量设置有界队列、显式拒绝并对调用方限流后，系统能够快速失败而不是积压到崩溃。
| 失败模式 | 首要证据 | 第一处置动作 |
|---|---|---|
| 无界队列掩盖过载直到 OOM | 活跃线程数 | 有界队列+显式拒绝 |
| 任务异常被 submit 的 Future 吞住 | 队列长度与等待时间 | 分离 CPU 与阻塞任务池 |
| 多个线程池共同耗尽同一下游连接池 | 拒绝次数 | 线程数受下游连接数约束 |
发布与回滚检查点
- 发布前：确认「ThreadPoolExecutor#execute」对应实现和上述配置在目标版本仍然有效，并保存「队列等待 P99」基线。
- 灰度中：同时观察 活跃线程数、队列长度与等待时间、拒绝次数；任一指标越过表中风险线，就停止继续扩量。
- 回滚时：先执行「有界队列+显式拒绝」控制影响，再回退代码或参数；涉及持久状态时必须额外核对结果差异。
- 发布后：至少覆盖一个完整峰值周期，确认「无界队列掩盖过载直到 OOM」没有再次出现，才关闭变更观察窗口。
方案对比与选型
| 方案 | 更适合的场景 | 主要收益 | 代价与边界 |
|---|---|---|---|
| CPU 密集固定池 | 计算任务且很少阻塞 | 线程数接近 CPU 核心，切换少 | 混入阻塞会拖慢全部任务 |
| 有界弹性池 | I/O 阻塞比例可测且需吸收短峰值 | 可用线程覆盖等待时间 | 必须限制最大线程与队列 |
| 虚拟线程/同步编排 | 大量独立阻塞 I/O | 代码直观、并发数高 | 仍需限制数据库等稀缺资源 |
选型至少带上 并发线程数、临界区长度、阻塞比例和任务到达速率，并用上面的量化基线验证；未知数据应明确为待测假设。
设计边界与工程取舍
线程池隔离的是调度资源，不会提升下游实际容量；线程数必须与 CPU、连接池和远端并发上限共同设计。
工程落地遵循：先建立 happens-before 与所有权边界，再谈吞吐和无锁优化。回答时直接引用「ThreadPoolExecutor#execute」、配置实验和事故数据，比复述固定模板更有说服力。