news 2026/6/10 0:44:35

线程池中线程抛了异常,这样处理太优雅了!

作者头像

张小明

前端开发工程师

1.2k 24
文章封面图
线程池中线程抛了异常,这样处理太优雅了!

在实际开发中,我们常常会用到线程池,但任务一旦提交到线程池之后,如果发生异常之后,怎么处理? 怎么获取到异常信息?在了解这个问题之前,可以先看一下 线程池的源码解析,从源码中我们知道了线程池的提交方式:submit和execute的区别,接下来分别使用他们执行带有异常的任务!看结果是怎么样的!

我们先用伪代码模拟一下线程池抛异常的场景:

public class ThreadPoolException { public static void main(String[] args) { //创建一个线程池 ExecutorService executorService= Executors.newFixedThreadPool(1); //当线程池抛出异常后 submit无提示,其他线程继续执行 executorService.submit(new task()); //当线程池抛出异常后 execute抛出异常,其他线程继续执行新任务 executorService.execute(new task()); } } //任务类 class task implements Runnable{ @Override public void run() { System.out.println("进入了task方法!!!"); int i=1/0; } }

运行结果:

可以看到:submit不打印异常信息,而execute则会打印异常信息!,submit的方式不打印异常信息,显然在生产中,是不可行的,因为我们无法保证线程中的任务永不异常,而如果使用submit的方式出现了异常,直接如上写法,我们将无法获取到异常信息,做出对应的判断和处理,所以下一步需要知道如何获取线程池抛出的异常!

推荐Java工程师技术指南:https://github.com/chenjiabing666/JavaFamily

submit()想要获取异常信息就必须使用get()方法!!

//当线程池抛出异常后 submit无提示,其他线程继续执行 Future<?> submit = executorService.submit(new task()); submit.get();

submit打印异常信息如下:

方案一:使用try -catch

public class ThreadPoolException { public static void main(String[] args) { //创建一个线程池 ExecutorService executorService = Executors.newFixedThreadPool(1); //当线程池抛出异常后 submit无提示,其他线程继续执行 executorService.submit(new task()); //当线程池抛出异常后 execute抛出异常,其他线程继续执行新任务 executorService.execute(new task()); } } // 任务类 class task implements Runnable { @Override public void run() { try { System.out.println("进入了task方法!!!"); int i = 1 / 0; } catch (Exception e) { System.out.println("使用了try -catch 捕获异常" + e); } } }

打印结果:

可以看到 submit 和 execute都清晰易懂的捕获到了异常,可以知道我们的任务出现了问题,而不是消失的无影无踪。关注公众号:码猿技术专栏,回复关键词:1111 获取阿里内部Java性能调优手册!

方案二:使用Thread.setDefaultUncaughtExceptionHandler方法捕获异常

方案一中,每一个任务都要加一个try-catch实在是太麻烦了,而且代码也不好看,那么这样想的话,可以用Thread.setDefaultUncaughtExceptionHandler方法捕获异常

UncaughtExceptionHandler是Thread类一个内部类,也是一个函数式接口。

推荐Java工程师技术指南:https://github.com/chenjiabing666/JavaFamily

内部的uncaughtException是一个处理线程内发生的异常的方法,参数为线程对象t和异常对象e。

应用在线程池中如下所示:重写它的线程工厂方法,在线程工厂创建线程的时候,都赋予UncaughtExceptionHandler处理器对象。

public class ThreadPoolException { public static void main(String[] args) throws InterruptedException { //1.实现一个自己的线程池工厂 ThreadFactory factory = (Runnable r) -> { //创建一个线程 Thread t = new Thread(r); //给创建的线程设置UncaughtExceptionHandler对象 里面实现异常的默认逻辑 t.setDefaultUncaughtExceptionHandler((Thread thread1, Throwable e) -> { System.out.println("线程工厂设置的exceptionHandler" + e.getMessage()); }); return t; }; //2.创建一个自己定义的线程池,使用自己定义的线程工厂 ExecutorService executorService = new ThreadPoolExecutor( 1, 1, 0, TimeUnit.MILLISECONDS, new LinkedBlockingQueue(10), factory); // submit无提示 executorService.submit(new task()); Thread.sleep(1000); System.out.println("==================为检验打印结果,1秒后执行execute方法"); // execute 方法被线程工厂factory 的UncaughtExceptionHandler捕捉到异常 executorService.execute(new task()); } } class task implements Runnable { @Override public void run() { System.out.println("进入了task方法!!!"); int i = 1 / 0; } }

打印结果如下:

根据打印结果我们看到,execute方法被线程工厂factory中设置的UncaughtExceptionHandler捕捉到异常,而submit方法却没有任何反应!说明UncaughtExceptionHandler在submit中并没有被调用。这是为什么呢?

在日常使用中,我们知道,execute和submit最大的区别就是execute没有返回值,submit有返回值。submit返回的是一个future ,可以通过这个future取到线程执行的结果或者异常信息。

Future<?> submit = executorService.submit(new task()); //打印异常结果 System.out.println(submit.get());

从结果看出:submit并不是丢失了异常,使用future.get()还是有异常打印的!!那为什么线程工厂factory 的UncaughtExceptionHandler没有打印异常呢?猜测是submit方法内部已经捕获了异常, 只是没有打印出来,也因为异常已经被捕获,因此jvm也就不会去调用Thread的UncaughtExceptionHandler去处理异常。

接下来,验证猜想:

首先看一下submit和execute的源码:

execute方法的源码在这博客中写的很详细,点击查看execute源码,在此就不再啰嗦了

https://blog.csdn.net/qq_45076180/article/details/108316340

submit源码在底层还是调用的execute方法,只不过多一层Future封装,并返回了这个Future,这也解释了为什么submit会有返回值

//submit()方法 public <T> Future<T> submit(Callable<T> task) { if (task == null) throw new NullPointerException(); //execute内部执行这个对象内部的逻辑,然后将结果或者异常 set到这个ftask里面 RunnableFuture<T> ftask = newTaskFor(task); // 执行execute方法 execute(ftask); //返回这个ftask return ftask; }

可以看到submit也是调用的execute,在execute方法中,我们的任务被提交到了addWorker(command, true),然后为每一个任务创建一个Worker去处理这个线程,这个Worker也是一个线程,执行任务时调用的就是Worker的run方法!run方法内部又调用了runworker方法!如下所示:

public void run() { runWorker(this); } final void runWorker(Worker w) { Thread wt = Thread.currentThread(); Runnable task = w.firstTask; w.firstTask = null; w.unlock(); // allow interrupts boolean completedAbruptly = true; try { //这里就是线程可以重用的原因,循环+条件判断,不断从队列中取任务 //还有一个问题就是非核心线程的超时删除是怎么解决的 //主要就是getTask方法()见下文③ while (task != null || (task = getTask()) != null) { w.lock(); if ((runStateAtLeast(ctl.get(), STOP) || (Thread.interrupted() && runStateAtLeast(ctl.get(), STOP))) && !wt.isInterrupted()) wt.interrupt(); try { beforeExecute(wt, task); Throwable thrown = null; try { //执行线程 task.run(); //异常处理 } catch (RuntimeException x) { thrown = x; throw x; } catch (Error x) { thrown = x; throw x; } catch (Throwable x) { thrown = x; throw new Error(x); } finally { //execute的方式可以重写此方法处理异常 afterExecute(task, thrown); } } finally { task = null; w.completedTasks++; w.unlock(); } } //出现异常时completedAbruptly不会被修改为false completedAbruptly = false; } finally { //如果如果completedAbruptly值为true,则出现异常,则添加新的Worker处理后边的线程 processWorkerExit(w, completedAbruptly); } }

核心就在task.run();这个方法里面了, 期间如果发生异常会被抛出。

  • 如果用execute提交的任务,会被封装成了一个runable任务,然后进去 再被封装成一个worker,最后在worker的run方法里面调用runWoker方法,runWoker方法里面执行任务任务,如果任务出现异常,用try-catch捕获异常往外面抛,我们在最外层使用try-catch捕获到了runWoker方法中抛出的异常。因此我们在execute中看到了我们的任务的异常信息。

  • 那么为什么submit没有异常信息呢? 因为submit是将任务封装成了一个futureTask,然后这个futureTask被封装成worker,在woker的run方法里面,最终调用的是futureTask的run方法, 猜测里面是直接吞掉了异常,并没有抛出异常,因此在worker的runWorker方法里面无法捕获到异常。

下面来看一下futureTask的run方法,果不其然,在try-catch中吞掉了异常,将异常放到了setException(ex);里面

public void run() { if (state != NEW || !UNSAFE.compareAndSwapObject(this, runnerOffset, null, Thread.currentThread())) return; try { Callable<V> c = callable; if (c != null && state == NEW) { V result; boolean ran; try { result = c.call(); ran = true; } catch (Throwable ex) { result = null; ran = false; //在此方法中设置了异常信息 setException(ex); } if (ran) set(result); } //省略下文 。。。。。。 setException(ex)`方法如下:将异常对象赋予`outcome protected void setException(Throwable t) { if (UNSAFE.compareAndSwapInt(this, stateOffset, NEW, COMPLETING)) { //将异常对象赋予outcome,记住这个outcome, outcome = t; UNSAFE.putOrderedInt(this, stateOffset, EXCEPTIONAL); // final state finishCompletion(); } }

将异常对象赋予outcome有什么用呢?这个outcome是什么呢?当我们使用submit返回Future对象,并使用Future.get()时, 会调用内部的report方法!

public V get() throws InterruptedException, ExecutionException { int s = state; if (s <= COMPLETING) s = awaitDone(false, 0L); //注意这个方法 return report(s); }

reoport里面实际上返回的是outcome ,刚好之前的异常就set到了这个outcome里面

private V report(int s) throws ExecutionException { //设置`outcome` Object x = outcome; if (s == NORMAL) //返回`outcome` return (V)x; if (s >= CANCELLED) throw new CancellationException(); throw new ExecutionException((Throwable)x); }

因此,在用submit提交的时候,runable对象被封装成了future ,future 里面的 run方法在处理异常时,try-catch了所有的异常,通过setException(ex);方法设置到了变量outcome里面, 可以通过future.get获取到outcome。

所以在submit提交的时候,里面发生了异常, 是不会有任何抛出信息的。而通过future.get()可以获取到submit抛出的异常!在submit里面,除了从返回结果里面取到异常之外, 没有其他方法。因此,在不需要返回结果的情况下,最好用execute ,这样就算没有写try-catch,疏漏了异常捕捉,也不至于丢掉异常信息。

方案三:重写afterExecute进行异常处理

通过上述源码分析,在excute的方法里面,可以通过重写afterExecute进行异常处理,但是注意! 这个也只适用于excute提交(submit的方式比较麻烦,下面说),因为submit的task.run里面把异常吞了,根本不会跑出来异常,因此也不会有异常进入到afterExecute里面。

runWorker里面,调用task.run之后,会调用线程池的afterExecute(task, thrown)方法

final void runWorker(Worker w) { //当前线程 Thread wt = Thread.currentThread(); //我们的提交的任务 Runnable task = w.firstTask; w.firstTask = null; w.unlock(); // allow interrupts boolean completedAbruptly = true; try { while (task != null || (task = getTask()) != null) { w.lock(); if ((runStateAtLeast(ctl.get(), STOP) || (Thread.interrupted() && runStateAtLeast(ctl.get(), STOP))) && !wt.isInterrupted()) wt.interrupt(); try { beforeExecute(wt, task); Throwable thrown = null; try { //直接就调用了task的run方法 task.run(); //如果是futuretask的run,里面是吞掉了异常,不会有异常抛出, // 因此Throwable thrown = null; 也不会进入到catch里面 } catch (RuntimeException x) { thrown = x; throw x; } catch (Error x) { thrown = x; throw x; } catch (Throwable x) { thrown = x; throw new Error(x); } finally { //调用线程池的afterExecute方法 传入了task和异常 afterExecute(task, thrown); } } finally { task = null; w.completedTasks++; w.unlock(); } } completedAbruptly = false; } finally { processWorkerExit(w, completedAbruptly); } }

重写afterExecute处理execute提交的异常

public class ThreadPoolException3 { public static void main(String[] args) throws InterruptedException, ExecutionException { //1.创建一个自己定义的线程池 ExecutorService executorService = new ThreadPoolExecutor( 2, 3, 0, TimeUnit.MILLISECONDS, new LinkedBlockingQueue(10) ) { //重写afterExecute方法 @Override protected void afterExecute(Runnable r, Throwable t) { System.out.println("afterExecute里面获取到异常信息,处理异常" + t.getMessage()); } }; //当线程池抛出异常后 execute executorService.execute(new task()); } } class task3 implements Runnable { @Override public void run() { System.out.println("进入了task方法!!!"); int i = 1 / 0; } }

执行结果:我们可以在afterExecute方法内部对异常进行处理

如果要用这个afterExecute处理submit提交的异常, 要额外处理。判断Throwable是否是FutureTask,如果是代表是submit提交的异常,代码如下:

public class ThreadPoolException3 { public static void main(String[] args) throws InterruptedException, ExecutionException { //1.创建一个自己定义的线程池 ExecutorService executorService = new ThreadPoolExecutor( 2, 3, 0, TimeUnit.MILLISECONDS, new LinkedBlockingQueue(10) ) { //重写afterExecute方法 @Override protected void afterExecute(Runnable r, Throwable t) { //这个是excute提交的时候 if (t != null) { System.out.println("afterExecute里面获取到excute提交的异常信息,处理异常" + t.getMessage()); } //如果r的实际类型是FutureTask 那么是submit提交的,所以可以在里面get到异常 if (r instanceof FutureTask) { try { Future<?> future = (Future<?>) r; //get获取异常 future.get(); } catch (Exception e) { System.out.println("afterExecute里面获取到submit提交的异常信息,处理异常" + e); } } } }; //当线程池抛出异常后 execute executorService.execute(new task()); //当线程池抛出异常后 submit executorService.submit(new task()); } } class task3 implements Runnable { @Override public void run() { System.out.println("进入了task方法!!!"); int i = 1 / 0; } }

处理结果如下:

可以看到使用重写afterExecute这种方式,既可以处理execute抛出的异常,也可以处理submit抛出的异常

版权声明: 本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若内容造成侵权/违法违规/事实不符,请联系邮箱:809451989@qq.com进行投诉反馈,一经查实,立即删除!
网站建设 2026/6/10 0:31:14

MyBatisPlus逻辑删除扩展GLM-4.6V-Flash-WEB历史记录管理

MyBatisPlus逻辑删除扩展GLM-4.6V-Flash-WEB历史记录管理 在AI驱动的Web应用日益普及的今天&#xff0c;一个看似简单的“删除”操作背后&#xff0c;往往隐藏着复杂的技术权衡。比如&#xff0c;当用户在智能图像问答系统中点击“删除某条分析记录”时&#xff0c;我们真的应…

作者头像 李华
网站建设 2026/6/9 21:00:34

【Dify工程师亲述】:构建高可用多模态系统的3种关键数据格式策略

第一章&#xff1a;Dify多模态系统中的数据格式演进随着多模态AI应用的快速发展&#xff0c;Dify平台在处理文本、图像、音频和视频等异构数据时&#xff0c;对数据格式的统一性与扩展性提出了更高要求。为应对这一挑战&#xff0c;Dify构建了一套灵活且可演进的数据结构体系&a…

作者头像 李华
网站建设 2026/6/9 22:42:37

实例控制台日志轮转防止GLM-4.6V-Flash-WEB日志过大

实例控制台日志轮转防止GLM-4.6V-Flash-WEB日志过大 在AI模型服务日益走向生产环境的今天&#xff0c;一个常被忽视却极具破坏力的问题正悄然浮现&#xff1a;日志失控。尤其是像 GLM-4.6V-Flash-WEB 这类部署在Jupyter实例或轻量Web服务器上的多模态推理模型&#xff0c;一旦开…

作者头像 李华
网站建设 2026/6/9 21:26:45

Instagram负责人:AI内容泛滥凸显真实媒体认证价值

Instagram负责人亚当莫塞里&#xff08;Adam Mosseri&#xff09;在一篇关于2026年平台趋势预测的长文中表示&#xff0c;生成式AI内容在2025年已经占领了社交媒体信息流&#xff0c;并且预计AI内容将超越非AI图像内容。莫塞里坦率地评估了AI如何颠覆Instagram平台。他写道&…

作者头像 李华
网站建设 2026/6/9 20:58:29

Dify描述生成限制全解析(从原理到破解策略)

第一章&#xff1a;Dify描述生成限制概述Dify 是一个面向 AI 应用开发的低代码平台&#xff0c;支持通过自然语言描述快速生成应用逻辑与前后端代码。然而&#xff0c;在使用其“描述生成”功能时&#xff0c;系统对输入内容存在若干限制&#xff0c;以确保生成结果的准确性与安…

作者头像 李华