Dubbo 源码分析之线程池

版权声明：本文为博主原创文章 http://blog.csdn.net/su20145104009 https://blog.csdn.net/su20145104009/article/details/86549936

前言

相信学过 netty 的都知道，每一个 ChannelHandler 都是通过它的 EventLoop(I/O线程) 来处理传递给它的事件，所以至关重要的是不要阻塞这个线程，因为这会对整体的 I/O 产生负面的影响。Dubbo 亦是如此，所以 Dubbo 定义了一些线程池，来供我们异步处理事件。

Dubbo 线程池分类

在 Dubbo-2.6.5 版本中共有三个线程池

• CachedThreadPool
• FixedThreadPool
• LimitedThreadPool

而在 GitHub 上 Dubbo 的最新源码中又提供了一个新的线程池

• EagerThreadPool

是不是很熟悉，除了 EagerThreadPool，别的线程池好像 java.util.concurrent.Executors 都为我们提供了。只不过 Dubbo 自己又实现了一下，调整下自定义参数（对线程池不熟悉的请查看为这篇文章：JAVA线程池ThreadPoolExecutor详解）

Dubbo 线程工厂

在看线程池之前先看一下 Dubbo 自定义的线程池工厂

public class NamedThreadFactory implements ThreadFactory {

	// 自增 线程池序号
    protected static final AtomicInteger POOL_SEQ = new AtomicInteger(1);
	// 线程池中 线程自增序号
    protected final AtomicInteger mThreadNum = new AtomicInteger(1);
	// 线程池名称前缀
    protected final String mPrefix;
	// 是否设置为守护线程
    protected final boolean mDaemon;
	// 所在线程组
    protected final ThreadGroup mGroup;
	// 默认非守护线程 即：用户线程
    public NamedThreadFactory() {
        this("pool-" + POOL_SEQ.getAndIncrement(), false);
    }
	
    public NamedThreadFactory(String prefix) {
        this(prefix, false);
    }

    public NamedThreadFactory(String prefix, boolean daemon) {
        mPrefix = prefix + "-thread-";
        mDaemon = daemon;
        SecurityManager s = System.getSecurityManager();
        mGroup = (s == null) ? Thread.currentThread().getThreadGroup() : s.getThreadGroup();
    }

    @Override
    public Thread newThread(Runnable runnable) {
        String name = mPrefix + mThreadNum.getAndIncrement();
        Thread ret = new Thread(mGroup, runnable, name, 0);
        ret.setDaemon(mDaemon);
        return ret;
    }

    public ThreadGroup getThreadGroup() {
        return mGroup;
    }
}

该线程工厂为我们的线程池创建了名称，为线程创建了名称，方便我们查看堆栈信息时进行 debug ，线程为守护/用户的决定权由使用者决定。
上面的线程工厂是在 Dubbo-2.6.5 版本中的源码
其实在 GitHub 上 Dubbo 的最新源码中为该线程工厂又封装了一层

public class NamedInternalThreadFactory extends NamedThreadFactory {

    public NamedInternalThreadFactory() {
        super();
    }

    public NamedInternalThreadFactory(String prefix) {
        super(prefix, false);
    }

    public NamedInternalThreadFactory(String prefix, boolean daemon) {
        super(prefix, daemon);
    }

    @Override
    public Thread newThread(Runnable runnable) {
        String name = mPrefix + mThreadNum.getAndIncrement();
        InternalThread ret = new InternalThread(mGroup, runnable, name, 0);
        ret.setDaemon(mDaemon);
        return ret;
    }
}

看着好像并没有做什么，其实细节都在 newThread 方法里，会发现我们在父类 NamedThreadFactory 中是直接使用的 new Thread ，而在这里使用的是 new InternalThread，有什么区别呢？仔细看看 InternalThread 也就是重新封装了一下 Thread ，好像什么都没做。其实作用这这里是看不出来的，看过 Netty 源码的可能知道 Netty 有个 FastThreadLocal FastThreadLocalThread，Dubbo 在这里也是如此，借鉴了 Netty 源码。要说 FastThreadLocal 和 ThreadLocal 什么区别，请移步我的这篇文章Java源码之ThreadLocal，在这里我就不多废话了。

线程池拒绝策略

Dubbo 也重写了线程池拒绝策略，主要操作就是在线程池拒绝时保存堆栈信息到文件。具体可以看我分析的这篇文章 Dubbo 源码分析之自定义线程池拒绝策略，这里不再详细介绍。

下面开始看线程池

CachedThreadPool

public class CachedThreadPool implements ThreadPool {

    public Executor getExecutor(URL url) {
    	//线程池名称前缀  默认:Dubbo 
        String name = url.getParameter(Constants.THREAD_NAME_KEY, Constants.DEFAULT_THREAD_NAME);
        //核心线程数 默认:0
        int cores = url.getParameter(Constants.CORE_THREADS_KEY, Constants.DEFAULT_CORE_THREADS);
        // 最大线程数 默认:Integer.MAX_VALUE
        int threads = url.getParameter(Constants.THREADS_KEY, Integer.MAX_VALUE);
        //阻塞队列大小 默认:0
        int queues = url.getParameter(Constants.QUEUES_KEY, Constants.DEFAULT_QUEUES);
        //线程存活时间 默认:60s
        int alive = url.getParameter(Constants.ALIVE_KEY, Constants.DEFAULT_ALIVE);
        return new ThreadPoolExecutor(cores, threads, alive, TimeUnit.MILLISECONDS, 
        		queues == 0 ? new SynchronousQueue<Runnable>() : 
        			(queues < 0 ? new LinkedBlockingQueue<Runnable>() 
        					: new LinkedBlockingQueue<Runnable>(queues)),
        		new NamedThreadFactory(name, true), new AbortPolicyWithReport(name, url));
    }
}

所谓 CachedThreadPool，就是线程池会伸缩，当事件较多时创建新的线程，事件较少时，超出一定时间回收线程。

注意：其实此 CachedThreadPool 并不是正经的 cache，可能大家发现了该线程池的阻塞队列虽然默认是 SynchronousQueue，但是如果用户配置了 queues 变量，且其值较大，使用的阻塞队列就是 LinkedBlockingQueue，此时一旦 corethreads 再使用默认值0，就会导致处理事件阻塞。

FixedThreadPool

public class FixedThreadPool implements ThreadPool {

    public Executor getExecutor(URL url) {
        String name = url.getParameter(Constants.THREAD_NAME_KEY, Constants.DEFAULT_THREAD_NAME);
        int threads = url.getParameter(Constants.THREADS_KEY, Constants.DEFAULT_THREADS);
        int queues = url.getParameter(Constants.QUEUES_KEY, Constants.DEFAULT_QUEUES);
        return new ThreadPoolExecutor(threads, threads, 0, TimeUnit.MILLISECONDS, 
        		queues == 0 ? new SynchronousQueue<Runnable>() : 
        			(queues < 0 ? new LinkedBlockingQueue<Runnable>() 
        					: new LinkedBlockingQueue<Runnable>(queues)),
        		new NamedThreadFactory(name, true), new AbortPolicyWithReport(name, url));
    }

}

FixedThreadPool 表示核心线程和最大线程大小都为固定值，在 Dubbo 中的确也是这么处理的，但是这里还有要注意的地方。

注意：如果使用 fixed 线程池，默认的线程池数量为200，默认阻塞队列大小为0，默认使用的阻塞队列为SynchronousQueue。如果你的业务事件并发较高或者处理时间较长，请适当调整阻塞队列大小，即 queues 变量，否则会导致大量请求被丢弃。该线程池也是 Dubbo 默认使用的线程池，估计出事的挺多。

LimitedThreadPool

public class LimitedThreadPool implements ThreadPool {

    public Executor getExecutor(URL url) {
        String name = url.getParameter(Constants.THREAD_NAME_KEY, Constants.DEFAULT_THREAD_NAME);
        int cores = url.getParameter(Constants.CORE_THREADS_KEY, Constants.DEFAULT_CORE_THREADS);
        int threads = url.getParameter(Constants.THREADS_KEY, Constants.DEFAULT_THREADS);
        int queues = url.getParameter(Constants.QUEUES_KEY, Constants.DEFAULT_QUEUES);
        return new ThreadPoolExecutor(cores, threads, Long.MAX_VALUE, TimeUnit.MILLISECONDS, 
        		queues == 0 ? new SynchronousQueue<Runnable>() : 
        			(queues < 0 ? new LinkedBlockingQueue<Runnable>() 
        					: new LinkedBlockingQueue<Runnable>(queues)),
        		new NamedThreadFactory(name, true), new AbortPolicyWithReport(name, url));
    }

}

这个线程池就比较有意思的，该线程池中的线程数可以一直增长到上限，永不回收，其实永不回收是个伪概念，查看代码可以发现，该线程设置线程的回收时间限制为 Long.MAX_VALUE，可以理解为永久不回收。这个如果说要注意的那就只有一点，因为线程池是不回收的，所以 threads 变量即线程最大限制的值不能太大，使用默认 200 即可，避免 OOM.

EagerThreadPool

注：此线程池在dubbo-2.6.5及其以下没有实现

首先介绍一下该线程池：线程池中的所有核心线程都在忙碌时，此时如果再添加新的任务不会放入阻塞队列，而且创建新的线程，直到达到最大线程限制，此时如果还有任务，才会放入阻塞队列。

public class EagerThreadPool implements ThreadPool {

    @Override
    public Executor getExecutor(URL url) {
        String name = url.getParameter(Constants.THREAD_NAME_KEY, Constants.DEFAULT_THREAD_NAME);
        int cores = url.getParameter(Constants.CORE_THREADS_KEY, Constants.DEFAULT_CORE_THREADS);
        int threads = url.getParameter(Constants.THREADS_KEY, Integer.MAX_VALUE);
        int queues = url.getParameter(Constants.QUEUES_KEY, Constants.DEFAULT_QUEUES);
        int alive = url.getParameter(Constants.ALIVE_KEY, Constants.DEFAULT_ALIVE);

        // init queue and executor
        TaskQueue<Runnable> taskQueue = new TaskQueue<Runnable>(queues <= 0 ? 1 : queues);
        EagerThreadPoolExecutor executor = new EagerThreadPoolExecutor(cores,
                threads,
                alive,
                TimeUnit.MILLISECONDS,
                taskQueue,
                new NamedInternalThreadFactory(name, true),
                new AbortPolicyWithReport(name, url));
        taskQueue.setExecutor(executor);
        return executor;
    }
}

大致规规矩矩，和上面一样，里面好像有两个我们没有见过的类 TaskQueue 和 EagerThreadPoolExecutor 。

先看一下自定义阻塞队列 TaskQueue

public class TaskQueue<R extends Runnable> extends LinkedBlockingQueue<Runnable> {

    private static final long serialVersionUID = -2635853580887179627L;

    private EagerThreadPoolExecutor executor;

    public TaskQueue(int capacity) {
        super(capacity);
    }

    public void setExecutor(EagerThreadPoolExecutor exec) {
        executor = exec;
    }
	// 重写 offer 操作
    @Override
    public boolean offer(Runnable runnable) {
        if (executor == null) {
            throw new RejectedExecutionException("The task queue does not have executor!");
        }

        int currentPoolThreadSize = executor.getPoolSize();
        // 小于核心线程数 直接调用父类offer
        if (executor.getSubmittedTaskCount() < currentPoolThreadSize) {
            return super.offer(runnable);
        }

        // 返回失败使线程池新建线程来执行任务 伪装阻塞队列已满
        if (currentPoolThreadSize < executor.getMaximumPoolSize()) {
            return false;
        }

        // currentPoolThreadSize >= max
        return super.offer(runnable);
    }

   	// 重试 offer 操作
    public boolean retryOffer(Runnable o, long timeout, TimeUnit unit) throws InterruptedException {
        if (executor.isShutdown()) {
            throw new RejectedExecutionException("Executor is shutdown!");
        }
        return super.offer(o, timeout, unit);
    }
}

最主要的逻辑就是在重写的 offer 方法里面，通过重写该方法可以在我们向线程池提交任务时，伪装阻塞队列已满，来使线程池新建线程执行任务。

贴上一段 ThreadPoolExecutor 类的 execute 代码

 public void execute(Runnable command) {
         /*如果提交的任务为null  抛出空指针异常*/
        if (command == null)
            throw new NullPointerException();

        int c = ctl.get();
        /*如果当前的任务数小于等于设置的核心线程大小，那么调用addWorker直接执行该任务*/
        if (workerCountOf(c) < corePoolSize) {
            if (addWorker(command, true))
                return;
            c = ctl.get();
        }
        /*如果当前的任务数大于设置的核心线程大小，而且当前的线程池状态时运行状态，那么向阻塞队列中添加任务*/
        if (isRunning(c) && workQueue.offer(command)) {
            int recheck = ctl.get();
            if (! isRunning(recheck) && remove(command))
                reject(command);
            else if (workerCountOf(recheck) == 0)
                addWorker(null, false);
        }
        /*如果向队列中添加失败，那么就新开启一个线程来执行该任务*/
        //tip:最主要的就是这里 当向阻塞队列插入失败时，会直接调用 addWorker 方法，创建新的线程执行任务
        else if (!addWorker(command, false))
            reject(command);
    }

想具体了解细节的可以查看我的这篇博客 线程池(ThreadPoolExecutor)源码分析之如何保证核心线程不被销毁的。
通过 ThreadPoolExecutor 源码可以发现，当向阻塞队列插入失败时，会直接调用 addWorker 方法，创建新的线程执行任务。现在就和重写的 TaskQueue 的 offer 方法对上了。

那就继续看 EagerThreadPoolExecutor 类。

// 继承ThreadPoolExecutor
public class EagerThreadPoolExecutor extends ThreadPoolExecutor {

   	// 任务数量
    private final AtomicInteger submittedTaskCount = new AtomicInteger(0);

    public EagerThreadPoolExecutor(int corePoolSize,
                                   int maximumPoolSize,
                                   long keepAliveTime,
                                   TimeUnit unit, TaskQueue<Runnable> workQueue,
                                   ThreadFactory threadFactory,
                                   RejectedExecutionHandler handler) {
        super(corePoolSize, maximumPoolSize, keepAliveTime, unit, workQueue, threadFactory, handler);
    }

    // 返回正在执行的任务数量
    public int getSubmittedTaskCount() {
        return submittedTaskCount.get();
    }

	// ThreadPoolExecutor 模版方法 任务执行完成之后会调用
    @Override
    protected void afterExecute(Runnable r, Throwable t) {
        submittedTaskCount.decrementAndGet();
    }

	// 重写 execute 方法
    @Override
    public void execute(Runnable command) {
        if (command == null) {
            throw new NullPointerException();
        }
        // do not increment in method beforeExecute!
        submittedTaskCount.incrementAndGet();
        try {
            super.execute(command);
        } catch (RejectedExecutionException rx) {
            // 提交任务拒绝时 直接放入阻塞队列
            final TaskQueue queue = (TaskQueue) super.getQueue();
            try {
                if (!queue.retryOffer(command, 0, TimeUnit.MILLISECONDS)) {
                    submittedTaskCount.decrementAndGet();
                    throw new RejectedExecutionException("Queue capacity is full.", rx);
                }
            } catch (InterruptedException x) {
                submittedTaskCount.decrementAndGet();
                throw new RejectedExecutionException(x);
            }
        } catch (Throwable t) {
            // decrease any way
            submittedTaskCount.decrementAndGet();
            throw t;
        }
    }
}

重写的线程池也很简单，提供一个当前任务数量的接口，供 TaskQueue 使用。execute 方法也很好理解。可能有的小伙伴要问了，为什么要在 execute 方法中捕获 RejectedExecutionException 异常呢。这个还要回到 ThreadPoolExecutor 源码中

//省略无关代码
 else if (!addWorker(command, false))
            reject(command);
//省略无关代码

这句代码，在 addWorker 失败时，会抛出 RejectedExecutionException 异常。在未重写的线程池中抛出该异常的条件是：阻塞队列已满，线程数已达到最大限制。重写后的 TaskQueue 阻塞队列中 offer 还会在线程池中线程数量小于最大限制时返回 false.即使返回 false 新的阻塞队列也不代表已经满了，所以需要 retryOffer

//省略无关代码
   if (currentPoolThreadSize < executor.getMaximumPoolSize()) {
            return false;
   }
//省略无关代码

---

线程池分析结束了，看了下提交记录 EagerThreadPool 好像还是当初我们公司的前师兄写的。目前好像是 Dubbo 的 PPMC。厉害的很啊，大家一起努力学习啊。coding