書接上篇：
既然Reactor反應器和Handler處理器，擠在一個線程中會造成非常嚴重的性能缺陷。那麼，可以使用多線程，對基礎的反應器模式進行改造和演進。
多線程池Reactor 反應器演進
多線程池Reactor反應器的演進，分爲兩個方面：
（1）首先是升級Handler處理器。即要使用多線程，又要儘可能的高效率，則可以考慮使用線程池。
（2）其次是升級Reactor反應器。可以考慮引入多個Selector選擇器，提升選擇大量通道的能力。
總體來說，多線程池反應器的模式，大致如下：
（1）將負責輸入輸出處理的IOHandler處理器的執行，放入獨立的線程池中。這樣，業務處理線程與負責監聽的和IO事件查詢的反應器線程相隔離，避免服務器的鏈接監聽收到阻塞。
（2）如果服務器爲多核的CPU，可以將反應器線程拆分爲多個子反應器（SubReactor）線程同時，引入多個選擇器，每一個SubReactor子線程負責一個選擇器。這樣，充分釋放了系統資源的能力；也提高了反應器管理大量鏈接，提升選擇大量通道的能力。
總結：
1.反應器模式和生產者消費者模式對比
相似之處：在一定程度上，反應器模式有點類似生產者消費者模式。在生產者消費者模式中，一個或多個生產者將事件加入到一個隊列中，一個或者多個消費者主動從這個隊列中提取（Pull）事件來處理。
不同之處在於：反應器模式是基於查詢的，沒有專門的隊列去緩衝存儲IO事件，查詢到IO事件後，反應器會根據不同IO選擇鍵（事件）將其分發給對應的Handler處理器來處理。
2.反應器模式和觀察者模式對比
相似之處在於：在反應器模式中，當查詢到IO事件後，服務處理程序使用單路/多路分發（Dispatch）策略，同步的分發這些IO事件。觀察者模式（Observ Pattern）也被稱作發佈/訂閱模式，它定義了一種依賴關係，讓多個觀察者同時監聽某一個主體（Topic）.這個主體對象在狀態發生變化時，會通知所有觀察者，他們能夠執行相應的處理。
不同之處在於：在反應器模式中，Handler處理器實例和IO事件（選擇鍵）的訂閱關係，基本上是一個是事件綁定到一個Handler處理器；每個IO事件（選擇鍵）被查詢後，反應器會將事件分發給所綁定的Handler處理器；在觀察者模式中，同一個時刻，同一個主體可以被訂閱過的多個觀察者處理。
最後，總結一下反應器模式的優點和缺點。作爲高性能的IO模式，反應器模式的優點如下：
1.響應快，雖然同一反應器線程本身是同步的，但不爲被單個鏈接的同步IO所阻塞。
2.編程相對簡單，最大程度上避免了複雜的多線程同步，也避免了多線程的各個進程之間的切換開銷。
3.可擴展，可以方便的通過增加反應器線程的個數來充分利用CPU
最主要的可以參考：
http://gee.cs.oswego.edu/dl/cpjslides/nio.pdf
學習知識最好的辦法是看最早的論文。併發編程大師的論文簡單易懂
反應器模式的缺點：
1.反應器模式增加了一定的複雜性，因而有一定的門檻，並且不易於調試。
2.反應器模式需要操作系統底層的IO多路複用的支持，如Linux中的epolll如果操作系統的底層不支持IO多路複用，反應器模式就不會有那麼高效了。
3.同一個Handler業務線程中，如果出現一個長時間的數據讀寫，會影響整個反應器中的其他通道的IO處理。例如在大文件傳輸時，IO操作就會影響到其他客戶端（Client）的響應時間。因爲對於這種操作，還需要進一步對反應器模式進行改進。