CreateFileMapping的使用

測試創建和打開文件映射的時候老是得到"句柄無效"的錯誤, 仔細看了MSDN以后才發覺是函數認識不透, 這里把相關的解釋翻譯出來
HANDLE CreateFileMapping(
HANDLE hFile, //物理文件句柄
LPSECURITY_ATTRIBUTES lpAttributes, //安全設置
DWORD flProtect, //保護設置
DWORD dwMaximumSizeHigh, //高位文件大小
DWORD dwMaximumSizeLow, //低位文件大小
LPCTSTR lpName //共享內存名稱
);

1) 物理文件句柄
任何可以獲得的物理文件句柄, 如果你需要創建一個物理文件無關的內存映射也無妨, 將它設置成為 0xFFFFFFFF(INVALID_HANDLE_VALUE)就可以了.

如果需要和物理文件關聯, 要確保你的物理文件創建的時候的訪問模式和"保護設置"匹配, 比如: 物理文件只讀, 內存映射需要讀寫就會發生錯誤. 推薦你的物理文件使用獨占方式創建.

如果使用 INVALID_HANDLE_VALUE, 也需要設置需要申請的內存空間的大小, 無論物理文件句柄參數是否有效, 這樣 CreateFileMapping 就可以創建一個和物理文件大小無關的內存空間給你, 甚至超過實際文件大小, 如果你的物理文件有效, 而大小參數為0, 則返回給你的是一個和物理文件大小一樣的內存空間地址范圍. 返回給你的文件映射地址空間是可以通過復制, 集成或者命名得到, 初始內容為0.

2) 保護設置
就是安全設置, 不過一般設置NULL就可以了, 使用默認的安全配置. 在win2k下如果需要進行限制, 這是針對那些將內存文件映射共享給整個網絡上面的應用進程使用是, 可以考慮進行限制.

3) 高位文件大小
弟兄們, 我想目前我們的機器都是32位的東東, 不可能得到超過32位進程所能尋址的私有32位地址空間, 一般還是設置0吧, 我沒有也不想嘗試將它設置超過0的情況.
4) 低位文件大小
這個還是可以進行設置的, 不過為了讓其他共享用戶知道你申請的文件映射的相關信息, 我使用的時候是在獲得的地址空間頭部添加一個結構化描述信息, 記錄內存映射的大小, 名稱等, 這樣實際申請的空間就比輸入的增加了一個頭信息結構大小了, 我認為這樣類似BSTR的方式應該是比較合理的.

5) 共享內存名稱
這個就是我今天測試的時候碰壁的禍根, 因為為了對于內存進行互斥訪問, 我設置了一個互斥句柄, 而名稱我選擇和命名共享內存同名, 之下就是因為他們使用共同的namespace導致了錯誤, 呵呵.

7) 調用CreateFileMapping的時候GetLastError的對應錯誤
ERROR_FILE_INVALID 如果企圖創建一個零長度的文件映射, 應有此報
ERROR_INVALID_HANDLE 如果發現你的命名內存空間和現有的內存映射, 互斥量, 信號量, 臨界區同名就麻煩了
ERROR_ALREADY_EXISTS 表示內存空間命名已經存在

8) 相關服務或者平臺的命名保留
Terminal Services:
命名可以包含 "Global" 或者 "Local" 前綴在全局或者會話名空間初級文件映射. 其他部分可以包含任何除了()以外的字符, 可以參考 Kernel Object Name Spaces.




　摘要： 本文給出了一種方便實用的解決大文件的讀取、存儲等處理的方法，并結合相關程序代碼對具體的實現過程進行了介紹。

　　引言

　　文件操作是應用程序最為基本的功能之一，Win32 API和MFC均提供有支持文件處理的函數和類，常用的有Win32 API的CreateFile()、WriteFile()、ReadFile()和MFC提供的CFile類等。一般來說，以上這些函數可以滿足大多數場合的要求，但是對于某些特殊應用領域所需要的動輒幾十GB、幾百GB、乃至幾TB的海量存儲，再以通常的文件處理方法進行處理顯然是行不通的。目前，對于上述這種大文件的操作一般是以內存映射文件的方式來加以處理的，本文下面將針對這種Windows核心編程技術展開討論。

　　內存映射文件

　　內存映射文件與虛擬內存有些類似，通過內存映射文件可以保留一個地址空間的區域，同時將物理存儲器提交給此區域，只是內存文件映射的物理存儲器來自一個已經存在于磁盤上的文件，而非系統的頁文件，而且在對該文件進行操作之前必須首先對文件進行映射，就如同將整個文件從磁盤加載到內存。由此可以看出，使用內存映射文件處理存儲于磁盤上的文件時，將不必再對文件執行I/O操作，這意味著在對文件進行處理時將不必再為文件申請并分配緩存，所有的文件緩存操作均由系統直接管理，由于取消了將文件數據加載到內存、數據從內存到文件的回寫以及釋放內存塊等步驟，使得內存映射文件在處理大數據量的文件時能起到相當重要的作用。另外，實際工程中的系統往往需要在多個進程之間共享數據，如果數據量小，處理方法是靈活多變的，如果共享數據容量巨大，那么就需要借助于內存映射文件來進行。實際上，內存映射文件正是解決本地多個進程間數據共享的最有效方法。

　　內存映射文件并不是簡單的文件I/O操作，實際用到了Windows的核心編程技術--內存管理。所以，如果想對內存映射文件有更深刻的認識，必須對Windows操作系統的內存管理機制有清楚的認識，內存管理的相關知識非常復雜，超出了本文的討論范疇，在此就不再贅述，感興趣的讀者可以參閱其他相關書籍。下面給出使用內存映射文件的一般方法：

　　首先要通過CreateFile()函數來創建或打開一個文件內核對象，這個對象標識了磁盤上將要用作內存映射文件的文件。在用CreateFile()將文件映像在物理存儲器的位置通告給操作系統后，只指定了映像文件的路徑，映像的長度還沒有指定。為了指定文件映射對象需要多大的物理存儲空間還需要通過CreateFileMapping()函數來創建一個文件映射內核對象以告訴系統文件的尺寸以及訪問文件的方式。在創建了文件映射對象后，還必須為文件數據保留一個地址空間區域，并把文件數據作為映射到該區域的物理存儲器進行提交。由MapViewOfFile()函數負責通過系統的管理而將文件映射對象的全部或部分映射到進程地址空間。此時，對內存映射文件的使用和處理同通常加載到內存中的文件數據的處理方式基本一樣，在完成了對內存映射文件的使用時，還要通過一系列的操作完成對其的清除和使用過資源的釋放。這部分相對比較簡單，可以通過UnmapViewOfFile()完成從進程的地址空間撤消文件數據的映像、通過CloseHandle()關閉前面創建的文件映射對象和文件對象。

　　內存映射文件相關函數

　　在使用內存映射文件時，所使用的API函數主要就是前面提到過的那幾個函數，下面分別對其進行介紹：

HANDLE CreateFile(LPCTSTR lpFileName,
DWORD dwDesiredAclearcase/" target="_blank" >ccess,
DWORD dwShareMode,
LPSECURITY_ATTRIBUTES lpSecurityAttributes,
DWORD dwCreationDisposition,
DWORD dwFlagsAndAttributes,
HANDLE hTemplateFile);

　　函數CreateFile()即使是在普通的文件操作時也經常用來創建、打開文件，在處理內存映射文件時，該函數來創建/打開一個文件內核對象，并將其句柄返回，在調用該函數時需要根據是否需要數據讀寫和文件的共享方式來設置參數dwDesiredAccess和dwShareMode，錯誤的參數設置將會導致相應操作時的失敗。

HANDLE CreateFileMapping(HANDLE hFile,
LPSECURITY_ATTRIBUTES lpFileMappingAttributes,
DWORD flProtect,
DWORD dwMaximumSizeHigh,
DWORD dwMaximumSizeLow,
LPCTSTR lpName);

　　CreateFileMapping()函數創建一個文件映射內核對象，通過參數hFile指定待映射到進程地址空間的文件句柄（該句柄由CreateFile()函數的返回值獲?。?。由于內存映射文件的物理存儲器實際是存儲于磁盤上的一個文件，而不是從系統的頁文件中分配的內存，所以系統不會主動為其保留地址空間區域，也不會自動將文件的存儲空間映射到該區域，為了讓系統能夠確定對頁面采取何種保護屬性，需要通過參數flProtect來設定，保護屬性PAGE_READONLY、PAGE_READWRITE和PAGE_WRITECOPY分別表示文件映射對象被映射后，可以讀取、讀寫文件數據。在使用PAGE_READONLY時，必須確保CreateFile()采用的是GENERIC_READ參數；PAGE_READWRITE則要求CreateFile()采用的是GENERIC_READ|GENERIC_WRITE參數；至于屬性PAGE_WRITECOPY則只需要確保CreateFile()采用了GENERIC_READ和GENERIC_WRITE其中之一即可。DWORD型的參數dwMaximumSizeHigh和dwMaximumSizeLow也是相當重要的，指定了文件的最大字節數，由于這兩個參數共64位，因此所支持的最大文件長度為16EB，幾乎可以滿足任何大數據量文件處理場合的要求。

LPVOID MapViewOfFile(HANDLE hFileMappingObject,
DWORD dwDesiredAccess,
DWORD dwFileOffsetHigh,
DWORD dwFileOffsetLow,
DWORD dwNumberOfBytesToMap);

　　MapViewOfFile()函數負責把文件數據映射到進程的地址空間，參數hFileMappingObject為CreateFileMapping()返回的文件映像對象句柄。參數dwDesiredAccess則再次指定了對文件數據的訪問方式，而且同樣要與CreateFileMapping()函數所設置的保護屬性相匹配。雖然這里一再對保護屬性進行重復設置看似多余，但卻可以使應用程序能更多的對數據的保護屬性實行有效控制。MapViewOfFile()函數允許全部或部分映射文件，在映射時，需要指定數據文件的偏移地址以及待映射的長度。其中，文件的偏移地址由DWORD型的參數dwFileOffsetHigh和dwFileOffsetLow組成的64位值來指定，而且必須是操作系統的分配粒度的整數倍，對于Windows操作系統，分配粒度固定為64KB。當然，也可以通過如下代碼來動態獲取當前操作系統的分配粒度：

SYSTEM_INFO sinf;
GetSystemInfo(&sinf);
DWORD dwAllocationGranularity = sinf.dwAllocationGranularity;

　　參數dwNumberOfBytesToMap指定了數據文件的映射長度，這里需要特別指出的是，對于Windows 9x操作系統，如果MapViewOfFile()無法找到足夠大的區域來存放整個文件映射對象，將返回空值（NULL）；但是在Windows 2000下，MapViewOfFile()只需要為必要的視圖找到足夠大的一個區域即可，而無須考慮整個文件映射對象的大小。

　　在完成對映射到進程地址空間區域的文件處理后，需要通過函數UnmapViewOfFile()完成對文件數據映像的釋放，該函數原型聲明如下：

BOOL UnmapViewOfFile(LPCVOID lpBaseAddress);

　　唯一的參數lpBaseAddress指定了返回區域的基地址，必須將其設定為MapViewOfFile()的返回值。在使用了函數MapViewOfFile()之后，必須要有對應的UnmapViewOfFile()調用，否則在進程終止之前，保留的區域將無法釋放。除此之外，前面還曾由CreateFile()和CreateFileMapping()函數創建過文件內核對象和文件映射內核對象，在進程終止之前有必要通過CloseHandle()將其釋放，否則將會出現資源泄漏的問題。

　　除了前面這些必須的API函數之外，在使用內存映射文件時還要根據情況來選用其他一些輔助函數。例如，在使用內存映射文件時，為了提高速度，系統將文件的數據頁面進行高速緩存，而且在處理文件映射視圖時不立即更新文件的磁盤映像。為解決這個問題可以考慮使用FlushViewOfFile()函數，該函數強制系統將修改過的數據部分或全部重新寫入磁盤映像，從而可以確保所有的數據更新能及時保存到磁盤。


使用內存映射文件處理大文件應用示例

　　下面結合一個具體的實例來進一步講述內存映射文件的使用方法。該實例從端口接收數據，并實時將其存放于磁盤，由于數據量大（幾十GB），在此選用內存映射文件進行處理。下面給出的是位于工作線程MainProc中的部分主要代碼，該線程自程序運行時啟動，當端口有數據到達時將會發出事件hEvent[0]，WaitForMultipleObjects()函數等待到該事件發生后將接收到的數據保存到磁盤，如果終止接收將發出事件hEvent[1]，事件處理過程將負責完成資源的釋放和文件的關閉等工作。下面給出此線程處理函數的具體實現過程：

……
// 創建文件內核對象，其句柄保存于hFile
HANDLE hFile = CreateFile("Recv1.zip",
GENERIC_WRITE | GENERIC_READ,
FILE_SHARE_READ,
NULL,
CREATE_ALWAYS,
FILE_FLAG_SEQUENTIAL_SCAN,
NULL);

// 創建文件映射內核對象，句柄保存于hFileMapping
HANDLE hFileMapping = CreateFileMapping(hFile,NULL,PAGE_READWRITE,
0, 0x4000000, NULL);
// 釋放文件內核對象
CloseHandle(hFile);

// 設定大小、偏移量等參數
__int64 qwFileSize = 0x4000000;
__int64 qwFileOffset = 0;
__int64 T = 600 * sinf.dwAllocationGranularity;
DWORD dwBytesInBlock = 1000 * sinf.dwAllocationGranularity;

// 將文件數據映射到進程的地址空間
PBYTE pbFile = (PBYTE)MapViewOfFile(hFileMapping,
FILE_MAP_ALL_ACCESS,
(DWORD)(qwFileOffset>>32), (DWORD)(qwFileOffset&0xFFFFFFFF), dwBytesInBlock);
while(bLoop)
{
// 捕獲事件hEvent[0]和事件hEvent[1]
DWORD ret = WaitForMultipleObjects(2, hEvent, FALSE, INFINITE);
ret -= WAIT_OBJECT_0;
switch (ret)
{
// 接收數據事件觸發
case 0:
// 從端口接收數據并保存到內存映射文件
nReadLen=syio_Read(port[1], pbFile + qwFileOffset, QueueLen);
qwFileOffset += nReadLen;

// 當數據寫滿60%時，為防數據溢出，需要在其后開辟一新的映射視圖
if (qwFileOffset > T)
{
T = qwFileOffset + 600 * sinf.dwAllocationGranularity;
UnmapViewOfFile(pbFile);
pbFile = (PBYTE)MapViewOfFile(hFileMapping,
FILE_MAP_ALL_ACCESS,
(DWORD)(qwFileOffset>>32), (DWORD)(qwFileOffset&0xFFFFFFFF), dwBytesInBlock);
}
break;

// 終止事件觸發
case 1:
bLoop = FALSE;

// 從進程的地址空間撤消文件數據映像
UnmapViewOfFile(pbFile);

// 關閉文件映射對象
CloseHandle(hFileMapping);
break;
}
}
…

　　在終止事件觸發處理過程中如果只簡單的執行UnmapViewOfFile()和CloseHandle()函數將無法正確標識文件的實際大小，即如果開辟的內存映射文件為30GB，而接收的數據只有14GB，那么上述程序執行完后，保存的文件長度仍是30GB。也就是說，在處理完成后還要再次通過內存映射文件的形式將文件恢復到實際大小，下面是實現此要求的主要代碼：

// 創建另外一個文件內核對象
hFile2 = CreateFile("Recv.zip",
GENERIC_WRITE | GENERIC_READ,
FILE_SHARE_READ,
NULL,
CREATE_ALWAYS,
FILE_FLAG_SEQUENTIAL_SCAN,
NULL);

// 以實際數據長度創建另外一個文件映射內核對象
hFileMapping2 = CreateFileMapping(hFile2,
NULL,
PAGE_READWRITE,
0,
(DWORD)(qwFileOffset&0xFFFFFFFF),
NULL);

// 關閉文件內核對象
CloseHandle(hFile2);

// 將文件數據映射到進程的地址空間
pbFile2 = (PBYTE)MapViewOfFile(hFileMapping2,
FILE_MAP_ALL_ACCESS,
0, 0, qwFileOffset);

// 將數據從原來的內存映射文件復制到此內存映射文件
memcpy(pbFile2, pbFile, qwFileOffset);

file://從進程的地址空間撤消文件數據映像
UnmapViewOfFile(pbFile);
UnmapViewOfFile(pbFile2);

// 關閉文件映射對象
CloseHandle(hFileMapping);
CloseHandle(hFileMapping2);

// 刪除臨時文件
DeleteFile("Recv1.zip");

　　結論

　　經實際測試，內存映射文件在處理大數據量文件時表現出了良好的性能，比通常使用CFile類和ReadFile()和WriteFile()等函數的文件處理方式具有明顯的優勢。本文所述代碼在Windows 98下由Microsoft Visual C++ 6.0編譯通過。

原文轉自：http://www.anti-gravitydesign.com