[TOC]
同 CPU 管理一樣，內(nèi)存管理也是操作系統(tǒng)最核心的功能之一。內(nèi)存主要用來存儲系統(tǒng)和應用程序的指令、數(shù)據(jù)、緩存等。
那么，Linux 到底是怎么管理內(nèi)存的呢？今天，我就來帶你一起來看看這個問題。
內(nèi)存映射
說到內(nèi)存，你能說出你現(xiàn)在用的這臺計算機內(nèi)存有多大嗎？我估計你記得很清楚，因為這是我們購買時，首先考慮的一個重要參數(shù)，比方說，我的筆記本電腦內(nèi)存就是 8GB 的 。
我們通常所說的內(nèi)存容量，就像我剛剛提到的 8GB，其實指的是物理內(nèi)存。物理內(nèi)存也稱為主存，大多數(shù)計算機用的主存都是動態(tài)隨機訪問內(nèi)存（DRAM）。只有內(nèi)核才可以直接訪問物理內(nèi)存。那么，進程要訪問內(nèi)存時，該怎么辦呢？
Linux 內(nèi)核給每個進程都提供了一個獨立的虛擬地址空間，并且這個地址空間是連續(xù)的。這樣，進程就可以很方便地訪問內(nèi)存，更確切地說是訪問虛擬內(nèi)存。
虛擬地址空間的內(nèi)部又被分為內(nèi)核空間和用戶空間兩部分，不同字長（也就是單個 CPU 指令可以處理數(shù)據(jù)的最大長度）的處理器，地址空間的范圍也不同。比如最常見的 32 位和 64 位系統(tǒng)，我畫了兩張圖來分別表示它們的虛擬地址空間，如下所示：
通過這里可以看出，32 位系統(tǒng)的內(nèi)核空間占用 1G，位于最高處，剩下的 3G 是用戶空間。而 64 位系統(tǒng)的內(nèi)核空間和用戶空間都是 128T，分別占據(jù)整個內(nèi)存空間的最高和最低處，剩下的中間部分是未定義的。
還記得進程的用戶態(tài)和內(nèi)核態(tài)嗎？進程在用戶態(tài)時，只能訪問用戶空間內(nèi)存；只有進入內(nèi)核態(tài)后，才可以訪問內(nèi)核空間內(nèi)存。雖然每個進程的地址空間都包含了內(nèi)核空間，但這些內(nèi)核空間，其實關聯(lián)的都是相同的物理內(nèi)存。這樣，進程切換到內(nèi)核態(tài)后，就可以很方便地訪問內(nèi)核空間內(nèi)存。
既然每個進程都有一個這么大的地址空間，那么所有進程的虛擬內(nèi)存加起來，自然要比實際的物理內(nèi)存大得多。所以，并不是所有的虛擬內(nèi)存都會分配物理內(nèi)存，只有那些實際使用的虛擬內(nèi)存才分配物理內(nèi)存，并且分配后的物理內(nèi)存，是通過內(nèi)存映射來管理的。
內(nèi)存映射，其實就是將虛擬內(nèi)存地址映射到物理內(nèi)存地址。為了完成內(nèi)存映射，內(nèi)核為每個進程都維護了一張頁表，記錄虛擬地址與物理地址的映射關系，如下圖所示：
頁表實際上存儲在 CPU 的內(nèi)存管理單元 MMU 中，這樣，正常情況下，處理器就可以直接通過硬件，找出要訪問的內(nèi)存。
而當進程訪問的虛擬地址在頁表中查不到時，系統(tǒng)會產(chǎn)生一個缺頁異常，進入內(nèi)核空間分配物理內(nèi)存、更新進程頁表，最后再返回用戶空間，恢復進程的運行。
不過要注意，MMU 并不以字節(jié)為單位來管理內(nèi)存，而是規(guī)定了一個內(nèi)存映射的最小單位，也就是頁，通常是 4 KB 大小。這樣，每一次內(nèi)存映射，都需要關聯(lián) 4 KB 或者 4KB 整數(shù)倍的內(nèi)存空間。
的大小只有 4 KB ，導致的另一個問題就是，整個頁表會變得非常大。比方說，僅 32 位系統(tǒng)就需要 100 多萬個頁表項（4GB/4KB），才可以實現(xiàn)整個地址空間的映射。為了解決頁表項過多的問題，Linux 提供了兩種機制，也就是多級頁表和大頁（HugePage）。
多級頁表就是把內(nèi)存分成區(qū)塊來管理，將原來的映射關系改成區(qū)塊索引和區(qū)塊內(nèi)的偏移。由于虛擬內(nèi)存空間通常只用了很少一部分，那么，多級頁表就只保存這些使用中的區(qū)塊，這樣就可以大大地減少頁表的項數(shù)。
Linux 用的正是四級頁表來管理內(nèi)存頁，如下圖所示，虛擬地址被分為 5 個部分，前 4 個表項用于選擇頁，而最后一個索引表示頁內(nèi)偏移。
再看大頁，顧名思義，就是比普通頁更大的內(nèi)存塊，常見的大小有 2MB 和 1GB。大頁通常用在使用大量內(nèi)存的進程上，比如 Oracle、DPDK 等。
通過這些機制，在頁表的映射下，進程就可以通過虛擬地址來訪問物理內(nèi)存了。那么具體到一個 Linux 進程中，這些內(nèi)存又是怎么使用的呢？
虛擬內(nèi)存空間分布
首先，我們需要進一步了解虛擬內(nèi)存空間的分布情況。最上方的內(nèi)核空間不用多講，下方的用戶空間內(nèi)存，其實又被分成了多個不同的段。以 32 位系統(tǒng)為例，我畫了一張圖來表示它們的關系。
通過這張圖你可以看到，用戶空間內(nèi)存，從低到高分別是五種不同的內(nèi)存段。
- 只讀段，包括代碼和常量等。
- 數(shù)據(jù)段，包括全局變量等。
- 堆，包括動態(tài)分配的內(nèi)存，從低地址開始向上增長。
- 文件映射段，包括動態(tài)庫、共享內(nèi)存等，從高地址開始向下增長。
- 棧，包括局部變量和函數(shù)調(diào)用的上下文等。棧的大小是固定的，一般是 8 MB。
在這五個內(nèi)存段中，堆和文件映射段的內(nèi)存是動態(tài)分配的。比如說，使用 C 標準庫的 malloc() 或者 mmap() ，就可以分別在堆和文件映射段動態(tài)分配內(nèi)存。
其實 64 位系統(tǒng)的內(nèi)存分布也類似，只不過內(nèi)存空間要大得多。那么，更重要的問題來了，內(nèi)存究竟是怎么分配的呢？
內(nèi)存分配與回收
malloc() 是 C 標準庫提供的內(nèi)存分配函數(shù)，對應到系統(tǒng)調(diào)用上，有兩種實現(xiàn)方式，即 brk() 和 mmap()。
對小塊內(nèi)存（小于 128K），C 標準庫使用 brk() 來分配，也就是通過移動堆頂?shù)奈恢脕矸峙鋬?nèi)存。這些內(nèi)存釋放后并不會立刻歸還系統(tǒng)，而是被緩存起來，這樣就可以重復使用。
而大塊內(nèi)存（大于 128K），則直接使用內(nèi)存映射 mmap() 來分配，也就是在文件映射段找一塊空閑內(nèi)存分配出去。
這兩種方式，自然各有優(yōu)缺點。
brk() 方式的緩存，可以減少缺頁異常的發(fā)生，提高內(nèi)存訪問效率。不過，由于這些內(nèi)存沒有歸還系統(tǒng)，在內(nèi)存工作繁忙時，頻繁的內(nèi)存分配和釋放會造成內(nèi)存碎片。
而 mmap() 方式分配的內(nèi)存，會在釋放時直接歸還系統(tǒng)，所以每次 mmap 都會發(fā)生缺頁異常。在內(nèi)存工作繁忙時，頻繁的內(nèi)存分配會導致大量的缺頁異常，使內(nèi)核的管理負擔增大。這也是 malloc 只對大塊內(nèi)存使用 mmap 的原因。
了解這兩種調(diào)用方式后，我們還需要清楚一點，那就是，當這兩種調(diào)用發(fā)生后，其實并沒有真正分配內(nèi)存。這些內(nèi)存，都只在首次訪問時才分配，也就是通過缺頁異常進入內(nèi)核中，再由內(nèi)核來分配內(nèi)存。
整體來說，Linux 使用伙伴系統(tǒng)來管理內(nèi)存分配。前面我們提到過，這些內(nèi)存在 MMU 中以頁為單位進行管理，伙伴系統(tǒng)也一樣，以頁為單位來管理內(nèi)存，并且會通過相鄰頁的合并，減少內(nèi)存碎片化（比如 brk 方式造成的內(nèi)存碎片）。
你可能會想到一個問題，如果遇到比頁更小的對象，比如不到 1K 的時候，該怎么分配內(nèi)存呢？
實際系統(tǒng)運行中，確實有大量比頁還小的對象，如果為它們也分配單獨的頁，那就太浪費內(nèi)存了。
所以，在用戶空間，malloc 通過 brk() 分配的內(nèi)存，在釋放時并不立即歸還系統(tǒng)，而是緩存起來重復利用。在內(nèi)核空間，Linux 則通過 slab 分配器來管理小內(nèi)存。你可以把 slab 看成構(gòu)建在伙伴系統(tǒng)上的一個緩存，主要作用就是分配并釋放內(nèi)核中的小對象。
對內(nèi)存來說，如果只分配而不釋放，就會造成內(nèi)存泄漏，甚至會耗盡系統(tǒng)內(nèi)存。所以，在應用程序用完內(nèi)存后，還需要調(diào)用 free() 或 unmap() ，來釋放這些不用的內(nèi)存。
當然，系統(tǒng)也不會任由某個進程用完所有內(nèi)存。在發(fā)現(xiàn)內(nèi)存緊張時，系統(tǒng)就會通過一系列機制來回收內(nèi)存，比如下面這三種方式：
- 回收緩存，比如使用 LRU（Least Recently Used）算法，回收最近使用最少的內(nèi)存頁面；
- 回收不常訪問的內(nèi)存，把不常用的內(nèi)存通過交換分區(qū)直接寫到磁盤中；
- 殺死進程，內(nèi)存緊張時系統(tǒng)還會通過 OOM（Out of Memory），直接殺掉占用大量內(nèi)存的進程。
其中，第二種方式回收不常訪問的內(nèi)存時，會用到交換分區(qū)（以下簡稱 Swap）。Swap 其實就是把一塊磁盤空間當成內(nèi)存來用。它可以把進程暫時不用的數(shù)據(jù)存儲到磁盤中（這個過程稱為換出），當進程訪問這些內(nèi)存時，再從磁盤讀取這些數(shù)據(jù)到內(nèi)存中（這個過程稱為換入）。
第三種方式提到的 OOM（Out of Memory），其實是內(nèi)核的一種保護機制。它監(jiān)控進程的內(nèi)存使用情況，并且使用 oom_score 為每個進程的內(nèi)存使用情況進行評分：
- 一個進程消耗的內(nèi)存越大，oom_score 就越大；
- 一個進程運行占用的 CPU 越多，oom_score 就越小。
這樣，進程的 oom_score 越大，代表消耗的內(nèi)存越多，也就越容易被 OOM 殺死，從而可以更好保護系統(tǒng)。
當然，為了實際工作的需要，管理員可以通過 /proc 文件系統(tǒng)，手動設置進程的 oom_adj ，從而調(diào)整進程的 oom_score。
oom_adj 的范圍是 [-17, 15]，數(shù)值越大，表示進程越容易被 OOM 殺死；數(shù)值越小，表示進程越不容易被 OOM 殺死，其中 -17 表示禁止 OOM。
比如用下面的命令，你就可以把 sshd 進程的 oom_adj 調(diào)小為 -16，這樣， sshd 進程就不容易被 OOM 殺死。
echo -16 > /proc/$(pidof sshd)/oom_adj
如何查看內(nèi)存使用情況
通過了解內(nèi)存空間的分布，以及內(nèi)存的分配和回收，我想你對內(nèi)存的工作原理應該有了大概的認識。當然，系統(tǒng)的實際工作原理更加復雜，也會涉及其他一些機制，這里我只講了最主要的原理。掌握了這些，你可以對內(nèi)存的運作有一條主線認識，不至于腦海里只有術語名詞的堆砌。
那么在了解內(nèi)存的工作原理之后，我們又該怎么查看系統(tǒng)內(nèi)存使用情況呢？
其實前面 CPU 內(nèi)容的學習中，我們也提到過一些相關工具。在這里，你第一個想到的應該是 free 工具吧。下面是一個 free 的輸出示例：
# 注意不同版本的free輸出可能會有所不同
$ free
total used free shared buff/cache available
Mem: 8169348 263524 6875352 668 1030472 7611064
Swap: 0 0 0
你可以看到，free 輸出的是一個表格，其中的數(shù)值都默認以字節(jié)為單位。表格總共有兩行六列，這兩行分別是物理內(nèi)存 Mem 和交換分區(qū) Swap 的使用情況，而六列中，每列數(shù)據(jù)的含義分別為：
第一列，total 是總內(nèi)存大??；
第二列，used 是已使用內(nèi)存的大小，包含了共享內(nèi)存；
第三列，free 是未使用內(nèi)存的大??；
第四列，shared 是共享內(nèi)存的大??；
第五列，buff/cache 是緩存和緩沖區(qū)的大??；
最后一列，available 是新進程可用內(nèi)存的大小。
這里尤其注意一下，最后一列的可用內(nèi)存 available 。available 不僅包含未使用內(nèi)存，還包括了可回收的緩存，所以一般會比未使用內(nèi)存更大。不過，并不是所有緩存都可以回收，因為有些緩存可能正在使用中。
不過，我們知道，free 顯示的是整個系統(tǒng)的內(nèi)存使用情況。如果你想查看進程的內(nèi)存使用情況，可以用 top 或者 ps 等工具。比如，下面是 top 的輸出示例：
# 按下M切換到內(nèi)存排序
$ top
...
KiB Mem : 8169348 total, 6871440 free, 267096 used, 1030812 buff/cache
KiB Swap: 0 total, 0 free, 0 used. 7607492 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
430 root 19 -1 122360 35588 23748 S 0.0 0.4 0:32.17 systemd-journal
1075 root 20 0 771860 22744 11368 S 0.0 0.3 0:38.89 snapd
1048 root 20 0 170904 17292 9488 S 0.0 0.2 0:00.24 networkd-dispat
1 root 20 0 78020 9156 6644 S 0.0 0.1 0:22.92 systemd
12376 azure 20 0 76632 7456 6420 S 0.0 0.1 0:00.01 systemd
12374 root 20 0 107984 7312 6304 S 0.0 0.1 0:00.00 sshd
...
top 輸出界面的頂端，也顯示了系統(tǒng)整體的內(nèi)存使用情況，這些數(shù)據(jù)跟 free 類似，我就不再重復解釋。我們接著看下面的內(nèi)容，跟內(nèi)存相關的幾列數(shù)據(jù)，比如 VIRT、RES、SHR 以及 %MEM 等。
這些數(shù)據(jù)，包含了進程最重要的幾個內(nèi)存使用情況，我們挨個來看。
- VIRT 是進程虛擬內(nèi)存的大小，只要是進程申請過的內(nèi)存，即便還沒有真正分配物理內(nèi)存，也會計算在內(nèi)。
- RES 是常駐內(nèi)存的大小，也就是進程實際使用的物理內(nèi)存大小，但不包括 Swap 和共享內(nèi)存。
- SHR 是共享內(nèi)存的大小，比如與其他進程共同使用的共享內(nèi)存、加載的動態(tài)鏈接庫以及程序的代碼段等。%MEM 是進程使用物理內(nèi)存占系統(tǒng)總內(nèi)存的百分比。
除了要認識這些基本信息，在查看 top 輸出時，你還要注意兩點。
- 第一，虛擬內(nèi)存通常并不會全部分配物理內(nèi)存。從上面的輸出，你可以發(fā)現(xiàn)每個進程的虛擬內(nèi)存都比常駐內(nèi)存大得多。
- 第二，共享內(nèi)存 SHR 并不一定是共享的，比方說，程序的代碼段、非共享的動態(tài)鏈接庫，也都算在 SHR 里。當然，SHR 也包括了進程間真正共享的內(nèi)存。所以在計算多個進程的內(nèi)存使用時，不要把所有進程的 SHR 直接相加得出結(jié)果。
小結(jié)
今天，我們梳理了 Linux 內(nèi)存的工作原理。對普通進程來說，它能看到的其實是內(nèi)核提供的虛擬內(nèi)存，這些虛擬內(nèi)存還需要通過頁表，由系統(tǒng)映射為物理內(nèi)存。
當進程通過 malloc() 申請內(nèi)存后，內(nèi)存并不會立即分配，而是在首次訪問時，才通過缺頁異常陷入內(nèi)核中分配內(nèi)存。
由于進程的虛擬地址空間比物理內(nèi)存大很多，Linux 還提供了一系列的機制，應對內(nèi)存不足的問題，比如緩存的回收、交換分區(qū) Swap 以及 OOM 等。
當你需要了解系統(tǒng)或者進程的內(nèi)存使用情況時，可以用 free 和 top 、ps 等性能工具。它們都是分析性能問題時最常用的性能工具，希望你能熟練使用它們，并真正理解各個指標的含義。
