DUBBO的事件派发策略和线程池

1、dubbo基于netty。有5种派发策略：

• 默认是all：所有消息都派发到线程池，包括请求，响应，连接事件，断开事件，心跳等。 即worker线程接收到事件后，将该事件提交到业务线程池中，自己再去处理其他事。
• direct：worker线程接收到事件后，由worker执行到底。
• message：只有请求响应消息派发到线程池，其它连接断开事件，心跳等消息，直接在 IO线程上执行
• execution：只请求消息派发到线程池，不含响应（客户端线程池），响应和其它连接断开事件，心跳等消息，直接在 IO 线程上执行
• connection：在 IO 线程上，将连接断开事件放入队列，有序逐个执行，其它消息派发到线程池。 

2、业务线程池：

dubbo提供了四种线程池。其实我理解还是还是根据ThreadPoolExecutor这个JDK提供的线程池类，只不过适应性的改变了其中的参数。dubbo分别提供了:

• fixed(默认fixed)：固定大小线程池，启动时建立线程，不关闭，一直持有。(缺省)
  • coresize：200
  • maxsize：200
  • 队列：SynchronousQueue
  • 回绝策略：AbortPolicyWithReport - 打印线程信息jstack，之后抛出异常

固定大小线程池，顾名思义就是线程池中的线程数量维持着固定大小。其原理就是将其中的队列设置为同步队列，同时将最大池和核心池的数量都设定为一致就行。源码：

public class FixedThreadPool implements ThreadPool {

    @Override
    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 NamedInternalThreadFactory(name, true), new AbortPolicyWithReport(name, url));
    }

}

• cached：缓存线程池，空闲一分钟自动删除，需要时重建。

从源码中可以看到，将队列设置为同步队列，只要没有没有达到threads的数量，就会一直增加线程。这里设置了alive这个参数，那么也就是说用这个存活时间来控制整个线程池的时间。源码：

public class CachedThreadPool 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);
        return new ThreadPoolExecutor(cores, threads, alive, TimeUnit.MILLISECONDS,
                queues == 0 ? new SynchronousQueue<Runnable>() :
                        (queues < 0 ? new LinkedBlockingQueue<Runnable>()
                                : new LinkedBlockingQueue<Runnable>(queues)),
                new NamedInternalThreadFactory(name, true), new AbortPolicyWithReport(name, url));
    }
}

• limited：可伸缩线程池，但池中的线程数只会增长不会收缩。只增长不收缩的目的是为了避免收缩时突然来了大流量引起的性能问题。

可扩张线程池,就是把阻塞队列改成同步队列。这样有任务的时候就会一直开辟新的线程。源码：

public class LimitedThreadPool 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, 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 NamedInternalThreadFactory(name, true), new AbortPolicyWithReport(name, url));
    }

}

• eager：这个池子的比较不同的是：还是通过ThreadPoolExecutor实现任务的管理，唯一不同的是当任务执行失败的时候，会将任务存储到自定义的taskqueue中。同时维持这一个当前池子的任务的计数。线程池中的所有核心线程都在忙碌时，此时如果再添加新的任务不会放入阻塞队列，而且创建新的线程，直到达到最大线程限制，此时如果还有任务，才会放入阻塞队列。

 

 

 

不积跬步，无以至千里；不积小流，无以成江海。