轉載自：http://blog.sina.com.cn/s/blog_5e83fce60100pz2p.html
最初接觸File Mapping是為了能夠方便地處理一個幾百兆的大文件，當時查了些資料大概了解了一下就匆匆動手了，因為知其然而不知其所以然，在使用過程中遇到了不少問題，今天在這里就是想把這些歷史遺留問題解決掉。
問題一、Mapping有“映射”之意，那么在該語境中形成映射關系的雙方是誰，也就是從哪里映射到哪里呢？
要回答這個問題，我們必須要對虛擬內存有所了解?，F在操作系統中，大多都使用虛擬內存技術來對內存進行管理。通過虛擬內存，操作系統給予了每個進程一個統一的地址空間。在32位操作系統中，該地址空間的大小達到 2^32個，也就是4G了。從一個進程的角度看來，這4G的地址空間是自己獨享的，也就是說，如果操作系統允許的話，我可以訪問這4G地址空間中的任何一個。當然，操作系統是不可能讓一個進程隨心所欲地使用這些地址的。下面，我們來看看這些地址具體是怎樣分配的：
上面這個圖大家應該都很熟悉，它是Linux中進程的內存映象。我們可以看到，在4G的地址空間中，我們先從下往上看， 0～0x08047ffff（大概128M左右）是系統保留的，不能使用。read-only segment和read/write segment用以存放系統加載器從可執行文件中載入的代碼段以及數據段等內容。運行時堆大家應該都比較清楚，是動態分配內存的地方，我們通過malloc和free等函數動態在堆中分配和釋放內存，堆的大小是往上增長的，最大可達到0x3FFFFFFF處。好，到這里我們在從上往下看，0xc0000000以上是核心虛擬內存，專門為操作系統核心的數據結構以及代碼預留的，一般用戶進程無權使用。然后就到了棧區了，這里是系統保存跟函數操作有關的數據，如局部變量，函數參數等內容。與堆不一樣，棧是從上往下增長的，其棧頂通過寄存器esp指出。那么被堆和棧夾著的區域是干什么的呢？原來，那是用來放動態共享庫的。在C/C++庫文件簡介中我們談到了共享庫，動態共享庫是在程序被載入時或者運行過程中載入到進程內存空間中的，它存放的地方就是我們稱作內存映射區的這個地方。
這樣一看，原來進程開始運行時，4G的地址已經被用掉了不少，其中，光是操作系統所占用的核心虛擬內存就達到1G，加上程序的代碼和數據以及動態共享庫等等，我們大概就剩下2G左右的地址空間可以使用了。那么，這2G空間我們是如何使用的呢？第一，我們使用malloc函數，在堆中分配空間，使堆往上增長；第二，我們在函數中使用局部的數據，以及函數調用時現場的保留，使?？臻g往下增長；第三，我們使用File Mapping，使內存映射區往上增長。
好了，終于出現File Mapping 了?，F在，我們也可以知道題目中“映射”的其中一方了：內存。原來它就是在內存映射區中的一段地址空間。那么，“映射”的另一方又是什么呢？那自然是文件了。我們可以將任何類型任何大?。ㄖ灰僮飨到y支持，現在win32支持最大的文件為16EB，就是2^64）的文件映射到內存映射區中。當然，太大的文件我們不可能一次性把它全部映射到虛擬內存中去，畢竟我們大概只有2G的地址空間，兩者間是不可能構成一一對應的關系的。此時，我們可以將文件分段進行映射，每次將文件的一部分映射到內存空間中。映射完以后，我們就可以像訪問內存那樣直接訪問文件了。
問題二、數據在哪呢？數據文件？物理內存？頁面文件？
這里，我們暫且將被映射的文件稱為數據文件。當我們映射好一個數據文件以后，操作系統并不會馬上將文件中的內容提交到物理內存中去，數據還是原封不動地放在數據文件中。但是，當程序首次對文件中某個數據進行訪問時（read /write），操作系統就會將該數據從數據文件中調入物理內存中，供CPU使用。操作完畢后，當我們解除映射時，操作系統將根據映射的屬性（write/write-on-copy）決定是將更改后的數據寫回到數據文件中還是將更改直接丟棄。Readonly 不存在這個問題，因為不可能被更改，因此unmap時只需將內存中的數據丟棄就可以了。
這中間還有一個問題，那就是在映射以后和解除映射之前這個時間段內，物理內存中的數據是有可能被換出的（swap out），那么，換出時這些數據是被存放在數據文件中還是像一般數據那樣存放在系統的頁面文件中呢？同樣，這也是跟映射的屬性緊密相關的：
如果映射為readonly，那么換出時只需修改相應的頁表（page table）內容，標注其已被換出即可。
如果映射為write-on-copy,那么換出將存放在頁面文件中，
如果映射為write，那么換出時將寫會到數據文件中。
問題三、使用File Mapping為什么可以提高訪問文件的速度呢？
這是因為操作系統在處理一般讀寫跟處理內存映射使用的方法不一樣。在處理一般的讀寫操作時，操作系統一般使用中斷的方式，先將內容拷貝到核心虛擬內存緩沖，然后再拷貝到進程空間中；但是，處理內存映射文件時，一般使用虛擬內存管理器，無需進行中間的拷貝過程，因此速度加快。此外，像Windows這樣使用頁式管理虛擬內存的操作系統中，數據的換入換出都是以頁為單位的（通常是4k或者8k），因為程序一般都具有時間和空間的局部性（locality），因此，相當于進行了大量的緩沖操作，有利于提高性能。
問題四、什么情況適合使用 File Mapping呢？看看人家的建議：
File mapping is effective in the following situations:
-
You have a large file whose contents you want to access randomly one or more times.
-
You have a small file whose contents you want to read into memory all at once and access frequently. This technique is best for files that are no more than a few virtual memory pages in size.
-
You want to cache specific portions of a file in memory. File mapping eliminates the need to cache the data at all, which leaves more room in the system disk caches for other data.
You should not use file mapping in the following situations:
-
You want to read a file sequentially from start to finish only once.
-
The file is several hundred megabytes or more in size. (Mapping large files fills virtual memory space quickly. In addition, your program may not have the available space if it has been running for a while or its memory space is fragmented.)
問題五、為什么在操作大文件時速度變得很慢呢？
遇到這個問題，你可以首先打開Windows的任務管理器，看看你進程究竟使用了多少的內存。呵呵，通常都是個天文數字。占用了那么多的內存，系統肯定就很慢了。遇到這樣的問題，我們通常都是使用內存映射文件對數據文件進行遍歷操作，譬如像將A文件拷貝為B文件。上面我們提到，操作系統是在真正用到數據的時候才會把它從數據文件中提交到物理內存里面的，因此，剛做好映射不進行操作的話，進程并不會消耗多少內存。但是，一旦你開始進行遍歷，那么，操作系統就馬上將它們調入物理內存中（你可以看看頁面錯誤的數量，肯定是飛速增長的），于是，內存就一路飛漲了。
怎么辦呢?不要一次性把整個文件進行映射，而是分開進行，操作完一部分后，將它unmap掉，這樣，操作系統就會把它們“趕回家去”了，內存就不會占用太高了。