线程复用依赖 runWorker 的 while 循环，未捕获异常会导致循环终止、Worker 退出；execute 提交的任务异常会中断复用并重建线程，submit 则因 FutureTask 的 try-catch 而保持复用；getTask() 返回 null 是唯一合法退出路径；自定义 ThreadFactory 的 UncaughtExceptionHandler 可捕获 execute 异常堆栈。
runWorker 的 while 循环是复用的唯一载体
线程池里真正干活的不是裸 Thread，而是 Worker 实例；它的 run() 方法只做一件事：调用 runWorker(this)。这个方法内部是个死循环：while (task != null || (task = getTask()) != null)。只要 getTask() 不返回 null，循环就继续，任务就不断被取出执行——这就是复用的本质。
关键点在于：这个循环体本身不处理异常。一旦你在任务里抛出未捕获的 RuntimeException（比如 NullPointerException、ArithmeticException），它会直接穿透到 task.run() 调用栈顶层，导致整个 runWorker 方法提前退出，while 循环终止，Worker 生命周期结束。
常见错误现象：
- 日志里看不到异常堆栈，但线程数波动明显（尤其低频任务场景）
-
ThreadPoolExecutor指标显示getCompletedTaskCount()增长缓慢，而getPoolSize()频繁升降 - 用
jstack抓现场，发现部分Worker线程已消失，只剩核心线程卡在workQueue.take()
execute() 和 submit() 对异常的处理路径完全不同
你用 execute(Runnable) 提交任务时，任务就是裸的 Runnable，异常直接在 Worker 线程里炸开，触发 processWorkerExit(w, true)，线程池会立即补一个新 Worker（只要没 shutdown）。这不是“线程复用失败”，而是“复用被迫中断后重建”。
但用 submit(Runnable) 或 submit(Callable) 就不同：任务会被包装成 FutureTask。它的 run() 方法里有 try-catch，异常被捕获后仅存入 outcome 字段，不会抛出，Worker 循环照常继续——复用不受影响。
注意两个坑：
-
Future.get()才真正抛异常，但这时是在**调用方线程**（比如 main 线程）里抛，和线程池无关 -
ScheduledThreadPoolExecutor.schedule()提交的任务，异常既不抛出也不打印，连Future.get()都没机会调，周期性任务直接静默失效
getTask() 返回 null 是线程退出的唯一合法出口
Worker 线程退出只有两种正经路径：一是任务异常导致 runWorker 循环崩掉；二是 getTask() 主动返回 null。后者取决于线程是否“超时可回收”：
- 非核心线程（
workerCount > corePoolSize）默认启用超时，调用workQueue.poll(keepAliveTime, unit)，超时没取到任务就返回null - 核心线程默认永不超时，走
workQueue.take()，永久阻塞，除非你设了allowCoreThreadTimeOut = true
所以，如果你观察到线程池里线程数稳定在 corePoolSize，基本说明异常没发生；如果线程数反复突破又回落，大概率是 execute() 提交的任务在持续炸掉 Worker，线程池在疲于补人。
自定义 ThreadFactory 是唯一能捞到异常堆栈的地方
线程池默认的 ThreadFactory 不设 UncaughtExceptionHandler，任务异常后，堆栈直接丢进黑洞。想定位问题，必须自己造一个：
new ThreadFactoryBuilder()
.setUncaughtExceptionHandler((t, e) -> {
log.error("Worker thread {} crashed", t.getName(), e);
})
.setNameFormat("my-pool-%d")
.build()
但要注意：这个 handler 只对 execute() 有效；对 submit() 包装的 FutureTask 无效，因为异常根本没到线程层面。
最易被忽略的一点：InterruptedException 处理不当也会让线程“假性退出”。比如在任务里 sleep 被中断，你只 catch 了事却不重置中断状态（Thread.currentThread().interrupt()），后续 getTask() 可能因检测到中断而提前返回 null，看起来像空闲退出，其实是逻辑 bug。
