Java异步线程池未处理异常默认被静默吞掉，需通过任务内try-catch、重写afterExecute、submit+Future.get()显式获取、或ThreadFactory设置UncaughtExceptionHandler四层机制捕获。
Java 中异步线程池的未处理异常默认不会打印、不传播、不中断主线程，而是被静默吞掉——任务看似执行完，实际中途失败，日志里却找不到痕迹。要真正捕获，得在异常发生的“现场”或“出口”主动拦截，不能依赖默认行为。
在任务内部用 try-catch 主动兜底
这是最直接、最可靠的方式，尤其适用于 execute() 提交的 Runnable 任务：
- 异常发生在
run()方法体内时，若没 catch，会直接终止当前工作线程 - 必须把业务逻辑包在 try 块里，catch 后至少记录完整堆栈（推荐 SLF4J + 线程名 + 任务上下文）
- 避免空 catch 或只写
e.printStackTrace()，它可能输出到错误流而被忽略 - 对
Callable同理，在call()中捕获，并可选择抛出运行时异常或返回默认值
重写 afterExecute 做集中监控
ThreadPoolExecutor 提供了 afterExecute(Runnable, Throwable) 钩子，是唯一能稳定拿到原始异常的地方：
- 只要任务执行结束（无论成功或异常），该方法必被调用；
Throwable t参数非 null 即表示发生了未捕获异常 - 适合统一记录日志、打点统计异常次数、触发告警，但不要在里面做耗时操作（如远程调用）
- 注意：对
submit(Callable)返回的Future，异常已被封装，此处t为 null - 需继承线程池并重写，或使用装饰器模式包装已有实例
用 submit + Future.get() 显式暴露异常
当任务需要结果反馈时，优先选 submit() 而非 execute()：
立即学习“Java免费学习笔记（深入）”；
-
Future.get()是异常的“释放开关”：不调就永远不抛，一调就以ExecutionException包装抛出 - 务必捕获
ExecutionException，再用getCause()取出原始异常（如NullPointerException） - 别忽略
InterruptedException，捕获后建议恢复中断状态：Thread.currentThread().interrupt() - 适用于需等待结果、支持重试或降级的场景（如发通知失败后改发短信）
通过 ThreadFactory 设置 UncaughtExceptionHandler
作为最后一道防线，用于捕获那些彻底漏掉的异常（比如在 afterExecute 里又抛了新异常）：
- 创建线程池时传入自定义
ThreadFactory，为每个工作线程设置专属处理器 - 处理器中应记录线程名（如
pool-2-thread-5）、时间戳、完整堆栈，输出到集中日志系统 - 它对
execute()场景有效，但对submit(Callable)无效——因为异常没“逃到”线程顶层 - 保持处理器轻量，禁止同步阻塞、锁操作或网络请求
