Java线程池异常处理

execute和submit都属于线程池的方法,execute只能提交Runnable类型的任务,而submit既能提交Runnable类型任务也能提交Callable类型任务。

execute会直接抛出任务执行时的异常,submit会吃掉异常,可通过Future的get方法将任务执行时的异常重新抛出。

execute所属顶层接口是Executor,submit所属顶层接口是ExecutorService,实现类ThreadPoolExecutor重写了execute方法,抽象类AbstractExecutorService重写了submit方法。

纠正下文错误:如果线程池execute提交任务,遇到报错(会直接抛出且可见)线程池会新建线程池处理任务保持核心线程数不变,如果采用submit提交即便出了异常也会被底层try catch且丢弃掉。

--------------------------------以下文章为转载---------------------------

自定义线程池MyThreadPoolExecutor执行任务的时候,如果任务报错,也不会被导致线程池被销毁。因为底层实现会把任务抛出的异常catch住且不打印。

假设我们有一个线程池,由于程序需要,我们向该线程池中提交了好多好多任务,但是 这些任务都没有对异常进行try catch处理,并且运行的时候都抛出了异常 。这会对线程池的运行带来什么影响?

正确答案是:没有影响。 这可不是好事情。

想一下,如果是你开发了一个线程池供开发者使用,你会不会对这种情况做处理?想想也是肯定的,不然你提供给别人使用的东西就是有问题的,欠考虑的。而且java线程池的主要开发人员是大名鼎鼎的Doug Lea,你觉得他开发的代码怎么会允许出现这种问题?

这个问题很棘手,因为它躺在角落里,程序正常运行的时候,它并不会出来作祟。

问题分析

接下来我们来看一下java中的线程池是如何运行我们提交的任务的,详细流程比较复杂,这里我们不关注,我们只关注任务执行的部分。java中的线程池用的是ThreadPoolExecutor,真正执行代码的部分是runWorker方法:final void runWorker(Worker w)

 

Java线程池异常处理_第1张图片

 

 

可以看到,程序会捕获包括Error在内的所有异常,并且在程序最后,将出现过的异常和当前任务传递给afterExecute方法。

而ThreadPoolExecutor中的afterExecute方法是没有任何实现的。

 protected void afterExecute(Runnable r, Throwable t) { }
复制代码

存在问题

想象下ThreadPoolExecutor这种处理方式会有什么问题?

这样做能够保证我们提交的任务抛出了异常不会影响其他任务的执行,同时也不会对用来执行该任务的线程产生任何影响。

问题就在afterExecute方法上, 这个方法没有做任何处理,所以如果我们的任务抛出了异常,我们也无法立刻感知到。 即使感知到了,也无法查看异常信息。

所以,作为一名好的开发者,是不应该允许这种情况出现的。

如何避免这种问题

思路很简单。

1、在提交的任务中将异常捕获并处理,不抛给线程池。

2、异常抛给线程池,但是我们要及时处理抛出的异常。

直接catch

第一种思路很简单,就是我们提交任务的时候,将所有可能的异常都Catch住,并且自己处理。

说白了就是把业务逻辑都trycatch起来。 但是这种思路的缺点就是: 1)所有的不同任务类型都要trycatch,增加了代码量。
2)不存在checkedexception的地方也需要都trycatch起来,代码丑陋。

线程池实现

第二种思路就可以避免上面的两个问题。

第二种思路又有以下四种实现方式

自定义线程池

自定义线程池,继承ThreadPoolExecutor并复写其afterExecute(Runnable r, Throwable t)方法。

 

Java线程池异常处理_第2张图片

 

 

实现Thread.UncaughtExceptionHandler接口

实现Thread.UncaughtExceptionHandler接口,实现void uncaughtException(Thread t, Throwable e);方法,并将该handler传递给线程池的ThreadFactory

 

Java线程池异常处理_第3张图片

 

 

继承ThreadGroup

覆盖其uncaughtException方法。(与第二种方式类似,因为ThreadGroup类本身就实现了Thread.UncaughtExceptionHandler接口)

尤其注意:上面三种方式针对的都是通过execute(xx)的方式提交任务,如果你提交任务用的是submit()方法,那么上面的三种方式都将不起作用,而应该使用下面的方式

 

Java线程池异常处理_第4张图片

 

 

采用Future模式

如果提交任务的时候使用的方法是submit,那么该方法将返回一个Future对象,所有的异常以及处理结果都可以通过future对象获取。 采用Future模式,将返回结果以及异常放到Future中,在Future中处理

 

Java线程池异常处理_第5张图片

 

 

总结

异常处理是java中非常重要的流程,但是线程池的默认操作,会使的这些内容被静悄悄的忽略,这在某些情况下是致命的。

文章探讨了从用户层面的代码到线程池层面的各种改造方法,力求让业务代码更加健壮可控。


作者:小姐姐味道
链接:https://juejin.im/post/5d27c3e6518825451f65ee15
来源:掘金
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

你可能感兴趣的:(JAVA技术,Java线程池异常处理,自定义线程池处理)