淺談Linux的虛擬內(nèi)存

更新時間：2021年05月27日 10:42:56 作者：枕邊書

現(xiàn)代操作系統(tǒng)中，多任務已是標配。多任務并行，大大提升了 CPU 利用率，但卻引出了多個進程對內(nèi)存操作的沖突問題，虛擬內(nèi)存概念的提出就是為了解決這個問題。

由來

虛擬內(nèi)存

毋庸置疑，虛擬內(nèi)存絕對是操作系統(tǒng)中最重要的概念之一。我想主要是由于內(nèi)存的重要”戰(zhàn)略地位”。CPU太快，但容量小且功能單一，其他 I/O 硬件支持各種花式功能，可是相對于 CPU，它們又太慢。于是它們之間就需要一種潤滑劑來作為緩沖，這就是內(nèi)存大顯身手的地方。

上圖是虛擬內(nèi)存最簡單也是最直觀的解釋。

操作系統(tǒng)有一塊物理內(nèi)存（中間的部分），有兩個進程（實際會更多）P1 和 P2，操作系統(tǒng)偷偷地分別告訴 P1 和 P2，我的整個內(nèi)存都是你的，隨便用，管夠?？墒聦嵣夏兀僮飨到y(tǒng)只是給它們畫了個大餅，這些內(nèi)存說是都給了 P1 和 P2，實際上只給了它們一個序號而已。只有當 P1 和 P2 真正開始使用這些內(nèi)存時，系統(tǒng)才開始使用輾轉挪移，拼湊出各個塊給進程用，P2 以為自己在用 A 內(nèi)存，實際上已經(jīng)被系統(tǒng)悄悄重定向到真正的 B 去了，甚至，當 P1 和 P2 共用了 C 內(nèi)存，他們也不知道。

操作系統(tǒng)的這種欺騙進程的手段，就是虛擬內(nèi)存。對 P1 和 P2 等進程來說，它們都以為自己占用了整個內(nèi)存，而自己使用的物理內(nèi)存的哪段地址，它們并不知道也無需關心。

分頁和頁表

虛擬內(nèi)存是操作系統(tǒng)里的概念，對操作系統(tǒng)來說，虛擬內(nèi)存就是一張張的對照表，P1 獲取 A 內(nèi)存里的數(shù)據(jù)時應該去物理內(nèi)存的 A 地址找，而找 B 內(nèi)存里的數(shù)據(jù)應該去物理內(nèi)存的 C 地址。

我們知道系統(tǒng)里的基本單位都是 Byte 字節(jié)，如果將每一個虛擬內(nèi)存的 Byte 都對應到物理內(nèi)存的地址，每個條目最少需要 8字節(jié)（32位虛擬地址->32位物理地址），在 4G 內(nèi)存的情況下，就需要 32GB 的空間來存放對照表，那么這張表就大得真正的物理地址也放不下了，于是操作系統(tǒng)引入了頁（Page）的概念。

在系統(tǒng)啟動時，操作系統(tǒng)將整個物理內(nèi)存以 4K 為單位，劃分為各個頁。之后進行內(nèi)存分配時，都以頁為單位，那么虛擬內(nèi)存頁對應物理內(nèi)存頁的映射表就大大減小了，4G 內(nèi)存，只需要 8M 的映射表即可，一些進程沒有使用到的虛擬內(nèi)存，也并不需要保存映射關系，而且Linux 還為大內(nèi)存設計了多級頁表，可以進一頁減少了內(nèi)存消耗。操作系統(tǒng)虛擬內(nèi)存到物理內(nèi)存的映射表，就被稱為頁表。

內(nèi)存尋址和分配

我們知道通過虛擬內(nèi)存機制，每個進程都以為自己占用了全部內(nèi)存，進程訪問內(nèi)存時，操作系統(tǒng)都會把進程提供的虛擬內(nèi)存地址轉換為物理地址，再去對應的物理地址上獲取數(shù)據(jù)。CPU 中有一種硬件，內(nèi)存管理單元 MMU（Memory Management Unit）專門用來將翻譯虛擬內(nèi)存地址。CPU 還為頁表尋址設置了緩存策略，由于程序的局部性，其緩存命中率能達到 98%。

以上情況是頁表內(nèi)存在虛擬地址到物理地址的映射，而如果進程訪問的物理地址還沒有被分配，系統(tǒng)則會產(chǎn)生一個缺頁中斷，在中斷處理時，系統(tǒng)切到內(nèi)核態(tài)為進程虛擬地址分配物理地址。

功能

虛擬內(nèi)存不僅通過內(nèi)存地址轉換解決了多個進程訪問內(nèi)存沖突的問題，還帶來更多的益處。

進程內(nèi)存管理

它有助于進程進行內(nèi)存管理，主要體現(xiàn)在：

內(nèi)存完整性：由于虛擬內(nèi)存對進程的”欺騙”，每個進程都認為自己獲取的內(nèi)存是一塊連續(xù)的地址。我們在編寫應用程序時，就不用考慮大塊地址的分配，總是認為系統(tǒng)有足夠的大塊內(nèi)存即可。
安全：由于進程訪問內(nèi)存時，都要通過頁表來尋址，操作系統(tǒng)在頁表的各個項目上添加各種訪問權限標識位，就可以實現(xiàn)內(nèi)存的權限控制。

數(shù)據(jù)共享

通過虛擬內(nèi)存更容易實現(xiàn)內(nèi)存和數(shù)據(jù)的共享。

在進程加載系統(tǒng)庫時，總是先分配一塊內(nèi)存，將磁盤中的庫文件加載到這塊內(nèi)存中，在直接使用物理內(nèi)存時，由于物理內(nèi)存地址唯一，即使系統(tǒng)發(fā)現(xiàn)同一個庫在系統(tǒng)內(nèi)加載了兩次，但每個進程指定的加載內(nèi)存不一樣，系統(tǒng)也無能為力。

而在使用虛擬內(nèi)存時，系統(tǒng)只需要將進程的虛擬內(nèi)存地址指向庫文件所在的物理內(nèi)存地址即可。如上文圖中所示，進程 P1 和 P2 的 B 地址都指向了物理地址 C。

而通過使用虛擬內(nèi)存使用共享內(nèi)存也很簡單，系統(tǒng)只需要將各個進程的虛擬內(nèi)存地址指向系統(tǒng)分配的共享內(nèi)存地址即可。

SWAP

虛擬內(nèi)存可以讓幫進程”擴充”內(nèi)存。

我們前文提到了虛擬內(nèi)存通過缺頁中斷為進程分配物理內(nèi)存，內(nèi)存總是有限的，如果所有的物理內(nèi)存都被占用了怎么辦呢？

Linux 提出 SWAP 的概念，Linux 中可以使用 SWAP 分區(qū)，在分配物理內(nèi)存，但可用內(nèi)存不足時，將暫時不用的內(nèi)存數(shù)據(jù)先放到磁盤上，讓有需要的進程先使用，等進程再需要使用這些數(shù)據(jù)時，再將這些數(shù)據(jù)加載到內(nèi)存中，通過這種”交換”技術，Linux 可以讓進程使用更多的內(nèi)存。

常見問題

在了解虛擬內(nèi)存時，我也有過很多的問題。

32位和64位

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

CPU 通過物理總線訪問內(nèi)存，那么訪問地址的范圍就受限于機器總線的數(shù)量，在32位機器上，有32條總線，每條總線有高低兩種電位分別代表 bit 的 1 和 0，那么可訪問的最大地址就是 2^32bit = 4GB，所以說 32 位機器上插入大于 4G 的內(nèi)存是無效的，CPU 訪問不到多于 4G 的內(nèi)存。

但 64位機器并沒有 64位總線，而且其最大內(nèi)存還要受限于操作系統(tǒng)，Linux 目前支持最大 256G 內(nèi)存。

根據(jù)虛擬內(nèi)存的概念，在 32 位系統(tǒng)上運行 64 位軟件也并無不可，但由于系統(tǒng)對虛擬內(nèi)存地址的結構設計，64位的虛擬地址在32位系統(tǒng)內(nèi)并不能使用。

直接操作物理內(nèi)存

操作系統(tǒng)使用了虛擬內(nèi)存，我們想要直接操作內(nèi)存該怎么辦呢？

Linux 會將各個設備都映射到/dev/目錄下的文件，我們可以通過這些設備文件直接操作硬件，內(nèi)存也不例外。在 Linux 中，內(nèi)存設置被映射為/dev/mem，root 用戶通過對這個文件讀寫，可以直接操作內(nèi)存。

JVM 進程占用虛擬內(nèi)存過多

使用 TOP 查看系統(tǒng)性能時，我們會發(fā)現(xiàn)在 VIRT 這一列，Java 進程會占用大量的虛擬內(nèi)存。

導致這種問題的原因是 Java 使用 Glibc 的 Arena 內(nèi)存池分配了大量的虛擬內(nèi)存并沒有使用。此外，Java 讀取的文件也會被映射為虛擬內(nèi)存，在虛擬機默認配置下 Java 每個線程棧會占用 1M 的虛擬內(nèi)存。具體可以查看為什么linux下多線程程序如此消耗虛擬內(nèi)存。

而真實占用的物理內(nèi)存要看RES(resident) 列，這一列的值才是真正被映射到物理內(nèi)存的大小。

常用管理命令

我們也可以自己來管理 Linux 的虛擬內(nèi)存。

查看系統(tǒng)內(nèi)存狀態(tài)

查看系統(tǒng)內(nèi)存情況的方式有很多，free、vmstat等命令都可輸出當前系統(tǒng)的內(nèi)存狀態(tài)，需要注意的是可用內(nèi)存并不只是 free 這一列，由于操作系統(tǒng)的 lazy 特性，大量的 buffer/cache 在進程不再使用后，不會被立即清理，如果之前使用它們的進程再次運行還可以繼續(xù)使用，它們在必要時也是可以被利用的。

此外，通過cat /proc/meminfo可以查看系統(tǒng)內(nèi)存被使用的詳細情況，包括臟頁狀態(tài)等。詳情可參見：/PROC/MEMINFO之謎。