必须在任务内部用try-catch捕获异常，因为线程池不自动处理任务内未捕获异常，否则线程终止、异常丢失、易致资源泄漏或雪崩。
任务里加 try-catch 是最直接、最有效的防止单个任务异常导致线程挂掉的方式。线程池本身不会替你捕获任务内的未处理异常，一旦抛出，线程就会终止，虽然线程池会补新线程，但异常信息容易丢失，排查困难，还可能引发资源泄漏或雪崩。
为什么必须在任务内部 catch 异常
线程池的工作线程执行的是你提交的 Runnable 或 Callable 的 run() / call() 方法。如果这个方法体里抛出未捕获异常（比如 NullPointerException、RuntimeException），它会直接冲出方法边界，击穿线程执行栈——结果就是该线程死亡。线程池检测到后会新建一个线程顶上，但原始异常若没记录，就彻底“静默消失”了。
- execute(Runnable) 提交的任务：异常不被捕获 → 线程销毁 → afterExecute() 中的 Throwable 参数才非 null
- submit(Callable) 提交的任务：异常被封装进 Future，不调 get() 就永远不会暴露
- UncaughtExceptionHandler 只对 execute 场景兜底，对 submit 无效
推荐写法：统一封装 safeRun / safeCall
避免每个任务都重复写 try-catch，可封装轻量工具方法，兼顾日志和线程存活：
- safeRun(Runnable r)：内部用 try-catch 包裹 r.run()，记录 ERROR 日志，不吞异常也不阻塞
- safeCall(Callable
c)：同理，catch 后返回默认值或包装成特定业务异常 - 注意别在 catch 块里做锁操作、远程调用或 sleep，否则会拖慢整个线程池
搭配 afterExecute 做全局监控
即使任务内已 catch，仍建议继承 ThreadPoolExecutor 并重写 afterExecute(Runnable, Throwable)：
- 当 Throwable 不为 null，说明有任务漏掉了内部捕获（比如某人忘了套 try）
- 这里适合统一打告警日志、上报 Prometheus 错误指标、触发熔断等运维动作
- 注意：submit 的异常不会传进来，它只对 execute + 未捕获异常生效
别忽略 UncaughtExceptionHandler 的兜底价值
为线程工厂设置 UncaughtExceptionHandler，是最后一道防线：
- 适用于 execute 提交且完全没做 try-catch 的“裸任务”
- Handler 里应至少记录完整堆栈到 ELK 或 Loki，避免只 System.out.println
- 不建议在 handler 中重启线程或执行复杂逻辑，保持轻量、快速返回
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
