大家好，我是小林。

這篇文章其實之前發過，但是最近有位讀者跟我反饋，我文章中的實驗在 64 位操作系統、2 G 物理內存的場景，申請 8G 內存是沒問題的，而他也是這個環境，為什么他就無法申請成功呢？

然后，我幫他排查了下，原來是跟 Linux 的 overcommit_memory 參數有關，這個參數主要是定義進程申請的內存收否允許激進。

然后這位讀者很用心，寫了個 world 文檔總結我和他交流的過程。

我現在把這部分內容也補充了進來，相比以前的文章會更全面了一些。

廢話不多說，發車辣！

正文

看到讀者在群里討論這些面試題：

其中，第一個問題「在 4GB 物理內存的機器上，申請 8G 內存會怎么樣？」存在比較大的爭議，有人說會申請失敗，有的人說可以申請成功。

這個問題在沒有前置條件下，就說出答案就是耍流氓。這個問題要考慮三個前置條件：

操作系統是 32 位的，還是 64 位的？

申請完 8G 內存后會不會被使用？

操作系統有沒有使用 Swap 機制？

所以，我們要分場景討論。

操作系統虛擬內存大小

應用程序通過 malloc 函數申請內存的時候，實際上申請的是虛擬內存，此時并不會分配物理內存。

當應用程序讀寫了這塊虛擬內存，CPU 就會去訪問這個虛擬內存， 這時會發現這個虛擬內存沒有映射到物理內存， CPU 就會產生缺頁中斷，進程會從用戶態切換到內核態，并將缺頁中斷交給內核的 Page Fault Handler （缺頁中斷函數）處理。

缺頁中斷處理函數會看是否有空閑的物理內存：

如果有，就直接分配物理內存，并建立虛擬內存與物理內存之間的映射關系。

如果沒有空閑的物理內存，那么內核就會開始進行回收內存的工作，如果回收內存工作結束后，空閑的物理內存仍然無法滿足此次物理內存的申請，那么內核就會放最后的大招了觸發 OOM （Out of Memory）機制。

32 位操作系統和 64 位操作系統的虛擬地址空間大小是不同的，在 Linux 操作系統中，虛擬地址空間的內部又被分為內核空間和用戶空間兩部分，如下所示：

通過這里可以看出：

32 位系統的內核空間占用 1G，位于最高處，剩下的 3G 是用戶空間；

64 位系統的內核空間和用戶空間都是 128T，分別占據整個內存空間的最高和最低處，剩下的中間部分是未定義的。

32 位操作系統的場景

現在可以回答這個問題了：在 32 位操作系統、4GB 物理內存的機器上，申請 8GB 內存，會怎么樣？

因為 32 位操作系統，進程最多只能申請 3 GB 大小的虛擬內存空間，所以進程申請 8GB 內存的話，在申請虛擬內存階段就會失敗（我手上沒有 32 位操作系統測試，我估計失敗的錯誤是 cannot allocate memory，也就是無法申請內存失敗）。

64 位操作系統的場景

在 64 位操作系統、4GB 物理內存的機器上，申請 8G 內存，會怎么樣？

64 位操作系統，進程可以使用 128 TB 大小的虛擬內存空間，所以進程申請 8GB 內存是沒問題的，因為進程申請內存是申請虛擬內存，只要不讀寫這個虛擬內存，操作系統就不會分配物理內存。

我們可以簡單做個測試，我的服務器是 64 位操作系統，但是物理內存只有 2 GB：

現在，我在機器上，連續申請 4 次 1 GB 內存，也就是一共申請了 4 GB 內存，注意下面代碼只是單純分配了虛擬內存，并沒有使用該虛擬內存：

#include
#include
#include
#include

#defineMEM_SIZE1024*1024*1024

intmain(){
char*addr[4];
inti=0;
for(i=0;i

	

	然后運行這個代碼，可以看到，我的物理內存雖然只有 2GB，但是程序正常分配了 4GB 大小的虛擬內存：

	

	我們可以通過下面這條命令查看進程（test）的虛擬內存大小：

	
#psaux|greptest
USERPID%CPU%MEMVSZRSSTTYSTATSTARTTIMECOMMAND
root77970.00.04198540352pts/1S+16:580:00./test


	

	其中，VSZ 就代表進程使用的虛擬內存大小，RSS 代表進程使用的物理內存大小。可以看到，VSZ 大小為 4198540，也就是 4GB 的虛擬內存。

	開頭說的讀者跟我反饋，說他自己也做了這個實驗，然后發現 64 位操作系統、2G 物理內存的機子上，在申請 4GB 虛擬內存的時候失敗了，這是為什么呢？

	失敗的錯誤：

	

	我當時幫他排查了下，發現跟 Linux 中的 overcommit_memory 參數有關，可以使用 cat /proc/sys/vm/overcommit_memory 來查看這個參數，這個參數接受三個值：

	如果值為 0（默認值），代表：Heuristic overcommit handling，它允許overcommit，但過于明目張膽的 overcommit 會被拒絕，比如malloc一次性申請的內存大小就超過了系統總內存。Heuristic的意思是“試探式的”，內核利用某種算法猜測你的內存申請是否合理，大概可以理解為單次申請不能超過free memory + free swap + pagecache的大小 + SLAB中可回收的部分 ，超過了就會拒絕overcommit。

	如果值為 1，代表：Always overcommit. 允許overcommit，對內存申請來者不拒。

	如果值為 2，代表：Don’t overcommit. 禁止overcommit。

	當時那位讀者的 overcommit_memory 參數是默認值 0 ，所以申請失敗的原因可能是內核認為我們申請的內存太大了，它認為不合理，所以 malloc() 返回了 Cannot allocate memory 錯誤，這里申請 4GB 虛擬內存失敗的同學可以將這個 overcommit_memory 設置為1，就可以 overcommit 了。

	
echo1>/proc/sys/vm/overcommit_memory


	

	設置完為 1 后，讀者的機子就可以正常申請 4GB 虛擬內存了。

	

	不過我的環境overcommit_memory 是 0，在 64 系統、2G 物理內存場景下，也是可以成功申請 4G 內存的，我懷疑可能是不同版本的內核在overcommit_memory 為 0 時，檢測內存申請是否合理的算法可能是不同的。

	總之，如果你申請大內存的時候，不想被內核檢測內存申請是否合理的算法干擾的話，將 overcommit_memory 設置為 1 就行。

	那么將這個 overcommit_memory 設置為 1 之后，64 位的主機就可以申請接近 128T 虛擬內存了嗎？

	不一定，還得看你服務器的物理內存大小。

	讀者的服務器物理內存是 2 GB，實驗后發現，進程還沒有申請到 128T 虛擬內存的時候就被殺死了。

	

	注意，這次是 killed，而不是 Cannot Allocate Memory，說明并不是內存申請有問題，而是觸發 OOM 了。

	但是為什么會觸發 OOM 呢？

	那得看你的主機的「物理內存」夠不夠大了，即使 malloc 申請的是虛擬內存，只要不去訪問就不會映射到物理內存，但是申請虛擬內存的過程中，還是使用到了物理內存（比如內核保存虛擬內存的數據結構，也是占用物理內存的），如果你的主機是只有 2GB 的物理內存的話，大概率會觸發 OOM。

	可以使用 top 命令，點擊兩下 m，通過進度條觀察物理內存使用情況。

	

	可以看到申請虛擬內存的過程中物理內存使用量一直在增長。

	

	直到直接內存回收之后，也無法回收出一塊空間供這個進程使用，這個時候就會觸發 OOM，給所有能殺死的進程打分，分數越高的進程越容易被殺死。

	在這里當然是這個進程得分最高，那么操作系統就會將這個進程殺死，所以最后會出現 killed，而不是Cannot allocate memory。

	那么 2GB 的物理內存的 64 位操作系統，就不能申請128T的虛擬內存了嗎？

	其實可以，上面的情況是還沒開啟 swap 的情況。

	使用 swapfile 的方式開啟了 1GB 的 swap 空間之后再做實驗：

	

	發現出現了 Cannot allocate memory，但是其實到這里已經成功了，

	打開計算器計算一下，發現已經申請了 127.998T 虛擬內存了。

	

	實際上我們是不可能申請完整個 128T 的用戶空間的，因為程序運行本身也需要申請虛擬空間

	申請 127T 虛擬內存試試：

	

	發現進程沒有被殺死，也沒有 Cannot allocate memory，也正好是 127T 虛擬內存空間。

	

	在 top 中我們可以看到這個申請了127T虛擬內存的進程。

	

	Swap 機制的作用

	前面討論在 32 位/64 位操作系統環境下，申請的虛擬內存超過物理內存后會怎么樣？

	在 32 位操作系統，因為進程最大只能申請 3 GB 大小的虛擬內存，所以直接申請 8G 內存，會申請失敗。

	在 64 位操作系統，因為進程最大只能申請 128 TB 大小的虛擬內存，即使物理內存只有 4GB，申請 8G 內存也是沒問題，因為申請的內存是虛擬內存。

	程序申請的虛擬內存，如果沒有被使用，它是不會占用物理空間的。當訪問這塊虛擬內存后，操作系統才會進行物理內存分配。

	如果申請物理內存大小超過了空閑物理內存大小，就要看操作系統有沒有開啟 Swap 機制：

	如果沒有開啟 Swap 機制，程序就會直接 OOM；

	如果有開啟 Swap 機制，程序可以正常運行。

	什么是 Swap 機制？

	當系統的物理內存不夠用的時候，就需要將物理內存中的一部分空間釋放出來，以供當前運行的程序使用。那些被釋放的空間可能來自一些很長時間沒有什么操作的程序，這些被釋放的空間會被臨時保存到磁盤，等到那些程序要運行時，再從磁盤中恢復保存的數據到內存中。

	另外，當內存使用存在壓力的時候，會開始觸發內存回收行為，會把這些不常訪問的內存先寫到磁盤中，然后釋放這些內存，給其他更需要的進程使用。再次訪問這些內存時，重新從磁盤讀入內存就可以了。

	這種，將內存數據換出磁盤，又從磁盤中恢復數據到內存的過程，就是 Swap 機制負責的。

	Swap 就是把一塊磁盤空間或者本地文件，當成內存來使用，它包含換出和換入兩個過程：

	換出（Swap Out） ，是把進程暫時不用的內存數據存儲到磁盤中，并釋放這些數據占用的內存；

	換入（Swap In），是在進程再次訪問這些內存的時候，把它們從磁盤讀到內存中來；

	Swap 換入換出的過程如下圖：

	

	使用 Swap 機制優點是，應用程序實際可以使用的內存空間將遠遠超過系統的物理內存。由于硬盤空間的價格遠比內存要低，因此這種方式無疑是經濟實惠的。當然，頻繁地讀寫硬盤，會顯著降低操作系統的運行速率，這也是 Swap 的弊端。

	Linux 中的 Swap 機制會在內存不足和內存閑置的場景下觸發：

	內存不足：當系統需要的內存超過了可用的物理內存時，內核會將內存中不常使用的內存頁交換到磁盤上為當前進程讓出內存，保證正在執行的進程的可用性，這個內存回收的過程是強制的直接內存回收（Direct Page Reclaim）。直接內存回收是同步的過程，會阻塞當前申請內存的進程。

	內存閑置：應用程序在啟動階段使用的大量內存在啟動后往往都不會使用，通過后臺運行的守護進程（kSwapd），我們可以將這部分只使用一次的內存交換到磁盤上為其他內存的申請預留空間。kSwapd 是 Linux 負責頁面置換（Page replacement）的守護進程，它也是負責交換閑置內存的主要進程，它會在時，回收內存頁中的空閑內存保證系統中的其他進程可以盡快獲得申請的內存。kSwapd 是后臺進程，所以回收內存的過程是異步的，不會阻塞當前申請內存的進程。

	Linux 提供了兩種不同的方法啟用 Swap，分別是 Swap 分區（Swap Partition）和 Swap 文件（Swapfile）：

	Swap 分區是硬盤上的獨立區域，該區域只會用于交換分區，其他的文件不能存儲在該區域上，我們可以使用 swapon -s 命令查看當前系統上的交換分區；

	Swap 文件是文件系統中的特殊文件，它與文件系統中的其他文件也沒有太多的區別；

	Swap 換入換出的是什么類型的內存？

	內核緩存的文件數據，因為都有對應的磁盤文件，所以在回收文件數據的時候， 直接寫回到對應的文件就可以了。

	但是像進程的堆、棧數據等，它們是沒有實際載體，這部分內存被稱為匿名頁。而且這部分內存很可能還要再次被訪問，所以不能直接釋放內存，于是就需要有一個能保存匿名頁的磁盤載體，這個載體就是 Swap 分區。

	匿名頁回收的方式是通過 Linux 的 Swap 機制，Swap 會把不常訪問的內存先寫到磁盤中，然后釋放這些內存，給其他更需要的進程使用。再次訪問這些內存時，重新從磁盤讀入內存就可以了。

	接下來，通過兩個實驗，看看申請的物理內存超過物理內存會怎樣？

	實驗一：沒有開啟 Swap 機制

	實驗二：有開啟 Swap 機制

	實驗一：沒有開啟 Swap 機制

	我的服務器是 64 位操作系統，但是物理內存只有 2 GB，而且沒有 Swap 分區：

	

	我們改一下前面的代碼，使得在申請完 4GB 虛擬內存后，通過 memset 函數訪問這個虛擬內存，看看在沒有 Swap 分區的情況下，會發生什么？

	
#include
#include
#include
#include

#defineMEM_SIZE1024*1024*1024

intmain(){
char*addr[4];
inti=0;
for(i=0;i

	

	運行結果：

	

	可以看到，在訪問第 2 塊虛擬內存（每一塊虛擬內存是 1 GB）的時候，因為超過了機器的物理內存（2GB），進程（test）被操作系統殺掉了。

	通過查看 message 系統日志，可以發現該進程是被操作系統 OOM killer 機制殺掉了，日志里報錯了 Out of memory，也就是發生 OOM（內存溢出錯誤）。

	

	什么是 OOM?

	內存溢出(Out Of Memory，簡稱OOM)是指應用系統中存在無法回收的內存或使用的內存過多，最終使得程序運行要用到的內存大于能提供的最大內存。此時程序就運行不了，系統會提示內存溢出。

	實驗二：有開啟 Swap 機制

	我用我的 mac book pro 筆記本做測試，我的筆記本是 64 位操作系統，物理內存是 8 GB， 目前 Swap 分區大小為 1 GB（注意，這個大小不是固定不變的，Swap 分區總大小是會動態變化的，當沒有使用 Swap 分區時，Swap 分區總大小是 0；當使用了 Swap 分區，Swap 分區總大小會增加至 1 GB；當 Swap 分區已使用的大小超過 1 GB 時；Swap 分區總大小就會增加到至 2 GB；當 Swap 分區已使用的大小超過 2 GB 時；Swap 分區總大小就增加至 3GB，如此往復。這個估計是 macos 自己實現的，Linux 的分區則是固定大小的，Swap 分區不會根據使用情況而自動增長）。

	

	為了方便觀察磁盤 I/O 情況，我們改進一下前面的代碼，分配完 32 GB虛擬內存后（筆記本物理內存是 8 GB），通過一個 while 循環頻繁訪問虛擬內存，代碼如下：

	
#include
#include
#include

#defineMEM_SIZE32*1024*1024*1024

intmain(){
char*addr=(char*)malloc((long)MEM_SIZE);
printf("主線程調用malloc后，目前共申請了32gb的虛擬內存
");

//循環頻繁訪問虛擬內存
while(1){
printf("開始訪問32gb大小的虛擬內存...
");
memset(addr,0,(long)MEM_SIZE);
}
return0;
}


	

	運行結果如下：

	

	可以看到，在有 Swap 分區的情況下，即使筆記本物理內存是 8 GB，申請并使用 32 GB 內存是沒問題，程序正常運行了，并沒有發生 OOM。

	從下圖可以看到，進程的內存顯示 32 GB（這個不要理解為占用的物理內存，理解為已被訪問的虛擬內存大小，也就是在物理內存呆過的內存大小），系統已使用的 Swap 分區達到 2.3 GB。

	

	此時我的筆記本電腦的磁盤開始出現“沙沙”的聲音，通過查看磁盤的 I/O 情況，可以看到磁盤 I/O 達到了一個峰值，非常高：

	

	有了 Swap 分區，是不是意味著進程可以使用的內存是無上限的？

	當然不是。

	我把上面的代碼改成了申請 64GB 內存后，當進程申請完 64GB 虛擬內存后，使用到 56 GB （這個不要理解為占用的物理內存，理解為已被訪問的虛擬內存大小，也就是在物理內存呆過的內存大小）的時候，進程就被系統 kill 掉了，如下圖：

	

	當系統多次嘗試回收內存，還是無法滿足所需使用的內存大小，進程就會被系統 kill 掉了，意味著發生了 OOM。

	總結

	至此， 驗證完成了。簡單總結下：

	在 32 位操作系統，因為進程理論上最大能申請 3 GB 大小的虛擬內存，所以直接申請 8G 內存，會申請失敗，報錯 Cannot allocate memory

	在 64位 位操作系統，因為進程理論上最大能申請 128 TB 大小的虛擬內存，即使物理內存只有 4GB，申請 8G 內存也是沒問題，因為申請的內存是虛擬內存。如果這塊虛擬內存被訪問了，要看系統有沒有 Swap 分區：

	如果沒有 Swap 分區，因為物理空間不夠，進程會被操作系統殺掉，原因是 OOM（內存溢出）；

	如果有 Swap 分區，即使物理內存只有 4GB，程序也能正常使用 8GB 的內存，進程可以正常運行；

	完！

	溜啦溜啦！

	審核編輯：湯梓紅