突然就懵了！面试官问我：线程池中多余的线程是如何回收的

实际上是不会的。为了防止这种情况，compareAndDecrementWorkerCount© 用的是CAS方法，如果CAS失败就continue，进入下一轮循环，重新判断。

像上述例子，其中一条线程会CAS失败，然后重新进入循环，发现工作线程数已经只有4了，timed为false, 这条线程就不会被销毁，可以一直阻塞了（workQueue.take())。

这一点我思考了很久才得出答案，一直在想没有加锁的情况下是怎么保证一定能不多不少回收到核心线程数的呢。原来是CAS的奥妙。

从这里也可以看出，虽然有核心线程数，但线程并没有区分是核心还是非核心，并不是先创建的就是核心，超过核心线程数后创建的就是非核心，最终保留哪些线程，完全随机。

3.2 调用shutdown() ，全部任务执行完成的场景

这种场景，无论是核心线程还是非核心线程，所有工作线程都会被销毁。

在调用shutdown()之后，会向所有的空闲工作线程发送中断信号。

最终传入false，调用下面这个方法。

可以看出，在发出中断信号前，会判断是否已经中断，以及要获得工作线程的独占锁。

发出中断信号的时候，工作线程要么在getTask()里准备获取任务，要么在执行任务，那就得等它执行完当前任务才会发出，因为工作线程在执行任务的时候，也会工作线程加锁。工作线程执行完任务，又跑到getTask()里面去了。

所以我们只要看getTask()里面怎么应对中断异常的就可以了。

工作线程在getTask()里，有两种可能。

3.2.1 任务已全部完成，线程在阻塞等待。

很简单，中断信号将其唤醒，从而进入下一轮循环。到达条件1处，符合条件，减少工作线程数量，并返回null，由外层结束这条线程。

这里的decrementWorkerCount()是自旋式的，一定会减1。

3.2.2 任务还没有完全执行完

调用shutdown()之后，未执行完的任务要执行完毕，池子才能结束。所以此时有可能线程还在工作。

这里又要分两个阶段讨论

阶段1 任务较多，工作线程都能获得任务

这里还不涉及到线程退出，可以跳过不看，只是分析一下收到中断信号后线程的表现。

假设有线程A，正通过getTask()里获取任务。此时A被中断，在获取任务时，无论是poll()还是take()，都会抛出中断异常。异常被捕获，重新进入下一轮循环，只要队列不为空，就可以继续取任务。

线程A被中断，再次取任务，调用workQueue.poll() or workQueue.take()，不会抛出异常吗？还可以正常取出任务吗？

这就要看workQueue的实现了。workQueue是BlockingQueue类型，以常见的LinkedBlockingQueue和ArrayBlockingQueue为例，加锁时都是调用lockInterruptibly()，是响应中断的。该方法又调用了AQS的acquireInterruptibly(int arg)。

acquireInterruptibly(int arg)，无论是在入口处判断中断异常，还是在parkAndCheckInterrupt()方法阻塞，被中断唤醒并判断中断异常时，均使用了Thread.interrupted()。这个方法会返回线程的中断状态，并把中断状态重置！也就是说，线程不再是中断状态了，这样在再次取任务时，就不会报错了。

因此，这对于正在准备取任务的线程，只是相当于浪费了一次循环，这可能是线程中断带来的副作用吧，当然，对整体的运行不影响。

分析到这里，我不禁感叹，这里BlockingQueue刚好是会重置中断状态，这到底是怎么想出来的绝妙设计啊？Doug Lea大神Orz.

阶段2 任务刚好要执行完了

这时任务已经快取完了，比如有4条工作线程，只剩下2个任务，那就可能出现2条线程获得任务，2条线程阻塞。

因为在获取任务前的判断，没有加锁，那么会不会出现，所有线程都通过了前面的校验，来到workQueue获取任务的地方，刚好任务队列已经空了，线程全部阻塞了呢？因为shutdown() 已经执行完毕，无法再向线程发出中断信号，从而线程一直在阻塞，无法被回收。

这种是不会发生的。

假设有A,B,C,D四条工作线程，同时通过了条件1和条件2的判断，来到取任务的地方。那么，工作队列至少还有一个任务，至少会有一条线程能取到任务。

假设A，B获得了任务，C,D阻塞。

A, B接下来的步骤是：

step1.任务执行完成后，再次getTask()，此时符合条件1，返回null，线程准备被回收。

step2.processWorkerExit(Worker w, boolean completedAbruptly) 将线程回收。

回收就只是把线程干掉这么简单吗？来看看processWorkerExit(Worker w, boolean completedAbruptly) 的方法。

可以看到，在里面除了workers.remove(w) 移除线，还调用了tryTerminate()。

第一个判断条件没有一个子条件符合，跳过。第二个条件，工作线程还存在，那么随机中断一条空闲线程。

那么问题就来了，中断一条空闲线程，也没说是一定中断正在阻塞的线程啊。如果A, B同时退出，有没有可能出现A中断B, B中断A，AB互相中断，从而没有线程去中断唤醒阻塞的线程呢？

答案仍然是，想多了……

假设A能走到这里，说明A已经从工作线程的集合workers里面移除了（processWorkerExit(Worker w, boolean completedAbruptly) 在tryTerminate()之前，已经将其移除）。那么A中断B，B来到这里中断，就不会在workers里面找到A了。

也就是说，退出的线程不能互相中断，我从集合中退出后，中断了你，你不能中断我，因为我已经退出集合，你只能中断别人。那么，即使有N个线程同时退出，至少在最后，也会有一条线程，会中断剩余的阻塞线程。

自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数Java工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年Java开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Java开发知识点，真正体系化！

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！

如果你觉得这些内容对你有帮助，可以扫码获取！！（备注Java获取）

总结

其他的内容都可以按照路线图里面整理出来的知识点逐一去熟悉，学习，消化，不建议你去看书学习，最好是多看一些视频，把不懂地方反复看，学习了一节视频内容第二天一定要去复习，并总结成思维导图，形成树状知识网络结构，方便日后复习。

这里还有一份很不错的《Java基础核心总结笔记》，特意跟大家分享出来

目录：

部分内容截图：

《一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频+实战项目源码》，点击传送门即可获取！
片转存中…(img-kSueV0Kb-1712497115247)]
《一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频+实战项目源码》，点击传送门即可获取！