|
引言 文件操作是應(yīng)用程序最為基本的功能之一,Win32 API和MFC均提供有支持文件處理的函數(shù)和類,常用的有Win32 API的CreateFile()、WriteFile()、ReadFile()和MFC提供的CFile類等。一般來說,以上這些函數(shù)可以滿足大多數(shù)場合的要求,但是對于某些特殊應(yīng)用領(lǐng)域所需要的動輒幾十GB、幾百GB、乃至幾TB的海量存儲,再以通常的文件處理方法進行處理顯然是行不通的。目前,對于上述這種大文件的操作一般是以內(nèi)存映射文件的方式來加以處理的,本文下面將針對這種Windows核心編程技術(shù)展開討論。 內(nèi)存映射文件概述 內(nèi)存文件映射也是Windows的一種內(nèi)存管理方法,提供了一個統(tǒng)一的內(nèi)存管理特征,使應(yīng)用程序可以通過內(nèi)存指針對磁盤上的文件進行訪問,其過程就如同對加載了文件的內(nèi)存的訪問。通過文件映射這種使磁盤文件的全部或部分內(nèi)容與進程虛擬地址空間的某個區(qū)域建立映射關(guān)聯(lián)的能力,可以直接對被映射的文件進行訪問,而不必執(zhí)行文件I/O操作也無需對文件內(nèi)容進行緩沖處理。內(nèi)存文件映射的這種特性是非常適合于用來管理大尺寸文件的。 在使用內(nèi)存映射文件進行I/O處理時,系統(tǒng)對數(shù)據(jù)的傳輸按頁面來進行。至于內(nèi)部的所有內(nèi)存頁面則是由虛擬內(nèi)存管理器來負責(zé)管理,由其來決定內(nèi)存頁面何時被分頁到磁盤,哪些頁面應(yīng)該被釋放以便為其它進程提供空閑空間,以及每個進程可以擁有超出實際分配物理內(nèi)存之外的多少個頁面空間等等。由于虛擬內(nèi)存管理器是以一種統(tǒng)一的方式來處理所有磁盤I/O的(以頁面為單位對內(nèi)存數(shù)據(jù)進行讀寫),因此這種優(yōu)化使其有能力以足夠快的速度來處理內(nèi)存操作。 使用內(nèi)存映射文件時所進行的任何實際I/O交互都是在內(nèi)存中進行并以標(biāo)準(zhǔn)的內(nèi)存地址形式來訪問。磁盤的周期性分頁也是由操作系統(tǒng)在后臺隱蔽實現(xiàn)的,對應(yīng)用程序而言是完全透明的。內(nèi)存映射文件的這種特性在進行大文件的磁盤事務(wù)操作時將獲得很高的效益。 需要說明的是,在系統(tǒng)的正常的分頁操作過程中,內(nèi)存映射文件并非一成不變的,它將被定期更新。如果系統(tǒng)要使用的頁面目前正被某個內(nèi)存映射文件所占用,系統(tǒng)將釋放此頁面,如果頁面數(shù)據(jù)尚未保存,系統(tǒng)將在釋放頁面之前自動完成頁面數(shù)據(jù)到磁盤的寫入。 對于使用頁虛擬存儲管理的Windows操作系統(tǒng),內(nèi)存映射文件是其內(nèi)部已有的內(nèi)存管理組件的一個擴充。由可執(zhí)行代碼頁面和數(shù)據(jù)頁面組成的應(yīng)用程序可根據(jù)需要由操作系統(tǒng)來將這些頁面換進或換出內(nèi)存。如果內(nèi)存中的某個頁面不再需要,操作系統(tǒng)將撤消此頁面原擁用者對它的控制權(quán),并釋放該頁面以供其它進程使用。只有在該頁面再次成為需求頁面時,才會從磁盤上的可執(zhí)行文件重新讀入內(nèi)存。同樣地,當(dāng)一個進程初始化啟動時,內(nèi)存的頁面將用來存儲該應(yīng)用程序的靜態(tài)、動態(tài)數(shù)據(jù),一旦對它們的操作被提交,這些頁面也將被備份至系統(tǒng)的頁面文件,這與可執(zhí)行文件被用來備份執(zhí)行代碼頁面的過程是很類似的。圖1展示了代碼頁面和數(shù)據(jù)頁面在磁盤存儲器上的備份過程: ![]() 圖1 進程的代碼頁、數(shù)據(jù)頁在磁盤存儲器上的備份 顯然,如果可以采取同一種方式來處理代碼和數(shù)據(jù)頁面,無疑將會提高程序的執(zhí)行效率,而內(nèi)存映射文件的使用恰恰可以滿足此需求。 對大文件的管理 內(nèi)存映射文件對象在關(guān)閉對象之前并沒有必要撤銷內(nèi)存映射文件的所有視圖。在對象被釋放之前,所有的臟頁面將自動寫入磁盤。通過CloseHandle()關(guān)閉內(nèi)存映射文件對象,只是釋放該對象,如果內(nèi)存映射文件代表的是磁盤文件,那么還需要調(diào)用標(biāo)準(zhǔn)文件I/O函數(shù)來將其關(guān)閉。在處理大文件處理時,內(nèi)存映射文件將表示出卓越的優(yōu)勢,只需要消耗極少的物理資源,對系統(tǒng)的影響微乎其微。下面先給出內(nèi)存映射文件的一般編程流程框圖: ![]() 圖2 使用內(nèi)存映射文件的一般流程 而在某些特殊行業(yè),經(jīng)常要面對十幾GB乃至幾十GB容量的巨型文件,而一個32位進程所擁有的虛擬地址空間只有232 = 4GB,顯然不能一次將文件映像全部映射進來。對于這種情況只能依次將大文件的各個部分映射到進程中的一個較小的地址空間。這需要對上面的一般流程進行適當(dāng)?shù)母模?br> 1)映射文件開頭的映像。 2)對該映像進行訪問。 3)取消此映像 4)映射一個從文件中的一個更深的位移開始的新映像。 5)重復(fù)步驟2,直到訪問完全部的文件數(shù)據(jù)。 下面給出一段根據(jù)此描述而寫出的對大于4GB的文件的處理代碼:
在本例中,首先通過GetFileSize()得到被處理文件長度(64位)的高32位和低32位值。然后在映射過程中設(shè)定每次映射的塊大小為1000倍的分配粒度,如果文件長度小于1000倍的分配粒度時則將塊大小設(shè)置為文件的實際長度。在處理過程中由映射、訪問、撤消映射構(gòu)成了一個循環(huán)處理。其中,每處理完一個文件塊后都通過關(guān)閉文件映射對象來對每個文件塊進行整理。CreateFileMapping()、MapViewOfFile()等函數(shù)是專門用來進行內(nèi)存文件映射處理用的。 下面分別對這些關(guān)鍵函數(shù)進行說明: 1)CreateFile():CreateFile()函數(shù)是一個用途非常廣泛的函數(shù), 在這里的用法并沒有什么特殊的地方,但有幾點需要注意:一是訪問模式參數(shù)dwDesiredAccess。該參數(shù)設(shè)置了對文件內(nèi)核對象的訪問類型,其允許設(shè)置的權(quán)限可以為讀權(quán)限GENERIC_READ、寫權(quán)限GENERIC_WRITE、讀寫權(quán)限GENERIC_READ | GENERIC_WRITE和設(shè)備查詢權(quán)限0。在使用映射文件時,只能打開那些具有可讀訪問權(quán)限的文件,即只能應(yīng)用GENERIC_READ和GENERIC_READ | GENERIC_WRITE這兩種組合;另一點需要注意的是共享模式參數(shù)dwShareMode。該參數(shù)定義了對文件內(nèi)核對象的共享方式,其可能的設(shè)置為FILE_SHARE_READ、FILE_SHARE_WRITE和0,并可對其組合使用。其中,設(shè)置為0時不允許共享對象;FILE_SHARE_READ和FILE_SHARE_WRITE分別為在要求只讀、只寫訪問的情況下才允許對象的共享。 由于通過內(nèi)存映射文件可以在多個進程間共享數(shù)據(jù),因此在進行這種應(yīng)用時應(yīng)當(dāng)考慮dwShareMode參數(shù)設(shè)置對運行結(jié)果的影響。 2)CreateFileMapping():該函數(shù)的作用是創(chuàng)建一個文件映射內(nèi)核對象,以告知系統(tǒng)文件映射對象需要多大的物理存儲器。創(chuàng)建內(nèi)存映射文件對象對系統(tǒng)資源幾乎沒有什么影響,也不會影響進程的虛擬地址空間。除了需要用來表示該對象的內(nèi)部資源之外通常并不用為其分配虛擬內(nèi)存,但是如果內(nèi)存映射文件對象是作共享內(nèi)存之用的話,就要在創(chuàng)建對象時由系統(tǒng)為內(nèi)存映射文件的使用在系統(tǒng)頁文件中保留足夠的空間。 函數(shù)第一個參數(shù)hFile為標(biāo)識要映射到進程的地址空間的文件的句柄。雖然由于內(nèi)存映射文件的物理存儲器是來自于磁盤上的文件,而非系統(tǒng)的頁文件,使創(chuàng)建內(nèi)存映射文件就像保留一個地址空間區(qū)域并將物理存儲器提交給該區(qū)域一樣。第二個參數(shù)為指向文件映射內(nèi)核對象的SECURITY_ATTRIBUTES結(jié)構(gòu)的指針,由此來決定子進程能否繼承得到返回的句柄。通常為其傳遞NULL值,以默認(rèn)的安全屬性來禁止返回句柄的被繼承。 接下來的參數(shù)用于文件被映射后設(shè)定文件映像的保護屬性。其可能的取值為PAGE_READONLY、PAGE_READWRITE和PAGE_WRITECOPY。雖然在創(chuàng)建文件映射對象時,系統(tǒng)并不為其保留地址空間區(qū)域,也不將文件的存儲器映射到該區(qū)域。但是,在系統(tǒng)將存儲器映射到進程的地址空間中去時,系統(tǒng)必須確切知道應(yīng)賦予物理存儲器頁面的保護屬性。在設(shè)置保護屬性時,必須與用CreateFile()函數(shù)打開文件時所指定的訪問標(biāo)識相匹配,否則將導(dǎo)致CreateFileMapping()的執(zhí)行失敗。因此這里設(shè)置PAGE_READWRITE屬性。除了上述三個頁面保護屬性外,還有4個區(qū)(Section)保護屬性也可以一起組合使用:
后面的兩個參數(shù)指定了要創(chuàng)建的文件映射對象的最大字節(jié)數(shù)的高32位值和低32位值,實際也就設(shè)定了文件的最大字節(jié)數(shù)(最大可以處理16EB的文件)。這兩個參數(shù)可以滿足確保文件映射對象能夠得到足夠的物理存儲器這一基本條件。在參數(shù)設(shè)置的大小小于文件實際大小時,系統(tǒng)將從文件映射指定的字節(jié)數(shù)。這里將其設(shè)置為0,將使所創(chuàng)建的文件映射對象將為文件的當(dāng)前大小,以上兩種情況均無法改變文件的大小。如果設(shè)置的參數(shù)大于文件的實際大小,系統(tǒng)將會在CreateFileMapping()函數(shù)返回前擴展該文件。需要指出的是,文件映射對象的大小是靜態(tài)的,一旦創(chuàng)建完畢后將無法更改。如果設(shè)置的文件映射對象尺寸偏小將導(dǎo)致無法對文件進行全面的訪問。 在本節(jié)開始也曾提到過,創(chuàng)建文件映射對象是不需要花費什么系統(tǒng)資源的,因此遵循"寧多勿缺"的原則,一般應(yīng)將文件映射對象的大小設(shè)置為文件大小的相同值。函數(shù)最后的參數(shù)將可以為映射對象命名。如果想打開一個已存在的文件映射對象,該對象必須要命名。對該名字字符串的要求僅限于未被其它對象使用過的名字即可。 CreateFileMapping()在成功執(zhí)行后將返回一個指向文件映射對象的句柄。如果對一個已經(jīng)存在的文件映射對象調(diào)用了CreateFileMapping()函數(shù),進程將得到一個指向現(xiàn)有映射對象的句柄。通過調(diào)用GetLastError()可以得到返回值ERROR_ALREADY_EXIST,由此可以判斷當(dāng)前得到的內(nèi)存映射對象句柄是新創(chuàng)建的還是打開已經(jīng)存在的。如果系統(tǒng)無法創(chuàng)建文件映射對象,將導(dǎo)致CreateFileMapping()的執(zhí)行失敗,返回N U L L句柄值。 3)MapViewOfFile():當(dāng)創(chuàng)建了一個內(nèi)存映射文件對象并得到其有效句柄后,該句柄即可用來在進程的虛擬地址空間中映射文件的一個映像。在內(nèi)存映射文件對象已經(jīng)存在的情況下,映像可被任意映射或取消映射。在文件映像被映射時,仍然必須由系統(tǒng)來為文件的數(shù)據(jù)保留一個地址空間區(qū)域,并將文件的數(shù)據(jù)作為映射到該區(qū)域的物理存儲器進行提交。在進程的地址空間中,一個足夠大的連續(xù)地址空間(通常足以覆蓋整個文件映像)將被指定給此文件映像。盡管如此,內(nèi)存的物理頁面還是根據(jù)在實際使用中的需求而進行分配的。真正分配一個對應(yīng)于內(nèi)存映射文件映像頁面的物理內(nèi)存頁面是在發(fā)生該頁的缺頁中斷時進行的,這將在第一次讀寫內(nèi)存頁面中的任一地址時自動完成。MapViewOfFile()即負責(zé)映射內(nèi)存映射文件的一個映像,
函數(shù)的第一個參數(shù)為CreateFileMapping()所返回的內(nèi)存映射文件對象句柄,第二個參數(shù)指定了對文件映像的訪問類型,可能取值有FILE_MAP_WRITE、FILE_MAP_READ、FILE_MAP_ALL_ACCESS和FILE_MAP_COPY等幾種,具體的設(shè)置要根據(jù)文件映射對象允許的保護模式而定。根據(jù)前面代碼的設(shè)置,這里應(yīng)該使用FILE_MAP_ALL_ACCESS參數(shù)。這種機制為對象的創(chuàng)建者提供了對映射此對象的方式進行控制的能力。接下來的2個參數(shù)分別指定了內(nèi)存映射文件的64位偏移地址的低32位和高32位地址,該地址是從內(nèi)存映射文件頭位置到映像開始位置的距離。最后的參數(shù)指定了視圖的大小,如果設(shè)置為0,前面的偏移地址將被忽略,系統(tǒng)將會把整個文件映射為一個映像。MapViewOfFile()如果成功執(zhí)行,將返回一個指向文件映像在進程的地址空間中的起始地址的指針。如果失敗,則返回NULL。在進程中,可以為同一個文件映射對象創(chuàng)建多個文件映像,這些映像可以在系統(tǒng)中共存和重疊,也可以與對應(yīng)的文件映射對象大小不相一致,但不能大于文件映射對象的大小。 4)UnmapViewOfFile():當(dāng)不再需要保留映射到進程地址空間區(qū)域中的文件映像數(shù)據(jù)時,可通過調(diào)用UnmapViewOfFile()函數(shù)將其釋放。該函數(shù)結(jié)構(gòu)非常簡單,只需要提供映像在進程中的起始地址(區(qū)域的基地址)作為參數(shù)即可。該函數(shù)的輸入?yún)?shù)為調(diào)用MapViewOfFile()時所返回的指向文件映像在進程的地址空間中的起始地址的指針。在調(diào)用MapViewOfFile()后,必須確保在進程退出之前能夠執(zhí)行UnmapViewOfFile()函數(shù),否則在進程終止之后先前保留的區(qū)域?qū)⒌貌坏结尫牛词乖俅螁舆M程重復(fù)調(diào)用MapViewOfFile()系統(tǒng)也總是在進程的地址空間中保留一個新的區(qū)域,而此前保留的所有區(qū)域?qū)⒌貌坏结尫拧?br> 一種比較特殊的情況是,對同一個內(nèi)存映射文件映射了兩個相同的映像的撤消。前面曾經(jīng)提到過,對于同一個內(nèi)存映射文件可以有多個映像,這些映像也可以重疊,因此這種情況的存在是合法的。對于這種情況,雖然從表面看上去在單進程的地址空間內(nèi)是不可能存在兩個基地址完全相同的映像的,這將導(dǎo)致無法對這它們的區(qū)分。但是事實上,由MapViewOfFile()所返回得到的基地址只是文件映像在進程地址空間中的起始基地址,因此在映射同一內(nèi)存映射文件的兩個相同映像時將會產(chǎn)生對內(nèi)存映射文件同一部分的兩個不同基地址的相同映像,可以用同樣的方法調(diào)用UnmapViewOfFile()將其從進程的地址空間中予以撤消。 5)CloseHandle(): 與Win32的大多數(shù)對象一樣,在使用完畢之后總是要通過CloseHandle()函數(shù)將已打開的內(nèi)核對象關(guān)閉。如果忘記關(guān)閉對象,在程序繼續(xù)運行時將會出現(xiàn)資源泄漏。雖然在程序退出運行時,操作系統(tǒng)會自動關(guān)閉在進程中已經(jīng)打開但未關(guān)閉的任何對象。但是在進程的運行過程中,勢必會積累過多的資源句柄。因此在不再需要使用對象的時候通過CloseHandle()將其予以關(guān)閉是有意義的。 小結(jié) 本文對內(nèi)存映射文件在大文件處理中的應(yīng)用作了較為詳細的闡述。經(jīng)實際測試,內(nèi)存映射文件在處理大數(shù)據(jù)量文件時表現(xiàn)出了良好的性能,比通常使用CFile類和ReadFile()和WriteFile()等函數(shù)的文件處理方式具有明顯的優(yōu)勢。本文所述程序代碼在Windows 2000 Professional下由Microsoft Visual C++ 6.0編譯通過。 |
|
|