java线程池任务异常默认被静默吞掉，需在四层捕获：①submit+future.get()主动拉取并处理executionexception；②自定义threadfactory设置uncaughtexceptionhandler兜底；③任务内try-catch打印堆栈；④重写afterexecute()钩子统一监控告警。
Java线程池中任务抛出异常时，默认不会输出堆栈，而是被静默吞掉——这是线上问题难以定位的常见根源。关键不在“能不能捕获”，而在于“在哪一层捕获才有效、可追溯”。下面从实际可落地的四个角度讲清楚怎么做。
✅ 用 submit + Future.get() 主动拉取异常
这是最推荐、也最可控的方式，适用于需要明确知道任务成败的场景（比如定时任务、异步回调）。
- 必须用 submit() 提交 Callable 或 Runnable（后者返回 null），不能用 execute()
- future.get() 是触发点：不调用就不会暴露异常，且会阻塞直到任务完成或超时
- 捕获的是 ExecutionException，原始异常在 e.getCause() 中，务必取出并打印完整堆栈
- 别忘了处理 InterruptedException，并恢复中断状态：Thread.currentThread().interrupt()
✅ 自定义 ThreadFactory 设置 UncaughtExceptionHandler
这是兜底手段，适合统一拦截所有未被捕获的 RuntimeException，尤其当业务代码无法修改时。
- 创建线程池时传入自定义 ThreadFactory，给每个新线程设置 setUncaughtExceptionHandler
- 处理器里能拿到 Thread 对象，可直接获取线程名（如 custom-thread-3），方便关联业务上下文
- 务必用日志框架（如 SLF4J）记录 e.printStackTrace() 或 logger.error("msg", e)，只打 getMessage 会丢关键信息
- 注意：对 execute 提交的 Runnable 有效；但 submit 的 Callable 异常仍走 Future 流程，不经过这里
✅ 在任务内部加 try-catch 打印堆栈
最直接、零依赖，适合临时排查或逻辑简单的任务。
- 把整个 run() 或 call() 体包在 try-catch 里，catch 块中调用 e.printStackTrace() 或写入日志
- 可结合 Thread.currentThread().getName() 输出线程标识，避免日志混杂
- 缺点是侵入业务代码，不适合大规模统一治理，但胜在简单可靠
✅ 重写 ThreadPoolExecutor.afterExecute() 钩子方法
这是企业级方案，适合需要统一做监控、告警、指标上报的系统。
- 继承 ThreadPoolExecutor，覆盖 afterExecute(Runnable r, Throwable t)
- 参数 t 就是任务执行中抛出的异常（Runnable 场景下有效；Callable 需配合 future.get() 才进得来）
- 钩子里可做：记录线程名、任务类型、异常分类、上报 Prometheus、触发钉钉告警等
- 比 ThreadFactory 更底层，能拿到任务实例 r，便于结合 MDC 或 traceId 做链路追踪
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
