glibc内存管理机制及内存碎片

1. glibc（即C库）内存管理框架

2. 内存碎片

2.1. 开启glibc tcache后的内存碎片

 C库在管理内存时，都是将其根据用户数据分配为相邻的块，在进行malloc时也是从满足用户数据大小的相邻块中抽出一块，然后返回给用户使用。在free时，它将会用当前free的块去寻找与其相邻的块，如果在已经free的序列中（fastbin、small bin、large bin或unsort bin中）能找到，则会将相邻的块进行合并，形成一个大块，否则它就是一个碎片（可能放入tcache、fastbin、small bin、large bin或unsort bin中）。

    在上图中，如果线程2、3和4已经退出运行，AA user data和BB user data都已经free了内存，而线程1依然在运行，则内存块1、2、3、4和5将会是C库中的内存碎片，由于线程1分配的内存是与堆顶相邻的，如果线程1永远不能退出，则这部分内存碎片永远不会还给操作系统（不论这块碎片有多大），但能够在C库中继续重复利用。这就是为啥我们一般检查内存泄露时明明没有内存泄漏，但进程所占用的物理内存一直降不下来的原因。

2.2. 关闭glibc tcache功能

此种情况与2.1中glibc开启tcache的情形类似，只是关闭了tcache功能后，堆的收缩不会受线程的影响。

2.3. 怎样查看glibc缓存的内存？？

C库提供内存统计接口函数mallinfo，可通过调用该函数查看C库缓存的内存情况。

2.4. 怎样手动回收C库缓存的内存？？

• 程序中显式调用malloc_trim(0)即可。
• 在未strip的程序中，通过gdb attach后，执行：call malloc_trim(0)可进行手动回收。

注：对于strip的程序，只能显式调用malloc_trim(0)才能完成手动回收。