Linux虛擬內存，你理解到位了？-Linux-PHP中文網

之前，我對作業系統的概念有一些了解，但畢業後我對自己大學四年的電腦專業的荒廢感到有些懊悔。因此，在工作之餘，我抽出時間觀看了哈爾濱工業大學在網易雲課堂上的操作系統公開課，也閱讀了一本講解操作系統概念較淺的書籍《Linux核心設計與實現》。此外，去年我使用C語言編寫了一個簡單的伺服器，深入了解了更多系統底層的知識。這些知識讓我對應用層的知識有了更好的掌握，並在最近一次故障排查中給予了我很大的幫助。

前幾天，另一位同事向我提出了另一個與虛擬記憶體相關的問題，我才意識到對虛擬記憶體的理解還不夠深刻，有些概念甚至存在矛盾。因此，我翻閱了一些資料，並重新整理了這些知識，希望下次在實際應用時能更加流暢。

起源

虛擬記憶體

#毫無疑問，虛擬記憶體絕對是作業系統中最重要的概念之一。我認為主要是因為內在整個系統中存在的重要性地位。 CPU速度非常快，但容量有限且功能單一，而其他的I/O硬體在各種花式功能方面都有支持，但相對於CPU來說它們速度較慢。因此，它們之間需要一種潤滑劑作為緩衝，這就是記憶體發揮作用的地方。

在現代作業系統中，多任務已經成為標配。多任務並行大大提高了CPU的使用率，但也帶來了多個進程對記憶體操作的衝突問題，而虛擬記憶體的概念就是為了解決這個問題。

上圖是虛擬記憶體最簡單也是最直覺的解釋。

作業系統有一塊實體記憶體（中間的部分），有兩個行程（實際上會更多）P1 和P2，作業系統偷偷地分別告訴P1 和P2，我的整個記憶體都是你的，隨便用，管夠。但事實上呢，作業系統只是給它們畫了個大餅，這些記憶體說是都給了 P1 和 P2，實際上只給了它們一個序號而已。只有當P1 和P2 真正開始使用這些內存時，系統才開始使用輾轉挪移，拼湊出各個塊給進程用，P2 以為自己在用A 內存，實際上已經被系統悄悄重定向到真正的B 去了，甚至，當P1 和P2 共用了C 內存，他們也不知道。

作業系統的這種欺騙進程的手段，就是虛擬記憶體。對 P1 和 P2 等進程來說，它們都以為自己佔用了整個內存，而自己使用的物理內存的哪段地址，它們並不知道也無需關心。

分頁與頁表

#虛擬記憶體是作業系統裡的概念，對作業系統來說，虛擬記憶體就是一張張的對照表，P1 取得A 記憶體裡的資料時應該去實體記憶體的A 位址找，而找B 記憶體裡的資料應該去物理記憶體的C 位址。

我們知道系統裡的基本單位都是Byte 字節，如果將每個虛擬記憶體的Byte 對應到物理記憶體的位址，每個條目最少需要8位元組（32位元虛擬位址->32位元物理位址），在4G 記憶體的情況下，就需要32GB 的空間來存放對照表，那麼這張表就大得真正的實體位址也放不下了，於是作業系統引入了頁（Page）的概念。

在系統啟動時，作業系統將整個實體記憶體以 4K 為單位，劃分為各頁。之後進行內存分配時，都以頁為單位，那麼虛擬內存頁對應物理內存頁的映射表就大大減小了，4G 內存，只需要8M 的映射表即可，一些進程沒有使用到的虛擬內存，也不需要保存映射關係，而且Linux 還為大記憶體設計了多層頁表，可以進一頁減少了記憶體消耗。作業系統虛擬記憶體到實體記憶體的映射表，就稱為頁表。

記憶體尋址與分配

#我們知道透過虛擬內存機制，每個進程都以為自己佔用了全部內存，進程訪問內存時，操作系統都會把進程提供的虛擬內存地址轉換為物理地址，再去對應的物理地址上獲取數據。 CPU 中有一種硬件，記憶體管理單元 MMU（Memory Management Unit）專門用來將翻譯虛擬記憶體位址。 CPU 也為頁表尋址設定了快取策略，由於程式的局部性，其快取命中率能達到 98%。

以上情況是頁表內存在虛擬位址到實體位址的映射，而如果進程存取的實體位址尚未被分配，系統則會產生一個缺頁中斷，中斷處理時，系統切到核心態為進程虛擬位址分配實體位址。

功能

虛擬記憶體不僅透過記憶體位址轉換解決了多個進程存取記憶體衝突的問題，還帶來更多的好處。

進程記憶體管理

#它有助於進程進行記憶體管理，主要體現在：

記憶體完整性：由於虛擬記憶體對進程的”欺騙”，每個進程都認為自己獲取的記憶體是一塊連續的位址。我們在編寫應用程式時，就不用考慮大塊位址的分配，總是認為系統有足夠的大塊記憶體即可。
安全性：由於進程存取記憶體時，都要透過頁表來定址，作業系統在頁表的各個項目上新增各種存取權限識別位，就可以實現記憶體的權限控制。

資料共享

#透過虛擬記憶體更容易實現記憶體和資料的共享。

在進程加載系統庫時，總是先分配一塊內存，將磁碟中的庫文件加載到這塊內存中，在直接使用物理內存時，由於物理內存地址唯一，即使系統發現同一個庫在系統內載入了兩次，但每個行程指定的載入記憶體不一樣，系統也無能為力。

而在使用虛擬記憶體時，系統只需要將進程的虛擬記憶體位址指向庫檔案所在的實體記憶體位址。如上文圖中所示，進程 P1 和 P2 的 B 位址都指向了實體位址 C。

而透過使用虛擬記憶體使用共享記憶體也很簡單，系統只需要將各個進程的虛擬記憶體位址指向系統分配的共享記憶體位址。

SWAP

虛擬記憶體可以讓幫進程」擴充」記憶體。

我們前文提到了虛擬記憶體透過缺頁中斷為進程分配物理內存，記憶體總是有限的，如果所有的實體記憶體都被佔用了怎麼辦呢？

Linux 提出SWAP 的概念，Linux 中可以使用SWAP 分區，在分配物理內存，但可用內存不足時，將暫時不用的內存資料先放到磁碟上，讓有需要的進程先使用，等進程再需要使用這些資料時，再將這些資料載入到記憶體中，透過這種」交換」技術，Linux 可以讓進程使用更多的記憶體。

常見問題

在了解虛擬記憶體時，我也有過很多的問題。

32位元和64位元

最常見的就是 32位元和64位元的問題了。

CPU 透過實體匯流排存取內存，那麼存取位址的範圍就受限於機器匯流排的數量，在32位元機器上，有32條匯流排，每條匯流排有高低兩種電位分別代表bit 的1 和0 ，那麼可存取的最大位址就是2^32bit = 4GB，所以說32 位元機器上插入大於4G 的記憶體是無效的，CPU 存取不到多於4G 的記憶體。

但 64位元機器並沒有 64位元匯流排，而且其最大記憶體還要受限於作業系統，Linux 目前支援最大 256G 記憶體。

根據虛擬記憶體的概念，在 32 位元系統上運行 64 位元軟體也並無不可，但由於系統對虛擬記憶體位址的結構設計，64位元的虛擬位址在32位元系統內並不能使用。

直接操作物理記憶體

#作業系統使用了虛擬內存，我們想要直接操作記憶體該怎麼辦？

Linux 會將各個設備都映射到 /dev/ 目錄下的文件，我們可以透過這些設備文件直接操作硬件，內存也不例外。在 Linux 中，記憶體設定被映射為 /dev/mem，root 使用者透過對這個檔案讀寫，可以直接操作記憶體。

JVM 進程佔用虛擬記憶體過多

使用 TOP 查看系統效能時，我們會發現在 VIRT 這一列，Java 進程會佔用大量的虛擬記憶體。

導致這種問題的原因是 Java 使用 Glibc 的 Arena 記憶體池分配了大量的虛擬記憶體並沒有使用。此外，Java 讀取的檔案也會被映射為虛擬內存，在虛擬機器預設配置下 Java 每個線程堆疊會佔用 1M 的虛擬內存。具體可以查看為什麼linux下多執行緒程式如此消耗虛擬記憶體。

而真實佔用的實體記憶體要看 RES (resident) 列，這一列的值才是真正被對應到實體記憶體的大小。

常用管理指令

#我們也可以自己來管理 Linux 的虛擬記憶體。

查看系統記憶體狀態

#查看系統記憶體狀況的方式有很多，free、 vmstat等指令都可輸出目前系統的記憶體狀態，需要注意的是可用記憶體不只是free 這一列，由於作業系統的lazy 特性，大量的buffer/cache 在進程不再使用後，不會被立即清理，如果之前使用它們的進程再次運行還可以繼續使用，它們在必要時也是可以被利用的。

此外，透過 cat /proc/meminfo 可以查看系統記憶體被使用的詳細情況，包括髒頁狀態等。詳情請見：/PROC/MEMINFO之謎。