通常桐玻，我們寫服務(wù)器處理模型的程序時(shí)篙挽，有以下幾種模型：
（1）每收到一個(gè)請(qǐng)求，創(chuàng)建一個(gè)新的進(jìn)程镊靴，來(lái)處理該請(qǐng)求铣卡；
（2）每收到一個(gè)請(qǐng)求，創(chuàng)建一個(gè)新的線程邑闲，來(lái)處理該請(qǐng)求；
（3）每收到一個(gè)請(qǐng)求梧油，放入一個(gè)事件列表苫耸，讓主進(jìn)程通過(guò)非阻塞I/O方式來(lái)處理請(qǐng)求
上面的幾種方式，各有千秋儡陨，
第（1）中方法褪子，由于創(chuàng)建新的進(jìn)程的開銷比較大，所以骗村，會(huì)導(dǎo)致服務(wù)器性能比較差,但實(shí)現(xiàn)比較簡(jiǎn)單嫌褪。
第（2）種方式，由于要涉及到線程的同步胚股，有可能會(huì)面臨死鎖等問(wèn)題笼痛。
第（3）種方式，在寫應(yīng)用程序代碼時(shí)琅拌，邏輯比前面兩種都復(fù)雜缨伊。
綜合考慮各方面因素，一般普遍認(rèn)為第（3）種方式是大多數(shù)網(wǎng)絡(luò)服務(wù)器采用的方式进宝。
什么是事件驅(qū)動(dòng)機(jī)制刻坊？
1.要理解事件驅(qū)動(dòng)和程序，就需要與非事件驅(qū)動(dòng)的程序進(jìn)行比較党晋。實(shí)際上谭胚，現(xiàn)代的程序大多是事件驅(qū)動(dòng)的徐块，比如多線程的程序，肯定是事件驅(qū)動(dòng)的灾而。早期則存在許多非事件驅(qū)動(dòng)的程序胡控，這樣的程序，在需要等待某個(gè)條件觸發(fā)時(shí)绰疤，會(huì)不斷地檢查這個(gè)條件铜犬，直到條件滿足，這是很浪費(fèi)cpu時(shí)間的轻庆。而事件驅(qū)動(dòng)的程序癣猾，則有機(jī)會(huì)釋放cpu從而進(jìn)入睡眠態(tài)（注意是有機(jī)會(huì)，當(dāng)然程序也可自行決定不釋放cpu）余爆，當(dāng)事件觸發(fā)時(shí)被操作系統(tǒng)喚醒纷宇，這樣就能更加有效地使用cpu.
2.再說(shuō)什么是事件驅(qū)動(dòng)的程序。一個(gè)典型的事件驅(qū)動(dòng)的程序蛾方，就是一個(gè)死循環(huán)像捶，并以一個(gè)線程的形式存在，這個(gè)死循環(huán)包括兩個(gè)部分桩砰，第一個(gè)部分是按照一定的條件接收并選擇一個(gè)要處理的事件拓春，第二個(gè)部分就是事件的處理過(guò)程。程序的執(zhí)行過(guò)程就是選擇事件和處理事件亚隅，而當(dāng)沒(méi)有任何事件觸發(fā)時(shí)硼莽，程序會(huì)因查詢事件隊(duì)列失敗而進(jìn)入睡眠狀態(tài)，從而釋放cpu煮纵。
3.事件驅(qū)動(dòng)的程序懂鸵，必定會(huì)直接或者間接擁有一個(gè)事件隊(duì)列，用于存儲(chǔ)未能及時(shí)處理的事件行疏。
4.事件驅(qū)動(dòng)的程序的行為匆光，完全受外部輸入的事件控制，所以酿联，事件驅(qū)動(dòng)的系統(tǒng)中终息，存在大量這種程序，并以事件作為主要的通信方式贞让。
5.事件驅(qū)動(dòng)的程序采幌，還有一個(gè)最大的好處，就是可以按照一定的順序處理隊(duì)列中的事件震桶，而這個(gè)順序則是由事件的觸發(fā)順序決定的休傍，這一特性往往被用于保證某些過(guò)程的原子化。
事件驅(qū)動(dòng)機(jī)制與IO多路復(fù)用有什么關(guān)系蹲姐？
I/O多路復(fù)用可以用作并發(fā)事件驅(qū)動(dòng)(event-driven)程序的基礎(chǔ)磨取，即整個(gè)事件驅(qū)動(dòng)模型是一個(gè)狀態(tài)機(jī)人柿，包含了狀態(tài)(state), 輸入事件(input-event), 狀態(tài)轉(zhuǎn)移(transition), 狀態(tài)轉(zhuǎn)移即狀態(tài)到輸入事件的一組映射。通過(guò)I/O多路復(fù)用的技術(shù)檢測(cè)事件的發(fā)生忙厌，并根據(jù)具體的事件(通常為讀寫)凫岖，進(jìn)行不同的操作，即狀態(tài)轉(zhuǎn)移逢净。
如何結(jié)合事件模型使用NIO同步非阻塞特性哥放？
回憶BIO模型，之所以需要多線程爹土，是因?yàn)樵谶M(jìn)行I/O操作的時(shí)候甥雕，一是沒(méi)有辦法知道到底能不能寫、能不能讀胀茵，只能"傻等"社露，即使通過(guò)各種估算，算出來(lái)操作系統(tǒng)沒(méi)有能力進(jìn)行讀寫琼娘，也沒(méi)法在socket.read()和socket.write()函數(shù)中返回峭弟，這兩個(gè)函數(shù)無(wú)法進(jìn)行有效的中斷。所以除了多開線程另起爐灶脱拼，沒(méi)有好的辦法利用CPU瞒瘸。
NIO的讀寫函數(shù)可以立刻返回，這就給了我們不開線程利用CPU的最好機(jī)會(huì)：如果一個(gè)連接不能讀寫（socket.read()返回0或者socket.write()返回0）熄浓，我們可以把這件事記下來(lái)情臭，記錄的方式通常是在Selector上注冊(cè)標(biāo)記位，然后切換到其它就緒的連接（channel）繼續(xù)進(jìn)行讀寫玉组。
下面具體看下如何利用事件模型單線程處理所有I/O請(qǐng)求：
NIO的主要事件有幾個(gè)：讀就緒谎柄、寫就緒丁侄、有新連接到來(lái)惯雳。
我們首先需要注冊(cè)當(dāng)這幾個(gè)事件到來(lái)的時(shí)候所對(duì)應(yīng)的處理器。然后在合適的時(shí)機(jī)告訴事件選擇器：我對(duì)這個(gè)事件感興趣鸿摇。對(duì)于寫操作石景，就是寫不出去的時(shí)候?qū)懯录信d趣；對(duì)于讀操作拙吉，就是完成連接和系統(tǒng)沒(méi)有辦法承載新讀入的數(shù)據(jù)的時(shí)潮孽；對(duì)于accept，一般是服務(wù)器剛啟動(dòng)的時(shí)候筷黔；而對(duì)于connect往史，一般是connect失敗需要重連或者直接異步調(diào)用connect的時(shí)候。
其次佛舱，用一個(gè)死循環(huán)選擇就緒的事件椎例，會(huì)執(zhí)行系統(tǒng)調(diào)用（Linux 2.6之前是select挨决、poll，2.6之后是epoll订歪，Windows是IOCP）脖祈，還會(huì)阻塞的等待新事件的到來(lái)。新事件到來(lái)的時(shí)候刷晋，會(huì)在selector上注冊(cè)標(biāo)記位盖高，標(biāo)示可讀、可寫或者有連接到來(lái)眼虱。
注意喻奥，select是阻塞的，無(wú)論是通過(guò)操作系統(tǒng)的通知（epoll）還是不停的輪詢(select蒙幻，poll)映凳，這個(gè)函數(shù)是阻塞的。所以你可以放心大膽地在一個(gè)while(true)里面調(diào)用這個(gè)函數(shù)而不用擔(dān)心CPU空轉(zhuǎn)邮破。
什么是事件（事件源）诈豌？
linux上為文件描述符，handler即為注冊(cè)在特定事件上的程序抒和，事件發(fā)生通常在linux下為I/O事件矫渔，由操作系統(tǒng)觸發(fā)。
什么是Reactor (反應(yīng)器)摧莽？
事件管理的接口庙洼，內(nèi)部使用event demultiplexer注冊(cè)，注銷事件镊辕；并運(yùn)行事件循環(huán)油够，當(dāng)有事件進(jìn)入"就緒"狀態(tài)時(shí)，調(diào)用注冊(cè)事件的回調(diào)函數(shù)處理事件征懈。
什么是Event demultiplexer(事件多路分發(fā)機(jī)制)石咬？
通常是由操作系統(tǒng)提供的I/O多路復(fù)用的機(jī)制，例如select,?epoll. 程序首先將handler（事件源）以及對(duì)應(yīng)的事件注冊(cè)到event demultiplexer上卖哎；當(dāng)有事件到達(dá)時(shí)鬼悠，event demultiplexer就會(huì)發(fā)出通知，通知Reactor調(diào)用事件處理程序進(jìn)行處理亏娜。
一般情況下焕窝，I/O 復(fù)用機(jī)制需要事件分發(fā)器（event dispatcher）。
事件分發(fā)器的作用维贺，即將那些讀寫事件源分發(fā)給各讀寫事件的處理者它掂，就像送快遞的在樓下喊: 誰(shuí)誰(shuí)誰(shuí)的快遞到了， 快來(lái)拿吧溯泣！開發(fā)人員在開始的時(shí)候需要在分發(fā)器那里注冊(cè)感興趣的事件虐秋，并提供相應(yīng)的處理者（event handler)晰韵，或者是回調(diào)函數(shù)；事件分發(fā)器在適當(dāng)?shù)臅r(shí)候熟妓，會(huì)將請(qǐng)求的事件分發(fā)給這些handler或者回調(diào)函數(shù)雪猪。涉及到事件分發(fā)器的兩種模式稱為：Reactor和Proactor。
什么是Event Handler(事件處理程序)起愈？
事件處理程序提供了一組接口只恨，在Reactor相應(yīng)的事件發(fā)生時(shí)調(diào)用，執(zhí)行相應(yīng)的事件處理抬虽，通常會(huì)綁定一個(gè)有效的handler官觅。
什么是Reactor模型？
Reactor模式是一種典型的事件驅(qū)動(dòng)的編程模型阐污，Reactor逆置了程序處理的流程休涤，其基本的思想即為Hollywood Principle— 'Don't call us, we'll call you'.
普通的函數(shù)處理機(jī)制為：調(diào)用某函數(shù)-> 函數(shù)執(zhí)行， 主程序等待阻塞-> 函數(shù)將結(jié)果返回給主程序-> 主程序繼續(xù)執(zhí)行笛辟。
Reactor事件處理機(jī)制為：主程序?qū)⑹录约皩?duì)應(yīng)事件處理的方法在Reactor上進(jìn)行注冊(cè), 如果相應(yīng)的事件發(fā)生功氨，Reactor將會(huì)主動(dòng)調(diào)用事件注冊(cè)的接口，即回調(diào)函數(shù).?libevent即為封裝了epoll并注冊(cè)相應(yīng)的事件(I/O讀寫手幢，時(shí)間事件捷凄，信號(hào)事件)以及回調(diào)函數(shù)，實(shí)現(xiàn)的事件驅(qū)動(dòng)的框架围来。
Reactor架構(gòu)模式允許事件驅(qū)動(dòng)的應(yīng)用通過(guò)多路分發(fā)的機(jī)制去處理來(lái)自不同客戶端的多個(gè)請(qǐng)求跺涤。事件(事件源)、Reactor (反應(yīng)器)监透、Event demultiplexer(事件多路分發(fā)機(jī)制)桶错、Event Handler(事件處理程序)是Reactor架構(gòu)模式的關(guān)鍵組件。Reactor核心的事件處理流程如圖所示：
什么是好萊塢原則胀蛮？
在網(wǎng)絡(luò)編程中院刁，特別是server端編程時(shí)，我們可能會(huì)大量利用好萊塢原則醇滥。在server端編程時(shí)黎比，我們大多會(huì)利用OS提供的一些功能強(qiáng)大的時(shí)間分派機(jī)制超营，比如select/ poll/ epoll/ WaitForMultipleObjects等鸳玩，通過(guò)對(duì)這些機(jī)制的再次包裝和抽象，牛人們提出了著名的reactor模式（中文翻譯成反應(yīng)堆模式）演闭。在此模式中不跟，我們使用者不用關(guān)心以下事情：
1）socket什么時(shí)候建立連接
2）socket什么時(shí)候有數(shù)據(jù)帶來(lái)
3）socket什么時(shí)候把數(shù)據(jù)發(fā)送
4）socket什么時(shí)候斷開連接
我們關(guān)心的是這些事件帶來(lái)的時(shí)候，我們?cè)趺刺幚砻着觯勘热鐂ocket建立連接了窝革，你是否要做一些log购城，以便以后查看。收到數(shù)據(jù)之后虐译，你是否要做完整性驗(yàn)證等瘪板。我們不用關(guān)心事件怎么來(lái)（HOW），什么時(shí)候來(lái)（WHEN）漆诽，我們關(guān)心的唯一一件事是處理它（Do it）侮攀。在這里如果把reactor等抽象系統(tǒng)（reactor模型）比喻成好萊塢的話，網(wǎng)絡(luò)上的數(shù)據(jù)/事件比喻成影片或劇本的話厢拭，我們可以把我們對(duì)數(shù)據(jù)的處理（對(duì)應(yīng)數(shù)據(jù)/事件的處理方法）比喻成演員兰英。這里，演員（對(duì)應(yīng)數(shù)據(jù)/事件的處理方法）不用去找劇本（數(shù)據(jù)/事件）供鸠，好萊塢（reactor模型）會(huì)帶著劇本（數(shù)據(jù)）來(lái)找你畦贸，你只要乖乖著等在家里不要亂動(dòng)，等劇本（數(shù)據(jù)）來(lái)了楞捂，你給我好好處理即可薄坏。
事件管理的接口，內(nèi)部使用event demultiplexer注冊(cè)寨闹，注銷事件颤殴；并運(yùn)行事件循環(huán)，當(dāng)有事件進(jìn)入"就緒"狀態(tài)時(shí)鼻忠，調(diào)用注冊(cè)事件的回調(diào)函數(shù)處理事件涵但。
通常是由操作系統(tǒng)提供的I/O多路復(fù)用的機(jī)制，例如select,?epoll. 程序首先將handler（事件源）以及對(duì)應(yīng)的事件注冊(cè)到event demultiplexer上帖蔓；當(dāng)有事件到達(dá)時(shí)矮瘟，event demultiplexer就會(huì)發(fā)出通知，通知Reactor調(diào)用事件處理程序進(jìn)行處理塑娇。
事件處理程序提供了一組接口澈侠，在Reactor相應(yīng)的事件發(fā)生時(shí)調(diào)用，執(zhí)行相應(yīng)的事件處理埋酬，通常會(huì)綁定一個(gè)有效的handler哨啃。
怎樣在Reactor中實(shí)現(xiàn)讀？
①?注冊(cè)讀就緒事件和相應(yīng)的事件處理器写妥。
②事件分發(fā)器等待事件拳球。
③事件到來(lái)，激活分發(fā)器珍特，分發(fā)器調(diào)用事件對(duì)應(yīng)的處理器祝峻。
④事件處理器完成實(shí)際的讀操作，處理讀到的數(shù)據(jù)，注冊(cè)新的事件莱找，然后返還控制權(quán)酬姆。
標(biāo)準(zhǔn)/典型的Reactor是什么？
步驟1：等待事件到來(lái)（Reactor負(fù)責(zé)）奥溺。
步驟2：將讀就緒事件分發(fā)給用戶定義的處理器（Reactor負(fù)責(zé)）辞色。
步驟3：讀數(shù)據(jù)（用戶處理器負(fù)責(zé)）。
步驟4：處理數(shù)據(jù)（用戶處理器負(fù)責(zé)）浮定。
Reactor模式流程是什么淫僻？
① 初始化Initiation Dispatcher，然后將若干個(gè)Concrete Event Handler注冊(cè)到Initiation Dispatcher中壶唤。當(dāng)應(yīng)用向Initiation Dispatcher注冊(cè)Concrete Event Handler時(shí)雳灵，會(huì)在注冊(cè)的同時(shí)指定感興趣的事件，即闸盔，應(yīng)用會(huì)標(biāo)識(shí)出該事件處理器希望Initiation Dispatcher在某些事件發(fā)生時(shí)向其發(fā)出通知悯辙，事件通過(guò)Handle來(lái)標(biāo)識(shí)，而Concrete Event Handler又持有該Handle迎吵。這樣躲撰，事件 —> Handle —> Concrete Event Handler 就關(guān)聯(lián)起來(lái)了。
② Initiation Dispatcher 會(huì)要求每個(gè)事件處理器向其傳遞內(nèi)部的Handle击费。該Handle向操作系統(tǒng)標(biāo)識(shí)了事件處理器拢蛋。
③ 當(dāng)所有的Concrete Event Handler都注冊(cè)完畢后，應(yīng)用會(huì)調(diào)用handle_events方法來(lái)啟動(dòng)Initiation Dispatcher的事件循環(huán)蔫巩。這是谆棱，Initiation Dispatcher會(huì)將每個(gè)注冊(cè)的Concrete Event Handler的Handle合并起來(lái)，并使用Synchronous Event Demultiplexer(同步事件分離器)同步阻塞的等待事件的發(fā)生圆仔。比如說(shuō)垃瞧，TCP協(xié)議層會(huì)使用select同步事件分離器操作來(lái)等待客戶端發(fā)送的數(shù)據(jù)到達(dá)連接的socket handler上。
比如坪郭，在Java中通過(guò)Selector的select()方法來(lái)實(shí)現(xiàn)這個(gè)同步阻塞等待事件發(fā)生的操作个从。在Linux操作系統(tǒng)下，select()的實(shí)現(xiàn)中 a)會(huì)將已經(jīng)注冊(cè)到Initiation Dispatcher的事件調(diào)用epollCtl(epfd, opcode, fd, events)注冊(cè)到linux系統(tǒng)中歪沃，這里fd表示Handle嗦锐，events表示我們所感興趣的Handle的事件；b)通過(guò)調(diào)用epollWait方法同步阻塞的等待已經(jīng)注冊(cè)的事件的發(fā)生沪曙。不同事件源上的事件可能同時(shí)發(fā)生奕污，一旦有事件被觸發(fā)了，epollWait方法就會(huì)返回珊蟀；c)最后通過(guò)發(fā)生的事件找到相關(guān)聯(lián)的SelectorKeyImpl對(duì)象菊值，并設(shè)置其發(fā)生的事件為就緒狀態(tài)，然后將SelectorKeyImpl放入selectedSet中育灸。這樣一來(lái)我們就可以通過(guò)Selector.selectedKeys()方法得到事件就緒的SelectorKeyImpl集合了腻窒。
④ 當(dāng)與某個(gè)事件源對(duì)應(yīng)的Handle變?yōu)閞eady狀態(tài)時(shí)(比如說(shuō)，TCP socket變?yōu)榈却x狀態(tài)時(shí))磅崭，Synchronous Event Demultiplexer就會(huì)通知Initiation Dispatcher儿子。
⑤ Initiation Dispatcher會(huì)觸發(fā)事件處理器的回調(diào)方法，從而響應(yīng)這個(gè)處于ready狀態(tài)的Handle砸喻。當(dāng)事件發(fā)生時(shí)柔逼，Initiation Dispatcher會(huì)將被事件源激活的Handle作為『key』來(lái)尋找并分發(fā)恰當(dāng)?shù)氖录幚砥骰卣{(diào)方法。
⑥ Initiation Dispatcher會(huì)回調(diào)事件處理器的handle_event(type)回調(diào)方法來(lái)執(zhí)行特定于應(yīng)用的功能(開發(fā)者自己所編寫的功能)割岛，從而相應(yīng)這個(gè)事件愉适。所發(fā)生的事件類型可以作為該方法參數(shù)并被該方法內(nèi)部使用來(lái)執(zhí)行額外的特定于服務(wù)的分離與分發(fā)。
Reactor模式的實(shí)現(xiàn)方式有哪些癣漆？
1. 單線程Reactor模式：
流程：
① 服務(wù)器端的Reactor是一個(gè)線程對(duì)象维咸，該線程會(huì)啟動(dòng)事件循環(huán)，并使用Selector來(lái)實(shí)現(xiàn)IO的多路復(fù)用惠爽。注冊(cè)一個(gè)Acceptor事件處理器到Reactor中癌蓖，Acceptor事件處理器所關(guān)注的事件是ACCEPT事件，這樣Reactor會(huì)監(jiān)聽客戶端向服務(wù)器端發(fā)起的連接請(qǐng)求事件(ACCEPT事件)婚肆。
② 客戶端向服務(wù)器端發(fā)起一個(gè)連接請(qǐng)求租副，Reactor監(jiān)聽到了該ACCEPT事件的發(fā)生并將該ACCEPT事件派發(fā)給相應(yīng)的Acceptor處理器來(lái)進(jìn)行處理。Acceptor處理器通過(guò)accept()方法得到與這個(gè)客戶端對(duì)應(yīng)的連接(SocketChannel)较性，然后將該連接所關(guān)注的READ事件以及對(duì)應(yīng)的READ事件處理器注冊(cè)到Reactor中用僧，這樣一來(lái)Reactor就會(huì)監(jiān)聽該連接的READ事件了≡蘖或者當(dāng)你需要向客戶端發(fā)送數(shù)據(jù)時(shí)永毅，就向Reactor注冊(cè)該連接的WRITE事件和其處理器。
③ 當(dāng)Reactor監(jiān)聽到有讀或者寫事件發(fā)生時(shí)人弓，將相關(guān)的事件派發(fā)給對(duì)應(yīng)的處理器進(jìn)行處理沼死。比如，讀處理器會(huì)通過(guò)SocketChannel的read()方法讀取數(shù)據(jù)崔赌，此時(shí)read()操作可以直接讀取到數(shù)據(jù)意蛀，而不會(huì)堵塞與等待可讀的數(shù)據(jù)到來(lái)。
④ 每當(dāng)處理完所有就緒的感興趣的I/O事件后健芭，Reactor線程會(huì)再次執(zhí)行select()阻塞等待新的事件就緒并將其分派給對(duì)應(yīng)處理器進(jìn)行處理县钥。
注意，Reactor的單線程模式的單線程主要是針對(duì)于I/O操作而言慈迈，也就是所以的I/O的accept()若贮、read()省有、write()以及connect()操作都在一個(gè)線程上完成的。
但在目前的單線程Reactor模式中谴麦，不僅I/O操作在該Reactor線程上蠢沿，連非I/O的業(yè)務(wù)操作也在該線程上進(jìn)行處理了，這可能會(huì)大大延遲I/O請(qǐng)求的響應(yīng)匾效。所以我們應(yīng)該將非I/O的業(yè)務(wù)邏輯操作從Reactor線程上卸載舷蟀，以此來(lái)加速Reactor線程對(duì)I/O請(qǐng)求的響應(yīng)。
2.?單線程Reactor模式的改進(jìn)面哼，使用工作者線程池
由上面的示例我們大概可以總結(jié)出NIO是怎么解決掉線程的瓶頸并處理海量連接的：
NIO由原來(lái)的阻塞讀寫（占用線程）變成了單線程輪詢事件野宜，找到可以進(jìn)行讀寫的網(wǎng)絡(luò)描述符進(jìn)行讀寫。除了事件的輪詢是阻塞的（沒(méi)有可干的事情必須要阻塞）魔策，剩余的I/O操作都是純CPU操作匈子，沒(méi)有必要開啟多線程。
并且由于線程的節(jié)約闯袒，連接數(shù)大的時(shí)候因?yàn)榫€程切換帶來(lái)的問(wèn)題也隨之解決旬牲，進(jìn)而為處理海量連接提供了可能。
單線程處理I/O的效率確實(shí)非常高搁吓，沒(méi)有線程切換原茅，只是拼命的讀、寫堕仔、選擇事件擂橘。但現(xiàn)在的服務(wù)器，一般都是多核處理器摩骨，如果能夠利用多核心進(jìn)行I/O通贞，無(wú)疑對(duì)效率會(huì)有更大的提高。
仔細(xì)分析一下我們需要的線程恼五，其實(shí)主要包括以下幾種：
事件分發(fā)器昌罩，單線程選擇就緒的事件。
I/O處理器灾馒，包括connect茎用、read、write等睬罗，這種純CPU操作轨功，一般開啟CPU核心個(gè)線程就可以。
業(yè)務(wù)線程容达，在處理完I/O后古涧，業(yè)務(wù)一般還會(huì)有自己的業(yè)務(wù)邏輯，有的還會(huì)有其他的阻塞I/O花盐，如DB操作羡滑，RPC等菇爪。只要有阻塞，就需要單獨(dú)的線程柒昏。
Java的Selector對(duì)于Linux系統(tǒng)來(lái)說(shuō)凳宙，有一個(gè)致命限制：同一個(gè)channel的select不能被并發(fā)的調(diào)用。因此昙楚，如果有多個(gè)I/O線程近速，必須保證：一個(gè)socket只能屬于一個(gè)IoThread诈嘿，而一個(gè)IoThread可以管理多個(gè)socket堪旧。
另外連接的處理和讀寫的處理通常可以選擇分開奖亚，這樣對(duì)于海量連接的注冊(cè)和讀寫就可以分發(fā)淳梦。雖然read()和write()是比較高效無(wú)阻塞的函數(shù)，但畢竟會(huì)占用CPU昔字，如果面對(duì)更高的并發(fā)則無(wú)能為力爆袍。
與單線程Reactor模式不同的是，添加了一個(gè)工作者線程池作郭，并將非I/O操作從Reactor線程中移出轉(zhuǎn)交給工作者線程池來(lái)執(zhí)行陨囊。這樣能夠提高Reactor線程的I/O響應(yīng)，不至于因?yàn)橐恍┖臅r(shí)的業(yè)務(wù)邏輯而延遲對(duì)后面I/O請(qǐng)求的處理夹攒。
使用線程池的優(yōu)勢(shì)：
① 通過(guò)重用現(xiàn)有的線程而不是創(chuàng)建新線程蜘醋，可以在處理多個(gè)請(qǐng)求時(shí)分?jǐn)傇诰€程創(chuàng)建和銷毀過(guò)程產(chǎn)生的巨大開銷。
② 另一個(gè)額外的好處是咏尝，當(dāng)請(qǐng)求到達(dá)時(shí)压语，工作線程通常已經(jīng)存在，因此不會(huì)由于等待創(chuàng)建線程而延遲任務(wù)的執(zhí)行编检，從而提高了響應(yīng)性胎食。
③ 通過(guò)適當(dāng)調(diào)整線程池的大小，可以創(chuàng)建足夠多的線程以便使處理器保持忙碌狀態(tài)允懂。同時(shí)還可以防止過(guò)多線程相互競(jìng)爭(zhēng)資源而使應(yīng)用程序耗盡內(nèi)存或失敗厕怜。
注意，在上圖的改進(jìn)的版本中蕾总，所有的I/O操作依舊由一個(gè)Reactor來(lái)完成酣倾，包括I/O的accept()、read()谤专、write()以及connect()操作躁锡。
對(duì)于一些小容量應(yīng)用場(chǎng)景，可以使用單線程模型置侍。但是對(duì)于高負(fù)載映之、大并發(fā)或大數(shù)據(jù)量的應(yīng)用場(chǎng)景卻不合適拦焚，主要原因如下：
① 一個(gè)NIO線程同時(shí)處理成百上千的鏈路，性能上無(wú)法支撐杠输，即便NIO線程的CPU負(fù)荷達(dá)到100%赎败，也無(wú)法滿足海量消息的讀取和發(fā)送；
② 當(dāng)NIO線程負(fù)載過(guò)重之后蠢甲，處理速度將變慢僵刮，這會(huì)導(dǎo)致大量客戶端連接超時(shí)，超時(shí)之后往往會(huì)進(jìn)行重發(fā)鹦牛，這更加重了NIO線程的負(fù)載搞糕，最終會(huì)導(dǎo)致大量消息積壓和處理超時(shí)，成為系統(tǒng)的性能瓶頸曼追；
3. 多Reactor線程模式
Reactor線程池中的每一Reactor線程都會(huì)有自己的Selector窍仰、線程和分發(fā)的事件循環(huán)邏輯。mainReactor可以只有一個(gè)礼殊，但subReactor一般會(huì)有多個(gè)驹吮。mainReactor線程主要負(fù)責(zé)接收客戶端的連接請(qǐng)求，然后將接收到的SocketChannel傳遞給subReactor晶伦，由subReactor來(lái)完成和客戶端的通信碟狞。
流程：
① 注冊(cè)一個(gè)Acceptor事件處理器到mainReactor中，Acceptor事件處理器所關(guān)注的事件是ACCEPT事件婚陪，這樣mainReactor會(huì)監(jiān)聽客戶端向服務(wù)器端發(fā)起的連接請(qǐng)求事件(ACCEPT事件)族沃。啟動(dòng)mainReactor的事件循環(huán)。
② 客戶端向服務(wù)器端發(fā)起一個(gè)連接請(qǐng)求近忙，mainReactor監(jiān)聽到了該ACCEPT事件并將該ACCEPT事件派發(fā)給Acceptor處理器來(lái)進(jìn)行處理竭业。Acceptor處理器通過(guò)accept()方法得到與這個(gè)客戶端對(duì)應(yīng)的連接(SocketChannel)，然后將這個(gè)SocketChannel傳遞給subReactor線程池及舍。
③ subReactor線程池分配一個(gè)subReactor線程給這個(gè)SocketChannel未辆，即，將SocketChannel關(guān)注的READ事件以及對(duì)應(yīng)的READ事件處理器注冊(cè)到subReactor線程中锯玛。當(dāng)然你也注冊(cè)WRITE事件以及WRITE事件處理器到subReactor線程中以完成I/O寫操作咐柜。Reactor線程池中的每一Reactor線程都會(huì)有自己的Selector、線程和分發(fā)的循環(huán)邏輯攘残。
④ 當(dāng)有I/O事件就緒時(shí)拙友，相關(guān)的subReactor就將事件派發(fā)給相應(yīng)的處理器處理。注意歼郭，這里subReactor線程只負(fù)責(zé)完成I/O的read()操作遗契，在讀取到數(shù)據(jù)后將業(yè)務(wù)邏輯的處理放入到線程池中完成，若完成業(yè)務(wù)邏輯后需要返回?cái)?shù)據(jù)給客戶端病曾，則相關(guān)的I/O的write操作還是會(huì)被提交回subReactor線程來(lái)完成牍蜂。
注意漾根，所有的I/O操作(包括，I/O的accept()鲫竞、read()辐怕、write()以及connect()操作)依舊還是在Reactor線程(mainReactor線程 或 subReactor線程)中完成的。Thread Pool(線程池)僅用來(lái)處理非I/O操作的邏輯从绘。
多Reactor線程模式將“接受客戶端的連接請(qǐng)求”和“與該客戶端的通信”分在了兩個(gè)Reactor線程來(lái)完成寄疏。mainReactor完成接收客戶端連接請(qǐng)求的操作，它不負(fù)責(zé)與客戶端的通信僵井，而是將建立好的連接轉(zhuǎn)交給subReactor線程來(lái)完成與客戶端的通信陕截，這樣一來(lái)就不會(huì)因?yàn)閞ead()數(shù)據(jù)量太大而導(dǎo)致后面的客戶端連接請(qǐng)求得不到即時(shí)處理的情況。并且多Reactor線程模式在海量的客戶端并發(fā)請(qǐng)求的情況下驹沿，還可以通過(guò)實(shí)現(xiàn)subReactor線程池來(lái)將海量的連接分發(fā)給多個(gè)subReactor線程艘策，在多核的操作系統(tǒng)中這能大大提升應(yīng)用的負(fù)載和吞吐量蹈胡。
參考鏈接：
