未捕获的运行时异常会导致工作线程静默死亡，表现为任务卡住、数据不更新等；应通过日志、jstack、线程计数确认问题，配置uncaughtexceptionhandler、改用callable+future或自定义threadfactory等方式主动捕获和处理异常。
多线程中未捕获的运行时异常会导致工作线程“静默死亡”——既不抛给主线程，也不中断程序流程，仅在控制台输出堆栈后悄然退出。这种故障极难察觉，常表现为任务卡住、数据不更新、定时任务失联等现象。关键在于：异常没被处理，但线程已终止，而调用方毫无感知。
确认是否真为未捕获异常导致线程退出
先验证问题性质，避免误判为死锁或阻塞：
- 检查日志中是否有类似
Exception in thread "xxx"的打印（尤其注意控制台或标准错误流，而非业务日志） - 在线程启动前设置名称：
thread.setName("订单补偿任务-01")，便于定位异常来源 - 用
jstack <pid></pid>抓取线程快照，对比异常前后线程数是否减少、对应命名线程是否消失 - 若使用线程池，观察
getCompletedTaskCount()或getActiveCount()是否异常停滞
为线程配置 UncaughtExceptionHandler
这是最直接有效的兜底手段，能捕获所有未被 try-catch 拦截的异常：
- 对单个线程：调用
thread.setUncaughtExceptionHandler((t, e) -> { /* 记录日志、告警、上报 */ }) - 对全部线程（推荐用于初始化阶段）：
Thread.setDefaultUncaughtExceptionHandler(...) - 处理器内务必记录完整堆栈：
e.printStackTrace()或用日志框架的error("线程 {} 异常", t.getName(), e) - 避免仅打印消息而忽略 cause 和嵌套异常，
e.getCause()可能才是根因
改用 Callable + Future 主动获取异常
适用于通过线程池提交的任务，让异常“浮出水面”而不是藏在线程内部：
- 将
Runnable改为Callable<void></void>，即使无返回值也利于异常传递 - 提交后必须调用
future.get()（可设超时），否则异常永远不会暴露 -
get()抛出的是ExecutionException，需用e.getCause()获取原始异常 - 批量提交时，建议用
invokeAll()并遍历每个Future调用get()，防止遗漏
在线程池层面统一拦截异常
避免为每个任务单独设置 handler，适合中大型项目：
- 自定义
ThreadFactory，在newThread()中自动设置UncaughtExceptionHandler - 重写
ThreadPoolExecutor.afterExecute()方法，在任务执行后检查Throwable参数 - Spring 环境下可用
@Async配合AsyncUncaughtExceptionHandler全局捕获异步异常 - 确保线程池拒绝策略、饱和处理逻辑不会掩盖异常（如
DiscardPolicy不报错）
