线程池的本质并非并发，而是对有限计算资源（线程）的系统性管理。
从第一性原理看，线程池解决四个问题，其中三个长期稳定，一个依赖前提：
这一定义中，资源控制与退化治理（上限、堆积、退化）跨语言、跨框架长期成立，属于稳定知识；资源复用则是前提性职能——它依赖"线程创建昂贵"这一运行时约束。
从架构角度，一个线程池永远由以下四个维度组成：
| 维度 | 核心问题 | 设计关注点 |
|---|---|---|
| 任务模型 | 任务是什么 | 是否有依赖、是否可拆分 |
| 调度策略 | 先执行谁 | 公平性 / 吞吐 |
| 资源模型 | 用多少线程 | 上限、回收、预热 |
| 背压与退化 | 超载怎么办 | 排队 / 拒绝 / 回退 |
后文所有 Executor、ThreadPoolExecutor、ForkJoinPool 的差异，本质都源于对这四个问题的不同回答。
public interface Executor {
void execute(Runnable command);
}
这个接口的价值在于在职责切分：
被彻底解耦。
Executor 把“怎么执行”从提交点剥离成可外部注入的策略实现。
ExecutorService 在 Executor 之上，主要引入了：
这标志着线程池从"工具"升级为受控系统组件。"受控"的重要性可抽象为三条第一性原理：
Future 不是为了"返回值"，而是为了：
将"尚未完成的计算"显式建模为一个对象
成为对象，它才获得对象的全部能力——可命名、可传递、可操作、可组合，从而实现生产者与消费者的时间解耦。
其本质能力只有三点：
FutureTask 同时扮演三种角色：
| 角色 | 设计模式 |
|---|---|
| 任务 | Callable |
| 结果容器 | Future |
| 状态机 | 并发状态管理 |
这也是它复杂度高的根本原因。
源码层的并发技术细节，都是为这个状态机一致性服务。
ThreadPoolExecutor 面向的问题是：
大量相互独立、执行时间不可控的任务
典型场景：
| 组件 | 架构角色 | 设计思想 |
|---|---|---|
| Worker | 执行单元 | Executor Pattern |
| BlockingQueue | 缓冲/背压 | Producer–Consumer |
| RejectHandler | 失败策略 | Policy Pattern |
| before/afterExecute | 扩展点 | AOP Hook |
| 运行状态机（runState + workerCount） | 生命周期治理 | 原子状态管理 |
BlockingQueue 与 Worker 构成生产者-消费者主轴；运行状态机是驱动所有分支的共享中枢；RejectHandler 守入口溢出、before/afterExecute 守执行横切。 五者合起来，就是“在有限线程资源下，安全地吞吐一股不可控任务流，并在过载时优雅退化”——也正是 ThreadPoolExecutor 作为“资源型”线程池的全部职责。
源码复杂，是因为它在用代码维护一个高并发状态机。
workerCount < corePoolSize？
├─ 是 → 新建核心线程执行
└─ 否 → 能否入队（队列未满）？
├─ 是 → 入队等待
└─ 否 → workerCount < maxPoolSize？
├─ 是 → 新建非核心线程
└─ 否 → 触发拒绝策略
线程池的提交决策树本质是“渐进降级”阶梯：沿代价递增、可逆性递减、伤害递增的方向，永远先用最便宜最可逆的动作，耗尽才升级——复用 ＜ 排队 ＜ 扩容 ＜ 拒绝。
这是稳定的调度决策树，实现细节可以变，但逻辑不会。
经验公式只提供方向，而非答案：
N = N_cpu × U_cpu × (1 + W/C)
| 符号 | 含义 |
|---|---|
| N_cpu | CPU 核数 |
| U_cpu | 目标 CPU 利用率（0~1） |
| W/C | 任务的等待耗时 / 计算耗时之比 |
它唯一稳定的信息是方向：等待占比（W/C）越高，应配的并发度越大——IO 密集型该多开，CPU 密集型该收紧。但它给不出具体值，因为：
正确策略：监控 + 动态调整，而非一次性计算。
四个参数不是独立配置项，而是上一节那条降级阶梯（复用 ＜ 排队 ＜ 扩容 ＜ 拒绝）的刻度旋钮——配参数，就是在声明各档拐点设在哪里：
| 参数 | 真正语义 | 在阶梯上调的是 |
|---|---|---|
| corePoolSize | 稳定态基线并发度 | "复用"档容量 |
| queue（含有界性） | 缓冲深度 + 吞吐/延迟权衡 | "排队"档深度；其有界性决定扩容档是否触发 |
| maxPoolSize | 应急峰值容量（仅在有界队列下才是真上限） | "扩容"档上限 |
| keepAlive | 应急线程的回落速度 | 扩容后弹回稳定态的速率 |
关键耦合：queue 的有界性决定 maxPoolSize 是否生效。无界队列下排队档永不溢出，扩容档无从触发，max 形同虚设、极限容量退化为无穷（堆到 OOM）——这正是上一节"无界队列下 max 失效"的参数层解释。
由此，参数从"配置项"升级为对系统行为形状的声明：core 定基线、queue 定缓冲、max 定应急上限、keepAlive 定回落速度。而这套静态声明无法预知动态负载——所以下一节转向运行期治理：用监控驱动这些旋钮的动态调整。
线程池治理的本质是一个带反馈的闭环控制——感知偏离、判断、调节，再感知。
可观测（感知偏离）→ 控制 / 退化（施加调节）→ 再观测……
三大能力正是前文"受控"三原理（可问责 / 可逆 / 鲁棒）在运行期的落地：
| 能力 | 对应受控原理 | 可决策信号 / 实现方式 |
|---|---|---|
| 可观测 | 可问责 | 队列持续增长=容量不足、活跃数/池大小=饱和度、拒绝计数=已过载（线程命名、队列长度、活跃数为其底层字段） |
| 控制 | 可逆 / 可干预 | 动态参数调整（即上一节那四个旋钮的运行期重设） |
| 退化 | 鲁棒性 | 拒绝策略，且内部是哲学相反的梯度——CallerRuns=反压（限速生产者） vs Abort=快速失败，对应降级阶梯"拒绝"档的细分 |
可观测的价值在支撑决策：度量必须能回答"是否偏离稳定态"，闭环才转得起来。
若说三大能力是治理的时间维（运行期的事中反馈），隔离则是其空间维（事前按故障域切分）——且隔离是"退化能局部化"的前提：没有隔离，单点慢调用耗尽共享池，故障全局扩散，退化无处施加。
隔离的本质是按故障域切分资源，主流粒度是依赖 / 资源 / 业务：
| 框架 | 隔离粒度 |
|---|---|
| Hystrix | 按依赖（per-dependency 线程池） |
| Resilience4j | 按调用（Bulkhead） |
| Dubbo | 按服务三元组 |
隔离是一笔用性能换稳定的交易：它增加上下文切换开销（性能上是负的），换来的是阻断单点慢调用引发的线程耗尽与级联失败。评判它要算稳定性账，而非性能账——这也是为什么过载场景下它仍然值得。
ForkJoinPool 解决的是：
可递归拆分的 CPU 密集型计算问题
其核心假设与违反后果：
| 核心假设 | 违反时的失效模式 |
|---|---|
| 子任务足够多、粒度足够细 | 任务过粗 → 窃取无对象，退化为串行 |
| 计算时间相对均衡 | 倾斜过大 → 窃取频繁，调度开销上升 |
| 任务不阻塞（纯计算） | 跑阻塞 IO → worker 饿死（parallel stream 误用于 IO 的经典事故） |
根本差异在任务模型：TPE 假设任务相互独立；fork/join 任务是父等子的依赖结构。在有限线程 + 单一共享队列下，父任务占着线程阻塞在 join，子任务排在队列后面无线程可执行——池自身成为死锁源。
ForkJoinPool 的本地队列正是为打破这个依赖死锁设计的：父任务 fork 出的子任务进入自己的本地队列，父线程可转头优先执行它，依赖链在线程内部就地消解。
工作窃取 = 把"集中队列的计划调度"换成"本地队列 + 空闲者主动偷"的去中心化调度，让负载均衡成为涌现属性
机制上靠一个双端队列（deque）的两端分工：
由此换来两个结构性收益：竞争被摊薄（无全局队列这一集中竞争点，仅窃取瞬间有竞争）、均衡是涌现的（不靠中央分派，靠空闲者主动找活）。代价是牺牲调度公平性——这对无外部 SLA 的内生计算任务无关紧要。
| 维度 | ThreadPoolExecutor（资源型） | ForkJoinPool（计算型） |
|---|---|---|
| 任务模型 | 相互独立、时长不可控 | 父子依赖、可递归拆分、时长均衡 |
| 调度策略 | 全局共享队列，FIFO 公平 | 本地 deque + 窃取，牺牲公平换吞吐 |
| 资源模型 | core/max 弹性伸缩 | 固定 ≈ CPU 核数（纯计算无须超配） |
| 背压与退化 | 排队/拒绝（核心关注） | 几乎不关注——任务由计算内生，而非外部洪峰 |
两个池对同四个问题给出不同回答，根源都是任务模型不同：独立任务流要治理的是资源与过载，依赖任务图要解决的是调度与依赖死锁。
FJP 如今已是 JDK 的基础设施调度器：parallel stream 与 CompletableFuture 的默认执行器（commonPool）、虚拟线程的底层载体。
CompletableFuture 不是线程池，也不是 Future 的简单升级，而是：
基于完成事件的数据流编排模型（Completion Stage）
| Future | CompletableFuture | |
|---|---|---|
| 获取结果 | 拉：消费者阻塞 get()，主动去取 |
推：完成事件驱动下游，结果到达自动触发后续 |
| 线程的角色 | 必须有一个线程等在那里 | 无人等待，完成时才占用线程 |
| 组合方式 | 无法组合，只能逐个阻塞 | thenApply/thenCombine 声明依赖即可 |
Future 把计算变成对象（可传递），但"可组合"在裸 Future 上无法兑现——只能阻塞等待。CF 把**"完成"本身变成事件**，组合才真正成立。
在"任务模型"这一维上，CF 是继 TPE、FJP 之后的第三种回答：
| 任务模型 | 依赖结构 | |
|---|---|---|
| ThreadPoolExecutor | 相互独立的任务流 | 无依赖 |
| ForkJoinPool | 同构递归拆分 | 父子树 |
| CompletableFuture | 异构任务的任意组合 | DAG（依赖图） |
"编排"编排的就是这张 DAG：节点是异步任务，边是数据依赖，完成事件沿边传播。
全文可收束为五条跨语言、跨框架成立的不变量：
理解线程池，最终是在理解：系统如何在压力下保持理性。