Linux进程虚拟地址空间的分布，以及堆和栈的区别

一、具体分布如图所示：

二、关于堆和栈

（1）分配方式：

栈：由编译器自动分配释放，存放函数的参数值，局部变量的值等。其 *** 作方式类似于数据结构中的栈。

堆： 一般由程序员分配释放，它的分配方式类似于链表。

（2）申请后系统的响应：

栈：只要所申请的空间小于栈的剩余空间，则系统为程序分配内存，否则栈溢出。

堆： *** 作系统有一个记录空闲内存地址的链表，当系统收到程序的申请时，遍历该链表，找出第一个大于所申请空间的节点，然后将其从链表中删除并分配，如果没用完，则系统会把多余的重新放回到链表中。

（3）申请大小的限制：

栈：栈是高地址向低地址扩展的连续内存，栈的大小一般是2M；

堆：堆是低地址向高地址扩展的不连续内存，堆的大小与计算机有效的虚拟内存有关系。

（4）申请效率：

栈：由系统自动分配，速度较快；

堆：速度慢，容易产生内存碎片；

关于Linux命令的介绍，看看《linux就该这么学》，具体关于这一章地址3w(dot)linuxprobe/chapter-02(dot)html.

3种地址：虚拟地址、物理地址、逻辑地址

物理地址：内存的电路地址，对应内存地址线上的高低电平，物理可见的。

虚拟地址： 分页机制 的产物，也叫线性地址，是进程能看见的地址。

逻辑地址： 分段机制 的产物，属于inter cpu的历史遗留问题，linux可以当做不存在。

3种地址的转换：进程访问逻辑地址，linux内核根据分段机制装换成虚拟地址，然后把进程的页表和虚拟地址都告诉cpu，cpu就可以根据分页机制将虚拟地址装换成物理地址，然后访问内存。

linux内核中巧妙地屏蔽里分段机制，就是逻辑地址等于虚拟地址，访问内存只需要利用分页机制把虚拟地址转换成物理地址。

linux会为每个进程创建自己的虚拟地址空间，就是进程地址空间，64位系统就是128T的内存空间。需要注意的是，虚拟地址就是假的，一开始不和物理地址对应，也就是说不占用物理内存，只有当虚拟地址有写入 *** 作是，内核会触发缺页，分配真实的物理地址给虚拟地址。物理地址的管理可参考 内核内存管理

从进程空间看，用户态闲置内存有3块，Stack、Memory Mapping Region、Heap，Stack是程序函数调用运行时需要的，不可控，能自由分配的内存就剩Memory Mapping Region、Heap了，linux系统提供的内存分配函数就是针对这两个区域的。

Heap *** 作函数：int brk(void *addr)、void *sbrk(intptr_t increment)

Memory Mapping Region *** 作函数：mmap()、munmap()

当然进程可以直接使用系统调用去申请内存，但是如果不管理的话，经过大量的申请和释放，会把进程空间切割的乱七八糟，导致不能申请大块的连续空间，为此就出现了内存管理模块，封装了系统调用，对进程提供malloc和free等高级函数。实际上，除了一些特殊程序，我们也很少用系统调用，一般都是使用内存管理模块提供的malloc和free，关系如下图：

内存管理模块用各种好处，例如不会每次 *** 作都去执行系统调用，减少内存碎片的产生等等。

当然也有很多实现方式，例如常用的glibc的Ptmalloc，google的tcmalloc，facebook的jemalloc等。各有各的应用场景，blablabla....

使用时，gcc默认会链接glibc的，如果想使用其他lib，gcc链接时指定就能覆盖掉glibc的。

我们重点讲Ptmalloc，从而启发程序员在写程序时多考虑下内存分配情况，可以选择或自己实现适合自己程序的内存管理lib。

Ptmalloc的历史发展，blablabla......，Ptmalloc采取内存池管理，进程malloc时，通过brk（小于128K的内存）、mmap（大内存）从系统获取地址空间，给进程使用，进程free时，不会立即通过brk、munmap将地址空间还给系统，会自己维护起来，叫做空闲内存，这些空闲内存在进程再次malloc时，还会被分出去，并且空闲内存会在特定条件下合并起来还给系统。

内存分配区，管理了一片内存，对外分发和回收，可以理解为一个内存池，分main arena和non main arena。

main arena：最早的分配区，管理着所有可分配的内存，通过brk，mmap等系统调用向系统申请内存。注意只有main arena可以 *** 作Heap。

non main arena：由于多线程的出现，如果多有线程都 *** 作main arena就会有竞争，需要加锁控制，所以出现了non main arena，通过mmap向main arena申请一大块内存，然后自己管理，可以理解为内存分销商。

只有主线程在main arena上申请内存，子线程在non main arena上，non main arena的个数是有上限的，所以non main arena允许多个子线程共用，这样就涉及到加锁，所以程序涉及应避免子线程个数太多。

进程申请到的一块内存叫做一个内存片，arena内部使用chunk数据结构来描述内存片，包括进程正在使用的内存片，和进程free掉的空闲内存片

A：是否main arena内存

M：使用mmap内存

P：上一块是否被使用

size of previous chunk：上一块没有被使用时，表示上块长度，被使用时是上块用来存User data的。

Size of chunk：就是下一块的size of previous chunk，释放时填上本块长度，供下块合并用。

分给进程的内存片arena可以不管，但是进程free回来的，arena需要通过一定方式组织起来，方便进程再次使用。组织方式有下面几种：

bins是个数组，包含128个bin，每个bin是个链表，分small bin和large bin两种，各64个，small bin中chunk大小固定，两个相邻的small bin中的chunk大小相差8bytes，large bin中chunk大小是一定范围内的，其中的chunk按大小排列。

空闲chunk按大小选择合适的bin，按新旧顺序挂到链表上，优先分配旧的chunk。

不大于max_fast （默认值为64B）的chunk被释放后，首先会被放到fast bins 中，fast bins中的chunk并不改变它的使用标志P。这样也就无法将它们合并，当需要给用户分配的chunk小于或等于max_fast时，ptmalloc首先会在fast bins中查找相应的空闲块。在特定的时候，ptmalloc会遍历fast bins中的chunk，将相邻的空闲chunk进行合并，并将合并后的chunk加入unsorted bin中。

进行malloc时，如果在fast bins中没有找到合适的chunk，则ptmalloc会先在unsorted bin中查找合适的空闲chunk，如果unsorted bin不能满足分配要求。malloc便会将unsorted bin中的chunk加入bins中。然后再从bins中继续进行查找和分配过程。从这个过程可以看出来，unsorted bin可以看做是bins的一个缓冲区，增加它只是为了加快分配的速度。

前面的bin中都是回收回来的内存，top chunk才是内存的初始来源，每个arena都有一个top chunk，用来管理Heap的，Heap会在arena第一次分配内存时初始化，会分配一块(chunk_size + 128K) align 4K的空间（132K）作为初始的Heap，top chunk占据整个空间，每次分配会在低地址出切出一片，如下图：

回收时，只有和top chunk相连的内存才能和top chunk合并，才能进而还给系统。

子线程Heap：在main arena中mmap出64M的空间，叫做sub-heap，再在sub-heap上初始化Heap。

主线程的Heap才是真Heap，使用进程Heap，使用brk申请内存。

子线程的heap不够用时，会在申请新的sub-heap，和老的sub-heap单向链表连起来，top chunk会搬到新sub-heap上。

描述mmap出来的内存，单独管理，free时按阈值来决定是否munmap，有动态调整阈值功能，防止太频繁的mmap和munmap。本文不关注。

即最后一次small request中因分割而得到的剩余部分，它有利于改进引用局部性，也即后续对 small chunk 的 malloc 请求可能最终被分配得彼此靠近。

当用户请求 small chunk而无法从small bin和unsorted bin得到时，会在large bin中找最合适的chunk，然后做切割，返回给用户的User chunk，剩下的是Remainder chunk添加到unsorted bin中。这一Remainder chunk就将成为last remainder chunk。

下一块为高地址，前一块为低地址。

Glibc内存管理 华庭（庄明强）

看这篇文章之前需要知道一个概念

虚拟内存系统通过将虚拟内存分割为称作虚拟页(Virtual Page，VP)大小固定的块，一般情况下，每个虚拟页的大小默认是4096字节。同样的，物理内存也被分割为物理页(Physical Page，PP)，也为4096字节。

在LINUX中我们可以使用mmap用来在进程虚拟内存地址空间中分配地址空间，创建和物理内存的映射关系。

映射关系可以分为两种

1、文件映射

磁盘文件映射进程的虚拟地址空间，使用文件内容初始化物理内存。

2、匿名映射

初始化全为0的内存空间。

而对于映射关系是否共享又分为

1、私有映射(MAP_PRIVATE)

多进程间数据共享，修改不反应到磁盘实际文件，是一个copy-on-write（写时复制）的映射方式。

2、共享映射(MAP_SHARED)

多进程间数据共享，修改反应到磁盘实际文件中。

因此总结起来有4种组合

1、私有文件映射

多个进程使用同样的物理内存页进行初始化，但是各个进程对内存文件的修改不会共享，也不会反应到物理文件中

2、私有匿名映射

mmap会创建一个新的映射，各个进程不共享，这种使用主要用于分配内存(malloc分配大内存会调用mmap)。

例如开辟新进程时，会为每个进程分配虚拟的地址空间，这些虚拟地址映射的物理内存空间各个进程间读的时候共享，写的时候会copy-on-write。

3、共享文件映射

多个进程通过虚拟内存技术共享同样的物理内存空间，对内存文件 的修改会反应到实际物理文件中，他也是进程间通信(IPC)的一种机制。

4、共享匿名映射

这种机制在进行fork的时候不会采用写时复制，父子进程完全共享同样的物理内存页，这也就实现了父子进程通信(IPC).

这里值得注意的是，mmap只是在虚拟内存分配了地址空间，只有在第一次访问虚拟内存的时候才分配物理内存。

在mmap之后，并没有在将文件内容加载到物理页上，只上在虚拟内存中分配了地址空间。当进程在访问这段地址时，通过查找页表，发现虚拟内存对应的页没有在物理内存中缓存，则产生"缺页"，由内核的缺页异常处理程序处理，将文件对应内容，以页为单位(4096)加载到物理内存，注意是只加载缺页，但也会受 *** 作系统一些调度策略影响，加载的比所需的多。

1.write

因为物理内存是有限的，mmap在写入数据超过物理内存时， *** 作系统会进行页置换，根据淘汰算法，将需要淘汰的页置换成所需的新页，所以mmap对应的内存是可以被淘汰的（若内存页是"脏"的，则 *** 作系统会先将数据回写磁盘再淘汰）。这样，就算mmap的数据远大于物理内存， *** 作系统也能很好地处理，不会产生功能上的问题。

2.read

从图中可以看出，mmap要比普通的read系统调用少了一次copy的过程。因为read调用，进程是无法直接访问kernel space的，所以在read系统调用返回前，内核需要将数据从内核复制到进程指定的buffer。但mmap之后，进程可以直接访问mmap的数据(page cache)。

测试结果来源于： 深入剖析mmap-从三个关键问题说起

1.读性能分析

场景：对2G的文件进行顺序写入

可以看到mmap在100byte写入时已经基本达到最大写入性能，而write调用需要在4096(也就是一个page size)时，才能达到最大写入性能。

从测试结果可以看出，在写小数据时，mmap会比write调用快，但在写大数据时，反而没那么快。

2.写性能分析

场景：对2G的文件进行顺序读取（为了避免磁盘对测试的影响，2G文件都缓存在pagecache中）

由上可以看出，在read上面，mmap的性能还是非常好的。

优点如下：

1、对文件的读取 *** 作跨过了页缓存，减少了数据的拷贝次数，用内存读写取代I/O读写，提高了文件读取效率。

2、实现了用户空间和内核空间的高效交互方式。两空间的各自修改 *** 作可以直接反映在映射的区域内，从而被对方空间及时捕捉。

3、提供进程间共享内存及相互通信的方式。不管是父子进程还是无亲缘关系的进程，都可以将自身用户空间映射到同一个文件或匿名映射到同一片区域。从而通过各自对映射区域的改动，达到进程间通信和进程间共享的目的。同时，如果进程A和进程B都映射了区域C，当A第一次读取C时通过缺页从磁盘复制文件页到内存中；但当B再读C的相同页面时，虽然也会产生缺页异常，但是不再需要从磁盘中复制文件过来，而可直接使用已经保存在内存中的文件数据。

4、可用于实现高效的大规模数据传输。内存空间不足，是制约大数据 *** 作的一个方面，解决方案往往是借助硬盘空间协助 *** 作，补充内存的不足。但是进一步会造成大量的文件I/O *** 作，极大影响效率。这个问题可以通过mmap映射很好的解决。换句话说，但凡是需要用磁盘空间代替内存的时候，mmap都可以发挥其功效。

缺点如下:

1.文件如果很小，是小于4096字节的，比如10字节，由于内存的最小粒度是页，而进程虚拟地址空间和内存的映射也是以页为单位。虽然被映射的文件只有10字节，但是对应到进程虚拟地址区域的大小需要满足整页大小，因此mmap函数执行后，实际映射到虚拟内存区域的是4096个字节，11~4096的字节部分用零填充。因此如果连续mmap小文件，会浪费内存空间。

3.如果更新文件的 *** 作很多，会触发大量的脏页回写及由此引发的随机IO上。所以在随机写很多的情况下，mmap方式在效率上不一定会比带缓冲区的一般写快。

---