java多线程未捕获异常会导致线程静默终止，引发任务丢失、资源泄漏和监控失察；应通过外层try-catch（捕获throwable）、设置uncaughtexceptionhandler及利用threadpoolexecutor.afterexecute和callable+future主动暴露异常来保障可观测性与响应。
Java 多线程中未捕获异常不会抛给主线程，也不会中断程序运行，只会让对应线程静默终止——表面正常，实则任务丢失、资源泄漏、监控失察。避免静默崩溃的关键不是“阻止线程退出”，而是确保异常**被看见、被记录、被响应**。
在任务入口加 try-catch 包裹全部逻辑
这是最直接、最可控的防线。无论 Runnable、Callable 还是 Thread 子类，都要把业务代码包在最外层 try-catch 中：
- 用 catch (Throwable e) 而非仅 catch Exception，防止 OutOfMemoryError、StackOverflowError 等致命错误被漏掉
- 捕获后必须做三件事：打完整堆栈日志（如 logger.error("任务失败", e)）、释放本线程独占资源（如关闭 Socket、清理临时文件）、按需决定是否重试或安全退出
- 不要只写
catch (Exception e) { e.printStackTrace(); }—— 控制台输出易被忽略，且不带线程上下文和业务标识
为每个线程设置专属 UncaughtExceptionHandler
它不替代 try-catch，而是兜底：当异常真的逃逸出 run()/call()，仍能留下痕迹并触发响应：
- 在线程创建后、start() 前调用
t.setUncaughtExceptionHandler((th, ex) -> { ... }) - 处理器里至少记录：线程名（建议提前 setName）、异常类型与消息、e.printStackTrace() 或 logger.error(..., ex)
- 若该线程持有关键资源（如数据库连接、文件句柄），在处理器中显式释放，避免泄漏
- 线程池场景下，必须通过自定义 ThreadFactory 设置，否则工作线程不会继承主线程或全局 handler
在线程池中统一拦截异常
ThreadPoolExecutor 提供了 afterExecute 钩子，是集中处理任务异常的理想位置：
- 继承 ThreadPoolExecutor，重写
afterExecute(Runnable r, Throwable t) - 参数 t 不为 null，说明任务执行中发生了未捕获异常（Runnable）或 Future.get() 抛出了 ExecutionException（Callable）
- 在此处统一做日志、指标打点（如 task_failure_total++）、触发熔断或告警，但绝不能 throw 新异常，否则可能阻塞线程池调度
- 注意：t 为 null 并不代表没异常——比如任务内 catch 住异常却没记录，此时异常已丢失，只能靠任务内日志保障可观测性
用 Callable + Future 主动“唤醒”异常
Runnable 的异常默认沉底，而 Callable 可让异常浮出水面：
- 将任务改为
Callable<void></void>，即使无返回值也利于异常传递 - 提交后必须调用
future.get(timeout, unit)，否则异常永远不会暴露 -
get()抛出 ExecutionException，要用e.getCause()获取原始异常 - 批量提交时用
invokeAll()，再遍历每个 Future 调用 get()，避免遗漏
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
