这一系列关于线程池的连环炮,就是我作为面试官时必问的几个问题。别问为什么,因为我们的招聘JD上明确写了:熟悉多线程编程。而这些问题,我觉得是熟悉多线程编程的基础。这里我也不解答了,这种文章网上还是挺多的,可以去了解一下。
这块真的很重要,我也多次给我的小伙伴强调:
来吧,一起分析一波
好了现在回到阿里的面试官问我的这道面试题:
一个线程池中的线程异常了,那么线程池会怎么处理这个线程?
先说说我当时的回答,因为心里没底,我的回答很犹豫也很烂!如下:
我的回答总结起来三句话:
1.抛出堆栈异常 —这句话对了一半!
2.不影响其他线程任务 —这句话全对!
3.这个线程会被放回线程池 —这句话全错!
测试用例写起来
抛出堆栈异常为啥对了一半?
先让程序跑起来,我们用事实说话:
从执行结果我们看出
当执行方式是execute时,可以看到堆栈异常的输出。
当执行方式是submit时,堆栈异常没有输出。
那么我们怎么拿到submit执行方式的堆栈异常呢,看图说话:
所以,现在知道为什么回答:抛出堆栈异常只对了一半吧。
execute方法执行时,会抛出(打印)堆栈异常。
submit方法执行时,返回结果封装在future中,如果调用future.get()方法则必须进行异常捕获,从而可以抛出(打印)堆栈异常。
你以为这一部分写到这里就完事了?那不行啊,你心里没有一个疑问吗?为啥execute直接抛出异常,submit没有直接抛出异常呢?
源码之下无秘密:
当执行方式是executes时:
在java.util.concurrent.ThreadPoolExecutor#runWorker中抛出了异常:
在_java.lang.ThreadGroup#uncaughtException_进行了异常处理:
这个uncaughtException是何许人也,看java doc上咋说的:
这个方法是JVM调用的,我们只需要指定我们想要的处理方式即可。
那我们怎么指定呢:
//直接new Thread()的时候
Thread t=newThread();
t.setUncaughtExceptionHandler(newThread.UncaughtExceptionHandler()
{publicvoiduncaughtException(Thread t, Throwable e){
//根据业务场景,做你想做的 }
});//线程池的时候:
ExecutorService threadPool = Executors.newFixedThreadPool(1, thread -> {
Thread t =newThread(thread);
t.setUncaughtExceptionHandler((t1, e) ->
System.out.println(“根据业务场景,做你想做的:”+ e.getMessage()));returnt;}
);
当执行方式是submit时:
其本质也是调用了execute方法,所以它还是回到_java.util.concurrent.ThreadPoolExecutor#runWorker_方法:
向前,继续跟进去看看:
_java.util.concurrent.FutureTask#setException_干啥了啊,瞅一眼:
深呼吸,整理好思路,我们马上走向最终的真相:
好了,第一个议题【抛出堆栈异常为啥对了一半?】讨论完毕。在源码里面走了一趟,现在我们可以给出这一部分的满分答案了。
不影响其他线程任务,回答正确
这一部分我们直接上代码,运行起来看结果吧:
代码和运行结果是不会骗人的:
线程池中一个线程异常了后,不影响其他线程任务
大家注意线程名称这个细节:1,2,3,4,6。魔鬼都在细节里啊,这个点我下面会讲,先在这里把问题抛出来:我就纳闷了,怎么没有5啊?!
这个线程会被放回线程池为啥全错了?
我们去源码里面寻找答案:
让源码给出答案:
5号线程去哪里了?
new Worker()方法会告诉你:5去哪里了。
再配上这张由我这个灵魂画师亲自操刀画的图,一起食用,味道更佳:
现在知道为啥:我回答这个线程会被放回线程池为啥全错了吧。还附带送你一个线程名称变化的细节,不客气。
总结一下
食用,味道更佳:[外链图片转存中…(img-MtrIpDWn-1726044800012)]
现在知道为啥:我回答这个线程会被放回线程池为啥全错了吧。还附带送你一个线程名称变化的细节,不客气。