在第 6 篇中我们已经看到一个非常反直觉的现象：
pool.submit(() -> { throw new RuntimeException("submit error"); });代码里明明 throw 了异常，但日志里却什么都没有。
这不是 JVM 的 Bug，也不是线程池“不可靠”，
而是你没搞清楚线程池里异常的完整传递链路。
本篇就专门把这件事讲清楚，并给出生产级解决方案。
一、先给结论（非常重要）
线程池里的异常，只有在“逃出线程执行边界”时，才会被 JVM 当作未捕获异常处理。
submit() 提交的任务，异常会被 Future 捕获，不会自动打印。
所以你看到的现象是设计行为，不是异常丢失。
二、execute vs submit：异常路径完全不同
1️⃣ execute：异常会“逃出线程”
executor.execute(() -> { throw new RuntimeException("execute boom"); });执行路径是：
Runnable.run() ↓ 抛异常 ↓ 异常逃出 worker 线程 ↓ UncaughtExceptionHandler ↓ 打印异常栈所以execute 的异常通常你能看到。
2️⃣ submit：异常被 FutureTask 吃掉
Future<?> f = executor.submit(() -> { throw new RuntimeException("submit boom"); });submit 内部流程（简化）：
FutureTask.run() { try { callable.call(); } catch (Throwable e) { setException(e); // 存起来 } }关键点在这里：
❗异常没有逃出线程
❗UncaughtExceptionHandler 不会被触发
❗只有 f.get() 才会把异常抛出来
如果你不get()，异常就像“从没发生过”。
三、最小 Demo：你可以亲手验证
ExecutorService pool = Executors.newFixedThreadPool(1); // execute：一定能看到异常栈 pool.execute(() -> { throw new RuntimeException("execute error"); }); // submit：默认看不到异常栈 Future<?> f = pool.submit(() -> { throw new RuntimeException("submit error"); }); Thread.sleep(500); // 注释掉这行，submit 的异常通常不会打印 // f.get(); pool.shutdown();运行后你会发现：
execute error几乎一定会打印submit error不 get 就“消失”
四、这在生产中为什么是“大坑”？
因为现实代码是这样的：
pool.submit(() -> { // 更新缓存 // 调用下游 // 写数据库 });然后某一天：
某个逻辑 NPE 了
你线上没看到任何异常
业务却悄悄不执行了
这不是小问题，而是典型的“静默失败”
五、生产级解决方案一：任务包装（最推荐）
✅ 思路
不要相信调用方一定会 get Future，异常必须在任务内部兜住。
✅ SafeRunnable（推荐）
public class SafeRunnable implements Runnable { private final Runnable delegate; private final String taskName; public SafeRunnable(Runnable delegate, String taskName) { this.delegate = delegate; this.taskName = taskName; } @Override public void run() { try { delegate.run(); } catch (Throwable e) { System.err.println("[TASK-EXCEPTION] " + taskName + ", thread=" + Thread.currentThread().getName()); e.printStackTrace(); } } }使用：
pool.execute(new SafeRunnable(() -> { throw new RuntimeException("boom"); }, "cache-refresh"));✔ 不管 execute / submit
✔ 不依赖 Future.get
✔ 异常一定有日志
这是最稳妥、最简单、最通用的方案。
六、生产级解决方案二：重写 afterExecute（框架级）
如果你想从线程池层面统一兜底，可以继承ThreadPoolExecutor。
1️⃣ 原理
ThreadPoolExecutor.afterExecute()在每个任务执行后都会被调用：
protected void afterExecute(Runnable r, Throwable t)t：execute 抛出的异常- 对于 submit：异常藏在
Future里，需要手动 get
2️⃣ 标准模板（非常经典）
public class MonitorThreadPoolExecutor extends ThreadPoolExecutor { public MonitorThreadPoolExecutor(...) { super(...); } @Override protected void afterExecute(Runnable r, Throwable t) { super.afterExecute(r, t); Throwable ex = t; // submit 的异常，需要从 Future 里捞 if (ex == null && r instanceof Future<?>) { try { Future<?> f = (Future<?>) r; if (f.isDone()) { f.get(); // 触发异常 } } catch (CancellationException ce) { ex = ce; } catch (ExecutionException ee) { ex = ee.getCause(); } catch (InterruptedException ie) { Thread.currentThread().interrupt(); } } if (ex != null) { System.err.println("[POOL-EXCEPTION] thread=" + Thread.currentThread().getName()); ex.printStackTrace(); } } }✔ 一次兜住所有 submit / execute
✔ 适合做成公共基础组件
❌ 代码复杂度略高
七、生产级解决方案三：Future 必须 get（有限场景）
Future<?> f = pool.submit(task); try { f.get(3, TimeUnit.SECONDS); } catch (ExecutionException e) { log.error("任务异常", e.getCause()); }适用场景：
- 必须拿结果
- 有超时控制
- 同步业务流程
❌ 不适合 fire-and-forget 任务
❌ 不适合大量异步任务
八、三种方案怎么选？（直接给你结论）
| 场景 | 推荐方案 |
|---|---|
| fire-and-forget 异步任务 | SafeRunnable 包装 |
| 框架 / 基础组件 | afterExecute 兜底 |
| 必须拿结果 | submit + get(timeout) |
一句工程经验：
异常必须在“离任务最近的地方”被处理。
不要指望调用方一定会 get。
九、本篇总结
- execute 抛异常 → 线程层面处理 → 通常能看到日志
- submit 抛异常 → Future 捕获 → 不 get 就“静默失败”
- 生产中必须统一异常兜底
- 推荐方案：任务包装 or afterExecute
- 不要把“异常可见性”交给调用方
