我們一直在說併發編程，我們只知道JDK5有個併發編程包幫我們封裝好了多線程下的複雜處理機制，這篇文章的重點不是說它的底層實現原理，只想說下併發包的編程模式思想，我以前一直在想這種思想來源於哪裏，面向對象編程的好處應該就是能總結一種模式，只有定義了模式理解了模式，我們平常才能更好的理解一些複雜的編程，這就是抽象到理論的過程吧!我們的前輩把這些編程思想作爲一種理論抽象成模式的概念，不就是方便我們更好的理解和接受編程的思想嗎？不僅如此，在現在開源如火如荼的進行中，我們怎麼通過代碼來交流？我們怎麼來更好的讀懂別人的代碼，更好的理解別人的意圖，我想這和模式是分不開的，只所以說分不開，是因爲我覺得，有了前輩們抽象的總結，我們編寫一些複雜代碼的時候，會有一些類似的思路，二而這種思路，不就是設計模式嗎？我們會想着針對什麼樣的功能使用什麼樣的模式，才能讓更多的人理解我們的意圖，理解我設計這個系統編寫這段代碼的意圖。讀懂了設計模式你會發現當你去看別人寫的系統的時候，你一看就能看出個大概，馬上就能梳理出閱讀該系統代碼的方向性在哪裏？說這麼多，好像跟我博文的題目沒什麼關係似的，其實不是的，我是想說，我們平常都在使用Java封裝好的併發編程包，是否會去想爲什麼要這麼封裝？這樣封裝有什麼好處？然後，設計模式的概念就出來了，對，我就想要說明Java併發編程使用的設計思想是基於哪種設計模式的。
Active Object模式，不知道大家是否聽說過，好像不是我們常見的OO23種設計模式之一，所想說下這個模式的結構：
在 Active Object 模式中，主要有以下幾種類型的參與者：
代 理 (Proxy) ：代理是 Active Object 所定義的對於調用者的公共接口。運行時，代理運行在調用者線程的上下文中，負責把調用者的方法調用轉換成相應的方法請求 (Method Request)，並將其插入相應的 Activation List，最後返回給調用者 Future 對象。
方法請求：方法請求定義了方法執行所需要的上下文信息，諸如調用參數等。
Activation List：負責存儲所有由代理創建的，等待執行的方法請求。從運行時來看，Activation List 會被包括調用者線程及其 Active Object 線程併發存取訪問，所以，Activation List 實現應當是線程安全的。
調度者 (Scheduler)：調度者運行在 Active Object 線程中，調度者來決定下一個執行的方法請求，而調度策略可以基於很多種標準，比如根據方法請求被插入的順序 FIFO 或者 LIFO，比如根據方法請求的優先級等等。
Servant: Servant 定義了 Active Object 的行爲和狀態，它是 Proxy 所定義的接口的事實實現。
Future: 調用者調用 Proxy 所定義的方法，獲得 Future 對象。調用者可以從該 Future 對象獲得方法執行的最終結果。在真實的實現裏，Future 對象會保留一個私有的空間，用來存放 Servant 方法執行的結果。
我 們可以從 Active Object 設計模式的角度來審視一下 Java Executor 框架。Java Executor 框架以任務 (Task) 爲中心，簡化了 Active Object 中的角色分工。可以看到，實現 Runnable 或者 Callable 接口的 Java Executor 任務整合了 Method Request 和 Servant 的角色 , 通過實現 run() 或者 call() 方法實現應用邏輯。Java Executor 框架並沒有顯式地定義 Proxy 接口，而是直接調用 Executor 提交任務，這裏的 Executor 相當於 Active Object 中調度者角色。從調用者的角度來看，這看起來並不像是在調用一個普通對象方法，而是向 Executor 提交了一個任務。所以，在這個層面上說，併發的底層細節已經暴露給了調用者。對於 Java 的開發者來說，如果你不擔心這樣的底層併發細節直接暴露給調用者，或者說你的應用並不需要像對待普通對象一樣對待併發對象，Java 的 Executor 框架是一個很好的選擇。相反，如果你希望隱藏這樣的併發細節，希望像操縱普通對象一樣操縱併發對象，那你就需要如本文上節所描述的那樣，遵循 Active Object 設計原則 , 清晰地定義各個角色，實現自己的 Active Object 模式。
總而言之，Java Executor 框架簡化了 Active Object 所定義的模式，模糊了 Active Object 中角色的分工，其基於生產者 / 消費者模式，生產者和消費者基於任務相互協作。