我的进程被Kill掉了

色字体行，该行是说，进程14134因为out of memory被linux内核kill掉了，该进程正是上面我们第一次执行的那个程序。

linux内核的oom killing机制，其实是一种弃车保帅的做法，因为如果我们不kill掉某进程，来释放物理内存的话，那很有可能会导致后续系统级别的crash，两害相权取其轻，操作系统只能这样处理，归根结底，是我们对进程使用物理内存的规划不足，才导致了这种情况。

那为什么不在第二次执行该程序时，在调用mmap分配虚拟内存时就直接报错，返回无法分配内存呢?

这是因为，经过多年观察，linux内核的开发人员发现，绝大部分程序在分配了很大的虚拟内存之后，在大部分时间里，并不会一直使用这么多的物理内存。

所以，为了更合理更高效的利用物理内存资源，linux内核允许虚拟内存的overcommit，即，例如在上面执行mmap分配虚拟内存时，linux内核并不会严格检查，所有运行中的进程分配的虚拟内存加起来，是否超过了整个物理内存大小。

这也就解释了为什么上面第二次运行该程序时，mmap是没有报错的。

但是，虽然mmap的虚拟内存分配成功了，但当真正使用该内存时，比如上面的写内存，此时要分配物理内存，则是有可能失败的，因为虚拟内存的overcommit，很可能导致后续的物理内存不足。

如果真的发生了这种情况，就会触发linux内核的oom killing机制，即linux内核中的oom killer会按一定的规则，选一个进程，将其kill掉，这个上面我们已经演示过了。

那为什么不kill掉第二个进程，而是kill掉第一个呢?

这个和linux内核中oom killer的选择策略有关，我们直接看源码：进程请求操作系统为其分配物理内存时，如果此时物理内存已经没有了，则会触发上图中的out_of_memory函数。

该函数中，会使用select_bad_process选择要被kill掉的进程，然后使用oom_kill_process将其kill掉，来释放物理内存。

在看select_bad_process之前，我们先看下oom_kill_process：

（编辑：应用网_丽江站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!