Linux内存的分配管理与内存回收基本框架
1.序言 内存对计算机系统来说是一项非常重要的资源，直接影响着系统运行的性能。最初的时候，系统是直接运行在物理内存上的，这存在着很多的问题，尤其是安全问题。后来出现了虚拟内存，内核和进程都运行在虚拟内存上，进程与进程之间有了空间隔离，增加了安全性。进程与内核之间有特权级的区别，进程运行在非特权级，内核运行在特权级，进程不能访问内核空间，只能通过系统调用和内核进行交互，内核会对进程进行严格的权限检查和参数检查，使得系统更加安全。通过虚拟内存访问物理内存，每次都需要解析页表，这大大降低了内存访问的性能，为此cpu的mmu里面加入了tlb用来缓存页表解析的结果，这样由于程序的时间局部性和空间局部性，能极大的提高内存访问的速度。虽然和直接访问物理内存相比，仍然存在着一些性能损耗，但是损耗已经降到很低了。因此虚拟内存机制在系统安全和性能之间达到了最大的平衡。虽然如此，但是虚拟内存机制也使得计算机的内存系统变得异常复杂，给我们的编程带来了巨大的挑战。内存问题，在很多软件公司里面，都是一个非常重要非常让人头疼的问题，今天我们从oom的角度来帮大家提高一点内存方面的知识，虽然不能说帮助人们来完全解决内存问题，但是也能从一个侧面来提高大家分析内存问题相关的能力。 2.内存的分配管理 我们已经知道了物理内存、虚拟内存、用户空间、内核空间之间的区别，下面我们再来深入的了解一下这方面的知识。系统刚启动的时候是运行在物理内存之上的，然后系统建立了一段足够自己继续运行的恒等映射的页表，也就是把物理地址映射到相同地址的虚拟地址上。等到系统再进一步初始化之后，就会建立完整的页表来映射物理内存，并把内核映射在虚拟地址空间的高部位，对于32位系统来说是3g之上的内存空间，对于64系统来说，是映射到比较接近虚拟地址顶端的地方。内核初始化之后就会启动init进程，从而启动整个用户空间的所有进程。内核空间和用户空间的内存管理方式的差别是非常大的，首先内核是不会缺页也不会换页的，不会缺页是指内核的物理内存在启动时就直接映射好了，使用时直接分配就行了，分配好虚拟内存的同时物理内存也分配好了。不会换页是指，当系统内存不足时内核自身使用的物理内存不会被swap出去。与此相反，用户空间的内存分配是先分配虚拟内存，此时并不会直接分配物理内存，而是延迟到程序运行时访问到哪里的内存，如果这个内存还没有对应的物理内存，mmu就会报缺页异常从而陷入内核，执行内核的缺页异常handler给分配物理内存，并建立页表映射，然后再回到用户空间刚才的那个指令处继续执行。当系统内存不足时，用户空间使用的物理内存会被swap到磁盘，从而回收物理内存。之后如果进程再访问这段内存又会再发生缺页异常从swap处把内存内容加载回来。 3.进程的内存空间布局
明白了上面这些，我们再来看看进程的用户空间内存布局。我们都知道进程的内存空间是由代码区、数据区、堆区、栈区组成。我们先来看下面的图，我们以32位进程为例进行讲解，64位的数值太大不好画的，但是原理都是一样的。
进程启动之后的内存布局如上图所示，程序file的代码段被映射到text区，数据段映射到data区，内核还会帮进程建立堆内存区映射和栈内存区映射，堆一般紧挨着data区的末尾往上增长，栈区在3g下面一点点往下增长。数据区和代码区是在进程启动时由内核之间分配好的，之后大小就不会再改变，heap区是随着程序运行中不断的malloc/free而增长或者缩小的，stack区是随时程序运行的局部变量分配释放而变化的，局部变量的分配释放是自动的，因此这三个区域也分别被叫做静态内存、动态内存、自动内存。由此我们可以看出，我们不必对静态内存、自动内存太操心，我们最应该关系的是动态内存。我们可以brk系统调用扩大heap区域来增加堆内存，然后再自己管理使用堆内存，但是这样做显然很麻烦。因此c库为我们准备了相关的api，malloc、free，来分配和释放堆内存，这样就方便到了。 c库里面最早的malloc实现叫做dlmalloc，在计算机早期还是单cpu时代的时候非常流行，效率也非常高，但是随着smp多cpu时代的到来，dlmalloc的缺点也越来越明显，尤其是多线程同时调用malloc的时候，锁冲突越来越严重，严重影响了性能。后来业界相继出现了ptmalloc、jemalloc、scudo等优秀的malloc库。 ptmalloc是glibc的默认malloc实现，jemalloc库是首先实现在freebsd的malloc库，后广泛应用于firefox、redis、netty等众多产品中，也长期是安卓的默认malloc库实现。目前安卓已经把malloc库替换为scudo了，据说scudo在安全和性能方面都很不错。 程序简单的时候还好说，但是对于很多产品级的软件来说，其逻辑结构都非常复杂，进而导致其内存管理方面也很复杂，很容易出现栈溢出、野指针、内存泄漏等问题。我们有着很多方法和规则来规避这些问题，比如谁申请谁释放，引用计数，智能指针等，但是仍然不能完全解决这些问题。尤其是内存泄漏，在很多公司里面都是令人头疼的顽疾，对于内存泄漏也存在着很多工具，但是都无法完美的解决这个问题。我们今天要说的不是内存泄漏，而是由于内存泄漏或者内存使用不合理而导致的oom问题。 4.内存回收基本框架 在讲oom之前，我们先来了解一下内核内存回收的总体框架。内存作为系统最宝贵的资源，总是不够用的，经常需要进行回收。内存回收可分为两种方式，同步回收和异步回收，同步回收是在分配内存时发现内存不足直接调用函数进行回收，异步回收是唤醒专门的回收线程kswapd进行回收。我们先看一下它们的总体架构图，然后再一一说明。
同步回收的话是在alloc_pages时发现内存不足就直接进行回收，首先尝试的是内存规整，也就是内存碎片整理，比如说系统当前有10个不连续的空闲page，但是你要分配两个连续的page，显然是无法分配的，此时就要进行内存规整，通过移动movable page，使空闲page尽量连在一起，这样能有可能分配出多个连续的page了。如果内存规整之后还是无法分配到内存，此时就会进行页帧回收了。用户空间的物理内存可以分为两种类型，文件页和匿名页，文件页是text data段对应的页帧，它们都有文件做后备存储，匿名是栈和堆对应的内存页，它们没有对应的文件，一般用swap分区或者swap文件做它们的后备存储。系统会首先考虑干净的文件页进行回收，因为回收它们只要直接丢弃内容就可以了，需要的时候再直接从文件里读取回来，这样不会有数据丢失。如果没有干净的文件页或者干净的文件页不太多，此时就要从dirty 文件页和匿名页进行回收了，因为它们都要进行io操作，所以会非常的慢。如果页帧回收也回收不到内存的话，内核只能使出最后一招了，oom killer，直接杀进程进行内存回收，虽然这招好像不太文雅，但是也是没有办法，因为不这样做的话，系统没有多余的内存就没法继续运行，系统就会卡死，用户就会重启系统，结果更糟，所以杀进程也是最后的无奈之举。一般能走到这一步都是因为进程有长期或者严重的内存泄漏导致的。 异步回收线程kswapd是被周期性的唤醒来执行回收任务的，当然同步回收的时候也会顺便唤醒它来一起回收内存。有一点需要注意的是kswapd线程不是per cpu的，而是per node的，是一个numa节点一个线程，这是因为内存的分配是per node不是 per cpu的，大部分内存分配都是优先从本node分配或者只能从本node分配，因此哪个node的内存不足了就唤醒哪个node的kswapd线程就行内存回收工作。对于家庭电脑和手机来说都是一个node，所以一般就只有一个kswapd线程。kswapd完成回收工作之后，它会唤醒kcompactd线程进行内存规整，对的，内存规整也可以异步执行。 5.oom基本原理
在讲内核的oom killer之前，我们先来说一下oom基本概念。oom，out of memory，就是内存用完了耗尽了的意思。oom分为虚拟内存oom和物理内存oom，两者是不一样的。虚拟内存oom发生在用户空间，因为用户空间分配的就是虚拟内存，不能分配物理内存，程序在运行的时候触发缺页异常从而需要分配物理内存，内核自身在运行的时候也需要分配物理内存，如果此时物理内存不足了，就会发生物理内存oom。用户空间虚拟内存oom表现为malloc、mmap等内存分配接口返回失败，错误码为enomem。大家也许会想，虚拟内存会oom吗，虚拟内存那么大，对于32位进程来说就有3g，对于64位进程来说至少也得有上百g，应有尽有，而且很多教科书上都说的是虚拟内存可以随意分配，不受物理内存的限制，事实上真的是这样吗，让我们来看一看。 5.1、虚拟内存oom
虚拟内存我们是不是可以随意分配，虚拟空间有多大我们就能分配多少？事实不是这样的。unix世界有个著名的哲学原理，提供机制而不是策略，对于这个问题，linux也提供了机制，我们可以通过 /proc/sys/vm/overcommit_memory 文件来选择策略。我们有三种选择，我们可以往这个文件里面写入0、1、2来选择不同的策略，这三个值对应的宏是： #define overcommit_guess 0
#define overcommit_always 1
#define overcommit_never 2
通过宏名我们也可以大概猜出来是啥意思，下面我们一一解析一下，先从最简单的开始，overcommit_always，从名字就可以看出来，只要虚拟内存空间还有富余，你malloc多少内存就给你多少虚拟内存，不管它物理内存到底还够不够用。overcommit_guess，名为guess，实在不好guess的，通过看代码发现，这个模式允许你最多分配的虚拟内存不能超过系统总的物理内存(这里说的总物理内存是物理内存加swap的总和，因为swap在一定意义上也相当于是增加了物理内存)，也就是说一个进程分配的总虚拟内存可以和系统的总物理内存相同，还是够可以的。overcommit_never，这个就比较苛刻了，它像一位勤俭持家的妈妈，总是只给你勉强够用的零花钱，从来不多给一分。我们来看一下它的计算过程，它先计算一个基准值，默认等于50%的物理内存加上swap大小，然后再减去系统管理保留的内存，再减去用户管理保留的内存，如果系统所有已分配的虚拟内存大于这个值，就返回分配失败。具体情况大家可以去看代码： linux-src/mm/util.c:__vm_enough_memory。 我们再来看一个这个三个宏的公共部分overcommit，过度承诺，这个词想表达什么含义呢，过程承诺 always never guess，我们可以看出来，过程承诺指的是，系统允许分配给你的虚拟内存是对你的承诺，后面当你具体用访问内存的时候，是要给你分配物理内存来实现对你的承诺的，那么这个承诺到底能不能实现呢，如果不能实现会怎么样呢？ 5.2、物理内存oom
出来混迟早是要还的，分配出去的虚拟内存迟早是要兑现物理内存的。内核运行时会分配物理内存，程序运行时也会通过缺页异常去分配物理。如果此时没有足够的物理内存，内核会通过各种手段来收集物理内存，比如内存规整、回收缓存、swap等，如果这些手段都用尽了，还是没有收集到足够的物理内存，那么就只能使出最后一招了，oom killer，通过杀死进程来回收内存。代码实现在linux-src/mm/oom_kill.c:out_of_memory，触发点在linux-src/mm/page_alloc.c:__alloc_pages_may_oom，当使用各种方法都回收不到不到内存时会调用out_of_memory函数。
out_of_memory函数的实现还是有点复杂，我们把各种检测代码和辅助代码都去除之后，高度简化之后的函数如下： bool out_of_memory(struct oom_control *oc){ select_bad_process(oc); oom_kill_process(oc, out of memory);} 这样就看逻辑就很简单了， 1先选择一个要杀死的进程
2杀死它，就是这么简单。
oom_kill_process函数的目的很简单，但是实现过程也有点复杂，这里就不展开分析了，大家可以自行去看一下代码。我们重点分析一下select_bad_process函数的逻辑，select_bad_process主要是依靠oom_score来进行进程选择的。我们先来看一下和每一个进程相关联的三个文件。 /proc//oom_score系统计算出来的oom_score值，只读文件，取值范围0 –- 1000，0代表never kill，1000代表aways kill，值越大，进程被选中的概率越大。 /proc//oom_score_adj 让用户空间调节oom_score之值的接口，root可读写，取值范围 -1000 --- 1000，默认为0，若为 -1000，则oom_score加上此值一定小于等于0，从而变成never kill进程。os可以把一些关键的系统进程的oom_score_adj设为-1000，从而避免被oom kill。 /proc//oom_adj 旧的接口文件，为兼容而保留，root可读写，取值范围 -16 — 15，会被线性映射到oom_score_adj，特殊值 -17代表 oom_disable，大家尽量不用再用此接口。
下面我们来分析一下select_bad_process函数的实现：
static void select_bad_process(struct oom_control *oc){ oc->chosen_points = long_min; struct task_struct *p; rcu_read_lock(); for_each_process(p) if (oom_evaluate_task(p, oc)) break; rcu_read_unlock();}
函数首先把chosen_points初始化为最小的long值，这个值是用来比较所有的oom_score值，最后谁的值最大就选中哪个进程。然后函数已经遍历所有进程，计算其oom_score，并更新chosen_points和被选中的task，有点类似于选择排序。我们继续看oom_evaluate_task函数是如何评估每个进程的函数。 static int oom_evaluate_task(struct task_struct *task, void *arg){ struct oom_control *oc = arg; long points; if (oom_unkillable_task(task)) goto next; /* p may not have freeable memory in nodemask */ if (!is_memcg_oom(oc) && !oom_cpuset_eligible(task, oc)) goto next; if (oom_task_origin(task)) { points = long_max; goto select; } points = oom_badness(task, oc->totalpages); if (points == long_min || points chosen_points) goto next;select: if (oc->chosen) put_task_struct(oc->chosen); get_task_struct(task); oc->chosen = task; oc->chosen_points = points;next: return 0;abort: if (oc->chosen) put_task_struct(oc->chosen); oc->chosen = (void *)-1ul; return 1;}
此函数首先会跳轨所有不适合kill的进程，如init进程、内核线程、oom_disable进程等。然后通过select_bad_process算出此进程的得分points 也就是oom_score，并和上一次的胜出进程进行比较，如果小的会话就会goto next 返回，如果大的话就会更新oc->chosen 的task 和 chosen_points 也就是目前最高的oom_score。那么 oom_badness是如何计算的呢？ long oom_badness(struct task_struct *p, unsigned long totalpages){ long points; long adj; if (oom_unkillable_task(p)) return long_min; p = find_lock_task_mm(p); if (!p) return long_min; adj = (long)p->signal->oom_score_adj; if (adj == oom_score_adj_min || test_bit(mmf_oom_skip, &p->mm->flags) || in_vfork(p)) { task_unlock(p); return long_min; } points = get_mm_rss(p->mm) + get_mm_counter(p->mm, mm_swapents) + mm_pgtables_bytes(p->mm) / page_size; task_unlock(p); adj *= totalpages / 1000; points += adj; return points;}
oom_badness首先把unkiller的进程也就是init进程内核线程直接返回 long_min，这样他们就不会被选中而杀死了，这里看好像和前面的检测冗余了，但是实际上这个函数还被/proc//oom_score的show函数调用用来显示数值，所以还是有必要的，这里也说明了一点，oom_score的值是不保留的，每次都是即时计算。然后又把oom_score_adj为-1000的进程直接也返回long_min，这样用户空间专门设置的进程就不会被kill了。最后就是计算oom_score了，计算方法比较简单，就是此进程使用的rss驻留内存、页表、swap之和越大，也就是此进程所用的总内存越大，oom_score的值就越大，逻辑简单直接，谁用的物理内存最多就杀谁，这样就能够回收更多的物理内存，而且使用内存最多的进程很可能是内存泄漏了，所以此算法虽然很简单，但是也很合理。
可能很多会觉得这里讲的不对，和自己在网上的看到的逻辑不一样，那是因为网上有很多讲oom_score算法的文章都是基于2.6版本的内核讲的，那个算法比较复杂，会考虑进程的nice值，nice值小的，oom_score会相应的降低，也会考虑进程的运行时间，运行时间越长，oom_score值也会相应的降低，因为当时认为进程运行的时间长消耗内存多是合理的。但是这个算法会让那些缓慢内存泄漏的进程逃脱制裁。因此后来这个算法就改成现在这样的了，只考虑谁用的内存多就杀谁，简洁高效。 5.3、安卓lmk简介
除了oom killer，android上还开发了low memory killer机制，我们在此也简单介绍一下。lmk是在系统内存较低时就开始杀进程，而不是等到内存不足时再杀。lmk复用了oom killer 的 /proc//oom_score_adj 文件接口，但是没有使用/proc//oom_score。lmk仅根据oom_score_adj值的大小选择杀进程，而不会考虑进程本身占用内存的大小。apk进程的oom_score_adj的值由ams根据apk的生命周期和其他一些因素进行设置，会动态变。apk进程的oom_score_adj都大于等于0，native进程的oom_score_adj的值由rc文件设置或者继承自父进程，一般都是静态的，不会变化，其值一般都小于0。很多重要的系统进程的oom_score_adj值为 -1000，在oom killer的情况下也免杀。lmk默认只管理oom_score_adj大于等于0的进程，所以只能杀死apk进程。 lmk的优点是，1.它在系统内存开始紧张时就开始杀进程，而不是拖到最后一刻一点内存都没有了才去杀进程，2.安卓framework对apk的运行状态很了解，知道哪个进程重要不重要，哪个进程处于什么状态，能更针对性的选择杀哪些进程。lmk和oom killer 共同构成了系统内存不足的两道防线，lmk在前，内存有些不足时就杀进程，oom killer在后，作为最后一道屏障，作最后的努力去回收内存。 6.总结
linux内存管理是一门庞大的学问，内存回收作为其中的一部分也是十分复杂的，我们今天给大家大概介绍了内核的内存回收概览，并详细的介绍了oom killer机制，也算是抛砖引玉让大家对内存回收有个初步的认识。另外如果你在工作中遇到你的进程莫名其妙挂掉了，如果你能在内核log中找到oom killer的log的话（搜索 out of memory 关键字并过滤你的进程名），那么你就可以快速的断定你的是因为系统内存不足了，而且你的进程占用物理内存最多，所以被杀了，此时你就有很大的理由怀疑自己的进程内存泄漏了，就可以开始进行内存相关问题的排查了。
原文标题：linux oom 基本原理解析
文章出处：【微信公众号：linux阅码场】欢迎添加关注！文章转载请注明出处。
快速接头在气体密封性能测试的应用原理
2018年全年可穿戴设备出货量达1．722亿台 苹果占据整个市场26．8％的领先地位
荣耀V20的游戏体验如何
华为nova5i全面评测 产品优劣让市场来定夺
远程支持助力危险区域应用的数字化转型
Linux内存的分配管理与内存回收基本框架
RT-Thread finsh组件工作流程详解
高通扩展骁龙计算生态系统_富昌电子推介日亚LED产品组合
对目前嵌入式产业现状、趋势及机遇进行了深入的交流
NAND Flash价格综合季跌幅近20% 第二季或有扭转
智能传感器的作用，它对物联网为何如此重要
化工厂环境监测系统参数
Achronix半导体全面对接Speedcore eFPGA技术
五个有趣的实用光电管应用电路分享
磁环电感是什么呢？主要起什么作用？
区块链真的可以信任吗
5G的“扬帆起航”与商用的五个要素紧密相连
一台机实现呼吸和爆破双重测试，JCGK助力新能源电池检测升级
华为与三家韩国企业签署了谅解备忘录共同建设良好的5G生态系统
SOLIDWORKS 2023主要增强的内容
明白了上面这些，我们再来看看进程的用户空间内存布局。我们都知道进程的内存空间是由代码区、数据区、堆区、栈区组成。我们先来看下面的图，我们以32位进程为例进行讲解，64位的数值太大不好画的，但是原理都是一样的。
进程启动之后的内存布局如上图所示，程序file的代码段被映射到text区，数据段映射到data区，内核还会帮进程建立堆内存区映射和栈内存区映射，堆一般紧挨着data区的末尾往上增长，栈区在3g下面一点点往下增长。数据区和代码区是在进程启动时由内核之间分配好的，之后大小就不会再改变，heap区是随着程序运行中不断的malloc/free而增长或者缩小的，stack区是随时程序运行的局部变量分配释放而变化的，局部变量的分配释放是自动的，因此这三个区域也分别被叫做静态内存、动态内存、自动内存。由此我们可以看出，我们不必对静态内存、自动内存太操心，我们最应该关系的是动态内存。我们可以brk系统调用扩大heap区域来增加堆内存，然后再自己管理使用堆内存，但是这样做显然很麻烦。因此c库为我们准备了相关的api，malloc、free，来分配和释放堆内存，这样就方便到了。 c库里面最早的malloc实现叫做dlmalloc，在计算机早期还是单cpu时代的时候非常流行，效率也非常高，但是随着smp多cpu时代的到来，dlmalloc的缺点也越来越明显，尤其是多线程同时调用malloc的时候，锁冲突越来越严重，严重影响了性能。后来业界相继出现了ptmalloc、jemalloc、scudo等优秀的malloc库。 ptmalloc是glibc的默认malloc实现，jemalloc库是首先实现在freebsd的malloc库，后广泛应用于firefox、redis、netty等众多产品中，也长期是安卓的默认malloc库实现。目前安卓已经把malloc库替换为scudo了，据说scudo在安全和性能方面都很不错。 程序简单的时候还好说，但是对于很多产品级的软件来说，其逻辑结构都非常复杂，进而导致其内存管理方面也很复杂，很容易出现栈溢出、野指针、内存泄漏等问题。我们有着很多方法和规则来规避这些问题，比如谁申请谁释放，引用计数，智能指针等，但是仍然不能完全解决这些问题。尤其是内存泄漏，在很多公司里面都是令人头疼的顽疾，对于内存泄漏也存在着很多工具，但是都无法完美的解决这个问题。我们今天要说的不是内存泄漏，而是由于内存泄漏或者内存使用不合理而导致的oom问题。 4.内存回收基本框架 在讲oom之前，我们先来了解一下内核内存回收的总体框架。内存作为系统最宝贵的资源，总是不够用的，经常需要进行回收。内存回收可分为两种方式，同步回收和异步回收，同步回收是在分配内存时发现内存不足直接调用函数进行回收，异步回收是唤醒专门的回收线程kswapd进行回收。我们先看一下它们的总体架构图，然后再一一说明。
同步回收的话是在alloc_pages时发现内存不足就直接进行回收，首先尝试的是内存规整，也就是内存碎片整理，比如说系统当前有10个不连续的空闲page，但是你要分配两个连续的page，显然是无法分配的，此时就要进行内存规整，通过移动movable page，使空闲page尽量连在一起，这样能有可能分配出多个连续的page了。如果内存规整之后还是无法分配到内存，此时就会进行页帧回收了。用户空间的物理内存可以分为两种类型，文件页和匿名页，文件页是text data段对应的页帧，它们都有文件做后备存储，匿名是栈和堆对应的内存页，它们没有对应的文件，一般用swap分区或者swap文件做它们的后备存储。系统会首先考虑干净的文件页进行回收，因为回收它们只要直接丢弃内容就可以了，需要的时候再直接从文件里读取回来，这样不会有数据丢失。如果没有干净的文件页或者干净的文件页不太多，此时就要从dirty 文件页和匿名页进行回收了，因为它们都要进行io操作，所以会非常的慢。如果页帧回收也回收不到内存的话，内核只能使出最后一招了，oom killer，直接杀进程进行内存回收，虽然这招好像不太文雅，但是也是没有办法，因为不这样做的话，系统没有多余的内存就没法继续运行，系统就会卡死，用户就会重启系统，结果更糟，所以杀进程也是最后的无奈之举。一般能走到这一步都是因为进程有长期或者严重的内存泄漏导致的。 异步回收线程kswapd是被周期性的唤醒来执行回收任务的，当然同步回收的时候也会顺便唤醒它来一起回收内存。有一点需要注意的是kswapd线程不是per cpu的，而是per node的，是一个numa节点一个线程，这是因为内存的分配是per node不是 per cpu的，大部分内存分配都是优先从本node分配或者只能从本node分配，因此哪个node的内存不足了就唤醒哪个node的kswapd线程就行内存回收工作。对于家庭电脑和手机来说都是一个node，所以一般就只有一个kswapd线程。kswapd完成回收工作之后，它会唤醒kcompactd线程进行内存规整，对的，内存规整也可以异步执行。 5.oom基本原理
在讲内核的oom killer之前，我们先来说一下oom基本概念。oom，out of memory，就是内存用完了耗尽了的意思。oom分为虚拟内存oom和物理内存oom，两者是不一样的。虚拟内存oom发生在用户空间，因为用户空间分配的就是虚拟内存，不能分配物理内存，程序在运行的时候触发缺页异常从而需要分配物理内存，内核自身在运行的时候也需要分配物理内存，如果此时物理内存不足了，就会发生物理内存oom。用户空间虚拟内存oom表现为malloc、mmap等内存分配接口返回失败，错误码为enomem。大家也许会想，虚拟内存会oom吗，虚拟内存那么大，对于32位进程来说就有3g，对于64位进程来说至少也得有上百g，应有尽有，而且很多教科书上都说的是虚拟内存可以随意分配，不受物理内存的限制，事实上真的是这样吗，让我们来看一看。 5.1、虚拟内存oom
虚拟内存我们是不是可以随意分配，虚拟空间有多大我们就能分配多少？事实不是这样的。unix世界有个著名的哲学原理，提供机制而不是策略，对于这个问题，linux也提供了机制，我们可以通过 /proc/sys/vm/overcommit_memory 文件来选择策略。我们有三种选择，我们可以往这个文件里面写入0、1、2来选择不同的策略，这三个值对应的宏是： #define overcommit_guess 0
#define overcommit_always 1
#define overcommit_never 2
通过宏名我们也可以大概猜出来是啥意思，下面我们一一解析一下，先从最简单的开始，overcommit_always，从名字就可以看出来，只要虚拟内存空间还有富余，你malloc多少内存就给你多少虚拟内存，不管它物理内存到底还够不够用。overcommit_guess，名为guess，实在不好guess的，通过看代码发现，这个模式允许你最多分配的虚拟内存不能超过系统总的物理内存(这里说的总物理内存是物理内存加swap的总和，因为swap在一定意义上也相当于是增加了物理内存)，也就是说一个进程分配的总虚拟内存可以和系统的总物理内存相同，还是够可以的。overcommit_never，这个就比较苛刻了，它像一位勤俭持家的妈妈，总是只给你勉强够用的零花钱，从来不多给一分。我们来看一下它的计算过程，它先计算一个基准值，默认等于50%的物理内存加上swap大小，然后再减去系统管理保留的内存，再减去用户管理保留的内存，如果系统所有已分配的虚拟内存大于这个值，就返回分配失败。具体情况大家可以去看代码： linux-src/mm/util.c:__vm_enough_memory。 我们再来看一个这个三个宏的公共部分overcommit，过度承诺，这个词想表达什么含义呢，过程承诺 always never guess，我们可以看出来，过程承诺指的是，系统允许分配给你的虚拟内存是对你的承诺，后面当你具体用访问内存的时候，是要给你分配物理内存来实现对你的承诺的，那么这个承诺到底能不能实现呢，如果不能实现会怎么样呢？ 5.2、物理内存oom
出来混迟早是要还的，分配出去的虚拟内存迟早是要兑现物理内存的。内核运行时会分配物理内存，程序运行时也会通过缺页异常去分配物理。如果此时没有足够的物理内存，内核会通过各种手段来收集物理内存，比如内存规整、回收缓存、swap等，如果这些手段都用尽了，还是没有收集到足够的物理内存，那么就只能使出最后一招了，oom killer，通过杀死进程来回收内存。代码实现在linux-src/mm/oom_kill.c:out_of_memory，触发点在linux-src/mm/page_alloc.c:__alloc_pages_may_oom，当使用各种方法都回收不到不到内存时会调用out_of_memory函数。
out_of_memory函数的实现还是有点复杂，我们把各种检测代码和辅助代码都去除之后，高度简化之后的函数如下： bool out_of_memory(struct oom_control *oc){ select_bad_process(oc); oom_kill_process(oc, out of memory);} 这样就看逻辑就很简单了， 1先选择一个要杀死的进程
2杀死它，就是这么简单。
oom_kill_process函数的目的很简单，但是实现过程也有点复杂，这里就不展开分析了，大家可以自行去看一下代码。我们重点分析一下select_bad_process函数的逻辑，select_bad_process主要是依靠oom_score来进行进程选择的。我们先来看一下和每一个进程相关联的三个文件。 /proc//oom_score系统计算出来的oom_score值，只读文件，取值范围0 –- 1000，0代表never kill，1000代表aways kill，值越大，进程被选中的概率越大。 /proc//oom_score_adj 让用户空间调节oom_score之值的接口，root可读写，取值范围 -1000 --- 1000，默认为0，若为 -1000，则oom_score加上此值一定小于等于0，从而变成never kill进程。os可以把一些关键的系统进程的oom_score_adj设为-1000，从而避免被oom kill。 /proc//oom_adj 旧的接口文件，为兼容而保留，root可读写，取值范围 -16 — 15，会被线性映射到oom_score_adj，特殊值 -17代表 oom_disable，大家尽量不用再用此接口。
下面我们来分析一下select_bad_process函数的实现：
static void select_bad_process(struct oom_control *oc){ oc->chosen_points = long_min; struct task_struct *p; rcu_read_lock(); for_each_process(p) if (oom_evaluate_task(p, oc)) break; rcu_read_unlock();}
函数首先把chosen_points初始化为最小的long值，这个值是用来比较所有的oom_score值，最后谁的值最大就选中哪个进程。然后函数已经遍历所有进程，计算其oom_score，并更新chosen_points和被选中的task，有点类似于选择排序。我们继续看oom_evaluate_task函数是如何评估每个进程的函数。 static int oom_evaluate_task(struct task_struct *task, void *arg){ struct oom_control *oc = arg; long points; if (oom_unkillable_task(task)) goto next; /* p may not have freeable memory in nodemask */ if (!is_memcg_oom(oc) && !oom_cpuset_eligible(task, oc)) goto next; if (oom_task_origin(task)) { points = long_max; goto select; } points = oom_badness(task, oc->totalpages); if (points == long_min || points chosen_points) goto next;select: if (oc->chosen) put_task_struct(oc->chosen); get_task_struct(task); oc->chosen = task; oc->chosen_points = points;next: return 0;abort: if (oc->chosen) put_task_struct(oc->chosen); oc->chosen = (void *)-1ul; return 1;}
此函数首先会跳轨所有不适合kill的进程，如init进程、内核线程、oom_disable进程等。然后通过select_bad_process算出此进程的得分points 也就是oom_score，并和上一次的胜出进程进行比较，如果小的会话就会goto next 返回，如果大的话就会更新oc->chosen 的task 和 chosen_points 也就是目前最高的oom_score。那么 oom_badness是如何计算的呢？ long oom_badness(struct task_struct *p, unsigned long totalpages){ long points; long adj; if (oom_unkillable_task(p)) return long_min; p = find_lock_task_mm(p); if (!p) return long_min; adj = (long)p->signal->oom_score_adj; if (adj == oom_score_adj_min || test_bit(mmf_oom_skip, &p->mm->flags) || in_vfork(p)) { task_unlock(p); return long_min; } points = get_mm_rss(p->mm) + get_mm_counter(p->mm, mm_swapents) + mm_pgtables_bytes(p->mm) / page_size; task_unlock(p); adj *= totalpages / 1000; points += adj; return points;}
oom_badness首先把unkiller的进程也就是init进程内核线程直接返回 long_min，这样他们就不会被选中而杀死了，这里看好像和前面的检测冗余了，但是实际上这个函数还被/proc//oom_score的show函数调用用来显示数值，所以还是有必要的，这里也说明了一点，oom_score的值是不保留的，每次都是即时计算。然后又把oom_score_adj为-1000的进程直接也返回long_min，这样用户空间专门设置的进程就不会被kill了。最后就是计算oom_score了，计算方法比较简单，就是此进程使用的rss驻留内存、页表、swap之和越大，也就是此进程所用的总内存越大，oom_score的值就越大，逻辑简单直接，谁用的物理内存最多就杀谁，这样就能够回收更多的物理内存，而且使用内存最多的进程很可能是内存泄漏了，所以此算法虽然很简单，但是也很合理。
可能很多会觉得这里讲的不对，和自己在网上的看到的逻辑不一样，那是因为网上有很多讲oom_score算法的文章都是基于2.6版本的内核讲的，那个算法比较复杂，会考虑进程的nice值，nice值小的，oom_score会相应的降低，也会考虑进程的运行时间，运行时间越长，oom_score值也会相应的降低，因为当时认为进程运行的时间长消耗内存多是合理的。但是这个算法会让那些缓慢内存泄漏的进程逃脱制裁。因此后来这个算法就改成现在这样的了，只考虑谁用的内存多就杀谁，简洁高效。 5.3、安卓lmk简介
除了oom killer，android上还开发了low memory killer机制，我们在此也简单介绍一下。lmk是在系统内存较低时就开始杀进程，而不是等到内存不足时再杀。lmk复用了oom killer 的 /proc//oom_score_adj 文件接口，但是没有使用/proc//oom_score。lmk仅根据oom_score_adj值的大小选择杀进程，而不会考虑进程本身占用内存的大小。apk进程的oom_score_adj的值由ams根据apk的生命周期和其他一些因素进行设置，会动态变。apk进程的oom_score_adj都大于等于0，native进程的oom_score_adj的值由rc文件设置或者继承自父进程，一般都是静态的，不会变化，其值一般都小于0。很多重要的系统进程的oom_score_adj值为 -1000，在oom killer的情况下也免杀。lmk默认只管理oom_score_adj大于等于0的进程，所以只能杀死apk进程。 lmk的优点是，1.它在系统内存开始紧张时就开始杀进程，而不是拖到最后一刻一点内存都没有了才去杀进程，2.安卓framework对apk的运行状态很了解，知道哪个进程重要不重要，哪个进程处于什么状态，能更针对性的选择杀哪些进程。lmk和oom killer 共同构成了系统内存不足的两道防线，lmk在前，内存有些不足时就杀进程，oom killer在后，作为最后一道屏障，作最后的努力去回收内存。 6.总结
linux内存管理是一门庞大的学问，内存回收作为其中的一部分也是十分复杂的，我们今天给大家大概介绍了内核的内存回收概览，并详细的介绍了oom killer机制，也算是抛砖引玉让大家对内存回收有个初步的认识。另外如果你在工作中遇到你的进程莫名其妙挂掉了，如果你能在内核log中找到oom killer的log的话（搜索 out of memory 关键字并过滤你的进程名），那么你就可以快速的断定你的是因为系统内存不足了，而且你的进程占用物理内存最多，所以被杀了，此时你就有很大的理由怀疑自己的进程内存泄漏了，就可以开始进行内存相关问题的排查了。
原文标题：linux oom 基本原理解析
文章出处：【微信公众号：linux阅码场】欢迎添加关注！文章转载请注明出处。
快速接头在气体密封性能测试的应用原理
2018年全年可穿戴设备出货量达1．722亿台 苹果占据整个市场26．8％的领先地位
荣耀V20的游戏体验如何
华为nova5i全面评测 产品优劣让市场来定夺
远程支持助力危险区域应用的数字化转型
Linux内存的分配管理与内存回收基本框架
RT-Thread finsh组件工作流程详解
高通扩展骁龙计算生态系统_富昌电子推介日亚LED产品组合
对目前嵌入式产业现状、趋势及机遇进行了深入的交流
NAND Flash价格综合季跌幅近20% 第二季或有扭转
智能传感器的作用，它对物联网为何如此重要
化工厂环境监测系统参数
Achronix半导体全面对接Speedcore eFPGA技术
五个有趣的实用光电管应用电路分享
磁环电感是什么呢？主要起什么作用？
区块链真的可以信任吗
5G的“扬帆起航”与商用的五个要素紧密相连
一台机实现呼吸和爆破双重测试，JCGK助力新能源电池检测升级
华为与三家韩国企业签署了谅解备忘录共同建设良好的5G生态系统
SOLIDWORKS 2023主要增强的内容