刚看了一个大牛的博客，介绍了一下glibc的“内存泄漏”的定位过程，觉得对今后实际碰到的问题有一定的参考作用，故在此复述一下，供自己今后参考。

问题重现：使用glibc下的malloc分配内存10G，后调用free后，发现进程的内存还是占用10G，有时候占用8G，有时候占用3G，不太稳定，有内存泄漏的嫌疑

于是开始经过长时间苦逼的定位过程，发现了glibc一个有趣的特性，

glibc在128KB大小一下的内存采取brk操作，大于128KB后会采取mmap来分配内存。

brk分配的内存，在后面分配的内存不释放的情况下，前面分配的内存也是不会释放的，如连续地址分配A和B两块内存，如果B不释放，A也不会释放

具体可以去google一下brk和mmap的分配方式的区别

glibc的对128KB是有一个控制位，是动态修改的，M_MMAP_THRESHOLD，如作者在分配时，一次分配了2MB的内存，那么这个值就被修改为了2MB ~ 2MB + 4KB 中间一个值，因此后面的分配内存都采取了brk操作，导致最后看到的free后，内存却得不到释放的假想

这与glibc的内存方式有关。

 

后面还提到了对内存分析的一个程序集工具，也是由glibc提供的malloc hook, 大致意思是可以捕获malloc和free等操作，然后替换为自己定位的操作，如可以在内存打印一些语句，来分析内存分配情况，具体可以google之。