剛看了一個大牛的博客，介紹了一下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之。