一：Thread per Connection
在沒有nio之前，傳統的網絡編程採用的線程模型。當連接建立後，創建新的線程/從線程池中取一個，處理連接。這個優缺點很明顯。優點：實現簡單，缺點：受到了線程數的限制。
二：Reactor in Single Thread
有了nio，就可以採用io的多路複用機制。
我們抽取出一個單線程版的reactor模型，時序圖見下文，該方案只有一個線程，所有的socket連接均註冊在了該reactor上，由一個線程全權負責所有的任務。它實現簡單，且不受線程數的限制。這種方案受限於使用場景，僅適合於IO密集的應用，不太適合CPU密集的應用，且適合於CPU資源緊張的應用上。
三：Reactor + Thread Pool
方案2由於受限於使用場景，但爲了可以更充分的使用CPU資源，抽取出一個邏輯處理線程池。reactor僅負責IO任務，線程池負責所有其它邏輯的處理。雖然該方案可以充分利用CPU資源，但是這個方案多了進出thread pool的兩次上下文切換。
四：Reactors in threads
基於方案3缺點的考慮，將reactor分成兩個部分。main reactor負責連接任務（accept、connect等），sub reactor負責IO、邏輯任務，即mina與netty的線程模型。該方案適應性十分強，可以調整sub reactor的數量適應CPU資源緊張的應用；同時CPU密集型任務時，又可以在業務處理邏輯中將任務交由線程池處理，如方案5。該方案有一個不太明顯的缺點，即session沒有分優先級，所有session平等對待均分到所有的線程中，這樣可能會導致優先級低耗資源的session堵塞高優先級的session，但似乎netty與mina並沒有針對這個做優化。
五：
Reactors in threads + Threads pool: 這也是我所在公司應用框架採用的模型，可以更爲靈活的適應所有的應用場景：調整reactor數量、調整thread pool大小等。
參考：http://ifeve.com/netty-mina-in-depth-1/