面试拷打：线程池抛了异常怎么处理？答出 try-catch 只是入门
👉这是一个或许对你有用的社群
🐱 一对一交流/面试小册/简历优化/求职解惑，欢迎加入「芋道快速开发平台」知识星球。下面是星球提供的部分资料：
《项目实战（视频）》：从书中学，往事中“练”
《互联网高频面试题》：面朝简历学习，春暖花开
《架构 x 系统设计》：摧枯拉朽，掌控面试高频场景题
《精进 Java 学习指南》：系统学习，互联网主流技术栈
《必读 Java 源码专栏》：知其然，知其所以然
👉这是一个或许对你有用的开源项目
国产Star破10w的开源项目，前端包括管理后台、微信小程序，后端支持单体、微服务架构
RBAC权限、数据权限、SaaS多租户、商城、支付、工作流、大屏报表、ERP、CRM、AI大模型、IoT物联网等功能：
多模块：https://gitee.com/zhijiantianya/ruoyi-vue-pro
微服务：https://gitee.com/zhijiantianya/yudao-cloud
视频教程：https://doc.iocoder.cn
【国内首批】支持 JDK17/21+SpringBoot3、JDK8/11+Spring Boot2双版本
来源：
这道题面试官真正在筛什么
L1：30 秒答案过基础线
L2：2 分钟答案显源码功底
L3：5 分钟答案显生产经验
直接掉分的几种答法
高频追问怎么接
一句话收口
这道题面试官真正在筛什么
「线程池里的线程抛出了异常，该如何处理？」——这是京东、美团、字节二面的高频题。
字面看是个 API 题，实际筛的是三件事：
你知道 submit 默默吞异常这个坑吗——做过线上的人都被坑过；
你了解 ThreadPoolExecutor 内部
runWorker的异常流转吗——源码角度的差距；你能写出真上生产的方案吗——
UncaughtExceptionHandler/afterExecute/Future.get三档要懂取舍。
只答「try-catch 包一下」，30 分；答出「submit 内部把异常 set 到 outcome，必须 future.get() 才能拿到」，60 分；能拉出三套生产方案对比 + 真踩过的坑，90 分。
下面按段位拆。
基于 Spring Boot + MyBatis Plus + Vue & Element 实现的后台管理系统 + 用户小程序，支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能
项目地址：https://github.com/YunaiV/ruoyi-vue-pro
视频教程：https://doc.iocoder.cn/video/
L1：30 秒答案过基础线
线程池里抛异常，先看怎么提交的：
提交方式 | 默认行为 |
|---|---|
execute(Runnable) | 异常会被打印到 stderr |
submit(Runnable)/ | 异常被吞掉，必须 |
跑个最小样例就一目了然：
public class Demo { public static void main(String[] args) { ExecutorService pool = Executors.newFixedThreadPool(1); pool.submit(new Task()); // 静默吞异常 pool.execute(new Task()); // 打印异常到 stderr } staticclass Task implements Runnable { public void run() { System.out.println("进入 task"); int i = 1 / 0; } } }输出对比：
要拿到submit的异常，必须显式future.get()：
Future<?> f = pool.submit(new Task()); f.get(); // 这里抛 ExecutionException，包了原异常最简单的兜底就是任务里 try-catch：
class Task implements Runnable { public void run() { try { int i = 1 / 0; } catch (Exception e) { log.error("任务异常", e); } } }这一档的回答到这里，30 分起步线已经过了——但面试官一定会追问「为什么 submit 不打印异常」「除了 try-catch 还有别的兜底吗」。要继续往上走，必须讲源码。
基于 Spring Cloud Alibaba + Gateway + Nacos + RocketMQ + Vue & Element 实现的后台管理系统 + 用户小程序，支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能
项目地址：https://github.com/YunaiV/yudao-cloud
视频教程：https://doc.iocoder.cn/video/
L2：2 分钟答案显源码功底
submit吞异常，根因在 FutureTask——它把任务包了一层，run 方法里 try-catch 了所有 Throwable，把异常 set 到内部的outcome字段。
ThreadPoolExecutor.submit()的实现：
public <T> Future<T> submit(Callable<T> task) { if (task == null) throw new NullPointerException(); RunnableFuture<T> ftask = newTaskFor(task); // 包成 FutureTask execute(ftask); // 底层还是 execute return ftask; }FutureTask.run()的关键逻辑：
public void run() { try { Callable<V> c = callable; V result; try { result = c.call(); ran = true; } catch (Throwable ex) { result = null; ran = false; setException(ex); // ← 异常被吞到这里 } if (ran) set(result); } finally { // ... } } protected void setException(Throwable t) { if (UNSAFE.compareAndSwapInt(this, stateOffset, NEW, COMPLETING)) { outcome = t; // ← 异常存到 outcome UNSAFE.putOrderedInt(this, stateOffset, EXCEPTIONAL); finishCompletion(); } }Future.get()的时候才把 outcome 抛出来：
private V report(int s) throws ExecutionException { Object x = outcome; if (s == NORMAL) return (V)x; if (s >= CANCELLED) throw new CancellationException(); throw new ExecutionException((Throwable)x); // ← 这里把异常包成 ExecutionException 抛 }所以 submit 不是丢了异常，是「等你来取」——不调get()就永远不会爆。
execute()的路径完全不同——异常一路抛到runWorker，被记录到Throwable thrown然后afterExecute(task, thrown)，最后重新 throw 出去：
final void runWorker(Worker w) { // ... try { beforeExecute(wt, task); Throwable thrown = null; try { task.run(); // ← execute 提交：异常会一路传上来 // ← submit 提交：异常被 FutureTask.run() 吞了 } catch (RuntimeException x) { thrown = x; throw x; } catch (Error x) { thrown = x; throw x; } catch (Throwable x) { thrown = x; thrownew Error(x); } finally { afterExecute(task, thrown); // ← 这里给了 hook } } finally { // ... } }关键观察：execute的异常会被重新 throw，最终走到Thread.UncaughtExceptionHandler；submit的异常被FutureTask吞了，根本走不到 UncaughtExceptionHandler。
L3：5 分钟答案显生产经验
生产里不会让每个任务都写 try-catch——业务代码会被切得稀碎。下面三套是真用过的方案，按推荐度递减。
方案 A：ThreadFactory + UncaughtExceptionHandler（有坑）
最常见的网文答案——给 ThreadFactory 设UncaughtExceptionHandler：
ThreadFactory factory = r -> { Thread t = new Thread(r); t.setUncaughtExceptionHandler((thread, e) -> log.error("线程 {} 异常", thread.getName(), e)); return t; }; ExecutorService pool = new ThreadPoolExecutor( 1, 1, 0, TimeUnit.MILLISECONDS, new LinkedBlockingQueue<>(10), factory);execute 提交的能被捕获：
但submit 提交的依然捕获不到——FutureTask 已经吞了，根本不会触发 UncaughtExceptionHandler：
这是网上 80% 答案的盲区——只对 execute 起作用。如果你的代码里 submit / execute 混用，这套方案兜不住。
方案 B：重写 afterExecute（推荐）
ThreadPoolExecutor.afterExecute(Runnable r, Throwable t)是个 protected hook，每个任务执行完都会调用一次：
ExecutorService pool = new ThreadPoolExecutor( 2, 3, 0, TimeUnit.MILLISECONDS, new LinkedBlockingQueue<>(10) ) { @Override protected void afterExecute(Runnable r, Throwable t) { super.afterExecute(r, t); // execute 提交的异常：直接从 t 拿 if (t != null) { log.error("任务异常（execute）", t); return; } // submit 提交的异常：要从 FutureTask 里 get 出来 if (r instanceof FutureTask) { Future<?> future = (Future<?>) r; try { future.get(); } catch (CancellationException ce) { // 任务被 cancel，不算异常 } catch (ExecutionException ee) { log.error("任务异常（submit）", ee.getCause()); } catch (InterruptedException ie) { Thread.currentThread().interrupt(); } } } };这是真正能兜底两种提交方式的方案——execute 直接看t，submit 通过future.get()取出来。
输出验证：
生产里就用这套——配合一个统一的告警 / Sentry 上报，所有线程池任务的异常都能拿到。
方案 C：CompletableFuture（新代码推荐）
如果是新写的代码，直接用 CompletableFuture 替代 submit：
CompletableFuture.runAsync(() -> { int i = 1 / 0; }, pool).exceptionally(ex -> { log.error("任务异常", ex); return null; });exceptionally是异步链式异常处理，比 submit + future.get() 优雅——也不用每次记得调 get。
直接掉分的几种答法
按扣分严重程度倒序：
「用 try-catch 包一下就行」——只答这个 = 没听说过 submit 的坑，30 分封顶；
「submit 也会打印异常」——直接错。submit 不调 get 永远不会暴露异常，这是常识题；
「UncaughtExceptionHandler 能兜底所有线程池异常」——错一半。submit 提交的根本不会触发 UncaughtExceptionHandler；
「线程池捕获异常会停掉 worker」——execute 的会，但 ThreadPoolExecutor 内部会立即新建一个 worker 顶上，不会影响后续任务——这点不知道说明没读过
processWorkerExit；「submit 比 execute 好用」/「execute 比 submit 好用」——这种二选一答法直接扣分。两者用途不同：execute 给「丢出去就不管」的任务，submit 给需要返回值或异常的任务；
从来不提 afterExecute——只会用 UncaughtExceptionHandler 说明只读过教程没读过源码。
高频追问怎么接
Q1：异常被吞之后，那个 worker 线程会停吗？
execute 提交的会——异常一路传到runWorker顶层，worker 线程退出。但processWorkerExit立刻补一个新 worker 进来，对后续任务无影响。
submit 提交的根本没异常往上传（FutureTask 吞了），worker 不会停，继续跑下一个任务。
Q2：方案 B 的afterExecute里future.get()会阻塞吗？
不会。afterExecute在任务执行完之后调用，FutureTask 状态已经是 NORMAL / EXCEPTIONAL，get()立即返回不阻塞。
Q3：Spring 的@Async注解抛异常会怎样？
@Async默认底层是submit——异常会被吞。要兜底有两条路：
配置
AsyncUncaughtExceptionHandler（只覆盖void返回值的@Async方法）；返回
CompletableFuture，调用方用exceptionally处理。
Q4：为什么 ThreadPoolExecutor 不让我们直接拿到 submit 的异常？
设计哲学问题——submit 默认假设你会用 future。Future 是「未来结果的承诺」，异常也是结果的一部分，你不主动取就不告诉你。execute 是「丢出去就不管」，没有 future 就只能把异常一路抛上来。
Q5：生产里你们怎么做的？
我们的做法（参考 Hippo4j / Dynamic Tp 这类开源动态线程池框架）：
统一封装 ThreadPoolExecutor，强制重写
afterExecute接告警；重要任务用
CompletableFuture+exceptionally显式处理；异常打到 Sentry，关联 traceId 反查请求链路；
慢任务 / 拒绝任务也走同一套告警通道。
一句话收口
「线程池抛异常怎么处理」真正考的不是 try-catch，是你对 ThreadPoolExecutor 的源码理解 + 生产兜底意识：
30 分：知道 submit 吞异常，会用 try-catch 兜底；
60 分：能讲清 FutureTask.run 把异常 set 到 outcome、必须 get 才能取；
90 分：能拉出 afterExecute 重写 + FutureTask 兜底两种方式的完整方案，并且知道为什么 UncaughtExceptionHandler 在 submit 上失效。
写线程池代码的核心心法很简单——异常永远要有归宿。submit 不调 get、execute 不重写 afterExecute、async 不接 exceptionally——这些都是异常的「黑洞」，进去出不来。
线程池兜底的本质，是给每条异步分支都修一条「异常回流通道」——这条通道修好了，并发问题排查的难度直接砍一半。
欢迎加入我的知识星球，全面提升技术能力。
👉 加入方式，“长按”或“扫描”下方二维码噢：
星球的内容包括：项目实战、面试招聘、源码解析、学习路线。
文章有帮助的话，在看，转发吧。 谢谢支持哟 (*^__^*）