
线程池中线程抛了异常,该如何处理?
大家好,我是不才陈某~
在实际开发中,我们常常会用到线程池,但任务一旦提交到线程池之后,如果发生异常之后,怎么处理? 怎么获取到异常信息?在了解这个问题之前,可以先看一下 线程池的源码解析,从源码中我们知道了线程池的提交方式:submit和execute的区别,接下来分别使用他们执行带有异常的任务!看结果是怎么样的!
我们先用伪代码模拟一下线程池抛异常的场景:
运行结果:
可以看到:submit不打印异常信息,而execute则会打印异常信息!,submit的方式不打印异常信息,显然在生产中,是不可行的,因为我们无法保证线程中的任务永不异常,而如果使用submit的方式出现了异常,直接如上写法,我们将无法获取到异常信息,做出对应的判断和处理,所以下一步需要知道如何获取线程池抛出的异常!
推荐Java工程师技术指南:https://java-family.cn
submit()
想要获取异常信息就必须使用get()
方法!!
submit打印异常信息如下:
方案一:使用 try -catch
打印结果:
可以看到 submit 和 execute都清晰易懂的捕获到了异常,可以知道我们的任务出现了问题,而不是消失的无影无踪。关注公众号:码猿技术专栏,回复关键词:1111 获取阿里内部Java性能调优手册!
方案二:使用Thread.setDefaultUncaughtExceptionHandler
方法捕获异常
方案一中,每一个任务都要加一个try-catch
实在是太麻烦了,而且代码也不好看,那么这样想的话,可以用Thread.setDefaultUncaughtExceptionHandler
方法捕获异常
UncaughtExceptionHandler
是Thread类一个内部类,也是一个函数式接口。
推荐Java工程师技术指南:https://java-family.cn
内部的uncaughtException
是一个处理线程内发生的异常的方法,参数为线程对象t和异常对象e。
应用在线程池中如下所示:重写它的线程工厂方法,在线程工厂创建线程的时候,都赋予UncaughtExceptionHandler
处理器对象。
打印结果如下:
根据打印结果我们看到,execute方法被线程工厂factory中设置的 UncaughtExceptionHandler
捕捉到异常,而submit方法却没有任何反应!说明UncaughtExceptionHandler
在submit中并没有被调用。这是为什么呢?
在日常使用中,我们知道,execute和submit最大的区别就是execute没有返回值,submit有返回值。submit返回的是一个future ,可以通过这个future取到线程执行的结果或者异常信息。
从结果看出: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也是调用的execute,在execute方法中,我们的任务被提交到了addWorker(command, true)
,然后为每一个任务创建一个Worker去处理这个线程,这个Worker也是一个线程,执行任务时调用的就是Worker的run方法!run方法内部又调用了runworker方法!如下所示:
核心就在 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);
里面
将异常对象赋予outcome
有什么用呢?这个outcome
是什么呢?当我们使用submit返回Future对象,并使用Future.get()
时, 会调用内部的report方法!
reoport里面实际上返回的是outcome ,刚好之前的异常就set到了这个outcome里面
因此,在用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)
方法
重写afterExecute
处理execute提交的异常
执行结果:我们可以在afterExecute
方法内部对异常进行处理
如果要用这个afterExecute
处理submit提交的异常, 要额外处理。判断Throwable
是否是FutureTask
,如果是代表是submit提交的异常,代码如下:
处理结果如下:
可以看到使用重写afterExecute
这种方式,既可以处理execute抛出的异常,也可以处理submit抛出的异常
文章转载自公众号: 码猿技术专栏
