线程池中工作线程异常退出主因是任务抛出未捕获异常（如RuntimeException）、严重Error（如OutOfMemoryError）或未正确处理InterruptedException，导致run()方法终止；默认ThreadFactory不设UncaughtExceptionHandler，异常静默丢失，需自定义以捕获并记录堆栈。
线程池中的线程异常退出，通常不是因为线程池主动销毁它，而是线程在执行任务时抛出了未捕获的异常，导致其运行体（Runnable 或 Callable 的 run() / call() 方法）提前终止。JVM 不会自动为线程兜底处理未捕获异常，一旦发生，该工作线程就会“静默死亡”，从线程池中消失——这直接影响线程复用和任务吞吐。
未捕获的运行时异常直接终结线程
线程池中每个工作线程都通过一个死循环不断从任务队列取任务执行。如果任务代码中抛出 RuntimeException（如 NullPointerException、ArrayIndexOutOfBoundsException）且未被 try-catch 捕获，该异常会一路向上穿透到线程的 run() 方法顶层，触发线程终止。
- 线程池默认不打印堆栈（除非自定义
ThreadFactory设置了异常处理器） - 线程退出后，线程池可能按需创建新线程补充（取决于配置），但频繁异常会导致线程反复创建销毁，增加开销
- 典型例子：
executor.submit(() -> { int i = 1 / 0; });—— 除零异常未捕获，对应工作线程立即退出
任务中显式调用 System.exit() 或 JVM 异常崩溃
虽然少见，但若提交的任务中包含 System.exit()、触发 OutOfMemoryError（且未被全局捕获）、或发生 JNI 崩溃等严重错误，整个 JVM 可能退出或当前线程强制终止，自然导致线程池线程消失。
-
System.exit()会终止整个 JVM，所有线程（包括线程池）一并结束 -
OutOfMemoryError等Error类异常默认不会被catch (Exception e)捕获，容易造成线程中断 - 这类问题往往伴随日志中出现 “
java.lang.OutOfMemoryError” 或 “Killed by signal” 等线索
线程被外部中断且任务未正确响应
当线程正在执行阻塞操作（如 Thread.sleep()、queue.take()、Lock.lockInterruptibly()）时，若被调用 thread.interrupt()（例如线程池 shutdownNow()），会抛出 InterruptedException。如果任务代码忽略该异常、未恢复中断状态（Thread.currentThread().interrupt()），或在 catch 块中直接 return，也会导致该次任务提前结束，线程回归空闲状态——看似“正常”，但若逻辑有误，可能被误判为异常退出。
立即学习“Java免费学习笔记（深入）”；
-
InterruptedException是可检查异常，必须处理，但常见错误是只catch了事，没重设中断标志 - 线程池本身不会因单次中断就销毁线程；但如果任务反复在中断后异常返回，可能掩盖真实问题
自定义 ThreadFactory 中线程未设置 UncaughtExceptionHandler
线程池默认使用 Executors.defaultThreadFactory()，它创建的线程未设置未捕获异常处理器。这意味着即使任务抛异常，也不会自动记录日志，开发者难以第一时间发现线程退出原因。
- 建议在构建线程池时，通过自定义
ThreadFactory为每个线程设置setUncaughtExceptionHandler - 例如：捕获异常后打印完整堆栈 + 当前线程名 + 任务信息，便于定位哪类任务、哪个环节出问题
- 注意：该处理器只对未捕获的
Exception和Error生效，对已 catch 的异常无效
本质上，线程池线程退出不是“故障”，而是 Java 线程模型的正常行为——线程执行体结束即终止。关键在于任务代码是否健壮、是否兜住异常、是否配合线程生命周期管理。排查时优先看日志（尤其是未捕获异常处理器输出）、监控线程数波动、结合任务类型做针对性防御。
