五年前，我写错了一道面试题。 - why技术
source link: https://www.cnblogs.com/thisiswhy/p/18150414
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
五年前，我写错了一道面试题。
你好呀，我是歪歪。
事情是这样的，上周有个读者找我，给我抛出了这样的一个问题：
问题中涉及到的文章分别是这两篇：
我自己写的这篇文章，虽然是五年前，2019 年的文章：
（卧槽，2019 年已经是五年前了）
但是毕竟是自己一个字一个字敲出来的，大概内容还是记得。
主要就是讨论了我在面试的时候遇到的这个问题：
一个线程池中的线程异常了，那么线程池会怎么处理这个线程?
当时我的回答是这样的：
在文章里面，我把我的回答总结成了三句话：
- 1.抛出堆栈异常 ---这句话对了一半！
- 2.不影响其他线程任务 ---这句话全对！
- 3.这个线程会被放回线程池---这句话全错！
然后我的文章就基于上面这三句话展开了。
过程就不再赘述了，这次只讨论我五年前的文章中说错的一个点：这个（异常的）线程会被放回线程池。
当时我的结论是这句话全错了，正确的描述应该是：
（当一个线程池里面的线程异常后，）线程池会把这个线程移除掉，并创建一个新的线程放到线程池中。
对于同样的问题，京东技术的结论是这样的：
- 当执行方式是 execute 时,可以看到堆栈异常的输出，线程池会把这个线程移除掉，并创建一个新的线程放到线程池中。
- 当执行方式是 submit 时,堆栈异常没有输出。但是调用 Future.get() 方法时，可以捕获到异常，不会把这个线程移除掉，也不会创建新的线程放入到线程池中。
歪师傅的结论是一概而论，京东技术则是分情况讨论。
首先，京东技术的结论是正确的。
其次，歪师傅当年写这个文章的时候，就是技不如人，就是写错了，就是情况没有分析完整。
只看了 execute 的情况，导致得出了一个“只对了一半的答案”。
而关于使用 submit 方法时，如果在线程中抛出了异常，为什么不创建新的线程，而是继续复用原线程的原因，京东技术也从源码的角度解析了。
歪师傅这里也赘述一下。
问题的关键就是要抓到关键的问题。
那么在这个问题中，关键的问题是什么？
就是移除线程的方法在哪儿。
对应到源码其实就是这里：
java.util.concurrent.ThreadPoolExecutor#processWorkerExit
那么其实关键点就是这个方法在哪儿，在什么情况下会被调用到？
对应的源码在这里：
java.util.concurrent.ThreadPoolExecutor#runWorker
通过源码我们可以知道，在抛出异常的情况下，该方法会被调用到。
而 try 部分就只有一行代码：
task.run();
那么能耍花招的地方就只能是 task 这个对象了。
比如这样的代码，当 execute 方法执行的时候，这就是一个原生的 Thread 线程：
该方法是否会抛出异常，取决于你代码是否会抛出异常。
比如这样去写，线程执行 sayHi 方法的时候就会抛出异常：
而这样去写，则不会抛出异常：
所以，你再去看京东技术的结论：
execute 提交到线程池的方式，如果执行中抛出异常，并且没有在执行逻辑中 catch，那么会抛出异常，并且移除抛出异常的线程，创建新的线程放入到线程池中。
特别提到了 catch。
但是 submit 的时候，是怎么回事呢？
task 从一个普通线程变成了 FutureTask 对象：
因为源码在这里玩个了个小花招：
java.util.concurrent.AbstractExecutorService#submit(java.lang.Runnable)
把 task 包装成了 FutureTask 对象。
而一切的秘密就藏在 FutureTask 对象的 run 方法中：
java.util.concurrent.FutureTask#run
异常之后，会调用 setException 方法，仅仅是把异常放在了 outcome 字段中，然后维护了 FutureTask 的状态，不会继续往外抛出异常。
如果需要获取异常，则需要调用 get 方法。
好，现在我要开始闭环了。
因为 submit 提交的时候会把任务封装为 FutureTask 对象，该对象重写了 run 方法，所以当任务异常之后，不会继续往外抛出异常。
因为不会继续往外抛出异常，所以不会走到 processWorkerExit 方法。
因为不会走到 processWorkerExit 方法，所以不涉及移除线程和添加线程的逻辑。
当执行方式是 submit 时，不会把这个线程移除掉，也不会创建新的线程放入到线程池中。
其实整体逻辑还是很清楚的，当年就是分析漏了 submit 的情况，导致最终的结论不对。
五年前我挖了个坑，五年后，我把这个坑填一下。
然后再回答一个京东技术那篇文章下留言区的一个问题：
execute 执行无论是否抛出异常，finally 块中代码不是都会执行吗？
也就是这段代码：
如果你只看这部分 try 和 finally 代码块，我们学习 Java 的时候，如果老师没有骗我们的话，那么不管是正常执行完成 try 里面的代码，还是 try 里面的代码抛出异常， finally 代码块的代码理论上都是会执行的。
是的，这一个知识点没有任何毛病。
但是，你注意我是怎么说的“不管是正常执行完成还是抛出异常”。
抛出异常我们前面已经分析了，提问者的疑问点在于“正常执行完成”为什么不会执行 finally 代码块里面的 processWorkerExit 方法。
我的答案是：会。
但是，try 里面要正常执行完成，也就是 while 循环要正常结束，所以你看看一眼循环条件中的这个部分，要返回 null 才满足条件：
getTask 对应的源码是这样的：
java.util.concurrent.ThreadPoolExecutor#getTask
在我们讨论的场景下，线程是会阻塞在队列的 poll 或者 take 方法这里的。
如果是 take 方法就不说了，不会返回 null，在这里死等。
如果是 poll 方法返回了 null，则说明该线程到了超时时间还未从队列中获取到任务。
这个时候该怎么办？
翻翻八股文看看，如果线程池设置了 allowCoreThreadTimeOut 为 true，针对核心线程，在指定时间内未获取到任务或者非核心线程在指定时间内未获取到任务的时候，线程池会怎么处理？
是不是说的该销毁了，该从线程池中移走了？
所以，才会走到 processWorkerExit 执行 workers.remove(w) 方法。
是不是感觉自己又能行了，知识点又串起来了。
当读者问我“是复用还是移除”这个问题的时候，我当时确实不知道答案。
但是我一点都不慌，因为我知道去哪里找答案。
如果我真的需要想要知道答案的话，在不借助任何搜索工具，仅仅给我源码的情况下，我应该很快就能得到一个准确的答案。
这一点自信的底气是因为我确实较为深入的研究过这部分源码。
但是当时我没有去寻找答案，结合我对于线程池的理解，我在思考另外一个问题：这重要吗？
你仔细想一想，如果这个问题抛出来之后你直接就是一头雾水，或者说和我一样知道去哪里找答案，那么这个问题的准确回答对你来说真的重要吗？
不管是那种情况都不重要，一点都不重要。
因为不管是销毁还是复用，它完全不影响你对于线程池的使用。
重要的是，在一头雾水的情况下，自己去寻找问题的答案的这个过程。
你当然可以拿着关键字去网上搜，肯定能搜到答案，这是一个寻找的过程，不过是轻松一点，然后遗忘起来快一点。
你也可以带着问题去翻源码，这也是一个寻找的过程，不过是难一点而已，记忆深刻一点。
如果觉得直接啃源码啃不动，那就结合网上的资料一起食用，这同样是一个寻找的过程。
等你真的找到这个问题的标准答案的时候、等你进一步理解线程池的时候，你会发现这个问题的答案不重要，但是在寻找的过程中你写的 Demo、接触到的源码、方法之间的调用关系、分支判断逻辑、查阅到的资料、付出的时间和对应的收获、甚至是内心中转瞬即逝的开心...
这些是重要的。
这个题其实是一个陷阱。
就像是我们读书的时候做的数学题，我们都知道参考答案就在练习册的最后几页，照着参考答案抄就能回答正确。
但是我们都知道比起正确答案来说，更重要的是你知道解题的过程。
最可怕的情况是你抄答案的次数多了，对自己产生了错误的认知，让你在抄答案的过程中还产生了这题很简单，自己也会做的错觉。
只有见过了无数千奇百怪的题目，摸熟了无数个解题的套路，当你在这个过程中，在某个瞬间体会到了“万变不离其宗”的时候，在自信心经历过建立、崩塌、再建立的过程后，在把参考答案真的只是当做参考的时候，你就可以淡定的说出：哦，这题啊，我没见过，但是我知道怎么去做。
就像是五年前我拿到这个题的时候，我经过一番研究，还是答错了。
五年后，再次遇到这个题的瞬间，我还是不知道答案，但是我的内心一点都不慌。
在学习编程的路上，这样的“陷阱题”真的太多太多了，难的不是回答出你被背下的标准答案，难的是你知道标准答案是怎么来的。
这就是我从“是复用还是移除”这个问题带给我的思考。
我觉得我其实是在试图给你阐述一种学习的方法，因为我也没有悟透，所以总感觉有点词不达意，但是我想要表述的都说完了，剩下的，我自己接着悟吧。
翻了一下，我过往还是写了很多线程相关的文章的。
都放在这里，作为一个合订版吧：
《如何设置线程池参数？美团给出了一个让面试官虎躯一震的回答。》
《每天都在用，但你知道 Tomcat 的线程池有多努力吗？》
《虽然是我遇到的一个棘手的生产问题，但是我写出来之后，就是你的了。》
《1000 多个并发线程，10 台机器，每台机器 4 核，设计线程池大小。》
《Doug Lea在J.U.C包里面写的BUG又被网友发现了。》
《“借助同步”这个理念在 FutureTask 里面的应用。》
《喜提JDK的BUG一枚！多线程的情况下请谨慎使用这个类的stream遍历。》
《面试官：一个 SpringBoot 项目能处理多少请求？（小心有坑）》
《这里有线程池、局部变量、内部类、静态嵌套类和一个莫得名堂的引用，哦，还有一个坑！》
如果里面的某一篇曾经帮助过你，安排一个一键三连就行了。
Recommend
-
69
2018-01-20 13:12 五年前的截屏，如今刷屏上头条那一次的讨论过程到今天依然还是有很深印象的。而印象最深之处，并不是入口是不是二维码。而是Allen 2点多还在思考。5年之后，我发现，这...
-
23
很少人愿意去回溯，到底一件事从想法到现实，经历了怎么样的思考和判断，以及自我完善的过程。
-
48
岛国推上著名的“击掌猫“Shijimi，五年前它被动物保护团体救下，来到主人家中，如今凭借萌到犯规的“夺命可爱HighFive拳”走红...
-
80
【空间的压榨性使用，这个 32㎡平小户型太高能】屋主在五年前购入的32㎡一居室，原始户型是老公房传统「一字型」套路，狭长的户型让厨卫空间和客厅采光很差，收纳空间也非常有限。屋主装修时尽量避免了隔墙，阳台的隔断采取了全透明的落地玻璃移门，还...
-
49
说一说我解救学生自杀的经历。大约四五年前，我教一届高中，有个学生很阳光很热情，然而这个学生的自杀倾向被我知道了，这并非偶然：我有三次自杀经历，一次未遂，一次被干预治疗，还有一次被同事拦下，因此我总是对这类冲动和隐约的不详气氛格外敏感...
-
28
新浪财经讯6月8日晚，456万美元拍下今年巴菲特午餐的90后孙宇晨突然晒出一张微信朋友圈截图称：听说王思聪骂我？据孙宇晨晒出的截图，王思聪在朋友圈转发了一篇《孙宇晨巴菲特的餐桌上全是“韭菜”》的文章，并表示“这不就是个傻X”。对此，孙宇晨回
-
23
有那么一些已经老去的产品，它们也许早已淡出人们的视线，但每每想到却令我们充满回忆。作为极客之选（微信号 GeekChoice）怀旧栏目，《极客博物馆》希望找到这些曾经带给我们惊喜和感动的产品，带你重拾它们迷人的特质。 自从手...
-
21
平时对电脑关注比较多的小伙伴们应该知道，一直以来，同样硬件配置下的苹果电脑通常会比其它品牌的笔记本电脑要贵上不少。别问（为什么），问就是它做工优秀、经久耐用。
-
6
独家｜知情人披露美团点评合并案内幕: 王兴五年前的惊险一跃 “这可能也是中国商业史上最戏剧性的一幕。”5月18日，上海，偶然的一个...
-
1
五年前的今天：苹果不同寻常的道歉 开启了Mac的复兴之路 2022年04月05日08:56 新浪数码 我有话说(41人参与) 收藏本...
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK