1. 线程池任务提交的两种入口为什么需要区分submit和execute很多同学第一次接触Java线程池的时候脑子里就一个印象把任务丢进去线程池帮我跑。至于丢的方式execute和submit看起来都能用参数都是个Runnable编译也不报错跑起来好像也没区别。但真正到了线上环境尤其是任务需要返回值、需要捕获异常、需要做超时控制的场景选错了方法轻则拿不到结果重则异常被静默吞掉排查半天找不到问题在哪。这篇文章就是把这个看似简单、实则暗藏玄机的问题彻底讲透。核心关键词就三个线程池、submit、execute。我会从接口定义、返回值处理、异常传播机制、适用场景、底层源码实现几个维度拆开来讲最后给出可以直接抄作业的选择建议和避坑清单。适合已经用过线程池但没深究过细节的开发者也适合正在准备面试、想把并发基础打牢的同学。读完你至少能搞清楚一件事什么时候必须用submit什么时候execute才是更稳妥的选择以及为什么很多人说“submit会吞异常”这句话到底对不对。先把结论摆在前面方便你带着问题往下看execute只能接收Runnable没有返回值异常会直接抛到线程的UncaughtExceptionHandlersubmit可以接收Runnable和Callable返回一个Future异常会被封装进Future只有调用get的时候才会抛出来。这一个核心差异衍生出了一系列使用上的注意事项。2. 从接口定义看本质差异2.1 Executor接口与ExecutorService接口的继承关系要理解这两个方法的区别得先看它们分别定义在哪个接口上。execute方法定义在最顶层的Executor接口里整个接口就这一个方法public interface Executor { void execute(Runnable command); }而submit方法定义在ExecutorService接口上这个接口继承了Executor并且扩展了一批带返回值、带生命周期管理的方法public interface ExecutorService extends Executor { T FutureT submit(CallableT task); T FutureT submit(Runnable task, T result); Future? submit(Runnable task); // ... 其他方法省略 }这个继承关系本身就说明了一个设计意图execute是最基础的执行契约只保证“任务被提交执行”不承诺任何结果反馈submit是在此之上的一层增强提供了异步结果的句柄。你可以把execute理解成“发射后不管”把submit理解成“发射后给你一个追踪器”。2.2 三个submit重载方法的参数与返回值submit有三个重载很多人只用过其中一个其实它们各有用途方法签名入参类型返回值典型用途submit(CallableT task)CallableFutureT需要任务返回计算结果submit(Runnable task, T result)Runnable 结果对象FutureT任务无返回值但需要拿到预设结果submit(Runnable task)RunnableFuture?只需要知道任务是否完成第二个重载比较有意思它接收一个Runnable和一个结果对象任务跑完之后Future.get()返回的就是你传进去的那个result。这个设计在需要“任务执行完但结果由外部指定”的场景下很有用比如批量任务只需要确认全部完成不需要每个任务返回具体数据。2.3 为什么execute不设计返回值有人会问既然submit这么好用为什么还要保留execute直接全用submit不就行了。这个问题的答案藏在接口分层设计里。Executor是最小接口它的定位是“能执行任务就行”不关心结果。这种极简设计让它的实现类可以非常轻量也让调用方明确知道自己不需要结果。而ExecutorService面向的是需要管理任务生命周期的场景。接口隔离原则在这里体现得很明显不需要结果的地方就不应该被迫处理Future。从性能角度看submit内部最终也是调用execute来执行任务的只是多包了一层FutureTask。这层包装有微小的对象创建开销在高频提交且不需要结果的场景下直接用execute更干净。3. 异常处理机制最容易踩坑的地方3.1 execute的异常传播路径用execute提交任务时如果任务内部抛出了未捕获的异常这个异常会沿着线程的调用栈往上抛最终由线程的UncaughtExceptionHandler处理。默认情况下它会打印堆栈到标准错误流你能在控制台看到完整的异常信息。ExecutorService pool Executors.newFixedThreadPool(2); pool.execute(() - { throw new RuntimeException(execute任务异常); }); // 控制台会打印出完整的异常堆栈这个行为符合直觉任务出错了错误信息直接暴露出来。但要注意如果线程池的线程是通过线程工厂创建的并且设置了自定义的UncaughtExceptionHandler那么异常的处理方式就取决于你的handler实现。3.2 submit的异常封装机制submit的行为完全不同。任务抛出的异常不会直接打印而是被捕获并封装进Future对象里。如果你不调用Future.get()这个异常就永远沉默你甚至不知道任务失败了。ExecutorService pool Executors.newFixedThreadPool(2); Future? future pool.submit(() - { throw new RuntimeException(submit任务异常); }); // 此时控制台没有任何异常输出 // 只有调用get时才会抛出ExecutionException try { future.get(); } catch (ExecutionException e) { Throwable cause e.getCause(); // 真正的异常在这里 }这就是“submit吞异常”这个说法的来源。严格来说不是吞了是暂存了但如果你不主动去取效果和吞了没区别。我见过不少线上问题任务失败了好几天没人发现就是因为用了submit但从来没调用过get。3.3 两种异常处理方式的取舍那到底哪种更好没有绝对答案取决于你的场景如果你希望任务失败时立即有反馈用execute让异常直接暴露。如果你需要统一收集任务结果和异常用submit但必须保证每个Future都被检查。如果用了submit又不想逐个get可以在任务内部自己try-catch把异常记录到日志系统。注意用submit提交任务后如果既不调用get也不做异常捕获等于把异常丢进了黑洞。这是生产环境最常见的隐患之一。4. 返回值与结果获取的实操细节4.1 Future.get的阻塞特性与超时控制submit返回的Future调用get()方法是阻塞的直到任务完成。如果任务执行很慢调用线程就会一直卡住。所以生产环境强烈建议使用带超时的getFutureString future pool.submit(() - { Thread.sleep(5000); return done; }); try { String result future.get(2, TimeUnit.SECONDS); } catch (TimeoutException e) { // 超时处理可以选择取消任务 future.cancel(true); } catch (ExecutionException e) { // 任务内部抛出的异常 Throwable cause e.getCause(); } catch (InterruptedException e) { Thread.currentThread().interrupt(); }这里有个细节future.cancel(true)会尝试中断正在执行的任务但能否真正中断取决于任务代码是否响应中断。如果任务里有阻塞的IO操作且不响应中断cancel也救不了你。4.2 Callable与Runnable的选择Callable和Runnable的区别就一个Callable的call()方法可以返回结果、可以抛受检异常Runnable的run()方法没有返回值、不能抛受检异常。所以需要返回值的场景必须用Callable不需要返回值但想用submit的异常封装机制可以用Runnable。// Callable方式 FutureInteger f1 pool.submit(() - { return 1 1; }); // Runnable方式结果由外部指定 FutureString f2 pool.submit(() - { System.out.println(执行任务); }, 预设结果);4.3 批量任务的提交与结果收集实际项目里更常见的是批量提交任务然后收集结果。这时候用invokeAll比逐个submit更高效因为它内部会优化任务提交和等待逻辑ListCallableString tasks new ArrayList(); for (int i 0; i 10; i) { final int idx i; tasks.add(() - 任务 idx 完成); } ListFutureString futures pool.invokeAll(tasks, 5, TimeUnit.SECONDS); for (FutureString f : futures) { if (f.isCancelled()) { // 超时被取消的任务 } else { System.out.println(f.get()); } }invokeAll的返回值顺序和任务提交顺序一致这点比手动submit再收集要方便。但要注意如果设置了超时超时后未完成的任务会被取消返回的Future处于cancelled状态此时调用get会抛CancellationException。5. 底层源码层面的实现差异5.1 AbstractExecutorService.submit的包装逻辑submit方法的具体实现是在AbstractExecutorService里核心就三步把任务包装成FutureTask调用execute执行返回FutureTask。public T FutureT submit(CallableT task) { if (task null) throw new NullPointerException(); RunnableFutureT ftask newTaskFor(task); execute(ftask); return ftask; }newTaskFor默认返回一个FutureTask。所以本质上submit就是execute加了一层FutureTask包装。FutureTask本身实现了Runnable所以能被execute接受。这也解释了为什么submit的异常会被封装FutureTask.run()内部用try-catch捕获了所有异常并保存到outcome字段只有get时才重新抛出。5.2 FutureTask的状态流转FutureTask内部有一个volatile的state字段表示任务状态流转路径大致是NEW - COMPLETING - NORMAL正常完成或EXCEPTIONAL异常完成或者NEW - CANCELLED被取消或者NEW - INTERRUPTING - INTERRUPTED中断中到已中断。这个状态机保证了get方法的正确性如果任务还没完成get会阻塞在等待队列上任务完成后完成线程会唤醒等待者。理解这个状态流转有助于你理解为什么cancel之后get会抛CancellationException以及为什么有时候cancel(true)返回true但任务还在跑因为任务不响应中断。5.3 execute在不同线程池实现中的行为差异execute是个抽象方法具体行为取决于线程池实现。以最常用的ThreadPoolExecutor为例它的execute逻辑分三步如果当前线程数小于核心线程数创建新线程执行任务。如果核心线程已满尝试把任务放入队列。如果队列也满了尝试创建非核心线程如果线程数达到最大值执行拒绝策略。这个逻辑对submit同样适用因为submit最终调用的就是execute。所以submit和execute在任务调度层面没有任何区别区别只在返回值和异常处理。6. 常见问题与排查技巧实录6.1 任务异常被静默吞掉的排查方法最常见的坑就是submit提交的任务失败了但没有任何日志。排查思路检查代码里是否有future.get()调用没有的话异常就丢了。如果用了submit但不想逐个get可以在任务内部包一层try-catch把异常打到日志。或者自定义ThreadPoolExecutor重写afterExecute方法从FutureTask里提取异常。protected void afterExecute(Runnable r, Throwable t) { super.afterExecute(r, t); if (t null r instanceof FutureTask) { try { ((FutureTask?) r).get(); } catch (CancellationException ce) { t ce; } catch (ExecutionException ee) { t ee.getCause(); } catch (InterruptedException ie) { Thread.currentThread().interrupt(); } } if (t ! null) { // 统一记录异常日志 log.error(任务执行异常, t); } }这段代码是ThreadPoolExecutor官方注释里给出的模板非常实用建议直接抄。6.2 submit后不get导致的线程泄漏假象有时候你会发现线程池的活跃线程数一直不降怀疑是线程泄漏。其实很可能是任务已经执行完了但Future对象还被引用着或者任务内部有阻塞操作。先检查任务是否真的执行完毕再检查是否有未关闭的资源。线程池本身不会因为submit而泄漏线程任务执行完线程就归还了。6.3 超时后任务仍在后台运行的困惑调用future.get(timeout)超时后任务并不会自动停止它还在后台跑。如果你希望超时后取消任务必须显式调用future.cancel(true)。但即使调用了cancel任务也可能继续运行直到它自己检查到中断标志。所以设计任务时要考虑中断响应比如在循环里检查Thread.currentThread().isInterrupted()。6.4 常见问题速查表问题现象可能原因解决方向任务失败无日志submit后未调用get调用get或重写afterExecuteget一直阻塞任务死锁或耗时过长使用带超时的getcancel后任务还在跑任务不响应中断任务内检查中断标志拿不到返回值用了execute或Runnable改用Callablesubmit异常类型不对ExecutionException包装用getCause()取原始异常7. 选型建议与实战经验总结7.1 什么场景用execute任务不需要返回值且希望异常直接暴露。高频提交的轻量任务想避免FutureTask的包装开销。任务内部已经做了完整的异常处理不需要外部再捕获。7.2 什么场景用submit需要获取任务执行结果。需要批量提交并统一等待完成。需要超时控制超时后取消任务。需要把多个任务的异常收集起来统一处理。7.3 我个人的使用习惯在实际项目里我的习惯是如果任务只是“跑一下”比如发个通知、写个日志、刷新缓存用execute让异常直接暴露在日志里。如果任务需要返回数据或者需要等待所有任务完成后再继续用submit并且一定配合带超时的get和afterExecute的异常记录。最忌讳的就是submit之后Future随手一丢既不get也不处理这种代码在code review时应该直接打回。还有一个细节线程池的队列容量和拒绝策略要和submit配合考虑。如果队列满了submit会抛RejectedExecutionException这个异常是在提交时抛出的不是任务执行时所以调用方必须捕获。而execute同样会抛这个异常。两者在拒绝策略上的行为一致。最后分享一个小技巧如果你用的是Spring的ThreadPoolTaskExecutor它的submit方法返回的是Spring包装的Future行为基本一致但异常处理上有些细微差别建议查看具体版本的文档确认。不管用什么封装核心原则不变有返回值就用submit并检查Future没返回值就用execute并确保异常有地方记录。把这个原则守住线程池的坑至少能避开一大半。 
长河君 · 2026/10/10 0:17:15 · 阅读 1.2k Java线程池submit与execute的区别：异常处理、返回值与选型指南
1. 线程池任务提交的两种入口为什么需要区分submit和execute很多同学第一次接触Java线程池的时候脑子里就一个印象把任务丢进去线程池帮我跑。至于丢的方式execute和submit看起来都能用参数都是个Runnable编译也不报错跑起来好像也没区别。但真正到了线上环境尤其是任务需要返回值、需要捕获异常、需要做超时控制的场景选错了方法轻则拿不到结果重则异常被静默吞掉排查半天找不到问题在哪。这篇文章就是把这个看似简单、实则暗藏玄机的问题彻底讲透。核心关键词就三个线程池、submit、execute。我会从接口定义、返回值处理、异常传播机制、适用场景、底层源码实现几个维度拆开来讲最后给出可以直接抄作业的选择建议和避坑清单。适合已经用过线程池但没深究过细节的开发者也适合正在准备面试、想把并发基础打牢的同学。读完你至少能搞清楚一件事什么时候必须用submit什么时候execute才是更稳妥的选择以及为什么很多人说“submit会吞异常”这句话到底对不对。先把结论摆在前面方便你带着问题往下看execute只能接收Runnable没有返回值异常会直接抛到线程的UncaughtExceptionHandlersubmit可以接收Runnable和Callable返回一个Future异常会被封装进Future只有调用get的时候才会抛出来。这一个核心差异衍生出了一系列使用上的注意事项。2. 从接口定义看本质差异2.1 Executor接口与ExecutorService接口的继承关系要理解这两个方法的区别得先看它们分别定义在哪个接口上。execute方法定义在最顶层的Executor接口里整个接口就这一个方法public interface Executor { void execute(Runnable command); }而submit方法定义在ExecutorService接口上这个接口继承了Executor并且扩展了一批带返回值、带生命周期管理的方法public interface ExecutorService extends Executor { T FutureT submit(CallableT task); T FutureT submit(Runnable task, T result); Future? submit(Runnable task); // ... 其他方法省略 }这个继承关系本身就说明了一个设计意图execute是最基础的执行契约只保证“任务被提交执行”不承诺任何结果反馈submit是在此之上的一层增强提供了异步结果的句柄。你可以把execute理解成“发射后不管”把submit理解成“发射后给你一个追踪器”。2.2 三个submit重载方法的参数与返回值submit有三个重载很多人只用过其中一个其实它们各有用途方法签名入参类型返回值典型用途submit(CallableT task)CallableFutureT需要任务返回计算结果submit(Runnable task, T result)Runnable 结果对象FutureT任务无返回值但需要拿到预设结果submit(Runnable task)RunnableFuture?只需要知道任务是否完成第二个重载比较有意思它接收一个Runnable和一个结果对象任务跑完之后Future.get()返回的就是你传进去的那个result。这个设计在需要“任务执行完但结果由外部指定”的场景下很有用比如批量任务只需要确认全部完成不需要每个任务返回具体数据。2.3 为什么execute不设计返回值有人会问既然submit这么好用为什么还要保留execute直接全用submit不就行了。这个问题的答案藏在接口分层设计里。Executor是最小接口它的定位是“能执行任务就行”不关心结果。这种极简设计让它的实现类可以非常轻量也让调用方明确知道自己不需要结果。而ExecutorService面向的是需要管理任务生命周期的场景。接口隔离原则在这里体现得很明显不需要结果的地方就不应该被迫处理Future。从性能角度看submit内部最终也是调用execute来执行任务的只是多包了一层FutureTask。这层包装有微小的对象创建开销在高频提交且不需要结果的场景下直接用execute更干净。3. 异常处理机制最容易踩坑的地方3.1 execute的异常传播路径用execute提交任务时如果任务内部抛出了未捕获的异常这个异常会沿着线程的调用栈往上抛最终由线程的UncaughtExceptionHandler处理。默认情况下它会打印堆栈到标准错误流你能在控制台看到完整的异常信息。ExecutorService pool Executors.newFixedThreadPool(2); pool.execute(() - { throw new RuntimeException(execute任务异常); }); // 控制台会打印出完整的异常堆栈这个行为符合直觉任务出错了错误信息直接暴露出来。但要注意如果线程池的线程是通过线程工厂创建的并且设置了自定义的UncaughtExceptionHandler那么异常的处理方式就取决于你的handler实现。3.2 submit的异常封装机制submit的行为完全不同。任务抛出的异常不会直接打印而是被捕获并封装进Future对象里。如果你不调用Future.get()这个异常就永远沉默你甚至不知道任务失败了。ExecutorService pool Executors.newFixedThreadPool(2); Future? future pool.submit(() - { throw new RuntimeException(submit任务异常); }); // 此时控制台没有任何异常输出 // 只有调用get时才会抛出ExecutionException try { future.get(); } catch (ExecutionException e) { Throwable cause e.getCause(); // 真正的异常在这里 }这就是“submit吞异常”这个说法的来源。严格来说不是吞了是暂存了但如果你不主动去取效果和吞了没区别。我见过不少线上问题任务失败了好几天没人发现就是因为用了submit但从来没调用过get。3.3 两种异常处理方式的取舍那到底哪种更好没有绝对答案取决于你的场景如果你希望任务失败时立即有反馈用execute让异常直接暴露。如果你需要统一收集任务结果和异常用submit但必须保证每个Future都被检查。如果用了submit又不想逐个get可以在任务内部自己try-catch把异常记录到日志系统。注意用submit提交任务后如果既不调用get也不做异常捕获等于把异常丢进了黑洞。这是生产环境最常见的隐患之一。4. 返回值与结果获取的实操细节4.1 Future.get的阻塞特性与超时控制submit返回的Future调用get()方法是阻塞的直到任务完成。如果任务执行很慢调用线程就会一直卡住。所以生产环境强烈建议使用带超时的getFutureString future pool.submit(() - { Thread.sleep(5000); return done; }); try { String result future.get(2, TimeUnit.SECONDS); } catch (TimeoutException e) { // 超时处理可以选择取消任务 future.cancel(true); } catch (ExecutionException e) { // 任务内部抛出的异常 Throwable cause e.getCause(); } catch (InterruptedException e) { Thread.currentThread().interrupt(); }这里有个细节future.cancel(true)会尝试中断正在执行的任务但能否真正中断取决于任务代码是否响应中断。如果任务里有阻塞的IO操作且不响应中断cancel也救不了你。4.2 Callable与Runnable的选择Callable和Runnable的区别就一个Callable的call()方法可以返回结果、可以抛受检异常Runnable的run()方法没有返回值、不能抛受检异常。所以需要返回值的场景必须用Callable不需要返回值但想用submit的异常封装机制可以用Runnable。// Callable方式 FutureInteger f1 pool.submit(() - { return 1 1; }); // Runnable方式结果由外部指定 FutureString f2 pool.submit(() - { System.out.println(执行任务); }, 预设结果);4.3 批量任务的提交与结果收集实际项目里更常见的是批量提交任务然后收集结果。这时候用invokeAll比逐个submit更高效因为它内部会优化任务提交和等待逻辑ListCallableString tasks new ArrayList(); for (int i 0; i 10; i) { final int idx i; tasks.add(() - 任务 idx 完成); } ListFutureString futures pool.invokeAll(tasks, 5, TimeUnit.SECONDS); for (FutureString f : futures) { if (f.isCancelled()) { // 超时被取消的任务 } else { System.out.println(f.get()); } }invokeAll的返回值顺序和任务提交顺序一致这点比手动submit再收集要方便。但要注意如果设置了超时超时后未完成的任务会被取消返回的Future处于cancelled状态此时调用get会抛CancellationException。5. 底层源码层面的实现差异5.1 AbstractExecutorService.submit的包装逻辑submit方法的具体实现是在AbstractExecutorService里核心就三步把任务包装成FutureTask调用execute执行返回FutureTask。public T FutureT submit(CallableT task) { if (task null) throw new NullPointerException(); RunnableFutureT ftask newTaskFor(task); execute(ftask); return ftask; }newTaskFor默认返回一个FutureTask。所以本质上submit就是execute加了一层FutureTask包装。FutureTask本身实现了Runnable所以能被execute接受。这也解释了为什么submit的异常会被封装FutureTask.run()内部用try-catch捕获了所有异常并保存到outcome字段只有get时才重新抛出。5.2 FutureTask的状态流转FutureTask内部有一个volatile的state字段表示任务状态流转路径大致是NEW - COMPLETING - NORMAL正常完成或EXCEPTIONAL异常完成或者NEW - CANCELLED被取消或者NEW - INTERRUPTING - INTERRUPTED中断中到已中断。这个状态机保证了get方法的正确性如果任务还没完成get会阻塞在等待队列上任务完成后完成线程会唤醒等待者。理解这个状态流转有助于你理解为什么cancel之后get会抛CancellationException以及为什么有时候cancel(true)返回true但任务还在跑因为任务不响应中断。5.3 execute在不同线程池实现中的行为差异execute是个抽象方法具体行为取决于线程池实现。以最常用的ThreadPoolExecutor为例它的execute逻辑分三步如果当前线程数小于核心线程数创建新线程执行任务。如果核心线程已满尝试把任务放入队列。如果队列也满了尝试创建非核心线程如果线程数达到最大值执行拒绝策略。这个逻辑对submit同样适用因为submit最终调用的就是execute。所以submit和execute在任务调度层面没有任何区别区别只在返回值和异常处理。6. 常见问题与排查技巧实录6.1 任务异常被静默吞掉的排查方法最常见的坑就是submit提交的任务失败了但没有任何日志。排查思路检查代码里是否有future.get()调用没有的话异常就丢了。如果用了submit但不想逐个get可以在任务内部包一层try-catch把异常打到日志。或者自定义ThreadPoolExecutor重写afterExecute方法从FutureTask里提取异常。protected void afterExecute(Runnable r, Throwable t) { super.afterExecute(r, t); if (t null r instanceof FutureTask) { try { ((FutureTask?) r).get(); } catch (CancellationException ce) { t ce; } catch (ExecutionException ee) { t ee.getCause(); } catch (InterruptedException ie) { Thread.currentThread().interrupt(); } } if (t ! null) { // 统一记录异常日志 log.error(任务执行异常, t); } }这段代码是ThreadPoolExecutor官方注释里给出的模板非常实用建议直接抄。6.2 submit后不get导致的线程泄漏假象有时候你会发现线程池的活跃线程数一直不降怀疑是线程泄漏。其实很可能是任务已经执行完了但Future对象还被引用着或者任务内部有阻塞操作。先检查任务是否真的执行完毕再检查是否有未关闭的资源。线程池本身不会因为submit而泄漏线程任务执行完线程就归还了。6.3 超时后任务仍在后台运行的困惑调用future.get(timeout)超时后任务并不会自动停止它还在后台跑。如果你希望超时后取消任务必须显式调用future.cancel(true)。但即使调用了cancel任务也可能继续运行直到它自己检查到中断标志。所以设计任务时要考虑中断响应比如在循环里检查Thread.currentThread().isInterrupted()。6.4 常见问题速查表问题现象可能原因解决方向任务失败无日志submit后未调用get调用get或重写afterExecuteget一直阻塞任务死锁或耗时过长使用带超时的getcancel后任务还在跑任务不响应中断任务内检查中断标志拿不到返回值用了execute或Runnable改用Callablesubmit异常类型不对ExecutionException包装用getCause()取原始异常7. 选型建议与实战经验总结7.1 什么场景用execute任务不需要返回值且希望异常直接暴露。高频提交的轻量任务想避免FutureTask的包装开销。任务内部已经做了完整的异常处理不需要外部再捕获。7.2 什么场景用submit需要获取任务执行结果。需要批量提交并统一等待完成。需要超时控制超时后取消任务。需要把多个任务的异常收集起来统一处理。7.3 我个人的使用习惯在实际项目里我的习惯是如果任务只是“跑一下”比如发个通知、写个日志、刷新缓存用execute让异常直接暴露在日志里。如果任务需要返回数据或者需要等待所有任务完成后再继续用submit并且一定配合带超时的get和afterExecute的异常记录。最忌讳的就是submit之后Future随手一丢既不get也不处理这种代码在code review时应该直接打回。还有一个细节线程池的队列容量和拒绝策略要和submit配合考虑。如果队列满了submit会抛RejectedExecutionException这个异常是在提交时抛出的不是任务执行时所以调用方必须捕获。而execute同样会抛这个异常。两者在拒绝策略上的行为一致。最后分享一个小技巧如果你用的是Spring的ThreadPoolTaskExecutor它的submit方法返回的是Spring包装的Future行为基本一致但异常处理上有些细微差别建议查看具体版本的文档确认。不管用什么封装核心原则不变有返回值就用submit并检查Future没返回值就用execute并确保异常有地方记录。把这个原则守住线程池的坑至少能避开一大半。