Ⅰ 源碼修煉筆記之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如果都配了，以消費方為主。