在4G內(nèi)存的機器上，申請8G內(nèi)存會怎么樣？

大家好，我是小林。

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

然后，我?guī)退挪榱讼?，原來是?Linux 的 overcommit_memory 參數(shù)有關，這個參數(shù)主要是定義進程申請的內(nèi)存收否允許激進。

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

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

廢話不多說，發(fā)車辣！

正文

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

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

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

操作系統(tǒng)是 32 位的，還是 64 位的？

申請完 8G 內(nèi)存后會不會被使用？

操作系統(tǒng)有沒有使用 Swap 機制？

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

操作系統(tǒng)虛擬內(nèi)存大小

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

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

缺頁中斷處理函數(shù)會看是否有空閑的物理內(nèi)存：

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

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

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

通過這里可以看出：

32 位系統(tǒng)的內(nèi)核空間占用 1G，位于最高處，剩下的 3G 是用戶空間；

64 位系統(tǒng)的內(nèi)核空間和用戶空間都是 128T，分別占據(jù)整個內(nèi)存空間的最高和最低處，剩下的中間部分是未定義的。

32 位操作系統(tǒng)的場景

現(xiàn)在可以回答這個問題了：在 32 位操作系統(tǒng)、4GB 物理內(nèi)存的機器上，申請 8GB 內(nèi)存，會怎么樣？

因為 32 位操作系統(tǒng)，進程最多只能申請 3 GB 大小的虛擬內(nèi)存空間，所以進程申請 8GB 內(nèi)存的話，在申請?zhí)摂M內(nèi)存階段就會失?。ㄎ沂稚蠜]有 32 位操作系統(tǒng)測試，我估計失敗的錯誤是 cannot allocate memory，也就是無法申請內(nèi)存失?。?。

64 位操作系統(tǒng)的場景

在 64 位操作系統(tǒng)、4GB 物理內(nèi)存的機器上，申請 8G 內(nèi)存，會怎么樣？

64 位操作系統(tǒng)，進程可以使用 128 TB 大小的虛擬內(nèi)存空間，所以進程申請 8GB 內(nèi)存是沒問題的，因為進程申請內(nèi)存是申請?zhí)摂M內(nèi)存，只要不讀寫這個虛擬內(nèi)存，操作系統(tǒng)就不會分配物理內(nèi)存。

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

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

#include
#include
#include
#include

#defineMEM_SIZE1024*1024*1024

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

	

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

	

	我們可以通過下面這條命令查看進程（test）的虛擬內(nèi)存大?。?/p>

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


	

	其中，VSZ 就代表進程使用的虛擬內(nèi)存大小，RSS 代表進程使用的物理內(nèi)存大小?？梢钥吹剑琕SZ 大小為 4198540，也就是 4GB 的虛擬內(nèi)存。

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

	失敗的錯誤：

	

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

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

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

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

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

	
echo1>/proc/sys/vm/overcommit_memory


	

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

	

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

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

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

	不一定，還得看你服務器的物理內(nèi)存大小。

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

	

	注意，這次是 killed，而不是 Cannot Allocate Memory，說明并不是內(nèi)存申請有問題，而是觸發(fā) OOM 了。

	但是為什么會觸發(fā) OOM 呢？

	那得看你的主機的「物理內(nèi)存」夠不夠大了，即使 malloc 申請的是虛擬內(nèi)存，只要不去訪問就不會映射到物理內(nèi)存，但是申請?zhí)摂M內(nèi)存的過程中，還是使用到了物理內(nèi)存（比如內(nèi)核保存虛擬內(nèi)存的數(shù)據(jù)結(jié)構(gòu)，也是占用物理內(nèi)存的），如果你的主機是只有 2GB 的物理內(nèi)存的話，大概率會觸發(fā) OOM。

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

	

	可以看到申請?zhí)摂M內(nèi)存的過程中物理內(nèi)存使用量一直在增長。

	

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

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

	那么 2GB 的物理內(nèi)存的 64 位操作系統(tǒng)，就不能申請128T的虛擬內(nèi)存了嗎？

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

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

	

	發(fā)現(xiàn)出現(xiàn)了 Cannot allocate memory，但是其實到這里已經(jīng)成功了，

	打開計算器計算一下，發(fā)現(xiàn)已經(jīng)申請了 127.998T 虛擬內(nèi)存了。

	

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

	申請 127T 虛擬內(nèi)存試試：

	

	發(fā)現(xiàn)進程沒有被殺死，也沒有 Cannot allocate memory，也正好是 127T 虛擬內(nèi)存空間。

	

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

	

	Swap 機制的作用

	前面討論在 32 位/64 位操作系統(tǒng)環(huán)境下，申請的虛擬內(nèi)存超過物理內(nèi)存后會怎么樣？

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

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

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

	如果申請物理內(nèi)存大小超過了空閑物理內(nèi)存大小，就要看操作系統(tǒng)有沒有開啟 Swap 機制：

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

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

	什么是 Swap 機制？

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

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

	這種，將內(nèi)存數(shù)據(jù)換出磁盤，又從磁盤中恢復數(shù)據(jù)到內(nèi)存的過程，就是 Swap 機制負責的。

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

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

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

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

	

	使用 Swap 機制優(yōu)點是，應用程序?qū)嶋H可以使用的內(nèi)存空間將遠遠超過系統(tǒng)的物理內(nèi)存。由于硬盤空間的價格遠比內(nèi)存要低，因此這種方式無疑是經(jīng)濟實惠的。當然，頻繁地讀寫硬盤，會顯著降低操作系統(tǒng)的運行速率，這也是 Swap 的弊端。

	Linux 中的 Swap 機制會在內(nèi)存不足和內(nèi)存閑置的場景下觸發(fā)：

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

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

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

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

	Swap 文件是文件系統(tǒng)中的特殊文件，它與文件系統(tǒng)中的其他文件也沒有太多的區(qū)別；

	Swap 換入換出的是什么類型的內(nèi)存？

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

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

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

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

	實驗一：沒有開啟 Swap 機制

	實驗二：有開啟 Swap 機制

	實驗一：沒有開啟 Swap 機制

	我的服務器是 64 位操作系統(tǒng)，但是物理內(nèi)存只有 2 GB，而且沒有 Swap 分區(qū)：

	

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

	
#include
#include
#include
#include

#defineMEM_SIZE1024*1024*1024

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

	

	運行結(jié)果：

	

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

	通過查看 message 系統(tǒng)日志，可以發(fā)現(xiàn)該進程是被操作系統(tǒng) OOM killer 機制殺掉了，日志里報錯了 Out of memory，也就是發(fā)生 OOM（內(nèi)存溢出錯誤）。

	

	什么是 OOM?

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

	實驗二：有開啟 Swap 機制

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

	

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

	
#include
#include
#include

#defineMEM_SIZE32*1024*1024*1024

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

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


	

	運行結(jié)果如下：

	

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

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

	

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

	

	有了 Swap 分區(qū)，是不是意味著進程可以使用的內(nèi)存是無上限的？

	當然不是。

	我把上面的代碼改成了申請 64GB 內(nèi)存后，當進程申請完 64GB 虛擬內(nèi)存后，使用到 56 GB （這個不要理解為占用的物理內(nèi)存，理解為已被訪問的虛擬內(nèi)存大小，也就是在物理內(nèi)存呆過的內(nèi)存大?。┑臅r候，進程就被系統(tǒng) kill 掉了，如下圖：

	

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

	總結(jié)

	至此， 驗證完成了。簡單總結(jié)下：

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

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

	如果沒有 Swap 分區(qū)，因為物理空間不夠，進程會被操作系統(tǒng)殺掉，原因是 OOM（內(nèi)存溢出）；

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

	完！

	溜啦溜啦！

	審核編輯：湯梓紅