线程池中异常默认不抛出，需主动捕获；execute丢弃异常或走UncaughtExceptionHandler，submit需调用get()才暴露异常，重写afterExecute是最可靠的全局捕获方式。
线程池中异常不会自动抛出，必须主动捕获
Java线程池（如 ThreadPoolExecutor）默认会吞掉任务执行时抛出的未检查异常（RuntimeException及其子类），不会传播到提交线程，也不会中断线程池运行。这意味着：你调用 submit(Runnable) 或 execute(Runnable) 后，即使任务内部空指针、数组越界，主线程也完全感知不到。
区分 submit 和 execute 的异常处理机制
execute(Runnable)：异常发生在 worker 线程中，会触发 Thread.UncaughtExceptionHandler（若已设置），否则静默丢弃。
submit(Callable) 或 submit(Runnable)：返回 Future，异常被封装进 Future，**必须显式调用 get() 才会抛出**（包装为 ExecutionException）。
- 用 execute → 需提前设置线程工厂，为每个线程指定 UncaughtExceptionHandler
- 用 submit + Future.get() → 在调用 get() 处 try-catch ExecutionException，并通过 getCause() 获取原始异常
统一拦截：重写 beforeExecute / afterExecute
ThreadPoolExecutor 提供了钩子方法：
- beforeExecute(Thread t, Runnable r)：任务执行前回调
- afterExecute(Runnable r, Throwable t)：任务执行后回调，t 不为 null 即表示发生了未捕获异常
这是最可靠、侵入性小的全局异常捕获方式。例如：
new ThreadPoolExecutor(...){
protected void afterExecute(Runnable r, Throwable t) {
if (t != null) {
// 记录日志、告警、上报监控
log.error("Task execution failed", t);
}
}
};避免异常丢失的实用建议
- 优先使用 Callable + submit 而非 Runnable + execute，便于后续同步获取结果和异常
- 若必须用 execute，务必通过 ThreadFactory 设置自定义 UncaughtExceptionHandler
- 在线程池配置阶段就覆写 afterExecute，不要依赖任务内部 try-catch —— 那样容易遗漏
- 对关键任务，可在 Runnable/Callable 内部做兜底日志记录，但不能替代线程池层的统一处理
不复杂但容易忽略
