线程池设计的初衷是避免频繁创建和销毁线程带来的开销，通过复用固定数量的Worker线程来持续消费任务队列。但很多使用线程池的程序员都遇到过这样的现象：某个任务抛出了未捕获的异常，之后执行该任务的线程就消失了，线程池会换一个新的线程继续工作。为什么一个任务异常就能杀死复用中的线程？这恰恰暴露了Worker线程复用逻辑的边界条件。
一、Worker线程的循环取任务机制
在Java的ThreadPoolExecutor中，线程复用并不是通过某种魔法让线程不退出，而是让线程的run方法内部维持一个循环，不断地从阻塞队列中拉取任务并执行。这个循环定义在内部类Worker的runWorker方法里。Worker本身实现了Runnable接口，构造时可以接收一个首任务，但真正的核心逻辑是启动后进入一个while循环。
这个循环的条件是：只要当前任务不为空，或者通过getTask()能从队列中取出新任务，就继续执行。正常情况下，任务执行完毕后task会被置空，下一轮循环再次调用getTask()从队列阻塞获取，取不到就阻塞等待。这样一来，线程不会在单个任务结束后退出，而是长期存活，反复消费队列中的任务，这就是线程复用的本质。
final void runWorker(Worker w) {
Thread wt = Thread.currentThread();
Runnable task = w.firstTask;
w.firstTask = null;
boolean completedAbruptly = true;
try {
while (task != null || (task = getTask()) != null) {
w.lock();
try {
// 线程池状态检查，必要时中断线程
beforeExecute(wt, task);
Throwable thrown = null;
try {
task.run();
} catch (RuntimeException x) {
thrown = x; throw x;
} catch (Error x) {
thrown = x; throw x;
} catch (Throwable x) {
thrown = x; throw new Error(x);
} finally {
afterExecute(task, thrown);
}
} finally {
task = null;
w.completedTasks++;
w.unlock();
}
}
completedAbruptly = false;
} finally {
processWorkerExit(w, completedAbruptly);
}
}
从代码结构可以看到，runWorker方法使用了try-finally块，但任务执行部分task.run()并没有被一个能够吞噬异常的外部try-catch包裹。实际上，内部虽然有catch (RuntimeException x) { thrown = x; throw x; }，但这只是记录异常后原样抛出，并没有阻止异常向外传播。这个设计非常关键，它决定了异常会跳出while循环，进而触发外层的finally块。
二、任务异常如何穿透循环并杀死线程
当一个Runnable任务的run()方法抛出未捕获的RuntimeException时，执行流程会立即跳出内层的try块，进入catch块，随后执行throw x重新抛出。这个异常会继续向外传播，越过while循环体，到达runWorker方法的最外层try块。由于runWorker没有捕获这个异常，异常会继续向上抛出，最终导致Worker.run()方法返回，线程的run方法执行完毕，线程自然终止。
这里需要区分两个不同的异常出口：getTask()方法内部会捕获中断异常并返回null，从而让while循环正常退出，此时completedAbruptly被置为false，这属于线程池关闭或者线程需要回收的正常退出。而任务执行异常走的是另一条路径，异常直接穿透循环，completedAbruptly仍然保持true，代表线程是突然终止的。这个标志会传递给processWorkerExit，线程池据此判断该Worker是否发生了异常退出。
举一个最简单的例子：向线程池提交一个execute(() -> { throw new RuntimeException("boom"); })任务。任务执行后，控制台会打印出未捕获异常的堆栈，同时执行该任务的线程会立即结束。如果此时线程池中还有其他空闲线程，队列中的后续任务会由其他线程继续处理；如果没有空闲线程，线程池会根据核心线程数判断是否需要新建线程来补充。总之，一个未捕获的异常并不会让整个线程池停止，只会让当前这个Worker线程“牺牲”掉。
三、线程池如何补位：processWorkerExit与addWorker
当runWorker的finally块执行时，无论线程是正常退出还是异常退出，都会调用processWorkerExit(w, completedAbruptly)。这个方法的作用是清理当前Worker，包括将其从workers集合中移除，并根据completedAbruptly的值决定是否需要补充线程。如果completedAbruptly为true，说明线程是因为异常导致的突然退出，线程池会尝试调用addWorker来创建新的Worker线程。
addWorker方法内部会再次检查线程池的状态，包括当前线程数是否超过核心线程数或最大线程数、线程池是否已经关闭等。如果条件允许，就创建一个新的Worker对象并启动其线程。这个新线程会从队列中继续取任务。补充线程的过程并不是立即同步完成的，而是在异常退出后的processWorkerExit中触发，因此线程池在经历一个任务异常后，可能出现短暂的线程数减少，随后恢复到预期规模。
值得强调的是，如果任务异常频繁发生，线程池会不断经历“线程退出-新建线程”的过程，虽然整体功能不受影响，但频繁创建线程会带来额外的系统开销，也容易导致workers集合的频繁变更。此外，如果异常发生在核心线程执行的任务中，核心线程也会被替换，新的核心线程不会继承旧线程的ThreadLocal数据，这可能引发隐式状态丢失的问题。
四、避免线程重复创建销毁的实践建议
要避免任务异常导致线程被替换，最直接的做法是在任务内部自己捕获异常。例如，将Runnable包装成一个带有异常处理的实现，确保run()方法不会向外抛出未捕获异常。这样runWorker中的task.run()就能正常返回，while循环继续执行，线程得以保持复用。
public class SafeRunnable implements Runnable {
private final Runnable delegate;
public SafeRunnable(Runnable delegate) {
this.delegate = delegate;
}
@Override
public void run() {
try {
delegate.run();
} catch (Throwable t) {
// 记录日志，吞掉异常，保证线程不退出
System.err.println("任务执行失败: " + t.getMessage());
}
}
}
另一种常见思路是使用submit方法提交任务并获取Future对象。与execute不同，submit会将任务包装成FutureTask，任务抛出的异常会被捕获并封装到Future内部，而不是直接抛出到runWorker。只有在调用future.get()时，异常才会以ExecutionException的形式重新抛出。因此使用submit提交的任务即使内部抛异常，执行线程也不会退出，线程复用不受影响。
如果业务中确实需要感知任务异常，又不想让线程频繁更换，可以结合ThreadFactory为线程池中的线程设置统一的未捕获异常处理器，或者利用afterExecute钩子来记录异常信息。但无论采用哪种方式，理解Worker线程的运行机制和异常传播路径都是写出健壮线程池代码的前提。