如何从线程池Worker复用机制分析任务异常引发线程退出的原因？

本文共计966个文字，预计阅读时间需要4分钟。

线程池中的真正活跃的不是Thread，而是Worker实例；它的run方法只做一件事：

关键点在于：这个循环体本身不处理异常。一旦你在任务里抛出未捕获的 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。