场景说明：在实际的应用中，当出现OOM的异常的时候，并不是我们期待的。我们强制进程终止，实际上，关闭服务，导致服务失效，在某种程度上和系统崩溃或者重启或者死机，没有什么分别。对于实际的客户而言，无法提供服务，本身就是一个异常，不管是为了宕机的需要或者是机器的冷却。实际上，我们都应该从中找出问题的根本。在很多的因素下，我们不是为了保护整个系统而设计了OOM保护程序，恰恰相反，是通过这种机制，找出问题的所在。

    如果我们尝试想监控我们的服务程序，是否会引发OOM，我们可以通过增加OOM的系数，当整个系统内存不足，可以直接关闭当前的进程。让我们来查看一段OOM的代码：

 /*	 * Adjust the score by oomkilladj.	 */	if (p->oomkilladj) {		if (p->oomkilladj > 0)			points <<= p->oomkilladj;		else			points >>= -(p->oomkilladj);	} 简单的说明：points是当前进程是否需要终止的评估量整型，数值越大，这个进程越可能被终止，p是当前进程的描述符struct task_struct.

下满描述如何能够修改oomkilladj参数，任何一个进程在/proc下生成一个进程标志的文件夹，记录下，当前进程的一些参数，例如我们通过ps 查看到进程的ID号是100，就可以查看/proc/100/下的东西。其中有一个oom_adj的参数可以设置，详细的设置如下：

摘自：

echo 100 > /proc/100/oom_adj

当然我们从移动的位置就可以看出不可能无限的移动，否则物极必反。其值一般是-16到15之间。

当然OOM机制也是可以被关闭的，通过传递如下的参数：

sysctl vm.overcommit_memory=2echo "vm.overcommit_memory=2" >> /etc/sysctl.conf