Java NIO 與IO 性能對(duì)比分析

趙思遠(yuǎn)

（北京工業(yè)大學(xué)軟件學(xué)院，北京 100124）

0 引言

隨著互聯(lián)網(wǎng)的蓬勃發(fā)展，網(wǎng)絡(luò)用戶(hù)激增［1］，很多應(yīng)用都服務(wù)于億級(jí)以上數(shù)量級(jí)的用戶(hù)。如此龐大的用戶(hù)基數(shù)導(dǎo)致在高峰時(shí)期可達(dá)到千萬(wàn)以上的并發(fā)訪(fǎng)問(wèn)量，如何處理高并發(fā)流量，以保證應(yīng)用能正常使用，成為企業(yè)迫切需要解決的問(wèn)題［2］。

Java 是Web 應(yīng)用中廣泛采用的一種語(yǔ)言［3］，JDK 中提供了NIO（也稱(chēng)為New IO），NIO 為非阻塞IO［4］，即IO 過(guò)程不會(huì)阻塞程序運(yùn)行，使得CPU 不會(huì)因?yàn)榈却齀O 而白白浪費(fèi)計(jì)算資源。使用NIO 編程，并采用適當(dāng)?shù)哪Ｐ停梢猿浞职l(fā)揮CPU 的性能，提高服務(wù)器的并發(fā)處理能力。

1 相關(guān)工作

羅振興等［5］在實(shí)踐的基礎(chǔ)上分析Java NIO 的特性，采用事件驅(qū)動(dòng)、非阻塞的IO 多路復(fù)用、多線(xiàn)程［6］、安全Cookies、SSL、高速緩存等多種技術(shù)，設(shè)計(jì)并實(shí)現(xiàn)了構(gòu)架在PKI上，基于角色訪(fǎng)問(wèn)控制策略的安全訪(fǎng)問(wèn)控制服務(wù)器，但其研究重點(diǎn)在于應(yīng)用系統(tǒng)的整體設(shè)計(jì)與實(shí)現(xiàn)，對(duì)其中的Java服務(wù)器及其模型并沒(méi)有進(jìn)行清晰、明確的描述；袁勁松等［7］對(duì)網(wǎng)絡(luò)應(yīng)用中的阻塞通信與非阻塞通信工作機(jī)制及實(shí)現(xiàn)等問(wèn)題進(jìn)行研究與探討，提出系統(tǒng)實(shí)現(xiàn)阻塞與非阻塞通信的方法和步驟，分別給出基于阻塞與非阻塞IO 開(kāi)發(fā)高性能網(wǎng)絡(luò)應(yīng)用程序的具體實(shí)例，但該研究局限在代碼層面，且僅實(shí)現(xiàn)了基本的非阻塞服務(wù)器，對(duì)于高并發(fā)、長(zhǎng)連接等實(shí)際應(yīng)用中會(huì)出現(xiàn)的情況未進(jìn)行討論；錢(qián)宇虹［8］對(duì)java.io包進(jìn)行簡(jiǎn)要介紹，指出導(dǎo)致I/O 性能低下的根本原因，提出改進(jìn)Java IO 性能的策略，但該策略?xún)H針對(duì)Java 的傳統(tǒng)IO方式，未考慮到在NIO 上的應(yīng)用；楊帆［9］列舉Java 中多種不同的文件復(fù)制編程方式，對(duì)比其編程復(fù)雜程度及執(zhí)行效率，為編程人員提供參考及編程建議，但其沒(méi)有對(duì)語(yǔ)言底層機(jī)制進(jìn)行分析，且只對(duì)100M 文件進(jìn)行了復(fù)制測(cè)試，沒(méi)有對(duì)服務(wù)器模型及其性能進(jìn)行討論。

在高并發(fā)服務(wù)器領(lǐng)域，遲殿委［10］針對(duì)當(dāng)前Web 應(yīng)用請(qǐng)求高并發(fā)導(dǎo)致響應(yīng)時(shí)間過(guò)長(zhǎng)，影響用戶(hù)體驗(yàn)的問(wèn)題，提出Servlet 異步處理技術(shù)，對(duì)傳統(tǒng)單實(shí)例的Servlet 與具有異步特性的Servlet 進(jìn)行對(duì)比分析，并通過(guò)JMeter 模擬多線(xiàn)程、高并發(fā)訪(fǎng)問(wèn)兩種Servlet，從平均響應(yīng)時(shí)間和吞吐量來(lái)看，具有異步特性的Servlet 在高并發(fā)壓力下表現(xiàn)出色；劉俊汐等［11］通過(guò)在Linux 服務(wù)端使用select 函數(shù)管理所有套接字，實(shí)現(xiàn)了單線(xiàn)程并發(fā)服務(wù)器；李明等［12］在socket 編程的基礎(chǔ)上，使用epoll 機(jī)制和線(xiàn)程池技術(shù)［13］設(shè)計(jì)并實(shí)現(xiàn)了一個(gè)高并發(fā)服務(wù)器；陳強(qiáng)等［14］提出使用Netty 開(kāi)發(fā)物聯(lián)網(wǎng)應(yīng)用服務(wù)器的方法；Jie［15］采用就緒通知機(jī)制處理網(wǎng)絡(luò)流，使用適當(dāng)?shù)臄?shù)據(jù)結(jié)構(gòu)處理IO 緩沖區(qū)，并使用優(yōu)先級(jí)隊(duì)列［16］實(shí)現(xiàn)計(jì)時(shí)器管理模塊，通過(guò)適當(dāng)?shù)亟M合這些技術(shù)，顯著提高了SSL VPN 服務(wù)器程序的性能。

Java NIO 技術(shù)有效解決了CPU 等待IO 時(shí)產(chǎn)生的計(jì)算資源浪費(fèi)問(wèn)題，使得單一線(xiàn)程也能同時(shí)處理多個(gè)連接［17］。單線(xiàn)程N(yùn)IO 模型實(shí)現(xiàn)簡(jiǎn)單，但在同一時(shí)間只能處理一個(gè)IO 事件，無(wú)法響應(yīng)其它用戶(hù)請(qǐng)求，這在IO 數(shù)據(jù)量較大或網(wǎng)絡(luò)條件較差等IO 耗時(shí)較多的環(huán)境下會(huì)嚴(yán)重影響應(yīng)用性能。在使用NIO 的同時(shí)使用多線(xiàn)程技術(shù)，則可有效利用多核CPU 的能力提高應(yīng)用性能。即使有一個(gè)CPU 核心在處理IO 任務(wù)，仍有其它核心可接受并處理用戶(hù)請(qǐng)求。但這種編程模型較為復(fù)雜，對(duì)開(kāi)發(fā)人員要求較高，同時(shí)這種按照模型編寫(xiě)的程序可讀性及可擴(kuò)展性較差，在實(shí)際生產(chǎn)開(kāi)發(fā)過(guò)程中應(yīng)避免這種情況。

為了解決原生Java NIO 模型帶來(lái)的問(wèn)題，業(yè)界提出MINA［18］、Netty［19］等框架對(duì)NIO 進(jìn)行包裝，提供統(tǒng)一的模型，并進(jìn)行了一些優(yōu)化。使用這些成熟的框架可簡(jiǎn)化NIO程序編寫(xiě)，大大提高應(yīng)用的可維護(hù)性［20］。

2 多Reactor 模型

2.1 傳統(tǒng)IO 模型

傳統(tǒng)IO 方式是面向流的，數(shù)據(jù)以字節(jié)為單位在輸入輸出流中傳輸，且流是單向的，如圖1 所示。

此外，IO 是阻塞式的，即Blocking IO，所以稱(chēng)之為BIO。當(dāng)程序發(fā)出讀寫(xiě)請(qǐng)求后，程序會(huì)進(jìn)入阻塞狀態(tài)，直到請(qǐng)求完成或中斷，如圖2 所示。

Fig.2 Blocking IO圖2 阻塞式IO

基于傳統(tǒng)IO 構(gòu)建的網(wǎng)絡(luò)應(yīng)用為了同時(shí)處理多個(gè)連接，需要為每個(gè)連接創(chuàng)建一個(gè)專(zhuān)用線(xiàn)程進(jìn)行讀寫(xiě)操作，接受新連接的線(xiàn)程稱(chēng)為Acceptor，處理socket 的線(xiàn)程稱(chēng)為Handler，如圖3 所示。

Fig.3 BIO server model圖3 BIO 服務(wù)器模型

這種模型在并發(fā)量不高時(shí)可以很好地處理多個(gè)連接，然而一旦并發(fā)量增長(zhǎng)，連接數(shù)增多，將導(dǎo)致服務(wù)器線(xiàn)程也隨之增長(zhǎng)。大量線(xiàn)程處于非活躍狀態(tài)，卻依然占用著系統(tǒng)資源，同時(shí)在大量線(xiàn)程中頻繁切換也會(huì)帶來(lái)很多額外的系統(tǒng)開(kāi)銷(xiāo)。當(dāng)連接數(shù)繼續(xù)增長(zhǎng)，創(chuàng)建的線(xiàn)程數(shù)達(dá)到服務(wù)器極限，系統(tǒng)資源耗盡，將會(huì)導(dǎo)致整個(gè)系統(tǒng)卡死，大量連接得不到響應(yīng)，直到服務(wù)器崩潰。因此，傳統(tǒng)IO 模型無(wú)法處理高并發(fā)流量。

2.2 NIO 單線(xiàn)程模型

NIO 是面向緩沖區(qū)的，數(shù)據(jù)必須通過(guò)通道讀取到緩沖區(qū)中才可以被程序使用，且通道是雙向的，如圖4 所示。

Fig.4 Buffer-oriented NIO圖4 面向緩沖區(qū)的NIO

通過(guò)緩沖區(qū)一次讀寫(xiě)多個(gè)字節(jié)可以大大減少數(shù)據(jù)源訪(fǎng)問(wèn)次數(shù)，從而提高執(zhí)行速度。

同時(shí)，NIO 是非阻塞的，讀請(qǐng)求在數(shù)據(jù)未準(zhǔn)備好時(shí)會(huì)立刻返回，不會(huì)阻塞程序運(yùn)行，如圖5 所示。

Fig.5 Non-blocking IO圖5 非阻塞式IO

NIO 允許SocketChannel 和ServerSocketChannel 被配置為非阻塞式，采用非阻塞模型可以使程序同時(shí)監(jiān)控多個(gè)通道，而不會(huì)因某個(gè)通道陷入阻塞，這種特性使其十分適合應(yīng)用于網(wǎng)絡(luò)應(yīng)用開(kāi)發(fā)。

利用NIO 技術(shù)，單一線(xiàn)程可以同時(shí)監(jiān)控多個(gè)通道，并循環(huán)處理其中已就緒的數(shù)據(jù)。實(shí)際上，系統(tǒng)已通過(guò)select、epoll 等方法為程序提供同時(shí)監(jiān)控多個(gè)通道的能力，即IO多路復(fù)用。在Java NIO 中，將多個(gè)通道注冊(cè)到Selector 中，即可在某個(gè)通道就緒時(shí)通過(guò)select 方法將其選擇出來(lái)。單線(xiàn)程服務(wù)器模型如圖6 所示。

Fig.6 NIO single-threaded server model圖6 NIO 單線(xiàn)程服務(wù)器模型

NIO 單線(xiàn)程模型中所有操作都在主線(xiàn)程中進(jìn)行。主線(xiàn)程中只有一個(gè)Selector，其監(jiān)聽(tīng)所有通道，并處理全部的accept 和read 事件。完成全部請(qǐng)求所需時(shí)間為：

其中，T 為完成全部請(qǐng)求所需時(shí)間，N 為并發(fā)連接數(shù)，taccept為接受一個(gè)連接所需時(shí)間，tread為每次讀取所需的平均時(shí)間，cread為每個(gè)連接讀取次數(shù)。

若接受連接的時(shí)間為0.1 ms，每個(gè)連接進(jìn)行兩次讀取，每次讀取用時(shí)2 ms，則單線(xiàn)程模型處理10 000 個(gè)并發(fā)連接所需時(shí)間為41 s。

2.3 NIO 線(xiàn)程池模型

單線(xiàn)程模型使用一個(gè)線(xiàn)程串行地處理所有通道的連接與讀取事件，而無(wú)法利用CPU 的多核性能。為此，服務(wù)器一般采用多線(xiàn)程模型，并通過(guò)線(xiàn)程池重用線(xiàn)程，以避免頻繁地創(chuàng)建與銷(xiāo)毀線(xiàn)程。NIO 線(xiàn)程池服務(wù)器模型如圖7 所示。

Fig.7 NIO thread pool server model圖7 NIO 線(xiàn)程池服務(wù)器模型

在NIO 線(xiàn)程池服務(wù)器模型中，主線(xiàn)程包含一個(gè)Seletor，監(jiān)聽(tīng)所有通道，并處理accept 事件。當(dāng)收到read 事件時(shí)，主線(xiàn)程將讀寫(xiě)操作提交到線(xiàn)程池中執(zhí)行。完成全部請(qǐng)求所需時(shí)間為：

其中，cthread為線(xiàn)程池線(xiàn)程數(shù)，一般設(shè)置為CPU 核心數(shù)，cost 為全部線(xiàn)程的切換總開(kāi)銷(xiāo)。若CPU 核心數(shù)為16，線(xiàn)程切換總開(kāi)銷(xiāo)為100ms，則線(xiàn)程池模型處理10 000 個(gè)并發(fā)連接所需時(shí)間為3.6s。

2.4 多Reactor 模型

以上單線(xiàn)程模型和線(xiàn)程池模型中均只使用一個(gè)Selector，即所有通道的accept 和read 事件都由一個(gè)Selector 進(jìn)行處理。當(dāng)大量通道頻繁讀寫(xiě)，且每次讀寫(xiě)的數(shù)據(jù)量很小時(shí)，會(huì)導(dǎo)致Selector 線(xiàn)程負(fù)載很高，而其它只進(jìn)行讀寫(xiě)操作的線(xiàn)程負(fù)載很低。在某些實(shí)際的網(wǎng)絡(luò)應(yīng)用中，每個(gè)連接單次讀取的數(shù)據(jù)量很少，所需的讀取時(shí)間很短，但讀取次數(shù)多，數(shù)據(jù)交換頻繁，如網(wǎng)絡(luò)游戲或大型物聯(lián)網(wǎng)系統(tǒng)等。在這種場(chǎng)景下，線(xiàn)程池模型會(huì)頻繁地切換線(xiàn)程，此時(shí)切換線(xiàn)程的開(kāi)銷(xiāo)便不能忽視。為解決這個(gè)問(wèn)題，本文提出多Reactor 模型，如圖8 所示。

多Reactor 服務(wù)器模型中包含一個(gè)主線(xiàn)程和一個(gè)線(xiàn)程池。主線(xiàn)程中的Selector 只監(jiān)聽(tīng)ServerSocketChannel 的accept 事件，當(dāng)連接到來(lái)時(shí)，會(huì)將SocketChannel 分發(fā)至線(xiàn)程池中的某個(gè)線(xiàn)程，所以主線(xiàn)程又稱(chēng)為分發(fā)器。線(xiàn)程池中每個(gè)線(xiàn)程也擁有自己的Selector，負(fù)責(zé)監(jiān)聽(tīng)分配到該線(xiàn)程SocketChannel 的read 事件。

多Reactor 服務(wù)器模型中包含多個(gè)Selector，將通道平均分配至多個(gè)線(xiàn)程，緩解了主線(xiàn)程的分發(fā)壓力。通道被分配給工作線(xiàn)程后不會(huì)再移動(dòng)，從而避免了頻繁切換線(xiàn)程的開(kāi)銷(xiāo)，且每個(gè)工作線(xiàn)程內(nèi)部都類(lèi)似于簡(jiǎn)單、高效的NIO 單線(xiàn)程模型。因此，多Reactor 服務(wù)器在保留多線(xiàn)程服務(wù)器優(yōu)勢(shì)的同時(shí)，可以降低資源消耗。

Fig.8 Multi-Reactor server model圖8 多Reactor 服務(wù)器模型

3 性能測(cè)試及結(jié)果

3.1 文件讀取性能測(cè)試

文件讀取性能測(cè)試的目的在于探究面向流的IO 和面向緩沖區(qū)的NIO 在讀取數(shù)據(jù)方面的性能差異。

實(shí)驗(yàn)使用多種方式對(duì)不同大小的文件進(jìn)行讀取與復(fù)制，文件大小分別為1KB、1MB、10MB、100MB、500MB 和1GB。讀取方式包括無(wú)緩沖IO、單字節(jié)讀取的緩沖IO、儲(chǔ)存到數(shù)組的緩沖IO、NIO、直接緩沖區(qū)NIO，復(fù)制方式除以上方式外，還包括雙映射緩沖區(qū)、單映射緩沖區(qū)以及transferTo。記錄操作所需時(shí)間，每個(gè)測(cè)試執(zhí)行8 次，記錄后5次平均值作為最終結(jié)果，單位為ms。讀取測(cè)試結(jié)果如表1所示。

Table 1 Read test results表1 讀取測(cè)試結(jié)果

復(fù)制測(cè)試結(jié)果如表2 所示。

Table 2 Copy test results表2 復(fù)制測(cè)試結(jié)果

測(cè)試結(jié)果顯示，使用緩沖區(qū)的文件讀取無(wú)論是IO 還是NIO，不會(huì)有太大的性能差異，使用直接緩沖區(qū)的NIO比普通NIO 速度稍快。文件復(fù)制測(cè)試結(jié)果也符合該結(jié)論，而且使用單映射緩沖區(qū)相較于雙映射緩沖區(qū)可減少一半的時(shí)間開(kāi)銷(xiāo)。

直接緩沖區(qū)也稱(chēng)為映射緩沖區(qū)，其不在用戶(hù)空間內(nèi)，而是系統(tǒng)內(nèi)存上的一塊區(qū)域。通過(guò)直接緩沖區(qū)，用戶(hù)可直接對(duì)該部分內(nèi)存進(jìn)行操作。通常程序讀取數(shù)據(jù)需要將數(shù)據(jù)讀取到內(nèi)核，再?gòu)?fù)制到用戶(hù)空間，如圖9 所示。

Fig.9 Read data from file圖9 從文件中讀取數(shù)據(jù)

使用直接緩沖區(qū)，不需要將數(shù)據(jù)從內(nèi)核空間復(fù)制到用戶(hù)空間，即零拷貝，這在進(jìn)行大文件復(fù)制等操作時(shí)具有顯著優(yōu)勢(shì)，如圖10 所示。

Fig.10 Copy files using direct buffer圖10 使用直接緩沖區(qū)復(fù)制文件

3.2 網(wǎng)絡(luò)通信性能測(cè)試

網(wǎng)絡(luò)通信性能測(cè)試的目的在于探究傳統(tǒng)IO 服務(wù)器模型與多種NIO 服務(wù)器模型之間在處理高并發(fā)網(wǎng)絡(luò)請(qǐng)求方面的性能差異。

實(shí)驗(yàn)使用多種模型構(gòu)建echo 服務(wù)器，包括BIO 多線(xiàn)程、BIO 線(xiàn)程池、NIO 單線(xiàn)程、NIO 線(xiàn)程池、NIO 多Reactor和Netty。使用Jmeter［21］對(duì)服務(wù)器進(jìn)行分布式壓力測(cè)試，先向服務(wù)器發(fā)送“hello”，延遲1s 后再發(fā)送“bye”，最后關(guān)閉連接。設(shè)置Jmeter 線(xiàn)程數(shù)控制并發(fā)級(jí)別，測(cè)試持續(xù)時(shí)間為120s，使用htop 和visualVM 監(jiān)控服務(wù)器運(yùn)行狀態(tài)，記錄服務(wù)器資源使用情況和請(qǐng)求響應(yīng)情況。測(cè)試機(jī)器全部為云主機(jī)，為防止客戶(hù)機(jī)產(chǎn)生性能瓶頸，將服務(wù)器配置為2 核8GB 內(nèi)存，客戶(hù)機(jī)配置為4 核8GB 內(nèi)存。

Table 3 BIO multi-thread model表3 BIO 多線(xiàn)程模型

由表3 結(jié)果可見(jiàn)，服務(wù)器的線(xiàn)程數(shù)隨并發(fā)數(shù)增長(zhǎng)，但在4 000 并發(fā)時(shí)，線(xiàn)程數(shù)并沒(méi)有達(dá)到4 000，可見(jiàn)服務(wù)器能創(chuàng)建的線(xiàn)程數(shù)已達(dá)到上限。而且TPS 在4 000 并發(fā)時(shí)與2 000 并發(fā)時(shí)差距不大，說(shuō)明服務(wù)器在2 000 并發(fā)時(shí)就已基本到達(dá)了性能瓶頸。

Table 4 NIO single-thread server表4 NIO 單線(xiàn)程服務(wù)器

由測(cè)試結(jié)果（見(jiàn)表4）可見(jiàn)，與BIO 服務(wù)器相比，NIO 服務(wù)器在資源占用、請(qǐng)求響應(yīng)時(shí)間和TPS 上都具有優(yōu)勢(shì)。

以4 000 并發(fā)為例，BIO 多線(xiàn)程服務(wù)器有3 002 個(gè)線(xiàn)程，CPU 占用率達(dá)到112%，完成“hello”請(qǐng)求306 322 個(gè)，平均響應(yīng)時(shí)間為573 ms，TPS 為1 826，與2 000 并發(fā)時(shí)差別不大，已達(dá)到性能瓶頸；NIO 單線(xiàn)程服務(wù)器只有53 個(gè)線(xiàn)程，CPU 占用率為17.7%，完成“hello”請(qǐng)求477 970 個(gè)，平均響應(yīng)時(shí)間為0.33 ms，TPS 為3 977。可見(jiàn)NIO 單線(xiàn)程服務(wù)器用更少的資源完成了更多請(qǐng)求，而且響應(yīng)時(shí)間極短。

通過(guò)橫向?qū)Ρ劝l(fā)現(xiàn)，每秒完成數(shù)隨著并發(fā)數(shù)而增長(zhǎng)，在10 000 并發(fā)時(shí)，TPS 也接近10 000，且CPU 使用率只有50.80%，說(shuō)明還沒(méi)有到達(dá)性能瓶頸，NIO 單線(xiàn)程服務(wù)器能支撐10 000 以上的并發(fā)。由此可見(jiàn)，NIO 服務(wù)器與BIO 服務(wù)器相比具有絕對(duì)優(yōu)勢(shì)。

設(shè)定并發(fā)級(jí)別為10 000，多種NIO 服務(wù)器模型對(duì)比測(cè)試結(jié)果如表5 所示。

Fig.11 TPS of NIO and BIO under different concurrency levels圖11 不同并發(fā)級(jí)別下NIO 與BIO 的TPS

Table 5 Comparison test results of multiple NIO models under 10 000 concurrent表5 10 000 并發(fā)下多種NIO 模型對(duì)比測(cè)試結(jié)果

測(cè)試結(jié)果顯示，在10 000 并發(fā)時(shí)各模型的處理能力相近，TPS 均在9 800 附近，表明10 000 并發(fā)沒(méi)有達(dá)到NIO服務(wù)器的性能瓶頸，在CPU 占用率上出現(xiàn)的差異表明不同模型在相同壓力下會(huì)產(chǎn)生不同的系統(tǒng)負(fù)載。

由于該測(cè)試在內(nèi)網(wǎng)環(huán)境下進(jìn)行，且讀取的數(shù)據(jù)量較少，所以每次讀取耗時(shí)很短，單線(xiàn)程模型不會(huì)因讀取數(shù)據(jù)而出現(xiàn)顯著的阻塞情況，因此單線(xiàn)程模型的請(qǐng)求完成數(shù)并未明顯低于多線(xiàn)程模型。此外，由于單線(xiàn)程模型沒(méi)有線(xiàn)程切換的額外開(kāi)銷(xiāo)，所以在完成相同數(shù)量請(qǐng)求的情況下，系統(tǒng)負(fù)載最低。

與單線(xiàn)程模型相比，線(xiàn)程池模型的CPU 占用率較高，TPS 反而更低，這是因?yàn)楸緶y(cè)試沒(méi)有網(wǎng)絡(luò)速度慢和單次讀寫(xiě)數(shù)據(jù)過(guò)大等IO 瓶頸，線(xiàn)程池的優(yōu)勢(shì)未得到發(fā)揮，反而因頻繁切換線(xiàn)程而引入了額外的系統(tǒng)開(kāi)銷(xiāo)。

本文提出的多Reactor 模型相較于原有的NIO 單線(xiàn)程模型和線(xiàn)程池模型有較大改進(jìn)。首先，CPU 占用率與線(xiàn)程池模型相比由90.70% 降低到68.50%，僅略高于單線(xiàn)程模型；其次，平均響應(yīng)時(shí)間和TPS 與單線(xiàn)程模型相比均有提升，同時(shí)避免了單線(xiàn)程模型會(huì)出現(xiàn)IO 操作阻塞其它連接的情況。這是由于多Reactor 模型的每個(gè)工作線(xiàn)程都相當(dāng)于一個(gè)NIO 單線(xiàn)程服務(wù)器，其內(nèi)部不會(huì)發(fā)生線(xiàn)程切換，所以效率很高，從整體來(lái)看是多個(gè)服務(wù)器并行，充分利用多核CPU 提高并發(fā)性能。

4 結(jié)語(yǔ)

在大文件讀取方面，面向緩沖區(qū)的NIO 與使用緩沖區(qū)的傳統(tǒng)流IO 相比性能差距不大；在大文件復(fù)制方面，通過(guò)使用直接緩沖區(qū)可以實(shí)現(xiàn)“零拷貝”，大大加快了復(fù)制速度；在網(wǎng)絡(luò)服務(wù)器方面，NIO 在高并發(fā)場(chǎng)景下與傳統(tǒng)IO 相比具有資源占用率低、響應(yīng)速度快、吞吐量高等特點(diǎn)。本文設(shè)計(jì)的多Reactor 服務(wù)器模型既避免了單線(xiàn)程模型讀寫(xiě)操作阻塞其它連接的問(wèn)題，提高了并發(fā)性能，又避免了線(xiàn)程池模型頻繁切換線(xiàn)程帶來(lái)的額外開(kāi)銷(xiāo)，降低了系統(tǒng)負(fù)載。利用設(shè)計(jì)良好的NIO 服務(wù)器模型，可適應(yīng)各種應(yīng)用場(chǎng)景。此外，還可利用成熟的框架降低開(kāi)發(fā)難度，快速開(kāi)發(fā)實(shí)現(xiàn)高性能服務(wù)器。