前言
之前在实习时，听了 OOM 的分享之后，就对 Linux 内核内存管理充满兴趣，但是这块知识非常庞大，没有一定积累，不敢写下，担心误人子弟，所以经过一个一段时间的积累，对内核内存有一定了解之后，今天才写下这篇博客，记录以及分享。
【OOM – Out of Memory】内存溢出
内存溢出的解决办法：
1、等比例缩小图片
2、对图片采用软引用，及时进行 recycle( ) 操作。
3、使用加载图片框架处理图片，如专业处理图片的 ImageLoader 图片加载框架，还有XUtils 的 BitMapUtils 来处理。
这篇文章主要是分析了单个进程空间的内存布局与分配，是从全局的视角分析下内核对内存的管理;
下面主要从以下方面介绍 Linux 内存管理:
- 进程的内存申请与分配；
- 内存耗尽之后 OOM；
- 申请的内存都在哪？
- 系统回收内存；
1、进程的内存申请与分配
之前有篇文章介绍 hello world 程序是如何载入内存以及是如何申请内存的，我在这，再次说明下：同样，还是先给出进程的地址空间，我觉得对于任何开发人员这张图是必须记住的，还有一张就是操作 disk ，memory 以及 cpu cache 的时间图。
当进程在用户态通过调用 free 释放内存时，如果这块内存是通过 mmap 分配，则调用 munmap 直接返回给系统。
否则内存是先返回给内存分配器，然后由内存分配器统一返还给系统，这就是为什么当我们调用 free 回收内存之后，再次访问这块内存时，可能不会报错的原因。
当然，当整个进程退出之后，这个进程占用的内存都会归还给系统。
2、内存耗尽之后OOM
在实习期间，有一台测试机上的 mysql 实例经常被 oom 杀死，OOM（out of memory）即为系统在内存耗尽时的自我拯救措施，他会选择一个进程，将其杀死，释放出内存，很明显，哪个进程占用的内存最多，即最可能被杀死，但事实是这样的吗？
昨天早上去上班，刚好碰到了一起 OOM，突然发现，OOM 一次，世界都安静下来了，哈哈，测试机上的 redis 被杀死了。
3、系统申请的内存都在哪？
我们了解了一个进程的地址空间之后，是否会好奇，申请到的物理内存都存在哪了？可能很多人觉得，不就是物理内存吗？
我这里说申请的内存在哪，是因为物理内存有分为cache和普通物理内存，可以通过 free 命令查看，而且物理内存还有分 DMA，NORMAL，HIGH 三个区，这里主要分析cache和普通内存。
通过第一部分，我们知道一个进程的地址空间几乎都是 mmap 函数申请，有文件映射和匿名映射两种。
3.1 共享文件映射
我们先来看下代码段和动态链接库映射段，这两个都是属于共享文件映射，也就是说由同一个可执行文件启动的两个进程是共享这两个段，都是映射到同一块物理内存，那么这块内存在哪了？我写了个程序测试如下：
dd if=/dev/zero of=fileblock bs=M count=1024
然后调用上述程序，进行共享文件映射,此时内存使用情况为：
3.2 私有文件映射段
对于进程空间中的数据段，其必须是私有文件映射，因为如果是共享文件映射，那么同一个可执行文件启动的两个进程，任何一个进程修改数据段，都将影响另一个进程了，我将上述测试程序改写成匿名文件映射：
echo 1 >> /proc/sys/vm/drop_caches
接着执行程序，看下内存使用情况:
3.3 私有匿名映射
像 bbs 段，堆，栈这些都是匿名映射，因为可执行文件中没有相应的段，而且必须是私有映射，否则如果当前进程 fork 出一个子进程，那么父子进程将会共享这些段，一个修改都会影响到彼此，这是不合理的。
ok，现在我把上述测试程序改成私有匿名映射
3.4 共享匿名映射
当我们需要在父子进程共享内存时，就可以用到 mmap 共享匿名映射，那么共享匿名映射的内存是存放在哪了？我继续改写上述测试程序为共享匿名映射 。
4、系统回收内存
当系统内存不足时，有两种方式进行内存释放，一种是手动的方式，另一种是系统自己触发的内存回收，先来看下手动触发方式。
4.1 手动回收内存
手动回收内存，之前也有演示过，即
echo 1 >> /proc/sys/vm/drop_caches
我们可以在 man proc 下面看到关于这个的简介
4.2 tmpfs
我们先来看下 tmpfs ，tmpfs 和 procfs，sysfs 以及 ramfs 一样，都是基于内存的文件系统，tmpfs 和 ramfs 的区别就是 ramfs 的文件基于纯内存的，和 tmpfs 除了纯内存外，还会使用 swap 交换空间，以及 ramfs 可能会把内存耗尽，而 tmpfs 可以限定使用内存大小，可以用命令 df -T -h 查看系统一些文件系统，其中就有一些是 tmpfs，比较出名的是目录 /dev/shm
tmpfs 文件系统源文件在内核源码 mm/shmem.c，tmpfs实现很复杂，之前有介绍虚拟文件系统，基于 tmpfs 文件系统创建文件和其他基于磁盘的文件系统一样，也会有 inode，super_block，identry，file 等结构，区别主要是在读写上，因为读写才涉及到文件的载体是内存还是磁盘。
而 tmpfs 文件的读函数 shmem_file_read，过程主要为通过 inode 结构找到 address_space 地址空间，其实就是磁盘文件的 pagecache，然后通过读偏移定位cache 页以及页内偏移。
这时就可以直接从这个 pagecache 通过函数 __copy_to_user 将缓存页内数据拷贝到用户空间，当我们要读物的数据不pagecache中时，这时要判断是否在 swap 中，如果在则先将内存页 swap in，再读取。
tmpfs 文件的写函数 shmem_file_write，过程主要为先判断要写的页是否在内存中，如果在，则直接将用户态数据通过函数__copy_from_user拷贝至内核pagecache中覆盖老数据，并标为 dirty。
如果要写的数据不再内存中，则判断是否在swap 中，如果在，则先读取出来，用新数据覆盖老数据并标为脏，如果即不在内存也不在磁盘，则新生成一个 pagecache 存储用户数据。
由上面分析，我们知道基于 tmpfs 的文件也是使用 cache 的，我们可以在/dev/shm上创建一个文件来检测下:
4.3 共享内存
posix 共享内存其实和 mmap 共享映射是同一个道理，都是利用在 tmpfs 文件系统上新建一个文件，然后再映射到用户态，最后两个进程操作同一个物理内存，那么 System V 共享内存是否也是利用 tmpfs 文件系统了？
我们可以跟踪到下述函数
shmem_kernel_file_setup
就是在 tmpfs 文件系统上创建一个文件，然后通过这个内存文件实现进程通信，这我就不写测试程序了，而且这也是不能回收的，因为共享内存ipc机制生命周期是随内核的，也就是说你创建共享内存之后，如果不显示删除的话，进程退出之后，共享内存还是存在的。
之前看了一些技术博客，说到 Poxic 和 System V 两套 ipc 机制(消息队列，信号量以及共享内存)都是使用 tmpfs 文件系统，也就是说最终内存使用的都是 pagecache，但是我在源码中看出了两个共享内存是基于 tmpfs 文件系统，其他信号量和消息队列还没看出来(有待后续考究)。
posix 消息队列的实现有点类似与 pipe 的实现，也是自己一套 mqueue 文件系统，然后在 inode 上的 i_private 上挂上关于消息队列属性 mqueue_inode_info，在这个属性上，内核2.6时，是用一个数组存储消息，而到了4.6则用红黑树了存储消息(我下载了这两个版本，具体什么时候开始用红黑树，没深究)。
然后两个进程每次操作都是操作这个 mqueue_inode_info 中的消息数组或者红黑树，实现进程通信，和这个 mqueue_inode_info 类似的还有 tmpfs 文件系统属性shmem_inode_info 和为epoll服务的文件系统 eventloop,也有一个特殊属性struct eventpoll，这个是挂在 file 结构的 private_data 等等。
说到这，可以小结下，进程空间中代码段，数据段，动态链接库(共享文件映射)，mmap 共享匿名映射都存在于 cache 中，但是这些内存页都有被进程引用，所以是不能释放的，基于 tmpfs 的 ipc 进程间通信机制的生命周期是随内核，因此也是不能通过 drop_caches 释放。
虽然上述提及的cache不能释放，但是后面有提到，当内存不足时，这些内存是可以 swap out 的。
因此 drop_caches 能释放的就是当从磁盘读取文件时的缓存页以及某个进程将某个文件映射到内存之后，进程退出，这时映射文件的的缓存页如果没有被引用，也是可以被释放的。
4.4 内存自动释放方式
当系统内存不够时，操作系统有一套自我整理内存，并尽可能的释放内存机制，如果这套机制不能释放足够多的内存，那么只能 OOM 了。
之前在提及 OOM 时，说道 redis 因为 OOM 被杀死，如下:
total-vm:186660kB, anon-rss:9388kB, file-rss:4kB
把一个进程内存使用情况，用三个属性进行了说明，即所有虚拟内存，常驻内存匿名映射页以及常驻内存文件映射页。
其实从上述的分析，我们也可以知道一个进程其实就是文件映射和匿名映射：
- 文件映射:代码段，数据段，动态链接库共享存储段以及用户程序的文件映射段；
- 匿名映射：bbs段，堆，以及当 malloc 用 mmap 分配的内存，还有mmap共享内存段；
其实内核回收内存就是根据文件映射和匿名映射来进行的，在 mmzone.h 有如下定义:
文件页：
- 如果是脏页，则直接回写进磁盘，再回收内存。
- 如果不是脏页，则直接释放回收，因为如果是io读缓存，直接释放掉，下次读时，缺页异常，直接到磁盘读回来即可，如果是文件映射页，直接释放掉，下次访问时，也是产生两个缺页异常，一次将文件内容读取进磁盘，另一次与进程虚拟内存关联。
匿名页：因为匿名页没有回写的地方，如果释放掉，那么就找不到数据了，所以匿名页的回收是采取 swap out 到磁盘，并在页表项做个标记，下次缺页异常在从磁盘 swap in 进内存。
swap 换进换出其实是很占用系统IO的，如果系统内存需求突然间迅速增长，那么cpu 将被io占用，系统会卡死，导致不能对外提供服务，因此系统提供一个参数，用于设置当进行内存回收时，执行回收 cache 和 swap 匿名页的，这个参数为:
5、总结
这篇文章主要是写了 linux 内存管理相关的东西：
首先是回顾了进程地址空间；
其次当进程消耗大量内存而导致内存不足时，我们可以有两种方式：第一是手动回收 cache；另一种是系统后台线程 swapd 执行内存回收工作。
最后当申请的内存大于系统剩余的内存时，这时就只会产生 OOM，杀死进程，释放内存，从这个过程，可以看出系统为了腾出足够的内存，是多么的努力啊。