這次我們的討論將涵蓋非常重要且常被誤解的文件與內存間關系的問題，以及它對系統性能的影響。

提到文件，操作系統必須解決兩個重要的問題。首先是硬盤驅動器的存取速度緩慢得令人頭疼(相對于內存而言)，尤其是磁盤的尋道性能。第二個是要滿足'一次性加載文件內容到物理內存并在程序間共享'的需求。如果你使用進程瀏覽器翻看Windows進程，就會發現大約15MB的共享DLL被加載進了每一個進程。我目前的Windows系統就運行了100個進程，如果沒有共享機制，那將消耗大約1.5GB的物理內存僅僅用于存放公用DLL。這可不怎么好。同樣的，幾乎所有的Linux程序都需要ld.so和libc，以及其它的公用函數庫。

[[270622]]

令人愉快的是，這兩個問題可以被一石二鳥的解決：頁面緩存(page cache)，內核用它保存與頁面同等大小的文件數據塊。為了展示頁面緩存，我需要祭出一個名叫render的Linux程序，它會打開一個scene.dat文件，每次讀取其中的512字節，并將這些內容保存到一個建立在堆上的內存塊中。***的讀取是這樣的：

在讀取了12KB以后，render的堆以及相關的頁幀情況如下：

這看起來很簡單，但還有很多事情會發生。首先，即使這個程序只調用了常規的read函數，此時也會有三個 4KB的頁幀存儲在頁面緩存當中，它們持有scene.dat的一部分數據。盡管有時這令人驚訝，但的確所有的常規文件I/O都是通過頁面緩存來進行的。在x86 Linux里，內核將文件看作是4KB大小的數據塊的序列。即使你只從文件讀取一個字節，包含此字節的整個4KB數據塊都會被讀取，并放入到頁面緩存當中。這樣做是有道理的，因為磁盤的持續性數據吞吐量很不錯，而且一般說來，程序對于文件中某區域的讀取都不止幾個字節。頁面緩存知道每一個4KB數據塊在文件中的對應位置，如上圖所示的#0, #1等等。與Linux的頁面緩存類似，Windows使用256KB的views。

不幸的是，在一個普通的文件讀取操作中，內核必須復制頁面緩存的內容到一個用戶緩沖區中，這不僅消耗CPU時間，傷害了CPU cache的性能，還因為存儲了重復信息而浪費物理內存。如上面每張圖所示，scene.dat的內容被保存了兩遍，而且程序的每個實例都會保存一份。至此，我們緩和了磁盤延遲的問題，但卻在其余的每個問題上慘敗。內存映射文件(memory-mapped files)將***我們走出混亂：

當你使用文件映射的時候，內核將你的程序的虛擬內存頁直接映射到頁面緩存上。這將導致一個顯著的性能提升：《Windows系統編程》指出常規的文件讀取操作運行時性能改善30%以上;《Unix環境高級編程》指出類似的情況也發生在Linux和Solaris系統上。你還可能因此而節省下大量的物理內存，這依賴于你的程序的具體情況。

和以前一樣，提到性能，實際測量才是王道，但是內存映射的確值得被程序員們放入工具箱。相關的API也很漂亮，它提供了像訪問內存中的字節一樣的方式來訪問一個文件，不需要你多操心，也不犧牲代碼的可讀性。回憶一下地址空間、還有那個在Unix類系統上關于mmap的實驗，Windows下的CreateFileMapping及其在高級語言中的各種可用封裝。當你映射一個文件時，它的內容并不是立刻就被全部放入內存的，而是依賴頁故障(page fault)按需讀取。在獲取了一個包含所需的文件數據的頁幀后，對應的故障處理函數會將你的虛擬內存頁映射到頁面緩存上。如果所需內容不在緩存當中，此過程還將包含磁盤I/O操作。

現在給你出一個流行的測試題。想象一下，在***一個render程序的實例退出之時，那些保存了scene.dat的頁面緩存會被立刻清理嗎?人們通常會這樣認為，但這是個壞主意。如果你仔細想想，我們經常會在一個程序中創建一個文件，退出，緊接著在第二個程序中使用這個文件。頁面緩存必須能處理此類情況。如果你再多想想，內核何必總是要舍棄頁面緩存中的內容呢?記住，磁盤比RAM慢5個數量級，因此一個頁面緩存的***(hit)就意味著巨大的勝利。只要還有足夠的空閑物理內存，緩存就應該盡可能保持滿狀態。所以它與特定的進程并不相關，而是一個系統級的資源。如果你一周前運行過render，而此時scene.dat還在緩存當中，那真令人高興。這就是為什么內核緩存的大小會穩步增加，直到緩存上限。這并非因為操作系統是破爛貨，吞噬你的RAM，事實上這是種好的行為，反而釋放物理內存才是一種浪費。緩存要利用得越充分越好。

由于使用了頁面緩存體系結構，當一個程序調用write()時，相關的字節被簡單的復制到頁面緩存中，并且將頁面標記為臟的(dirty)。磁盤I/O一般不會立刻發生，因此你的程序的執行不會被打斷去等待磁盤設備。這樣做的缺點是，如果此時計算機死機，那么你寫入的數據將不會被記錄下來。因此重要的文件，比如數據庫事務記錄必須被fsync() (但是還要小心磁盤控制器的緩存)。另一方面，讀取操作一般會打斷你的程序直到準備好所需的數據。內核通常采用積極加載(eager loading)的方式來緩解這個問題。以提前讀取(read ahead)為例，內核會預先加載一些頁到頁面緩存，并期待你的讀取操作。通過提示系統即將對文件進行的是順序還是隨機讀取操作(參看madvise(), readahead(), Windows緩存提示)，你可以幫助內核調整它的積極加載行為。Linux的確會對內存映射文件進行預取，但我不太確定Windows是否也如此。***需要一提的是，你還可以通過在Linux中使用O_DIRECT或在Windows中使用NO_BUFFERING來繞過頁面緩存，有些數據庫軟件就是這么做的。

一個文件映射可以是私有的(private)或共享的(shared)。這里的區別只有在更改(update)內存中的內容時才會顯現出來：在私有映射中，更改并不會被提交到磁盤或對其他進程可見，而這在共享的映射中就會發生。內核使用寫時拷貝(copy on write)技術，通過頁表項(page table entries)，實現私有映射。在下面的例子中，render和另一個叫render3d的程序(我是不是很有創意?)同時私有映射了scene.dat。隨后render改寫了映射到此文件的虛擬內存區域：

上圖所示的只讀的頁表項并不意 味著映射是只讀的，它們只是內核耍的小把戲，用于共享物理內存直到可能的***一刻。你會發現'私有'一詞是多么的不恰當，你只需記住它只在數據發生更改時 起作用。此設計所帶來的一個結果就是，一個以私有方式映射文件的虛擬內存頁可以觀察到其他進程對此文件的改動，只要之前對這個內存頁進行的都是讀取操作。 一旦發生過寫時拷貝，就不會再觀察到其他進程對此文件的改動了。此行為不是內核提供的，而是在x86系統上就會如此。另外，從API的角度來說，這也是合理的。與此相反，共享映射只是簡單的映射到頁面緩存，僅此而已。對頁面的所有更改操作對其他進程都可見，而且最終會執行磁盤操作。***，如果此共享映射是只讀的，那么頁故障將觸發段錯誤(segmentation fault)而不是寫時拷貝。

被動態加載的函數庫通過文件映射機制放入到你的程序的地址空間中。這里沒有任何特別之處，同樣是采用私有文件映射，跟提供給你調用的常規API別無二致。下面的例子展示了兩個運行中的render程序的一部分地址空間，還有物理內存。它將我們之前看到的概念都聯系在了一起。