基础理论
1. 内存映射
可以参考： Linux内存映射 - 知乎 写的很详细，而且也有代码分析
2. 虚拟内存的空间分布
通过这张图你可以看到，用户空间内存，从低到高分别是五种不同的内存段。只读段，包括代码和常量等。数据段，包括全局变量等。堆，包括动态分配的内存，从低地址开始向上增长。文件映射段，包括动态库、共享内存等，从高地址开始向下增长。栈，包括局部变量和函数调用的上下文等。栈的大小是固定的，一般是 8 MB。
内存分配
malloc() 是 C 标准库提供的内存分配函数，对应到系统调用上，有两种实现方式，即 brk() 和 mmap()。
对小块内存（小于 128K），C 标准库使用 brk() 来分配，也就是通过移动堆顶的位置来分配内存。这些内存释放后并不会立刻归还系统，而是被缓存起来，这样就可以重复使用。
brk() 方式的缓存，可以减少缺页异常的发生，提高内存访问效率。不过，由于这些内存没有归还系统，在内存工作繁忙时，频繁的内存分配和释放会造成内存碎片。
而大块内存（大于 128K），则直接使用内存映射 mmap() 来分配，也就是在文件映射段找一块空闲内存分配出去。
mmap() 方式分配的内存，会在释放时直接归还系统，所以每次 mmap 都会发生缺页异常。在内存工作繁忙时，频繁的内存分配会导致大量的缺页异常，使内核的管理负担增大。这也是 malloc 只对大块内存使用 mmap 的原因。
如果遇到比页(4k)更小的对象，比如不到 1K 的时候，该怎么分配内存呢？
实际系统运行中，确实有大量比页还小的对象，如果为它们也分配单独的页，那就太浪费内存了。所以，在用户空间，malloc 通过 brk() 分配的内存，在释放时并不立即归还系统，而是缓存起来重复利用。在内核空间，Linux 则通过 slab 分配器来管理小内存。你可以把 slab 看成构建在伙伴系统上的一个缓存，主要作用就是分配并释放内核中的小对象。对内存来说，如果只分配而不释放，就会造成内存泄漏，甚至会耗尽系统内存。所以，在应用程序用完内存后，还需要调用 free() 或 unmap() ，来释放这些不用的内存。
内存回收以及相关命令
- 回收缓存，比如使用 LRU（Least Recently Used）算法，回收最近使用最少的内存页面；
- 回收不常访问的内存，把不常用的内存通过交换分区直接写到磁盘中；（swap）
- 杀死进程，内存紧张时系统还会通过 OOM（Out of Memory），直接杀掉占用大量内存的进程。（通过打分oom_score: 进程的 oom_score 越大，代表消耗的内存越多，也就越容易被 OOM 杀死，从而可以更好保护系统.）
如何查看内存使用情况
-
free: 显示总共内存使用情况以及swap
available 不仅包含未使用内存，还包括了可回收的缓存，所以一般会比未使用内存更大。不过，并不是所有缓存都可以回收，因为有些缓存可能正在使用中。
# 注意不同版本的free输出可能会有所不同 $ free total used free shared buff/cache available Mem: 8169348 263524 6875352 668 1030472 7611064 Swap: 0 0 0 第一列，total 是总内存大小； 第二列，used 是已使用内存的大小，包含了共享内存； 第三列，free 是未使用内存的大小； 第四列，shared 是共享内存的大小； 第五列，buff/cache 是缓存和缓冲区的大小； 最后一列，available 是新进程可用内存的大小。
2. top
VIRT 是进程虚拟内存的大小，只要是进程申请过的内存，即便还没有真正分配物理内存，也会计算在内。
RES 是常驻内存的大小，也就是进程实际使用的物理内存大小，但不包括 Swap 和共享内存。
SHR 是共享内存的大小，比如与其他进程共同使用的共享内存、加载的动态链接库以及程序的代码段等。
%MEM 是进程使用物理内存占系统总内存的百分比。
注意：第一，虚拟内存通常并不会全部分配物理内存。从上面的输出，你可以发现每个进程的虚拟内存都比常驻内存大得多。
第二，共享内存 SHR 并不一定是共享的，比方说，程序的代码段、非共享的动态链接库，也都算在 SHR 里。当然，SHR 也包括了进程间真正共享的内存。所以在计算多个进程的内存使用时，不要把所有进程的 SHR 直接相加得出结果。
内存泄漏的排除有效方法
memleak（bcc包中GitHub - iovisor/bcc: BCC - Tools for BPF-based Linux IO analysis, networking, monitoring, and more）跟踪系统、指定进程的内存分配，释放请求，然后定期输出一个未释放内存和相应调用栈的汇总情况（5s）
/usr/share/bcc/tools/memleak -p $(pidof app) -a
Attaching to pid 12512, Ctrl+C to quit.
[03:00:41] Top 10 stacks with outstanding allocations:addr = 7f8f70863220 size = 8192addr = 7f8f70861210 size = 8192addr = 7f8f7085b1e0 size = 8192addr = 7f8f7085f200 size = 8192addr = 7f8f7085d1f0 size = 819240960 bytes in 5 allocations from stackfibo+0x1f [app]child+0x4f [app]start_thread+0xdb [libpthread-2.27.so] 可以看出fibo() 这function在分配stack栈空间。
然后通过各种搜索工具找到fibo这个 function，逐行代码分析。
long long *fibo(long long *n0, long long *n1)
{//分配1024个长整数空间方便观测内存的变化情况long long *v = (long long *) calloc(1024, sizeof(long long));*v = *n0 + *n1;return v;
}void *child(void *arg)
{long long n0 = 0;long long n1 = 1;long long *v = NULL;for (int n = 2; n > 0; n++) {v = fibo(&n0, &n1);n0 = n1;n1 = *v;printf("%dth => %lld\n", n, *v);sleep(1);}
}可以知道调用一次fibo，就会用 calloc()分配一次内存，但是从没发现哪里free这个空间。
所以我们需要修复它：
void *child(void *arg)
{...for (int n = 2; n > 0; n++) {v = fibonacci(&n0, &n1);n0 = n1;n1 = *v;printf("%dth => %lld\n", n, *v);free(v); // 释放内存sleep(1);}
} 大功告成！
