Ⅰ 源码修炼笔记之Dubbo线程池策略
FixedThreadPool
FixThreadPool内部是通过ThreadPoolExecutor来创建线程，核心线程数和最大线程数都是上下文中指定的线程数量threads，因为不存在空闲线程所以keepAliveTime为0，
当queues=0，创建SynchronousQueue阻塞队列；
当queues<0，创建无界的阻塞队列LinkedBlockingQueue；
当queues>0，创建有界的阻塞队列LinkedBlockingQueue。
采用bbo自己实现的线程工厂NamedInternalThreadFactory，将线程置为守护线程（Demon）
拒绝策略为AbortPolicyWithReport，策略为将调用时的堆栈信息保存到本地文件中，并抛出异常RejectedExecutionException
CachedThreadPool
CachedThreadPool与FixedThreadPool的区别是核心线程数和最大线程数不相等，通过alive来控制空闲线程的释放
LimitedThreadPool
LimitedThreadPool与CachedThreadPool的区别是空闲线程的超时时间为Long.MAX_VALUE，相当于线程数量不会动态变化了，创建的线程不会被释放。
EagerThreadPool
与上述三种线程池不同，EagerThreadPool并非通过JUC中的ThreadPoolExecutor来创建线程池，而是通过EagerThreadPoolExecutor来创建线程池，EagerThreadPoolExecutor继承自ThreadPoolExecutor，实现自定义的execute方法，采用的阻塞队列是TaskQueue，TaskQueue继承自LinkedBlockingQueue。
execute方法首先调用ThreadPoolExecutor的execute方法，如果执行失败会重新放入TaskQueue进行重试。
实现自定义的ThreadPool
ThreadPool被定义为一个扩展点，如下所示，
其默认实现是FixedThreadPool，可以通过实现该扩展来实现自定义的线程池策略。
Ⅱ android 可以使用bbo吗
可以的
DUBBO配置规则详解
研究DUBBO也已经大半年了，对它的大部分源码进行了分析，以及对它的内部机制有了比较深入的了解，以及各个模块的实现。DUBBO包含很多内容，如果想了解DUBBO第一步就是启动它，从而可以很好的使用它，那么如何更好的使用呢？就需要知道DUBBO的各个配置项，以及它可以通过哪些途径进行配置。个人对配置的理解，就好比时对动物的驯服，如何很好的驯服一头猛兽，那就需要知道它各种因子，从而调整，已达到自己期望的结果。这篇不对DUBBO有哪些配置项可以配置，但是通过这篇文章，你应该能够知道DUBBO可以进行哪些配置。本文会通过分析DUBBO加载配置源码的分析，来使得大家对DUBBO的配置一块有更加深入的了解。从而达到“驯服”DUBBO，以使得它成为你们自己的DUBBO。
DUBBO在配置这一块做的确实很完美，提供很很多参数，以及提供了多种渠道。下面进入正题，看看DUBBO怎么加载配置的。在讲这些之前，先给大家介绍一下在DUBBO源码层面定义了哪些类来存储各个模块的配置项，从而了解DUBBO可以对哪些模块进行配置。
哪些东西可以配置
由于大部分项目都会使用Spring，而且DUBBO也提供了通过Spring来进行配置，那么先从这里进行着手。DUBBO加载Spring的集成时在bbo-config下面的bbo-config-spring模块下面，其中有一个类DubboNamespaceHandler，它实现了Spring提供的接口NamespaceHandlerSupport。那么Spring怎么发现整个实现类的呢？在该模块的META-INF文件夹下有两个文件： spring.handlers和spring.schemas，这两个文件里面制定了bbo的namespace的XSD文件的位置以及bbo的namespace由DubboNamespaceHandler来处理解析。说了这么多废话，只是想说明Spring是怎么解析<bbo:.../>配置的。
知道了DUBBO和Spring关于配置一块时怎么整合的之后，那么你应该就不会诧异Spring怎么那么聪明，能够解析bbo的namespace。接下来看看DubboNamespaceHandler类里面有什么东西。
Ⅲ bbo之ProtocolFilterWrapper
ProtocolFilterWrapper是bbo-rpc模块中，bbo-rpc-api的一个核心类，其中核心方法buildInvokerChain，顾名思义构建invoker链。bbo源码看到这块时，理解起来有点费劲儿，特意做记录，方便日后查看。
1、首先，我们先看一下方法中的3个核心变量，invoker、filter、next
2、可以清晰看到源码中，invoker采用了匿名类 ProtocolFilterWrapper$1 实现，我们来看一下生成的匿名内部类结构
重点关注红框内的构造方法，以及invoke方法的实现。
OK，下面我们对buildInvokerChain的具体逻辑做分析；我们先对方法逻辑做一个抽象，首先是原始方法
借助前面我们提到的匿名类，我们做一下抽象，下面是抽象后的方法：
这样看起来就简单多了，实际上这块逻辑就是把url里拿到的filter包装成Invoker，串起来；下面我们了解一下bbo是如何把Invoker 串起来的，为了方便理解，这里做图解。
假设现在有A、B、C、D、E 5个filter，初始Invoker顺序如下：
最后 return last 5，这样就把所有filter串起来了，最终的Invoker chain顺序是 last 5 -> last 4 -> last 3 -> last 2 -> last 1(即 invoker 本身)。
Ⅳ bbo privider与consumer同时配置retry以哪个为主
bbo配置优先级：
方法级>接口级>全局级
消费方配置优先于提供方配置
所以，retry如果都配了，以消费方为主。