之前在實習時，聽了 OOM 的分享之后，就對 Linux 內核內存管理充滿興趣，但是這塊知識非常龐大，沒有一定積累，不敢寫下，擔心誤人子弟，所以經過一個一段時間的積累，對內核內存有一定了解之后，今天才寫下這篇文章記錄，分享。

這篇文章主要是分析了單個進程空間的內存布局與分配，是從全局的視角分析下內核對內存的管理；

下面主要從以下方面介紹 Linux 內存管理：

進程的內存申請與分配；

內存耗盡之后 OOM；

申請的內存都在哪？

系統回收內存；

1、進程的內存申請與分配

之前文章介紹 hello world 程序是如何載入內存以及是如何申請內存的，在這再次說明下：同樣，還是先給出進程的地址空間，我覺得對于任何開發人員這張圖是必須記住的，還有一張就是操作 disk ，memory 以及 cpu cache 的時間圖。

當我們在終端啟動一個程序時，終端進程調用 exec 函數將可執行文件載入內存，此時代碼段，數據段，bbs 段，stack 段都通過 mmap 函數映射到內存空間，堆則要根據是否有在堆上申請內存來決定是否映射。

exec 執行之后，此時并未真正開始執行進程，而是將 cpu 控制權交給了動態鏈接庫裝載器，由它來將該進程需要的動態鏈接庫裝載進內存。之后才開始進程的執行，這個過程可以通過 strace 命令跟蹤進程調用的系統函數來分析。

這是認識 pipe 中的程序，從這個輸出過程，可以看出和我上述描述的一致。

當第一次調用 malloc 申請內存時，通過系統調用 brk 嵌入到內核，首先會進行一次判斷，是否有關于堆的 vma，如果沒有，則通過 mmap 匿名映射一塊內存給堆，并建立 vma 結構，掛到 mm_struct 描述符上的紅黑樹和鏈表上。

然后回到用戶態，通過內存分配器（ptmaloc，tcmalloc，jemalloc）算法將分配到的內存進行管理，返回給用戶所需要的內存。

如果用戶態申請大內存時，是直接調用 mmap 分配內存，此時返回給用戶態的內存還是虛擬內存，直到第一次訪問返回的內存時，才真正進行內存的分配。

其實通過 brk 返回的也是虛擬內存，但是經過內存分配器進行切割分配之后（切割就必須訪問內存），全都分配到了物理內存。

當進程在用戶態通過調用 free 釋放內存時，如果這塊內存是通過 mmap 分配，則調用 munmap 直接返回給系統。

否則內存是先返回給內存分配器，然后由內存分配器統一返還給系統，這就是為什么當我們調用 free 回收內存之后，再次訪問這塊內存時，可能不會報錯的原因。

當然，當整個進程退出之后，這個進程占用的內存都會歸還給系統。

2、內存耗盡之后OOM

在實習期間，有一臺測試機上的 mysql 實例經常被 oom 殺死，OOM（out of memory）即為系統在內存耗盡時的自我拯救措施，他會選擇一個進程，將其殺死，釋放出內存，很明顯，哪個進程占用的內存最多，即最可能被殺死，但事實是這樣的嗎？

今天早上去上班，剛好碰到了一起 OOM，突然發現，OOM 一次，世界都安靜下來了，哈哈，測試機上的 redis 被殺死了。

OOM 關鍵文件 oom_kill.c，里面介紹了當內存不夠時，系統如何選擇最應該被殺死的進程，選擇因素有挺多的，除了進程占用的內存外，還有進程運行的時間，進程的優先級，是否為 root 用戶進程，子進程個數和占用內存以及用戶控制參數 oom_adj 都相關。

當產生 oom 之后，函數 select_bad_process 會遍歷所有進程，通過之前提到的那些因素，每個進程都會得到一個 oom_score 分數，分數最高，則被選為殺死的進程。

我們可以通過設置 /proc//oom_adj 分數來干預系統選擇殺死的進程。

這是內核關于這個oom_adj調整值的定義，最大可以調整為15,最小為-16，如果為-17，則該進程就像買了vip會員一樣，不會被系統驅逐殺死了，因此，如果在一臺機器上有跑很多服務器，且你不希望自己的服務被殺死的話，就可以設置自己服務的 oom_adj 為-17。

當然，說到這，就必須提到另一個參數 /proc/sys/vm/overcommit_memory，man proc 說明如下:

意思就是當 overcommit_memory 為0時，則為啟發式oom，即當申請的虛擬內存不是很夸張的大于物理內存，則系統允許申請，但是當進程申請的虛擬內存很夸張的大于物理內存，則就會產生 OOM。

例如只有8g的物理內存，然后 redis 虛擬內存占用了24G，物理內存占用3g，如果這時執行 bgsave，子進程和父進程共享物理內存，但是虛擬內存是自己的，即子進程會申請24g的虛擬內存，這很夸張大于物理內存，就會產生一次OOM。

當 overcommit_memory 為1時，則永遠都允許 overmemory 內存申請，即不管你多大的虛擬內存申請都允許，但是當系統內存耗盡時，這時就會產生oom，即上述的redis例子，在 overcommit_memory=1 時，是不會產生oom 的，因為物理內存足夠。

當 overcommit_memory 為2時，永遠都不能超出某個限定額的內存申請，這個限定額為 swap+RAM* 系數（/proc/sys/vm/overcmmit_ratio，默認50%，可以自己調整），如果這么多資源已經用光，那么后面任何嘗試申請內存的行為都會返回錯誤，這通常意味著此時沒法運行任何新程序。

以上就是 OOM 的內容，了解原理，以及如何根據自己的應用，合理的設置OOM。

3、系統申請的內存都在哪？ ?

我們了解了一個進程的地址空間之后，是否會好奇，申請到的物理內存都存在哪了？可能很多人覺得，不就是物理內存嗎？

我這里說申請的內存在哪，是因為物理內存有分為cache和普通物理內存，可以通過 free 命令查看，而且物理內存還有分 DMA，NORMAL，HIGH 三個區，這里主要分析cache和普通內存。

通過第一部分，我們知道一個進程的地址空間幾乎都是 mmap 函數申請，有文件映射和匿名映射兩種。

3.1 共享文件映射 我們先來看下代碼段和動態鏈接庫映射段，這兩個都是屬于共享文件映射，也就是說由同一個可執行文件啟動的兩個進程是共享這兩個段，都是映射到同一塊物理內存，那么這塊內存在哪了？我寫了個程序測試如下：

我們先看下當前系統的內存使用情況：

當我在本地新建一個1G的文件：

dd if=/dev/zero of=fileblock bs=M count=1024

然后調用上述程序，進行共享文件映射,此時內存使用情況為：

我們可以發現，buff/cache 增長了大概1G，因此我們可以得出結論，代碼段和動態鏈接庫段是映射到內核cache中，也就是說當執行共享文件映射時，文件是先被讀取到 cache 中，然后再映射到用戶進程空間中。

3.2 私有文件映射段 對于進程空間中的數據段，其必須是私有文件映射，因為如果是共享文件映射，那么同一個可執行文件啟動的兩個進程，任何一個進程修改數據段，都將影響另一個進程了，我將上述測試程序改寫成匿名文件映射：

在執行程序執行，需要先將之前的 cache 釋放掉，否則會影響結果

echo 1 >> /proc/sys/vm/drop_caches

接著執行程序，看下內存使用情況：

從使用前和使用后對比，可以發現 used 和 buff/cache 分別增長了1G，說明當進行私有文件映射時，首先是將文件映射到 cache 中，然后如果某個文件對這個文件進行修改，則會從其他內存中分配一塊內存先將文件數據拷貝至新分配的內存，然后再在新分配的內存上進行修改，這也就是寫時復制。

這也很好理解，因為如果同一個可執行文件開啟多個實例，那么內核先將這個可執行的數據段映射到 cache，然后每個實例如果有修改數據段，則都將分配一個一塊內存存儲數據段，畢竟數據段也是一個進程私有的。

通過上述分析，可以得出結論，如果是文件映射，則都是將文件映射到 cache 中，然后根據共享還是私有進行不同的操作。

3.3 私有匿名映射

像 bbs 段，堆，棧這些都是匿名映射，因為可執行文件中沒有相應的段，而且必須是私有映射，否則如果當前進程 fork 出一個子進程，那么父子進程將會共享這些段，一個修改都會影響到彼此，這是不合理的。

ok，現在我把上述測試程序改成私有匿名映射

這時再來看下內存的使用情況：

我們可以看到，只有 used 增加了1G，而 buff/cache 并沒有增長；說明，在進行匿名私有映射時，并沒有占用 cache，其實這也是有道理，因為就只有當前進程在使用這塊這塊內存，沒有必要占用寶貴的 cache。

3.4 共享匿名映射 當我們需要在父子進程共享內存時，就可以用到 mmap 共享匿名映射，那么共享匿名映射的內存是存放在哪了？我繼續改寫上述測試程序為共享匿名映射。

這時來看下內存的使用情況：

從上述結果，我們可以看出，只有buff/cache增長了1G，即當進行共享匿名映射時，這時是從 cache 中申請內存，道理也很明顯，因為父子進程共享這塊內存，共享匿名映射存在于 cache，然后每個進程再映射到彼此的虛存空間，這樣即可操作的是同一塊內存。

4、系統回收內存

當系統內存不足時，有兩種方式進行內存釋放，一種是手動的方式，另一種是系統自己觸發的內存回收，先來看下手動觸發方式。

4.1 手動回收內存

手動回收內存，之前也有演示過，即

echo 1 >> /proc/sys/vm/drop_caches

我們可以在 man proc 下面看到關于這個的簡介

從這個介紹可以看出，當 drop_caches 文件為1時，這時將釋放 pagecache 中可釋放的部分（有些 cache 是不能通過這個釋放的），當 drop_caches 為2時，這時將釋放 dentries 和 inodes 緩存，當 drop_caches 為3時，這同時釋放上述兩項。

關鍵還有最后一句，意思是說如果 pagecache 中有臟數據時，操作 drop_caches 是不能釋放的，必須通過 sync 命令將臟數據刷新到磁盤，才能通過操作 drop_caches 釋放 pagecache。

ok，之前有提到有些pagecache是不能通過drop_caches釋放的，那么除了上述提文件映射和共享匿名映射外，還有有哪些東西是存在pagecache了？

4.2 tmpfs

我們先來看下 tmpfs ，tmpfs 和 procfs，sysfs 以及 ramfs 一樣，都是基于內存的文件系統，tmpfs 和 ramfs 的區別就是 ramfs 的文件基于純內存的，和 tmpfs 除了純內存外，還會使用 swap 交換空間，以及 ramfs 可能會把內存耗盡，而 tmpfs 可以限定使用內存大小，可以用命令 df -T -h 查看系統一些文件系統，其中就有一些是 tmpfs，比較出名的是目錄 /dev/shm。

tmpfs 文件系統源文件在內核源碼 mm/shmem.c，tmpfs實現很復雜，之前有介紹虛擬文件系統，基于 tmpfs 文件系統創建文件和其他基于磁盤的文件系統一樣，也會有 inode，super_block，identry，file 等結構，區別主要是在讀寫上，因為讀寫才涉及到文件的載體是內存還是磁盤。

而 tmpfs 文件的讀函數 shmem_file_read，過程主要為通過 inode 結構找到 address_space 地址空間，其實就是磁盤文件的 pagecache，然后通過讀偏移定位cache 頁以及頁內偏移。

這時就可以直接從這個 pagecache 通過函數 __copy_to_user 將緩存頁內數據拷貝到用戶空間，當我們要讀取的數據不pagecache中時，這時要判斷是否在 swap 中，如果在則先將內存頁 swap in，再讀取。

tmpfs 文件的寫函數 shmem_file_write，過程主要為先判斷要寫的頁是否在內存中，如果在，則直接將用戶態數據通過函數__copy_from_user拷貝至內核pagecache中覆蓋老數據，并標為 dirty。

如果要寫的數據不在內存中，則判斷是否在swap 中，如果在，則先讀取出來，用新數據覆蓋老數據并標為臟，如果既不在內存也不在磁盤，則新生成一個 pagecache 存儲用戶數據。

由上面分析，我們知道基于 tmpfs 的文件也是使用 cache 的，我們可以在/dev/shm上創建一個文件來檢測下:

看到了吧，cache 增長了1G，驗證了 tmpfs 的確使用的 cache 內存。

其實 mmap 匿名映射原理也是用了 tmpfs，在 mm/mmap.c->do_mmap_pgoff 函數內部，有判斷如果 file 結構為空以及為 SHARED 映射，則調用 shmem_zero_setup(vma) 函數在 tmpfs 上用新建一個文件

這里就解釋了為什么共享匿名映射內存初始化為0了，但是我們知道用 mmap 分配的內存初始化為0，就是說 mmap 私有匿名映射也為0，那么體現在哪了？

這個在 do_mmap_pgoff 函數內部可沒有體現出來，而是在缺頁異常，然后分配一種特殊的初始化為0的頁。

那么這個 tmpfs 占有的內存頁可以回收嗎？

也就是說 tmpfs 文件占有的 pagecache 是不能回收的，道理也很明顯，因為有文件引用這些頁，就不能回收。

4.3 共享內存

posix 共享內存其實和 mmap 共享映射是同一個道理，都是利用在 tmpfs 文件系統上新建一個文件，然后再映射到用戶態，最后兩個進程操作同一個物理內存，那么 System V 共享內存是否也是利用 tmpfs 文件系統了？

我們可以跟蹤到下述函數

這個函數就是新建一個共享內存段，其中函數

shmem_kernel_file_setup

就是在 tmpfs 文件系統上創建一個文件，然后通過這個內存文件實現進程通信，這我就不寫測試程序了，而且這也是不能回收的，因為共享內存ipc機制生命周期是隨內核的，也就是說你創建共享內存之后，如果不顯示刪除的話，進程退出之后，共享內存還是存在的。

之前看了一些技術博客，說到 Poxic 和 System V 兩套 ipc 機制(消息隊列，信號量以及共享內存)都是使用 tmpfs 文件系統，也就是說最終內存使用的都是 pagecache，但是我在源碼中看出了兩個共享內存是基于 tmpfs 文件系統，其他信號量和消息隊列還沒看出來(有待后續考究)。

posix 消息隊列的實現有點類似與 pipe 的實現，也是自己一套 mqueue 文件系統，然后在 inode 上的 i_private 上掛上關于消息隊列屬性 mqueue_inode_info，在這個屬性上，內核2.6時，是用一個數組存儲消息，而到了4.6則用紅黑樹了存儲消息(我下載了這兩個版本，具體什么時候開始用紅黑樹，沒深究)。

然后兩個進程每次操作都是操作這個 mqueue_inode_info 中的消息數組或者紅黑樹，實現進程通信，和這個 mqueue_inode_info 類似的還有 tmpfs 文件系統屬性shmem_inode_info 和為epoll服務的文件系統 eventloop,也有一個特殊屬性struct eventpoll，這個是掛在 file 結構的 private_data 等等。

說到這，可以小結下，進程空間中代碼段，數據段，動態鏈接庫(共享文件映射)，mmap 共享匿名映射都存在于 cache 中，但是這些內存頁都有被進程引用，所以是不能釋放的，基于 tmpfs 的 ipc 進程間通信機制的生命周期是隨內核，因此也是不能通過 drop_caches 釋放。

雖然上述提及的cache不能釋放，但是后面有提到，當內存不足時，這些內存是可以 swap out 的。

因此 drop_caches 能釋放的就是當從磁盤讀取文件時的緩存頁以及某個進程將某個文件映射到內存之后，進程退出，這時映射文件的的緩存頁如果沒有被引用，也是可以被釋放的。

4.4 內存自動釋放方式

當系統內存不夠時，操作系統有一套自我整理內存，并盡可能的釋放內存機制，如果這套機制不能釋放足夠多的內存，那么只能 OOM 了。

之前在提及 OOM 時，說道 redis 因為 OOM 被殺死，如下:

第二句后半部分，

total-vm:186660kB, anon-rss:9388kB, file-rss:4kB

把一個進程內存使用情況，用三個屬性進行了說明，即所有虛擬內存，常駐內存匿名映射頁以及常駐內存文件映射頁。

其實從上述的分析，我們也可以知道一個進程其實就是文件映射和匿名映射：

文件映射：代碼段，數據段，動態鏈接庫共享存儲段以及用戶程序的文件映射段；

匿名映射：bbs段，堆，以及當 malloc 用 mmap 分配的內存，還有mmap共享內存段；

其實內核回收內存就是根據文件映射和匿名映射來進行的，在 mmzone.h 有如下定義：

LRU_UNEVICTABLE 即為不可驅逐頁 lru，我的理解就是當調用 mlock 鎖住內存，不讓系統 swap out 出去的頁列表。

簡單說下 linux 內核自動回收內存原理，內核有一個 kswapd 會周期性的檢查內存使用情況，如果發現空閑內存定于 pages_low，則 kswapd 會對 lru_list 前四個 lru 隊列進行掃描，在活躍鏈表中查找不活躍的頁，并添加不活躍鏈表。

然后再遍歷不活躍鏈表，逐個進行回收釋放出32個頁，知道 free page 數量達到 pages_high，針對不同的頁，回收方式也不一樣。

當然，當內存水平低于某個極限閾值時，會直接發出內存回收，原理和 kswapd 一樣，但是這次回收力度更大，需要回收更多的內存。

文件頁：

如果是臟頁，則直接回寫進磁盤，再回收內存。

如果不是臟頁，則直接釋放回收，因為如果是io讀緩存，直接釋放掉，下次讀時，缺頁異常，直接到磁盤讀回來即可，如果是文件映射頁，直接釋放掉，下次訪問時，也是產生兩個缺頁異常，一次將文件內容讀取進磁盤，另一次與進程虛擬內存關聯。

匿名頁：因為匿名頁沒有回寫的地方，如果釋放掉，那么就找不到數據了，所以匿名頁的回收是采取 swap out 到磁盤，并在頁表項做個標記，下次缺頁異常在從磁盤 swap in 進內存。

swap 換進換出其實是很占用系統IO的，如果系統內存需求突然間迅速增長，那么cpu 將被io占用，系統會卡死，導致不能對外提供服務，因此系統提供一個參數，用于設置當進行內存回收時，執行回收 cache 和 swap 匿名頁的，這個參數為：

意思就是說這個值越高，越可能使用 swap 的方式回收內存，最大值為100，如果設為0，則盡可能使用回收 cache 的方式釋放內存。

5、總結

這篇文章主要是寫了 linux 內存管理相關的東西：

首先是回顧了進程地址空間；

其次當進程消耗大量內存而導致內存不足時，我們可以有兩種方式：第一是手動回收 cache；另一種是系統后臺線程 swapd 執行內存回收工作。

最后當申請的內存大于系統剩余的內存時，這時就只會產生 OOM，殺死進程，釋放內存，從這個過程，可以看出系統為了騰出足夠的內存，是多么的努力啊。

編輯：黃飛