c hash链表 释放空间的疑惑

hebingyue

hash.tar (20 KB, 下载次数: 83)

2011-04-27 17:12 上传

点击文件名下载附件

写的一个hash链表，申请了1000000个桶里面放500000条数据，然后查询，删除，最后释放链表 hash_close。
可是在本进程退出之前，明明已经释放了所有的申请空间，但是本进程还是占了40M内存（用free -m看到的），
但是用valgrind检测：
#valgrind --tool=memcheck --leak-check=full -v ./hash_test
结果是：
==8627== HEAP SUMMARY:
==8627==     in use at exit: 0 bytes in 0 blocks
==8627==   total heap usage: 1,500,005 allocs, 1,500,005 frees, 58,777,857 bytes allocated
==8627==
==8627== All heap blocks were freed -- no leaks are possible
==8627==
==8627== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 3 from 3)
--8627--
--8627-- used_suppression:      3 dl-hack3-cond-1
==8627==
==8627== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 3 from 3)
提示没有内存泄露。

这是怎么回事啊？
已经附上源码。

hebingyue

代码不到300行，里面有编译脚本，热心的cu们，测试下吧，在此谢过。。
跟踪代码到 elf_hash.c文件中：
259                 free_list_node( tmp );
释放hash节点，注释和不注释占用内存没有变化，感觉是释放没起作用。
我的做法是先定位到双向链表尾部，从后往前删除。
明明已经调用释放，为什么没起作用？

hebingyue

有可能是上百万次 malloc 和 free 造成内存碎片？但是内存碎片也应该是空闲的，而不是算到本进程下？

hebingyue

第一次发帖竟然这么冷清，是我问题没有描述明白呢，还是提问方式不对啊。

hebingyue

最近进行了一些测试：
得出以下结论
1、代码本身没有内存泄露，valgrind检测结果是对的。
2、造成进程占用内存虚高的原因是 malloc分配调用sbrk系统调用实现，该系统调用扩充（或缩小）本进程的堆。
虽然sbrk可以扩充或缩小进程堆空间，但大多数malloc和free的实现都不减少进程的存储空间（特殊情况下会减少，
见第三点）。释放的空间可供以后再分配，但通常将他们保持在malloc池中而不返给内核。(参考 unix环境高级
编程 7.8节，155页)
3、那要是在使用过程中频繁申请了大量内存，后续不再使用，但进程常驻内存，内存块是不是永远被本进程锁定呢？
由于前面的链表节点都是40~50个字节，因此造成大量小块内存没有返还内核并回收，估计频繁回收对内核也是个挑战。
我测试发现了一个方法，在释放后申请一个稍大的内存块（比如 100K），然后把其释放掉，
这样触发了内存回收机制（猜测的，没有确认），把前面申请到的大片小内存块给一起回收了。
内存又回来啦.....

新右卫门

只要申请一次就足够了

新右卫门

只要申请一次就足够了

hebingyue

其实这也说明了为什么申请的小块内存free后，指针还可以使用。因为申请的空间太小了，系统没必要立即回收到内核，暂时放在本进程空间，但这段内存随时可能被再次申请使用。
所以指针释放后，再次使用就像抱者yk炸弹，随时可能crash.