正文
我们可以通过设置 /proc/
/oom_adj 分数来干预系统选择杀死的进程。
这是内核关于这个oom_adj调整值的定义，最大可以调整为15,最小为-16，如果为-17，则该进程就像买了vip会员一样，不会被系统驱逐杀死了，因此，如果在一台机器上有跑很多服务器，且你不希望自己的服务被杀死的话，就可以设置自己服务的 oom_adj 为-17。
当然，说到这，就必须提到另一个参数 /proc/sys/vm/overcommit_memory，man proc 说明如下:
意思就是当 overcommit_memory 为0时，则为启发式oom，即当申请的虚拟内存不是很夸张的大于物理内存，则系统允许申请，但是当进程申请的虚拟内存很夸张的大于物理内存，则就会产生 OOM。
例如只有8g的物理内存，然后 redis 虚拟内存占用了24G，物理内存占用3g，如果这时执行 bgsave，子进程和父进程共享物理内存，但是虚拟内存是自己的，即子进程会申请24g的虚拟内存，这很夸张大于物理内存，就会产生一次OOM。
当 overcommit_memory 为1时，则永远都允许 overmemory 内存申请，即不管你多大的虚拟内存申请都允许，但是当系统内存耗尽时，这时就会产生oom，即上述的redis例子，在 overcommit_memory=1 时，是不会产生oom 的，因为物理内存足够。
当 overcommit_memory 为2时，永远都不能超出某个限定额的内存申请，这个限定额为 swap+RAM* 系数（/proc/sys/vm/overcmmit_ratio，默认50%，可以自己调整），如果这么多资源已经用光，那么后面任何尝试申请内存的行为都会返回错误，这通常意味着此时没法运行任何新程序
以上就是 OOM 的内容，了解原理，以及如何根据自己的应用，合理的设置OOM。
3、系统申请的内存都在哪？
我们了解了一个进程的地址空间之后，是否会好奇，申请到的物理内存都存在哪了？可能很多人觉得，不就是物理内存吗？
我这里说申请的内存在哪，是因为物理内存有分为cache和普通物理内存，可以通过 free 命令查看，而且物理内存还有分 DMA，NORMAL，HIGH 三个区，这里主要分析cache和普通内存。
通过第一部分，我们知道一个进程的地址空间几乎都是 mmap 函数申请，有文件映射和匿名映射两种。
3.1 共享文件映射
我们先来看下代码段和动态链接库映射段，这两个都是属于共享文件映射，也就是说由同一个可执行文件启动的两个进程是共享这两个段，都是映射到同一块物理内存，那么这块内存在哪了？我写了个程序测试如下：
我们先看下当前系统的内存使用情况:
当我在本地新建一个1G的文件：
dd if=/dev/zero of=fileblock bs=M count=1024
然后调用上述程序，进行共享文件映射,此时内存使用情况为：
我们可以发现，buff/cache 增长了大概1G，因此我们可以得出结论，代码段和动态链接库段是映射到内核cache中，也就是说当执行共享文件映射时，文件是先被读取到 cache 中，然后再映射到用户进程空间中。
3.2 私有文件映射段
对于进程空间中的数据段，其必须是私有文件映射，因为如果是共享文件映射，那么同一个可执行文件启动的两个进程，任何一个进程修改数据段，都将影响另一个进程了，我将上述测试程序改写成匿名文件映射：
在执行程序执行，需要先将之前的 cache 释放掉，否则会影响结果
echo 1 >> /proc/sys/vm/drop_caches
接着执行程序，看下内存使用情况:
从使用前和使用后对比，可以发现 used 和 buff/cache 分别增长了1G，说明当进行私有文件映射时，首先是将文件映射到 cache 中，然后如果某个文件对这个文件进行修改，则会从其他内存中分配一块内存先将文件数据拷贝至新分配的内存，然后再在新分配的内存上进行修改，这也就是写时复制。
这也很好理解，因为如果同一个可执行文件开启多个实例，那么内核先将这个可执行的数据段映射到 cache，然后每个实例如果有修改数据段，则都将分配一个一块内存存储数据段，毕竟数据段也是一个进程私有的。
通过上述分析，可以得出结论，如果是文件映射，则都是将文件映射到 cache 中，然后根据共享还是私有进行不同的操作。
3.3 私有匿名映射
