其实，

你是否经常在阅读《ThreadPoolExecutor》源码后只记住了几个参数。却仍然对内部运行方式一头雾水？下面从源码层面逐步拆解任务流转、Worker 的设计、锁的选择还有异常处理，让你真正“啃透”线程池。

任务进来之后发生了什么

痛点：提交一个任务后到底是新建线程、放队列还是走拒绝策略？老实说，很多人只知道大概流程，却不清楚每一步的判定细节。

先把整体流程过一下。按理说，

一个 Task 提交进来线程池先看当前 Worker 数量有没有超过 corePoolSize。没超的话，直接创建一个新 Worker。把这个 Task 作为它的 firstTask 去执行。超了就把 Task 丢进阻塞队列排队；如果队列也满了再看能否创建新 Worker，仍不行则执行拒绝策略。

对应的 execute 实现如下：

public void execute {
if
throw new NullPointerException;int c = ctl.get;// Worker 数量 

以上只是粗略的运行方式，下面继续深入。

谁在执行任务的观点是。Worker

痛点：看到 ThreadPoolExecutor 的实现代码，却不知道实际负责取任务并执行的到底是哪一块？

Worker 是线程池里的主要角色。可以把它想象成流水线上的工人。负责不断从传送带上取任务、执行，接下来再取下一个。

private final class Worker
extends AbstractQueuedSynchronizer
implements Runnable {
final Thread thread;怎么说呢，// 实际执行任务的线程
Runnable firstTask;// 初始任务
volatile long completedTasks;// 完成任务数统计
Worker {
setState;// 初始化状态为 -1，抑制中断
this.firstTask = firstTask;this.thread = getThreadFactory.newThread;// 把 Worker 本身作为 Runnable 传入
}
public void run {
runWorker;}
// ...
}

Worker 类是 ThreadPoolExecutor 的内部类，实现了 Runnable 接口。在构造方法里把自己（This) 作为 Runnable 交给 ThreadFactory`newThread` 创建实际的线程。当线程启动后执行的是 Worker.run,而该方法又委托给外部类的 runWorker——这是理解后续逻辑的关键。

怎么创建 Worker

痛点： 看到 AddWorker 方法却不明白它到底做了哪些原子操作、什么时候会返回 false。

AddWorker 负责完成以下几件事：

• 检查线程池状态是否允许新增工作者；
• 原子递增 workerCount；若并发竞争失败则重试，
• 创建 Worker;
• 将新建的 worker 加入到 wor kers;
• 启动内部 thread 并返回成功标志。

private boolean addWorker {
retry的观点是，for {
int c = ctl.get;说起来，int rs = runStateOf;// 计算线程池运行状态
if (rs>= SHUTDOWN &&
))
return false;for {
int wc = workerCountOf;if (wc>= CAPACITY ||
wc>= )
return false;if )
break retry;不过，c = ctl.get;// Re-read ctl
if!= rs)
continue retry;// state changed,restart outer loop
// else CAS failed due to workerCount change;retry inner loop
}
}
boolean workerStarted = false;boolean workerAdded = false;Worker w = null;try {
w = new Worker;final Thread t = w.thread;if {
final ReentrantLock mainLock = this.mainLock;mainLock.lock;try {
int rs = runStateOf);if ) {
if )
throw new IllegalThreadStateException;workers.add，int s = workers.size;if
largestPoolSize = s;workerAdded = true;}
} finally {
mainLock.unlock;}
if {
t.start;// 启动内部线程
workerStarted = true;}
}
} finally {
if
addWorkerFailed;// 清理工作：移除、计数、尝试终止等
}
return workerStarted;}

a）为何多处与 S HUTDOWN  比较？** S HUTDOWN  是线程池的一种状态，其余状态包括 RUNNING、STOP、TIDYING、TERMINATED。只有当池处于 RUNNING 或者正处于 SHUTDOWN 且还有未处理的队列任务且新增的是没有初始任务的 worker 时才允许添加。

b）core  参数决定使用哪套上限：

• true → 上限为 corePo olSize
• false → 上限为 maximumPo olSize

线程启动后跑什么代码

痛点： "firstTask" 与循环取任务之间到底有什么关联？为什么要用 while 循环？"

The key is that a Worker itself is a task whose job is to repeatedly fetch and run user‑submitted tasks.

public void run { // 被 Thread.start 调用
runWorker;}
final void runWorker {
Thread wt = Thread.currentThread;Runnable task = w.firstTask;w.firstTask = null;不过，w.unlock，// allow interrupts
boolean completedAbruptly = true;try {
while )!= null) { // 主要循环
w.lock;// 防止 idle 中断
try {
beforeExecute;Throwable thrown = null;try { task.run;} // 真正执 行使用者代码
catch{ thrown=x;throw x，话说回来，}
catch{ thrown=x;throw x，}
catch{ thrown=x;throw new Error;}
finally { afterExecute;
}
} finally {
task = null;w.completedTasks++;w.unlock，}
}
completedAbruptly = false;按理说，} finally {
processWorkerExit;怎么说呢，}
}

• `firstTask`: 当第一次创建 Worker 时会携带提交进来的初始任务；其实，随后循环里通过 `getTask` 从阻塞队列获取下一条待办。
• `while` 循环: 实现“线程复用”，只要还能拿到任务就永不退出。
• `completedAbruptly`: 若在 `task.run` 中抛异常，则此标志保持 `true` 并触发 `processWorkerExit` 中的补偿逻辑；正常退出则设为 `false` 表示可以回收。

getTask 的细节——决定何时回收空闲线程

private Runnable getTask {
boolean timedOut = false;// 上一次 poll 是否超时
for {
int c = ctl.get;int rs = runStateOf;if (rs>= SHUTDOWN &&
)) {
decrementWorkerCount;return null，}
int wc = workerCountOf;boolean timed =
allowCoreThreadTimeOut || wc> corePoolSize;if ((wc> maximumPoolSize ||
) &&
)) {
if )
return null;continue，}
try {
Runnable r =
timed?workQueue.poll(keepAliveTime,TimeUnit.NANOSECONDS)
: workQueue.take;if
return r，说起来，timedOut = true;// poll 超时未拿到任务
} catch {
timedOut = false;}
}
}

• `poll` vs `take`: 
  • `take` 永久阻塞直到有元素；`poll` 在指定时间内没有元素则返回 null 并标记超时。
• `timed` 判定依据: `allowCoreThreadTimeOut` 为 true 或当前 worker 数已超过 `corePoolSize` 时即使是 core 线程也会采用带超时的 poll。怎么说呢，
• `timedOut` 为 true 且 轮询仍未拿到。则通过原子递减 `workerCount` 并让该 thread 退出，这样就能实现“空闲回收”。不过，

为什么要继承 AQS?

Pain point: "为什么不直接用 ReentrantLock，而要自己写一把锁？"

• AQS 为,用来保护正在运行使用者 Task 的 thread 不被意外中断。
• `lock` 在 `runW ork er` 中围绕使用者 Task 加锁；不过，若某个工作者正在执 行 Task，则 lock 持有。随后 `interruptIdleWorkers` 会尝试 `tryLock`——只有空闲的工作者才能被中断，从而避免“误伤”。
• AQS 而不是 ReentrantLock，因为我们不希望同一工作者在执行 Task 时 调用诸如 `setCorePoolSize` 等可能触发重新获取锁的方法导致死锁或错误中断。
• `setState` 在构造函数里把 lock 状态置为负数，以**抑制中断**直到真正进入 `runW ork er` 并调用 `unlock` 才释放。话说回来，

java // 简化说明：lock -> state 从 -1 改为 0。unlock -> state 恢复 -1。

至于另一把锁。mainLock

Pain point: "为什么 ThreadPoo lExecutor 不直接使用并发 Set 来管理 workers，而额外再加一把全局锁?"​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​‌‌‌‌‌‌‌‌‌‌‍‍‍‍‍‍‍‏‏‏‏‏‏‏‏‏‎‎‎‎‎‎‎️️️️️️️️️‌‪‪‪‪‪‪🧩🧩🧩🧩🧩🧩"

⟨⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⟩ • Main lock 用途：
⟨⠀⠀⠀⠀⠀⠀⟩ - 保证对 workers 、largestPo olSiz e 、completedTas kCoun t etc. &n bsp;的修改具备原子性，话说回来，⟨⠀⠀⠀⠀⠀⠀⟩ - 序列化 interruptIdleWorkers&nb sp;防止 shutdown 时出现“中断风暴”；⟨⠀⠀⠀          ⌘︎ ⟩ - shutdown / shutdownNow 必须先持有该锁，以确保 workers 集合在检查‑‑‑‑‑‑‑‐‐‐‐‐‐‐‐­–——-—–—–—–-- ——————---——---—————–— ———– —– — – ——－­­－‒‒-‒-⁻⁻⁻⁻⁻⁻- \ \ \

 The Javadoc explicitly says:
text
While we could use a concurrent set of some sort。it turns out to be generally preferable to use a lock.
The “lock” prevents multiple threads from simultaneously interrupting idle workers during shutdown and simplifies bookkeeping such as updating `largestPo olSiz e`.

java final ReentrantLock mainLock=this.mainLock;mainLock.lock;try{ ，}finally{ mainLock.unlock;老实说，} 注意 **lock 放在 try 前面**：如果 lock 本身抛异常且进入 finally。会导致 IllegalMonitorStateException，因为当前线程并非持有锁。

任务执行时抛异常，会怎样？

Pain point : "如果我的业务代码抛出 RuntimeException，是整个工作者都挂掉吗？我该如何捕获/日志这些异常？"

⟨  ⟩ • 按理说，#1 异常在线程内部捕获并上报至 afterExecute 

java try{ task.run;按理说，// 使用者业务代码 }catch{ thrown=x;throw x，}catch{ thrown=x;throw x，}catch{ thrown=x;throw new Error;}finally{ afterExecute;// Hook，可自定义日志/统计等 }

• completedAbruptly 为 true → 表示该 worker 因异常提前退出；随后 processWor kerExit 会 decrement worker count 并 补充新 worker。

• completedAbruptly 为 false → 正常从 queue 中取不到新任务而结束循环，此时不会补充。

---

UncaughtExceptionHandler 与 submit 场景

• 对于 execute 提交方式。如果业务代码未捕获异常，它会沿着上述方法最终由 Thread.dispatchUncaughtException 分发给当前 thread 的 UncaughtExceptionHandler。说起来，

• 对于 submit 提交方式。业务代码被包装成 FutureTask。即使 call 方法抛出异常，也会被捕获并保存至 FutureResult。随后调用者通过 future.get 获取时会重新抛出 ExecutionException。怎么说呢，

java Future