线程池不会自动重建异常终止的核心线程，而是通过worker任务执行隔离与corepoolsize保底扩容策略协同实现隐式补位：当核心线程因未捕获异常退出导致poolsize
线程池不会“自动重建”因异常暴毙的核心线程——它根本不会重建，而是由线程池内部的 Worker 循环机制自然兜底、隐式补位。这不是一个“恢复”或“重启”动作，而是一次任务执行生命周期的正常终结与线程复用逻辑的延续。
核心线程暴毙后，谁在“善后”？
当核心线程执行任务时抛出未捕获的 RuntimeException（比如 NullPointerException、IllegalArgumentException），该线程会直接终止退出 JVM 线程栈。但 ThreadPoolExecutor 并不监听或干预这个过程；真正起作用的是其内部 Worker 类的 runWorker 方法中的无限循环 + 异常捕获外层结构。
关键点在于：Worker 本身不是“守护线程”，它的 run() 方法是一个 while 循环体，只要 getTask() 返回非 null，就持续取任务、执行、再取任务。一旦任务 run() 抛异常，Worker 的 try-catch 仅捕获并记录日志（默认 UncaughtExceptionHandler），然后循环继续——但此时当前线程已结束，无法再进入下一轮循环。
所以真正“补位”的不是重建线程，而是：线程池在发现活跃线程数低于 corePoolSize 时，主动 addWorker(null, true) 创建新 Worker（即新线程）来维持核心数量。这个触发时机发生在：
- 已有 Worker 线程因异常死亡，导致 poolSize
- 且线程池状态为 RUNNING；
- 且线程工厂能成功创建新线程。
为什么你感觉“自动重建”了？
因为整个过程对使用者完全透明：
- 你提交的任务不会因某个核心线程挂掉而丢失（只要队列没满、线程池没 shutdown）；
- 线程池仍保持至少 corePoolSize 个活跃线程对外服务；
- 新线程由线程工厂创建，继承相同 name prefix、优先级等配置；
- 从监控指标看（如 getPoolSize()、getActiveCount()），数值很快回弹，像“自愈”一样。
这背后没有魔法，只有两个硬逻辑在协同：Worker 的单次任务执行隔离性 + 线程池对 corePoolSize 的保底扩容策略。
注意：这不是无条件兜底
以下情况会导致“补位失败”，进而出现线程数持续低于 corePoolSize：
- 线程工厂返回 null 或抛异常（如资源耗尽、自定义 factory 逻辑错误）；
- 线程池已被 shutdown/shutdownNow；
- corePoolSize 被动态调小（setCorePoolSize）；
- JVM 级资源枯竭（如 unable to create native thread）；
- 拒绝策略生效前，任务已在队列中堆积，但无空闲线程消费——此时不是线程缺失，而是任务积压。
如何验证这个行为？
写一个故意抛 RuntimeException 的 Runnable，用 newFixedThreadPool(2) 提交多个任务，观察：
- 通过 jstack 查看实际线程名变化（旧线程消失，新线程以相同 pattern 命名出现）；
- 调用 executor.getPoolSize() 和 executor.getActiveCount()，可见短暂下降后恢复；
- 重写 ThreadFactory，在创建线程时打日志，可确认异常后确实有新线程被 new 出来。
这个机制是 ThreadPoolExecutor 的默认健壮性设计，无需额外配置，但前提是别禁用核心线程保活（比如误设 allowCoreThreadTimeOut(true)）。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
