先來看段代碼：

這段代碼非常簡單，就是先用mmap的方式，為該進程分配10GiB的虛擬內(nèi)存，然后再用page寫的方式，讓操作系統(tǒng)為這10GiB虛擬內(nèi)存，分配對應的物理內(nèi)存，最后sleep，等待我們測試。
運行下：

沒啥問題，和我們預期的一樣，正常執(zhí)行。
打開另一個終端，執(zhí)行以下命令，看下它的內(nèi)存占用：

上圖中的VSZ指的是虛擬內(nèi)存，RSS指的是物理內(nèi)存，單位都是KiB，所以該進程虛擬內(nèi)存和物理內(nèi)存的使用，都約等于10GiB，沒問題。
我們再開個終端，再執(zhí)行下這個程序：

第二次執(zhí)行這個程序也沒問題，但奇怪的是，此時第一次執(zhí)行的那個程序卻被kill掉了：

這是為什么呢？
上面我們說到，該程序的邏輯是分配10GiB的物理內(nèi)存，所以運行兩次，也就是要分配20GiB的物理內(nèi)存。
但在我們的測試機器上，物理內(nèi)存一共才16GiB，所以，運行兩個這樣的進程肯定是不行的。
在第二次執(zhí)行該程序，且向操作系統(tǒng)申請物理內(nèi)存時，操作系統(tǒng)會發(fā)現(xiàn)，物理內(nèi)存已經(jīng)沒有了。
此時，為了防止整個系統(tǒng)crash掉，linux內(nèi)核會觸發(fā) OOM/Out of Memory killing 機制，即按照一定的規(guī)則選擇一個進程，將其kill掉，以便回收物理內(nèi)存，以此來保證機器整體的穩(wěn)定運行。
同時，該kill事件，也會被記錄到內(nèi)核日志中，且可通過dmesg命令等方式查看。
比如上面第一個進程被kill掉的事件記錄如下：

看上面紅色字體行，該行是說，進程14134因為out of memory被linux內(nèi)核kill掉了，該進程正是上面我們第一次執(zhí)行的那個程序。
linux內(nèi)核的oom killing機制，其實是一種棄車保帥的做法，因為如果我們不kill掉某進程，來釋放物理內(nèi)存的話，那很有可能會導致后續(xù)系統(tǒng)級別的crash，兩害相權取其輕，操作系統(tǒng)只能這樣處理，歸根結底，是我們對進程使用物理內(nèi)存的規(guī)劃不足，才導致了這種情況。
那為什么不在第二次執(zhí)行該程序時，在調(diào)用mmap分配虛擬內(nèi)存時就直接報錯，返回無法分配內(nèi)存呢？
這是因為，經(jīng)過多年觀察，linux內(nèi)核的開發(fā)人員發(fā)現(xiàn)，絕大部分程序在分配了很大的虛擬內(nèi)存之后，在大部分時間里，并不會一直使用這么多的物理內(nèi)存。
所以，為了更合理更高效的利用物理內(nèi)存資源，linux內(nèi)核允許虛擬內(nèi)存的overcommit，即，例如在上面執(zhí)行mmap分配虛擬內(nèi)存時，linux內(nèi)核并不會嚴格檢查，所有運行中的進程分配的虛擬內(nèi)存加起來，是否超過了整個物理內(nèi)存大小。
這也就解釋了為什么上面第二次運行該程序時，mmap是沒有報錯的。
但是，雖然mmap的虛擬內(nèi)存分配成功了，但當真正使用該內(nèi)存時，比如上面的寫內(nèi)存，此時要分配物理內(nèi)存，則是有可能失敗的，因為虛擬內(nèi)存的overcommit，很可能導致后續(xù)的物理內(nèi)存不足。
如果真的發(fā)生了這種情況，就會觸發(fā)linux內(nèi)核的oom killing機制，即linux內(nèi)核中的oom killer會按一定的規(guī)則，選一個進程，將其kill掉，這個上面我們已經(jīng)演示過了。
那為什么不kill掉第二個進程，而是kill掉第一個呢？
這個和linux內(nèi)核中oom killer的選擇策略有關，我們直接看源碼：

當進程請求操作系統(tǒng)為其分配物理內(nèi)存時，如果此時物理內(nèi)存已經(jīng)沒有了，則會觸發(fā)上圖中的out_of_memory函數(shù)。
該函數(shù)中，會使用select_bad_process選擇要被kill掉的進程，然后使用oom_kill_process將其kill掉，來釋放物理內(nèi)存。
在看select_bad_process之前，我們先看下oom_kill_process。

該函數(shù)調(diào)用了__oom_kill_process：

在上面的函數(shù)中，通過向victim進程發(fā)送SIGKILL這個signal（我們平時使用的kill -9命令，就是用的這個signal），將其kill掉，然后該kill事件，會被記錄到內(nèi)核日志中。
注意，這里記錄的日志格式，正好和我們上面用dmesg輸出的，14134進程被kill掉事件日志格式完全一樣。
kill掉進程的過程就是這樣，我們再來看下select_bad_process函數(shù)是如何選擇要被kill掉進程的：

在該函數(shù)中，會遍歷系統(tǒng)中的所有進程，然后使用oom_evaluate_task這個函數(shù)，對各個進程進行評估：

oom_evaluate_task函數(shù)中，會使用oom_badness，計算某進程badness的點數(shù)，點數(shù)越高，越容易被kill掉。
如果badness的點數(shù)是LONG_MIN這個特殊值，則直接跳過該進程，即該進程不會成為被kill掉的對象，如果badness點數(shù)小于之前選擇進程的badness點數(shù)，同樣也跳過該進程，即被kill掉的進程badness點數(shù)要是最大的。
遍歷中選擇的進程，及其badness的點數(shù)，會被賦值到oc->chosen和oc->chosen_points里，oc->chosen最終指向的進程，就是上面oom_kill_process里kill掉的進程。
我們再來看下badness點數(shù)是如何計算的：

該函數(shù)主體邏輯分成兩部分，一部分是，在某些情況下，該進程的badness點數(shù)直接返回LONG_MIN，即不會被kill掉。
這些情況包括，oom_score_adj的值為OOM_SCORE_ADJ_MIN，即-1000，或者該進程已經(jīng)在被kill的過程中了，或者該進程在vfork過程中。
該函數(shù)邏輯的另外一部分就是計算進程的badness點數(shù)，其大致計算規(guī)則為：
points = 該進程占用的物理內(nèi)存總數(shù)  總物理內(nèi)存 * oom_score_adj值的千分比。
oom_score_adj的值，是進程獨有的，是可以通過寫 /proc/[pid]/oom_score_adj 的方式調(diào)整的，取值范圍為 -1000 到 1000。
該值越大，進程總的badness點數(shù)就會越大，進程也就越容易被kill掉。
該值越小，進程總的badness點數(shù)就會越小，該進程也就越不容易被kill掉。
上面我們還提到oom_score_adj有一個特殊值為OOM_SCORE_ADJ_MIN，即-1000，表示該進程不能被kill掉。
各進程的oom_score_adj的值默認為0。
綜上可知，linux內(nèi)核中oom killer選擇被kill進程的方式，就是看各進程badness點數(shù)的大小。
默認情況下，因為各進程的oom_score_adj的值都為0，所以進程占用的物理內(nèi)存越大，其badness點數(shù)也就越大，其也就越容易被kill掉。

這也就解釋了，為什么上面在第二次執(zhí)行那個程序時，被kill掉的是第一次執(zhí)行的那個進程，而不是第二次執(zhí)行的進程，因為第一次執(zhí)行的那個進程，占用的物理內(nèi)存更大。