c++實現使用記憶體對映檔案處理大檔案
阿新 • • 發佈：2019-02-02
摘要：本文給出了一種方便實用的解決大檔案的讀取、儲存等處理的方法，並結合相關程式程式碼對具體的實現過程進行了介紹。
引言
檔案操作是應用程式最為基本的功能之一，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函式主要就是前面提到過的那幾個函式，下面分別對其進行介紹：
函式CreateFile()即使是在普通的檔案操作時也經常用來建立、開啟檔案，在處理記憶體對映檔案時，該函式來建立/開啟一個檔案核心物件，並將其控制代碼返回，在呼叫該函式時需要根據是否需要資料讀寫和檔案的共享方式來設定引數dwDesiredAccess和dwShareMode，錯誤的引數設定將會導致相應操作時的失敗。
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，幾乎可以滿足任何大資料量檔案處理場合的要求。
MapViewOfFile()函式負責把檔案資料對映到程序的地址空間，引數hFileMappingObject為CreateFileMapping()返回的檔案映像物件控制代碼。引數dwDesiredAccess則再次指定了對檔案資料的訪問方式，而且同樣要與CreateFileMapping()函式所設定的保護屬性相匹配。雖然這裡一再對保護屬性進行重複設定看似多餘，但卻可以使應用程式能更多的對資料的保護屬性實行有效控制。MapViewOfFile()函式允許全部或部分對映檔案，在對映時，需要指定資料檔案的偏移地址以及待對映的長度。其中，檔案的偏移地址由DWORD型的引數dwFileOffsetHigh和dwFileOffsetLow組成的64位值來指定，而且必須是作業系統的分配粒度的整數倍，對於Windows作業系統，分配粒度固定為64KB。當然，也可以通過如下程式碼來動態獲取當前作業系統的分配粒度：
引數dwNumberOfBytesToMap指定了資料檔案的對映長度，這裡需要特別指出的是，對於Windows 9x作業系統，如果MapViewOfFile()無法找到足夠大的區域來存放整個檔案對映物件，將返回空值（NULL）；但是在Windows 2000下，MapViewOfFile()只需要為必要的檢視找到足夠大的一個區域即可，而無須考慮整個檔案對映物件的大小。
在完成對對映到程序地址空間區域的檔案處理後，需要通過函式UnmapViewOfFile()完成對檔案資料映像的釋放，該函式原型宣告如下：
在終止事件觸發處理過程中如果只簡單的執行UnmapViewOfFile()和CloseHandle()函式將無法正確標識檔案的實際大小，即如果開闢的記憶體對映檔案為30GB，而接收的資料只有14GB，那麼上述程式執行完後，儲存的檔案長度仍是30GB。也就是說，在處理完成後還要再次通過記憶體對映檔案的形式將檔案恢復到實際大小，下面是實現此要求的主要程式碼：
結論
經實際測試，記憶體對映檔案在處理大資料量檔案時表現出了良好的效能，比通常使用CFile類和ReadFile()和WriteFile()等函式的檔案處理方式具有明顯的優勢。本文所述程式碼在Windows 98下由Microsoft Visual C++ 6.0編譯通過。
引言
檔案操作是應用程式最為基本的功能之一，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 dwDesiredAccess, 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編譯通過。