Java多线程异步任务中异常易静默丢失，须通过submit()+Future.get()显式暴露、设置UncaughtExceptionHandler兜底、重写afterExecute()全局捕获、封装SafeRunnable/SafeCallable安全包装四层机制统一归口处理。
Java 多线程异步任务中，未处理异常容易静默丢失——不是没发生，而是被吞掉了。关键在于：异常不会自动跨线程传播，必须主动拦截、显式暴露、统一归口。
用 submit() + Future.get() 显式暴露异常
这是最可控的方式，适用于有返回值或需强感知失败的场景：
- execute() 提交 Runnable：异常直接触发 UncaughtExceptionHandler，但若未设置，就彻底消失
- submit() 提交 Runnable/Callable：异常被封装进 ExecutionException，必须调用 future.get()（或 get(timeout, unit)）才会抛出
- 调用 get() 后，用
ex.getCause()获取原始异常（如 NullPointerException、业务自定义异常） - 若捕获到 InterruptedException，建议恢复中断状态：
Thread.currentThread().interrupt()
为线程池设置 UncaughtExceptionHandler
这是 execute() 类任务的兜底防线，防止线程因异常直接退出且无日志：
- 通过自定义 ThreadFactory，在创建每个工作线程时调用
t.setUncaughtExceptionHandler(...) - 处理器中应记录线程名（如
pool-1-thread-3）、异常类型、完整堆栈、时间戳 - 避免只写
System.err.println；统一走 SLF4J 等日志框架，并集成告警（如 AlertManager） - 该机制对 execute() 有效，但对 submit() 的 Callable 无效（其异常已被 Future 包装）
重写 ThreadPoolExecutor.afterExecute() 做全局钩子
线程池原生支持的扩展点，适合集中做异常归集和监控：
立即学习“Java免费学习笔记（深入）”；
- 无论用 execute() 还是 submit()，只要任务执行完毕，
afterExecute(Runnable r, Throwable t)都会被调用 - 参数
t就是未被捕获的异常（submit() 的 Runnable 任务异常会传入此参数；Callable 则为 null） - 适合打点统计“异常任务数”、记录结构化日志、触发熔断或降级逻辑
- 注意：不要在此方法里再抛新异常，否则可能触发线程级 UncaughtExceptionHandler
封装 SafeRunnable/SafeCallable 统一兜底
当无法修改上游调用逻辑（如第三方 SDK 回调、框架自动调度），可在提交前做安全包装：
- SafeRunnable：在 run() 内 try-catch 所有 Throwable，记录日志并上报监控，不向上抛
- SafeCallable：在 call() 中捕获异常，可选择返回默认值、抛出运行时异常，或封装成 Result 对象
- 所有日志必须带上下文：任务标识、线程名、执行耗时、入参摘要（脱敏后）
- 比逐个加 try-catch 更轻量，也比依赖钩子更前置
