Dubbo 线程池

这里再扩展一个 Dubbo 的线程池实现。

org.apache.dubbo.common.threadpool.support.eager.EagerThreadPoolExecutor

你可以看一下，思想还是这个思想：

但是 execute 方法有点不一样：

从代码上看，这里放入失败之后又立马调了一次 offer 方法，且没有等待时间。

也就是说两次 offer 的间隔是非常的短的。

其实我不太明白为什么这样去写，可能是作者留着口子好扩展吧？

因为如果这样写，为什么不直接调用这个方法呢？

java.util.concurrent.LinkedBlockingQueue#offer(E)

也是作者是想在极短的时间能赌一下吧？谁知道呢？

然后可以发现该线程池在拒绝策略上也做了很大的文章：

可以看到日志打印的非常详尽，warn 级别：

dumpJStack 方法，看名字也知道它是要去 Dump 线程了，保留现场：

在这个方法里面，他用了 JDK 默认的线程池，去异常 Dump 线程。

等等，阿里开发规范不是说了不建议用默认线程池吗？

其实这个规范看你怎么去拿捏。在这个场景下，用自带的线程池就能满足需求了。

而且你看第二个红框：提交之后就执行了 shutdown 方法，上面还给了个贴心警告。

必须要 shutdown 线程池，不然会导致 OOM。

这就是细节呀，朋友们。魔鬼都在细节里！

这里为什么用的 shutdown 不是 shutdownNow ？他们的区别是什么？为什么不调用 shutdown 方法会 OOM？

知识点呀，朋友们，都是知识点啊！

好了，到这里本文的分享也到了尾声。

以后当面试官问你 JDK 线程池的运行流程的时候，你答完之后画风一转，再来一个：

其实我们也可以先把最大线程数用完，然后再让任务进入队列。通过自定义队列，重写其 offer 方法就可以实现。目前我知道的 Tomcat 和 Dubbo 都提供了这样策略的线程池。

轻描淡写之间又装了一个漂亮逼。让面试官能进入下一个知识点，让你能更多的展现自己。

最后说一句（求关注）

本文主要介绍了 Tomcat 线程池的运行流程，和 JDK 线程池的流程比起来，它确实不一样。

而 Tomcat 线程池为什么要这样做呢？

其实就是因为 Tomcat 处理的多是 IO 密集型任务，用户在前面等着响应呢，结果你明明还能处理，却让用户的请求入队等待？

这样不好，不好。

说到底，又回到了任务类型是 IO 密集型还是 CPU 密集型这个话题上来。

有兴趣的可以看看我的这篇文章：《如何设置线程池参数？美团给出了一个让面试官虎躯一震的回答。》

点个赞吧，周更很累的，不要白嫖我，需要一点正反馈。

感谢您的阅读，我坚持原创，十分欢迎并感谢您的关注。

我是why技术，一个不是大佬，但是喜欢分享，又暖又有料的四川好男人。

欢迎关注公众号【why不止技术】,坚持输出原创。分享技术、品味生活，愿你我共同进步。