摘要：在對(duì)I/O 完成端口進(jìn)行底層封裝的基礎(chǔ)上，提出一種具有高性能的、可擴(kuò)展性的通用網(wǎng)絡(luò)通信模塊設(shè)計(jì)方案。該方案采用多種系
統(tǒng)性能優(yōu)化技術(shù)，如線程池、對(duì)象池和環(huán)形緩存區(qū)等。該模塊在Win32 平臺(tái)上用C++開發(fā)完成，經(jīng)過嚴(yán)格的壓力和性能測(cè)試后，實(shí)驗(yàn)結(jié)果
表明該模塊能夠支持海量并發(fā)連接，具有較高的數(shù)據(jù)吞吐量，在實(shí)際項(xiàng)目應(yīng)用中也取得了良好的表現(xiàn)。
關(guān)鍵詞：完成端口；服務(wù)器；多線程；線程池；對(duì)象池；緩存區(qū)
Design Method of Underlying Module of Network Communication
for High Performance Server
WANGWen-wu1,2, ZHAOWei-dong1,2,WANG Zhi-cheng1,2, CHEN Yue1,2, HAN Xia-lin1,2
(1. State Education Commission Engineering Center for Enterprise Digital Technology, Shanghai 200092;
2. Research Center of CAD, Tongji University, Shanghai 201804)
【Abstract】On the base of underlying encapsulation for I/O Completion Port(IOCP), this paper presents a design solution with high performance
and scalable module of generic network communication, which emploies a variety of optimization techniques of system performance, such as thread
pool, object pool and ring buffer. The module is developed in C++ programming language on Win32 platform. Experimental results show that the
module can support massive concurrent connections, and has higher data throughput based on severe pressure and performance tests. The proposed
solution has also got a good performance in the actual project application.
【Key words】completion port; server; multi-threading; thread pool; object pool; ring buffer

計(jì)算機(jī)工程

Computer Engineering

第35 卷第3 期
Vol.35 No.3
2009 年2 月
February 2009

1 概述
要設(shè)計(jì)與開發(fā)出一款高性能的服務(wù)器(如網(wǎng)游服務(wù)器、
Web 服務(wù)器和代理服務(wù)器等)，一般都采用高效率的網(wǎng)絡(luò)I/O
模型[1]。Linux 平臺(tái)上經(jīng)常會(huì)采用epoll 模型，而在Win32 平
臺(tái)上完成端口(以下簡(jiǎn)稱IOCP)模型[2]是設(shè)計(jì)與開發(fā)高性能
的、具有可伸縮性的服務(wù)器的最佳選擇，它可以支持海量并
發(fā)客戶端請(qǐng)求。多線程編程是服務(wù)器端開發(fā)常用技術(shù)，多線
程必然涉及線程間的通信與同步。如果使用不當(dāng)，也會(huì)影響
到系統(tǒng)的性能，必須謹(jǐn)慎設(shè)計(jì)才能保證系統(tǒng)良好運(yùn)行。減少
數(shù)據(jù)拷貝以及小對(duì)象頻繁創(chuàng)建與銷毀是一種很重要的提高系
統(tǒng)性能手段，可通過設(shè)計(jì)內(nèi)存池或?qū)ο蟪丶右越鉀Q。這幾個(gè)
問題的提出，說(shuō)明實(shí)際的高性能服務(wù)器研發(fā)比較復(fù)雜，尤其
是采用高效I/O 模型來(lái)架構(gòu)服務(wù)器時(shí)，更是增加了開發(fā)的難
度，原因是這些模型的機(jī)制比較復(fù)雜。
底層網(wǎng)絡(luò)通信模塊是服務(wù)器應(yīng)用程序的核心模塊，也是
高性能服務(wù)器的最基礎(chǔ)模塊之一。它主要的功能是接收海量
并發(fā)連接、接收網(wǎng)絡(luò)數(shù)據(jù)包、暫存和發(fā)送應(yīng)用邏輯層的邏輯
數(shù)據(jù)包，所以，它也是上次應(yīng)用邏輯和底層網(wǎng)絡(luò)之間通信的
媒介。
2 IOCP 機(jī)制
要實(shí)現(xiàn)一個(gè)并發(fā)的網(wǎng)絡(luò)服務(wù)器，比較簡(jiǎn)單的模型是：每
當(dāng)一個(gè)請(qǐng)求到達(dá)就創(chuàng)建一個(gè)新線程，然后在新線程中為請(qǐng)求
服務(wù)。這種模型減輕了實(shí)際開發(fā)的復(fù)雜度，在并發(fā)連接較少
的情況下可以考慮使用，然而在高并發(fā)需求下并不適用。高
并發(fā)環(huán)境中，創(chuàng)建和銷毀大量線程所花費(fèi)的時(shí)間和消耗的系
統(tǒng)資源是巨大的，而且會(huì)加重線程調(diào)度的負(fù)擔(dān)，同時(shí)線程上
下文切換(context switch)也會(huì)浪費(fèi)許多寶貴的CPU 時(shí)間。
為了提高系統(tǒng)性能，首先必須有足夠的可運(yùn)行線程來(lái)充
分利用CPU 資源，但線程的數(shù)量不能太多。事實(shí)上，具體工
作線程的數(shù)量和并發(fā)連接數(shù)量不是直接相關(guān)聯(lián)的。在Win32
平臺(tái)下開發(fā)高效的服務(wù)器端應(yīng)用程序，最理想的模型是IOCP
模型，該模型解決了一系列系統(tǒng)性能瓶頸問題。
IOCP 提供了最好的可伸縮性，而且其執(zhí)行效率比較高，
采用這種網(wǎng)絡(luò)模型可能會(huì)加大開發(fā)的復(fù)雜度， 但卻是
Windows 平臺(tái)上唯一適用于開發(fā)高負(fù)載服務(wù)器的技術(shù)。
IOCPWindows 系統(tǒng)的一種內(nèi)核對(duì)象[3]，也是Win32 下最復(fù)雜
的一種I/O 模型，它通過一定數(shù)量的工作線程對(duì)重疊I/O 請(qǐng)
求進(jìn)行處理，以便為已經(jīng)完成的I/O 請(qǐng)求提供服務(wù)，相對(duì)其
他I/O 模型，它可以管理任意數(shù)量套接字句柄。它主要由等
待線程隊(duì)列和I/O 完成隊(duì)列2 個(gè)部分組成。一個(gè)完成端口對(duì)
象可以和多個(gè)套接字句柄相關(guān)聯(lián)，當(dāng)針對(duì)某個(gè)套接字句柄發(fā)
起的異步I/O 操作完成時(shí)，系統(tǒng)向該完成端口的I/O 完成隊(duì)
列加入一個(gè)I/O 完成包。于此同時(shí)， 工作線程調(diào)用
GetQueuedCompletionStatus(以下簡(jiǎn)稱GQCS)時(shí)，如果I/O 完
基金項(xiàng)目：廣東省教育部產(chǎn)學(xué)研結(jié)合基金資助項(xiàng)目“基于RFID 技
術(shù)石化產(chǎn)品計(jì)量監(jiān)控管理系統(tǒng)應(yīng)用研究與開發(fā)”(2007A090302094)
作者簡(jiǎn)介：王文武(1983－)，男，碩士研究生，主研方向：CAD，
企業(yè)信息化；趙衛(wèi)東，研究員、博士生導(dǎo)師；王志成，博士；陳悅、
韓下林，碩士研究生
收稿日期：2008-11-30 E-mail：jerry.wenwu@gmail.com
—104—
成隊(duì)列中有完成包，當(dāng)前調(diào)用就會(huì)返回，取得數(shù)據(jù)進(jìn)行后續(xù)
的處理。
成功創(chuàng)建一個(gè)完成端口后，便可開始將套接字句柄與對(duì)
象關(guān)聯(lián)到一起。但在關(guān)聯(lián)套接字之前，首先必須創(chuàng)建一個(gè)或
多個(gè)工作者線程為完成端口提供服務(wù)。
3 模塊設(shè)計(jì)方案
3.1 架構(gòu)設(shè)計(jì)
在充分考慮服務(wù)器性能和擴(kuò)展性的基礎(chǔ)上，本文提出了
基于三層結(jié)構(gòu)的系統(tǒng)設(shè)計(jì)方案，該模塊的架構(gòu)如圖1 所示。
#OnConnectionEstablished() : void
#OnReadCompleted() : void
#OnWriteCompleted() : void
CIocpServer
#HandleRecvMessage() : void
CTestServer
#OnConnectionEstablished() : void
#OnReadCompleted() : void
#OnWriteCompleted() : void
#HandleRecvMessage() : void
CUserServer
圖1 模塊設(shè)計(jì)架構(gòu)
圖1 看上去并不復(fù)雜，但卻是一個(gè)兼顧可擴(kuò)展性和高性
能的架構(gòu)，在實(shí)際項(xiàng)目應(yīng)用中也取得了很好的表現(xiàn)，下面是
對(duì)圖1 主要類的功能分析。
CIocpServer 類是完成端口服務(wù)器基本通信類，它使用
Windows 平臺(tái)特有的IOCP 機(jī)制，對(duì)網(wǎng)絡(luò)通信模型進(jìn)行底層
封裝。提供了基本的服務(wù)器端網(wǎng)絡(luò)通信功能，這些功能主要
有開啟服務(wù)器、關(guān)閉服務(wù)器、管理客戶端連接列表、管理未
決的接受請(qǐng)求列表、發(fā)出異步操作等。同時(shí)通過多態(tài)機(jī)制向
它的派生類提供以下基本擴(kuò)展接口：
(1)新連接確立的處理接口。
(2)客戶端斷開連接時(shí)的處理接口。
(3)連接出現(xiàn)錯(cuò)誤時(shí)的處理接口。
(4)從客戶端接收完數(shù)據(jù)后的處理接口。
(5)向客戶端發(fā)送完數(shù)據(jù)后的處理接口。
(6)拼包處理接口。
CUserServer 類繼承CIocpServer，在CIocpServer 的基礎(chǔ)
上，CUserServer 加入了一些服務(wù)器邏輯處理功能，并且封裝
了3 類數(shù)據(jù)隊(duì)列和3 類處理線程，分別如下：
(1)接收數(shù)據(jù)包隊(duì)列及接收線程：接收隊(duì)列用于存放接收
到的數(shù)據(jù)包，此數(shù)據(jù)包還沒有進(jìn)行邏輯意義上的拼包，接收
線程從此隊(duì)列中取出數(shù)據(jù)包，并將其拼裝成邏輯意義上完整
的數(shù)據(jù)包加入到邏輯數(shù)據(jù)包隊(duì)列中。
(2)邏輯數(shù)據(jù)包隊(duì)列及邏輯處理線程：邏輯隊(duì)列用于存放
已經(jīng)拼包成了邏輯意義上的數(shù)據(jù)包，邏輯處理線程對(duì)此類數(shù)
據(jù)包進(jìn)行邏輯解析，這里就是服務(wù)器的主要邏輯部分，有的
數(shù)據(jù)包在處理完成后，可能是需要向客戶端返回處理結(jié)果，
此時(shí)就需要邏輯線程將處理完成的數(shù)據(jù)包放入發(fā)送數(shù)據(jù)包隊(duì)
列中。
(3)發(fā)送數(shù)據(jù)包隊(duì)列及發(fā)送線程：發(fā)送隊(duì)列存放待發(fā)送的
數(shù)據(jù)包，發(fā)送線程根據(jù)數(shù)據(jù)包里的客戶端套接字發(fā)送給特定
客戶端。
CTestServer 類是一個(gè)測(cè)試類， 主要用于演示如何在
CUserServer 的基礎(chǔ)上派生一個(gè)真正的應(yīng)用服務(wù)器，并用于說(shuō)
明它需要重載實(shí)現(xiàn)CUserServer 的哪些重要虛函數(shù)。
3.2 資源管理
用IOCP 開發(fā)服務(wù)器時(shí)，當(dāng)I/O 發(fā)生錯(cuò)誤時(shí)需要有效地
釋放與套接字相關(guān)的緩存區(qū)，如果對(duì)同一緩存區(qū)釋放多次，
就會(huì)導(dǎo)致內(nèi)存釋放的錯(cuò)誤。當(dāng)投遞的異步I/O 請(qǐng)求返回了非
WSA_IO_PENDING 錯(cuò)誤時(shí)，要對(duì)此錯(cuò)誤進(jìn)行處理，通常執(zhí)
行2 步操作：釋放此次操作使用的緩沖區(qū)數(shù)據(jù)；關(guān)閉當(dāng)前操
作所使用的套接字句柄。同時(shí)GQCS 調(diào)用會(huì)返回FALSE，也
要做上面2 步相同的操作，這樣就可能產(chǎn)生對(duì)同一緩存區(qū)進(jìn)
行重復(fù)釋放的錯(cuò)誤。解決的辦法可以有2 種：
(1)通過引用計(jì)數(shù)機(jī)制控制緩存區(qū)釋放；
(2)使緩存區(qū)釋放操作線性化。
該系統(tǒng)的設(shè)計(jì)采用了第(2)種解決方案，所謂的釋放操作
線性化是指把可能引起2 次釋放同一緩存區(qū)的操作合并為一
次釋放。如果在執(zhí)行異步I/O 操作過程中發(fā)生了非WSA_ IO_
PENDING 錯(cuò)誤，可以讓GQCS 返回時(shí)得知這個(gè)錯(cuò)誤和發(fā)生
錯(cuò)誤時(shí)的緩存區(qū)指針，而不對(duì)該錯(cuò)誤進(jìn)行處理。通知的方式
是，使用PostQueuedCompletionStatus(以下簡(jiǎn)稱Post)函數(shù)拋
出一個(gè)特殊標(biāo)志的消息，這個(gè)特殊標(biāo)志可以通過GQCS 函數(shù)
的第2 個(gè)參數(shù)，即傳送字節(jié)數(shù)來(lái)表示，可以選擇任何一個(gè)不
可能出現(xiàn)的值，比如一個(gè)負(fù)數(shù)。當(dāng)然，如果通過單句柄數(shù)據(jù)
或單I/O 數(shù)據(jù)來(lái)傳遞也是可以的。而發(fā)生錯(cuò)誤時(shí)的緩沖區(qū)指
針，必須要通過單句柄數(shù)據(jù)或單I/O 數(shù)據(jù)來(lái)傳遞。
把釋放操作全放在GQCS 函數(shù)里以后，對(duì)釋放操作的處
理就比較統(tǒng)一了。當(dāng)然，為了實(shí)現(xiàn)真正的線性化和原子化，
在釋放操作的執(zhí)行邏輯上需要對(duì)釋放代碼加鎖以實(shí)現(xiàn)線程互
斥(多線程情況下)。
3.3 包的亂序解決方案
如果在同一個(gè)套接字上一次提交多個(gè)異步I/O 請(qǐng)求，肯
定會(huì)按照它們提交的次序完成，但在多線程環(huán)境下，完成包
處理次序可能和提交次序不一致。該問題的一個(gè)簡(jiǎn)單的解決
方法是一次只投遞一個(gè)異步I/O 請(qǐng)求，當(dāng)工作線程處理完該
請(qǐng)求的完成數(shù)據(jù)包后，再投遞下一個(gè)異步I/O 請(qǐng)求。但這樣
做會(huì)降低服務(wù)器的處理性能。為了保證完成包處理次序和提
交次序相一致，可以為每個(gè)連接上投遞的請(qǐng)求都分配一個(gè)序
號(hào)，單句柄數(shù)據(jù)中記錄當(dāng)前需要讀取的單I/O 數(shù)據(jù)的序號(hào)，
如果工作線程獲得的單I/O 數(shù)據(jù)的序號(hào)與單句柄數(shù)據(jù)中記錄
的序號(hào)一致的話，就處理該數(shù)據(jù)。如果不相等，則把這個(gè)單
I/O 數(shù)據(jù)保存到該連接的pOutOfOrderReads 列表中。
4 性能優(yōu)化
在網(wǎng)絡(luò)服務(wù)器的開發(fā)過程中，池(Pool)技術(shù)已經(jīng)被廣泛應(yīng)
用。使用池技術(shù)在一定層度上可以明顯優(yōu)化服務(wù)器應(yīng)用程序
的性能，提高程序執(zhí)行效率和降低系統(tǒng)資源開銷。這里所說(shuō)
的池是一種廣義上的池，比如數(shù)據(jù)庫(kù)連接池、線程池、內(nèi)存
池、對(duì)象池等。其中，對(duì)象池可以看成保存對(duì)象的容器，在
進(jìn)程初始化時(shí)創(chuàng)建一定數(shù)量的對(duì)象，需要時(shí)直接從池中取出
一個(gè)空閑對(duì)象，用完后并不直接釋放掉對(duì)象，而是再放到對(duì)
象池中以方便下一次對(duì)象請(qǐng)求可以直接復(fù)用。其他幾種池的
設(shè)計(jì)思想也是如此，池技術(shù)的優(yōu)勢(shì)是，可以消除對(duì)象創(chuàng)建所
—105—
帶來(lái)的延遲，從而提高系統(tǒng)的性能。
4.1 線程池
線程池[4]是提高服務(wù)器程序性能的一種很好技術(shù)，在
Win32 平臺(tái)下開發(fā)的網(wǎng)絡(luò)服務(wù)器程序使用的線程池可分為兩
類：一類是由完成端口對(duì)象負(fù)責(zé)維護(hù)的工作線程池，主要負(fù)
責(zé)網(wǎng)絡(luò)層相關(guān)處理(比如投遞異步讀或?qū)懖僮鞯?；另一類是
負(fù)責(zé)邏輯處理的線程池，它是專門提供給應(yīng)用層來(lái)使用的。
本文提出了一種邏輯線程池的設(shè)計(jì)方案，線程池框架結(jié)構(gòu)主
要分為以下幾個(gè)部分：
(1)線程池管理器：用于創(chuàng)建并管理線程，往任務(wù)隊(duì)列添
加數(shù)據(jù)包等，并可以動(dòng)態(tài)增加工作線程。
(2)工作線程：線程池中的線程，執(zhí)行實(shí)際的邏輯處理。
(3)任務(wù)接口：每個(gè)任務(wù)必須實(shí)現(xiàn)的接口，以供工作線程
調(diào)度任務(wù)使用。
(4)任務(wù)隊(duì)列：提供一種緩存機(jī)制，用于存放從網(wǎng)絡(luò)層接
收的數(shù)據(jù)包。
該通信模塊使用了上述線程池的設(shè)計(jì)方案，從測(cè)試結(jié)果
來(lái)看，當(dāng)并發(fā)連接數(shù)很大時(shí)，線程池對(duì)服務(wù)器的性能改善是
顯著的。
該設(shè)計(jì)方案有個(gè)很好的特性，就是可以創(chuàng)建工作線程數(shù)
量固定的線程池，也可以創(chuàng)建動(dòng)態(tài)線程池。如果有大量的客
戶要求服務(wù)器為其服務(wù)，但由于線程池的工作線程是有限的
話，服務(wù)器只能為部分客戶端服務(wù)，客戶端提交的任務(wù)只能
在任務(wù)隊(duì)列中等待處理。動(dòng)態(tài)改變的工作線程數(shù)目的線程池，
可以以適應(yīng)突發(fā)性的請(qǐng)求。一旦請(qǐng)求變少了將逐步減少線程
池中工作線程的數(shù)目。當(dāng)然線程增加可以采用一種超前方式，
即批量增加一批工作線程，而不是來(lái)一個(gè)請(qǐng)求才建立創(chuàng)建一
個(gè)線程。批量創(chuàng)建是更加有效的方式，而且該方案還限制了
線程池中工作線程數(shù)目的上限和下限，確保線程池技術(shù)能提
高系統(tǒng)整體性能。
4.2 對(duì)象池
對(duì)象池[5-6]是針對(duì)特定應(yīng)用程序而設(shè)計(jì)的內(nèi)存管理方式，
在某種場(chǎng)合下內(nèi)存的分配和釋放性能會(huì)大大提升。默認(rèn)的內(nèi)
存管理函數(shù)(new/delete 或malloc/free)有其不足之處，如果應(yīng)
用程序頻繁地在堆上分配和釋放內(nèi)存，那么就會(huì)導(dǎo)致性能損
失，并且會(huì)使系統(tǒng)中出現(xiàn)大量的內(nèi)存碎片，降低內(nèi)存的利
用率。
所謂對(duì)象池就是應(yīng)用程序可以通過系統(tǒng)的內(nèi)存分配調(diào)用
預(yù)先一次性申請(qǐng)適當(dāng)大小的內(nèi)存塊，然后可以根據(jù)特定對(duì)象
的大小，把該塊內(nèi)存分割成一個(gè)個(gè)大小相同的對(duì)象。如果對(duì)
象池中沒有空閑對(duì)象使用時(shí)，可以再向系統(tǒng)申請(qǐng)同樣大小的
內(nèi)存塊。如果對(duì)象使用完畢后直接放到對(duì)象池中，這種內(nèi)存
管理策略能有效地提升程序性能。
4.2.1 對(duì)象池的應(yīng)用
當(dāng)服務(wù)器接受一個(gè)客戶端請(qǐng)求后，會(huì)創(chuàng)建成功返回一個(gè)
客戶端套接字句柄。如果出現(xiàn)大量并發(fā)客戶端連接請(qǐng)求時(shí)，
就會(huì)出現(xiàn)頻繁地分配和釋放對(duì)象的情況，這個(gè)過程可能會(huì)消
耗大量的系統(tǒng)資源，有損系統(tǒng)性能。WinSock2 還提供一個(gè)接
受擴(kuò)展函數(shù)AcceptEx，它允許在接受連接之前就事先創(chuàng)建一
個(gè)套接字句柄，使之與接受連接相關(guān)聯(lián)。在調(diào)用AcceptEx 時(shí)，
可以直接把該句柄作為參數(shù)傳遞給AcceptEx。有了這個(gè)保證，
可以通過采用對(duì)象池技術(shù)來(lái)提升系統(tǒng)性能，可以在接受連接
之前就創(chuàng)建一定數(shù)量的套接字句柄，隨著新連接請(qǐng)求的到來(lái)
將句柄分配出去，當(dāng)客戶端斷開連接后，把相應(yīng)句柄重新放
入套接字對(duì)象池中。
另外需要用到對(duì)象池的地方是，在每一次投遞WSASend
或WSARecv 操作時(shí)，都要傳進(jìn)一個(gè)重疊結(jié)構(gòu)體參數(shù)。可以
提前創(chuàng)建一個(gè)重疊結(jié)構(gòu)體對(duì)象池，當(dāng)發(fā)起異步I/O 操作時(shí)，
先從池中取一個(gè)結(jié)構(gòu)體對(duì)象，用完之后并不直接銷毀，而是
再放回對(duì)象池以便以后重復(fù)利用。創(chuàng)建的結(jié)構(gòu)體數(shù)量取決于
完成端口的處理效率，如果處理效率比較高，則數(shù)量可能就
少些，反之，就需要多創(chuàng)建些對(duì)象。
該系統(tǒng)所設(shè)計(jì)的對(duì)象池是線程安全的，可以被多個(gè)線程
共享，在獲得和釋放對(duì)象時(shí)都需要加鎖，從而保證線程間互
斥訪問對(duì)象池。
4.2.2 對(duì)象池的優(yōu)點(diǎn)
與系統(tǒng)直接管理內(nèi)存相比，對(duì)象池在系統(tǒng)性能優(yōu)化方面
主要有如下優(yōu)點(diǎn)：
(1)針對(duì)特殊情況，例如需要頻繁分配和釋放固定大小的
對(duì)象時(shí)，不需要復(fù)雜的分配算法和線程同步。也不需要維護(hù)
內(nèi)存空閑表的額外開銷，從而獲得較好的性能。
(2)由于直接分配一定數(shù)量的連續(xù)內(nèi)存空間作為內(nèi)存塊，
因此一定程度上提高了程序局部性能，提升了應(yīng)用程序整體
性能。
(3)比較容易控制頁(yè)邊界對(duì)齊和內(nèi)存字節(jié)對(duì)齊，基本沒有
內(nèi)存碎片問題。
4.3 環(huán)形緩存區(qū)
基于TCP 協(xié)議的服務(wù)器應(yīng)用程序，拼包處理過程必不可
少。由于要從接收緩存中分解出一個(gè)個(gè)邏輯數(shù)據(jù)包，因此一
般都要涉及內(nèi)存拷貝操作，過多的內(nèi)存拷貝必然降低系統(tǒng)
性能。
當(dāng)然，就邏輯數(shù)據(jù)包的拼裝問題而言，也完全可以避免
數(shù)據(jù)拷貝操作，方法是使用環(huán)形緩沖區(qū)。本文所說(shuō)的環(huán)形緩
沖區(qū)是具體這種特征的接收緩沖區(qū)，在服務(wù)器的接收事件里，
當(dāng)處理完了一次從緩沖區(qū)里取走所有完整邏輯包的操作后，
可能會(huì)在緩沖區(qū)里遺留下來(lái)新的不完整數(shù)據(jù)包。使用了環(huán)形
緩沖區(qū)后，就可以不將數(shù)據(jù)重新復(fù)制到緩沖區(qū)首部以等待后
續(xù)數(shù)據(jù)的拼裝，可以根據(jù)記錄下的隊(duì)列首部和隊(duì)列尾部指針
進(jìn)行下一次的拼包操作。
環(huán)形緩沖區(qū)在IOCP 的處理中，甚至在其他需要高效率
處理數(shù)據(jù)收發(fā)的網(wǎng)絡(luò)模型的接收事件處理中，是一種被廣泛
采用的優(yōu)化方案。
5 實(shí)驗(yàn)結(jié)果
為了證明論文中系統(tǒng)優(yōu)化的方法能獲得預(yù)期的性能優(yōu)
勢(shì)，對(duì)內(nèi)存池和系統(tǒng)整體性能進(jìn)行了實(shí)驗(yàn)測(cè)試。測(cè)試硬件是：
CPU：AMD Turion 64，內(nèi)存：1 024 MB，網(wǎng)絡(luò)：100 MB 局
域網(wǎng)，操作系統(tǒng)：Windows XP Professional SP2。
測(cè)試1：對(duì)象池性能測(cè)試
由表1 可以看出，由于使用對(duì)象池來(lái)分配小對(duì)象的內(nèi)存，
速度提高了52.48%，使得內(nèi)存分配獲得了顯著的效率提升。
速度提高的原因可以歸結(jié)為以下幾點(diǎn)：
(1)除了偶爾的內(nèi)存申請(qǐng)和銷毀會(huì)導(dǎo)致從進(jìn)程堆中分配
和銷毀內(nèi)存塊外，絕大多數(shù)的內(nèi)存申請(qǐng)和銷毀都由對(duì)象池在
已經(jīng)申請(qǐng)到的內(nèi)存塊中進(jìn)行，而沒有直接與進(jìn)程打交道，而
直接與進(jìn)程打交道是很耗時(shí)的操作。
(2)這是在單線程環(huán)境的對(duì)象池，在多線程環(huán)境下，由于
加鎖，因此速度提高的會(huì)少些。
（下轉(zhuǎn)第114 頁(yè)）