其實這個話題分成兩個部分：
虛擬記憶體分配 與 空閒物理記憶體 的關係
如果單單從Linux的虛擬記憶體角度理解，虛擬記憶體和物理記憶體是沒有直接關係的。當程序mmap一塊記憶體時， Linux只是給她分配一個虛擬記憶體空間，只有等她使用該空間時，才分配物理記憶體。理論上所有程序虛擬記憶體空間加起來，會超過物理記憶體總量。一旦這些程序使用物理記憶體越來越多時，物理記憶體就不夠用了。
噢，引入swap不是可以解決了嗎？ 其實不能完全解決，只能緩解，或者增加記憶體使用的緩衝，那是因為：swap分割槽也有一個總容量的。如果真的嘗測寫測試用例，可以寫一個佔用大量匿名記憶體程式，並且執行很多個例項，那他們的虛擬記憶體總和 超越物理記憶體和swap記憶體的總和。
其實，我們想到的問題，各位OS前輩早已看到了。根據不同的場景制定不同的虛擬記憶體使用策略，具體策略在/proc/sys/vm/overcommit_memory 這個檔案控制 (策略控制說明原文在這裡），我在這裡簡單說一下：
值為0時：虛擬記憶體控制策略就是大名鼎鼎的銀行家演算法，程序申請的虛擬空間，必須小於當前可用物理記憶體空間，才能申請透過。
值為1時：不做任何檢查，所有虛擬記憶體申請都透過。
值為2時：不允許記憶體超量使用原則，所有程序的空虛記憶體空間總和，不能超過物理內物理總量 (實際上還是要乘以一個小於1的因子，以保證核心態使用記憶體）
如果物理記憶體不足了，核心會怎麼辦
物理記憶體一定有不夠用的可能，上述談到3種虛擬記憶體分配策略，都可能出現物理記憶體不足。值為1和2時，就不用說了，虛擬記憶體總量一定會超過物理記憶體。值為2時，使用者態不會超，但核心態會種造成物理記憶體不足。如果物理記憶體不足，就會發生OOM（out-of-memory）行為。
核心使用oom-killer模組去殺程序，釋放記憶體，讓當前系統可用。
oom-killer會根據每程序使用的記憶體量和活躍做個綜合評分，得分高者會被殺死，直到記憶體充足為止。當然，也會遇到無法釋放足夠的記憶體給當前系統使用，如果真發生這種情況，核心只能噗一聲（panic），表示無力迴天。
其實這個話題分成兩個部分：
虛擬記憶體分配 與 空閒物理記憶體 的關係
如果單單從Linux的虛擬記憶體角度理解，虛擬記憶體和物理記憶體是沒有直接關係的。當程序mmap一塊記憶體時， Linux只是給她分配一個虛擬記憶體空間，只有等她使用該空間時，才分配物理記憶體。理論上所有程序虛擬記憶體空間加起來，會超過物理記憶體總量。一旦這些程序使用物理記憶體越來越多時，物理記憶體就不夠用了。
噢，引入swap不是可以解決了嗎？ 其實不能完全解決，只能緩解，或者增加記憶體使用的緩衝，那是因為：swap分割槽也有一個總容量的。如果真的嘗測寫測試用例，可以寫一個佔用大量匿名記憶體程式，並且執行很多個例項，那他們的虛擬記憶體總和 超越物理記憶體和swap記憶體的總和。
其實，我們想到的問題，各位OS前輩早已看到了。根據不同的場景制定不同的虛擬記憶體使用策略，具體策略在/proc/sys/vm/overcommit_memory 這個檔案控制 (策略控制說明原文在這裡），我在這裡簡單說一下：
值為0時：虛擬記憶體控制策略就是大名鼎鼎的銀行家演算法，程序申請的虛擬空間，必須小於當前可用物理記憶體空間，才能申請透過。
值為1時：不做任何檢查，所有虛擬記憶體申請都透過。
值為2時：不允許記憶體超量使用原則，所有程序的空虛記憶體空間總和，不能超過物理內物理總量 (實際上還是要乘以一個小於1的因子，以保證核心態使用記憶體）
如果物理記憶體不足了，核心會怎麼辦
物理記憶體一定有不夠用的可能，上述談到3種虛擬記憶體分配策略，都可能出現物理記憶體不足。值為1和2時，就不用說了，虛擬記憶體總量一定會超過物理記憶體。值為2時，使用者態不會超，但核心態會種造成物理記憶體不足。如果物理記憶體不足，就會發生OOM（out-of-memory）行為。
核心使用oom-killer模組去殺程序，釋放記憶體，讓當前系統可用。
oom-killer會根據每程序使用的記憶體量和活躍做個綜合評分，得分高者會被殺死，直到記憶體充足為止。當然，也會遇到無法釋放足夠的記憶體給當前系統使用，如果真發生這種情況，核心只能噗一聲（panic），表示無力迴天。