4G的機器上申請8G的內存,是否可以成功?
4G的機器上申請8G的內存,是否可以成功?這個問題沒有辦法,是沒有辦法進行回答,這個問題要考慮三個前置條件:
操作系統是 32 位的,還是 64 位的?
申請完 8G 內存后會不會被使用?
操作系統有沒有使用 Swap 機制?
先在這說一下結論:
- 在 32 位操作系統,因為進程最大只能申請 3 GB 大小的虛擬內存,所以直接申請 8G 內存,會申請失敗。
- 在 64 位操作系統,因為進程最大只能申請 128 TB 大小的虛擬內存,即使物理內存只有 4GB,申請 8G 內存也是沒問題,因為申請的內存是虛擬內存。如果這塊虛擬內存被訪問了,要看系統有沒有 Swap 分區:
如果沒有 Swap 分區,因為物理空間不夠,進程會被操作系統殺掉,原因是 OOM(內存溢出);
如果有 Swap 分區,即使物理內存只有 4GB,程序也能正常使用 8GB 的內存,進程可以正常運行;
操作系統是 32 位的,還是 64 位的?
為什么要考慮操作系統是 32 位的,還是 64 位的這個前置條件呢?
我們先來回顧一下之前學習的虛擬內存的大小的知識
應用程序通過 malloc 函數申請內存的時候,實際上申請的是虛擬內存,此時并不會分配物理內存。
當應用程序讀寫了這塊虛擬內存,CPU 就會去訪問這個虛擬內存, 這時會發現這個虛擬內存沒有映射到物理內存, CPU 就會產生缺頁中斷,進程會從用戶態切換到內核態,并將缺頁中斷交給內核的 Page Fault Handler (缺頁中斷函數)處理。
缺頁中斷處理函數會看是否有空閑的物理內存:
- 如果有,就直接分配物理內存,并建立虛擬內存與物理內存之間的映射關系。
- 如果沒有空閑的物理內存,那么內核就會開始進行回收內存的工作,如果回收內存工作結束后,空閑的物理內存仍然無法滿足此次物理內存的申請,那么內核就會觸發 OOM 。
32 位操作系統和 64 位操作系統的虛擬地址空間大小是不同的,在 Linux 操作系統中,虛擬地址空間的內部又被分為內核空間和用戶空間兩部分,如下所示:
通過這里可以看出:
- 32 位系統的內核空間占用 1G,剩下的 3G 是用戶空間;
- 64 位系統的內核空間和用戶空間都是 128T,剩下的中間部分是未定義的。
32 位系統的場景
因為 32 位操作系統,進程最多只能申請 3 GB 大小的虛擬內存空間,所以進程申請 8GB 內存的話,在申請虛擬內存階段就會失敗。
64 位系統的場景
64 位操作系統,進程可以使用 128 TB 大小的虛擬內存空間,所以進程申請 8GB 內存是沒問題的,因為進程申請內存是申請虛擬內存,只要不讀寫這個虛擬內存,操作系統就不會分配物理內存。
注意:即使 malloc 申請的是虛擬內存,只要不去訪問就不會映射到物理內存,但是申請虛擬內存的過程中,還是使用到了物理內存(比如內核保存虛擬內存的數據結構,也是占用物理內存的),如果你的主機是只有 2GB 的物理內存的話,大概率會觸發 OOM。
申請后的8G內存是否真的被使用
如果沒有被使用,就不用分配物理內存,所以64系統的前提下:一定是可以成功的沒有任何問題。
操作系統有沒有使用 Swap 機制?
如果申請的內存被使用了,也就意味著要進行物理內存的分配了,這個時候就要考慮是否開啟了Swap機制。
Swap機制
在系統的物理內存不夠用的時候,把硬盤內存中的一部分空間釋放出來,以供當前運行的程序使用。那些被釋放的空間可能來自一些很長時間沒有什么操作的程序,這些被釋放的空間被臨時保存到Swap分區中,等到那些程序要運行時,再從Swap分區中恢復保存的數據到內存中。
使用 Swap 機制優點是,應用程序實際可以使用的內存空間將遠遠超過系統的物理內存。由于硬盤空間的價格遠比內存要低,因此這種方式無疑是經濟實惠的。當然,頻繁地讀寫硬盤,會顯著降低操作系統的運行速率,這也是 Swap 的弊端。