最直接后果是日志无痕迹、监控无告警、线程悄悄退出；应通过自定义uncaughtexceptionhandler、saferunnable包装、重写afterexecute及规范submit调用四步兜底。
线程池里任务抛出 RuntimeException 却没捕获，最直接的后果不是功能报错，而是——日志里没痕迹、监控里没告警、线程悄悄退出、后续任务照常执行，问题像蒸发了一样。排查时翻遍业务代码、查监控指标、看线程数波动，就是找不到“谁干的”。这不是玄学，是 Java 线程池默认异常处理机制的真实写照。
用自定义 UncaughtExceptionHandler 锁定异常源头
这是最快定位“哪个线程、哪次执行”出问题的方式。线程池工作线程一旦因未捕获异常终止，JVM 会调用其 UncaughtExceptionHandler。只要给每个线程设好处理器，就能在异常发生的第一时间打印线程名、堆栈和上下文。
- 通过
ThreadFactory创建线程时，调用thread.setUncaughtExceptionHandler(...) - 处理器里至少记录：
thread.getName()、e.toString()、Arrays.toString(e.getStackTrace()) - 别只用
System.out.println，务必接入统一日志框架（如 Logback/Log4j2），确保日志可检索、带 traceId
对 execute 提交的任务做统一包装
execute(Runnable) 是静默异常高发区：异常逃出 run() 就直接终结线程，不通知、不记录、不重试。不能靠每个任务都手动加 try-catch，而应从提交入口统一兜底。
- 封装一个
SafeRunnable，构造时传入原始任务，在run()内部包一层 try-catch - catch 块中必须记录完整异常，并建议 重新 throw（或包装为 RuntimeException）——避免吞异常导致逻辑中断却不感知
- 禁止在 catch 里只打日志然后 return；更禁止空 catch
重写 afterExecute 做兜底校验
ThreadPoolExecutor.afterExecute(Runnable, Throwable) 是线程池提供的钩子方法：每次任务执行完（无论成功或异常）都会回调。它是比 UncaughtExceptionHandler 更上层、更可控的拦截点。
- 继承
ThreadPoolExecutor，重写该方法 - 当第二个参数
Throwable t非 null，说明任务执行中抛了未捕获异常（包括 RuntimeException） - 此时可记录日志、上报监控、触发告警，甚至结合 MDC 补充当前任务的业务标识（如订单号、用户ID）
- 注意：它不替代 try-catch，而是最后一道防线，尤其对已上线但未规范包装的老任务有效
区分 submit 和 execute 的异常路径，别误以为“submit 更安全”
很多人以为用 submit 就高枕无忧，其实不然：submit 把异常塞进 Future，但你不调 get()，它就永远沉睡。大量异步通知、定时调度场景中，Future 对象被创建后就丢弃，异常彻底隐身。
- 对所有
submit返回的Future，必须显式调用get()（或get(timeout, unit)）并捕获ExecutionException - 若确实不需要结果，也请至少调用
future.isDone()+future.get(0, TimeUnit.NANOSECONDS)做一次非阻塞检查（需捕获TimeoutException和ExecutionException） - 更稳妥做法：封装
safeSubmit(Callable)，内部自动完成 get + 异常记录
