reactor模式：反應器模式
并發系統常使用reactor模式，代替常用的多線程的處理方式，節省系統的資源，提高系統的吞吐量。
和多線程的比較：
以一個餐飲為例，每一個人來就餐就是一個事件，他會先看一下菜單，然後點餐。就像一個網站會有很多的請求，要求伺服器做一些事情。處理這些就餐事件的就需要我們的服務人員了。
在多線程處理的方式會是這樣的：
一個人來就餐，一個服務員去服務，然後客人會看菜單，點菜。 服務員将菜單給後廚。
二個人來就餐，二個服務員去服務……
五個人來就餐，五個服務員去服務……
這個就是多線程的處理方式，一個事件到來，就會有一個線程服務。很顯然這種方式在人少的情況下會有很好的使用者體驗，每個客人都感覺自己是VIP，專人服務的。如果餐廳一直這樣同一時間最多來5個客人，這家餐廳是可以很好的服務下去的。
來了一個好消息，因為這家店的服務好，吃飯的人多了起來。同一時間會來10個客人，老闆很開心，但是隻有5個服務員，這樣就不能一對一服務了，有些客人就要沒有人管了。老闆就又請了5個服務員，現在好了，又能每個人都受VIP待遇了。
越來越多的人對這家餐廳滿意，客源又多了，同時來吃飯的人到了20人，老闆高興不起來了，再請服務員吧，占地方不說，還要開工錢，再請人就攢不到錢了。怎麼辦呢？老闆想了想，10個服務員對付20個客人也是能對付過來的，服務員勤快點就好了，伺候完一個客人馬上伺候另外一個，還是來得及的。綜合考慮了一下，老闆決定就使用10個服務人員的線程池啦~~~
但是這樣有一個比較嚴重的缺點就是，如果正在接受服務員服務的客人點菜很慢，其他的客人可能就要等好長時間了。有些火爆脾氣的客人可能就等不了走人了。
Reactor如何處理這個問題呢：
老闆後來發現，客人點菜比較慢，大部服務員都在等着客人點菜，其實幹的活不是太多。老闆能當老闆當然有點不一樣的地方，終于發現了一個新的方法，那就是：當客人點菜的時候，服務員就可以去招呼其他客人了，等客人點好了菜，直接招呼一聲“服務員”，馬上就有個服務員過去服務。嘿嘿，然後在老闆有了這個新的方法之後，就進行了一次裁員，隻留了一個服務員！這就是用單個線程來做多線程的事。
實際的餐館都是用的Reactor模式在服務。一些設計的模型其實都是從生活中來的。
Reactor模式主要是提高系統的吞吐量，在有限的資源下處理更多的事情。
在單核的機上，多線程并不能提高系統的性能，除非在有一些阻塞的情況發生。否則線程切換的開銷會使處理的速度變慢。就像你一個人做兩件事情，1、削一個蘋果。2、切一個西瓜。那你可以一件一件的做，我想你也會一件一件的做。如果這個時候你使用多線程，一會兒削蘋果，一會切西瓜，可以相像究竟是哪個速度快。這也就是說為什麼在單核機上多線程來處理可能會更慢。
但當有阻礙操作發生時，多線程的優勢才會顯示出來，現在你有另外兩件事情去做，1、削一個蘋果。2、燒一壺開水。我想沒有人會去做完一件再做另一件，你肯定會一邊燒水，一邊就把蘋果削了。
proactor模式
當然，如果還是以第一篇那樣以飯店的經營模式來講解的話，proactor模式應該是這樣的：
我們知道每一個飯店都有自己的招牌菜去吸引顧客。當然，其實這道菜你也會做，隻是别人做的比你更好，更美味。有一天，一群高富帥來了這家大拍檔：
老闆就是老闆，人面廣啊，自家廚師不會做，可以讓更專業的人去做，省時省事省心啊！
其實這裡我們都能看出reactor模式和proactor模式的一點點差別了吧！隻是還不了解具體的細節。
第二篇《性能IO設計的Reactor和Proactor模式》就是幹這個事的，給我們介紹具體細節和差別，我也是讀了好幾遍，慢慢畫個流程圖才了解了啊。
其實說到底就是一句廣告語：把事情交給更專業的人，你會更開心。
在高性能的I/O設計中，有兩個比較著名的模式Reactor和Proactor模式，其中Reactor模式用于同步I/O，而Proactor運用于異步I/O操作。
在比較這兩個模式之前，我們首先的搞明白幾個概念，什麼是阻塞和非阻塞，什麼是同步和異步；
同步和異步是針對應用程式和核心的互動而言的；
同步指的是使用者程序觸發IO操作并等待或者輪詢的去檢視IO操作是否就緒，
異步是指使用者程序觸發IO操作以後便開始做自己的事情，而當IO操作已經完成的時候會得到IO完成的通知。
阻塞和非阻塞是針對于程序在通路資料的時候，根據IO操作的就緒狀态來采取的不同方式，說白了是一種讀取或者寫入操作函數的實作方式；
阻塞方式下讀取或者寫入函數将一直等待，
非阻塞方式下，讀取或者寫入函數會立即傳回一個狀态值。
一般來說I/O模型可以分為：同步阻塞，同步非阻塞，異步阻塞，異步非阻塞IO
同步阻塞IO：
在此種方式下，使用者程序在發起一個IO操作以後，必須等待IO操作的完成，隻有當真正完成了IO操作以後，使用者程序才能運作。JAVA傳統的IO模型屬于此種方式！
同步非阻塞IO:
在此種方式下，使用者程序發起一個IO操作以後邊可傳回做其它事情，但是使用者程序需要時不時的詢問IO操作是否就緒，這就要求使用者程序不停的去詢問，進而引入不必要的CPU資源浪費。其中目前JAVA的NIO就屬于同步非阻塞IO。
異步阻塞IO：
此種方式下是指應用發起一個IO操作以後，不等待核心IO操作的完成，等核心完成IO操作以後會通知應用程式，這其實就是同步和異步最關鍵的差別，同步必須等待或者主動的去詢問IO是否完成，那麼為什麼說是阻塞的呢？因為此時是通過select系統調用來完成的，而select函數本身的實作方式是阻塞的，而采用select函數有個好處就是它可以同時監聽多個檔案句柄，進而提高系統的并發性！
異步非阻塞IO:
在此種模式下，使用者程序隻需要發起一個IO操作然後立即傳回，等IO操作真正的完成以後，應用程式會得到IO操作完成的通知，此時使用者程序隻需要對資料進行處理就好了，不需要進行實際的IO讀寫操作，因為真正的IO讀取或者寫入操作已經由核心完成了。目前Java中還沒有支援此種IO模型。
搞清楚了以上概念以後，我們再回過頭來看看，Reactor模式和Proactor模式。
首先來看看Reactor模式，Reactor模式應用于同步I/O的場景。我們以讀操作為例來看看Reactor中的具體步驟：
讀取操作：
- 應用程式注冊讀就需事件和相關聯的事件處理器
- 事件分離器等待事件的發生
- 當發生讀就需事件的時候，事件分離器調用第一步注冊的事件處理器
- 事件處理器首先執行實際的讀取操作，然後根據讀取到的内容進行進一步的處理
下面我們來看看Proactor模式中讀取操作和寫入操作的過程：
讀取操作：
- 應用程式初始化一個異步讀取操作，然後注冊相應的事件處理器，此時事件處理器不關注讀取就緒事件，而是關注讀取完成事件，這是差別于Reactor的關鍵。
- 事件分離器等待讀取操作完成事件
- 在事件分離器等待讀取操作完成的時候，作業系統調用核心線程完成讀取操作，并将讀取的内容放入使用者傳遞過來的緩存區中。這也是差別于Reactor的一點，Proactor中，應用程式需要傳遞緩存區。
- 事件分離器捕獲到讀取完成事件後，激活應用程式注冊的事件處理器，事件處理器直接從緩存區讀取資料，而不需要進行實際的讀取操作。
Proactor中寫入操作和讀取操作，隻不過感興趣的事件是寫入完成事件。
從上面可以看出，Reactor和Proactor模式的主要差別就是真正的讀取和寫入操作是有誰來完成的，Reactor中需要應用程式自己讀取或者寫入資料，而Proactor模式中，應用程式不需要進行實際的讀寫過程，它隻需要從緩存區讀取或者寫入即可，作業系統會讀取緩存區或者寫入緩存區到真正的IO裝置.
綜上所述，同步和異步是相對于應用和核心的互動方式而言的，同步 需要主動去詢問，而異步的時候核心在IO事件發生的時候通知應用程式，而阻塞和非阻塞僅僅是系統在調用系統調用的時候函數的實作方式而已。
最後來兩張圖做個總結：
