《阿布的点点滴滴》：”线程池玩出花来“之”急切的线程池“

正常线程池的处理流程大致：①核心线程数 -> ②线程数不小于核心线程数，入队列->③队列已满，使用最大线程数。如下图：

但有些场景当线程数不小于核心线程数时，要先达到最大线程数，再任务入队列。该如何实现？

看源码，当①offer失败，会使用最大线程数。所以可以在队列上做文章，当线程数不大于最大线程数时，即offer失败，此时的offer失败并不代表队列已满！

哪有这样的队列？ 没有自己实现，（有个小秘密我不告诉别人，dubbo的org.apache.dubbo.common.threadpool.support.eager.TaskQueue自己实现了，源码如下：）

很简单，继承了LinkedBlockingQueue，重写了offer方法。

题外话：细心地朋友看到后面有个retryOffer方法是干嘛的？原来是dubbo 在线程池的基础上，新增了重试的功能线程池：org.apache.dubbo.common.threadpool.support.eager.EagerThreadPoolExecutor

重点在执行拒绝策略后的代码，重新尝试offer ，若重试失败才算最终失败。

EagerThreadPoolExecutor：急切的线程池。形象生动的描述了”先将线程数先达到最大线程数，再入队列的业务场景“。

代码很简单，难的是发现问题，并敢于挑战源码并解决问题。