Linux下free/delete不释放内存

[alexapples]

在linux下写了个程序，需要频繁的分配和释放内存，而当真正调用free/delete是，通过top命令查看，程序所占用的内存并没有真正释放。
在windows上程序就不会这样。
具体是什么原因？

[dskit]

glibc free/delete 并不真正将物理内存规划给操作系统

换句话说，glibc会帮助管理内存，

只有在堆的顶部有大于128K的空间才归还内存给操作系统

[taodm]

还有人信top的显示啊。

[alexapples]

[Quote=引用 1 楼 dskit 的回复:]
glibc free/delete 并不真正将物理内存规划给操作系统

换句话说，glibc会帮助管理内存，

只有在堆的顶部有大于128K的空间才归还内存给操作系统
[/Quote]
因为我的程序是一个类似于守护进程的程序，需要一直运行。有时会出现内存被耗尽，但是用valgrind去检测，发现没有内存泄露的情况。弄得一头雾水。有什么好的方法可以解决吗？

[alexapples]

[Quote=引用 2 楼 taodm 的回复:]
还有人信top的显示啊。
[/Quote]
那有什么工具可以实时地检测程序内存的使用情况吗？

[yutaooo]

通常，比如在x86上跑的linux。堆是从低向高增长的。当glibc的内存分配器发觉内存不足时，会向内核请求扩张数据段。这个数据段是紧接着以前的边界扩展的。新扩展出来的内存纳入到glibc的分配器管理。

当调用free()的时候，用户使用的内存返回给glibc的内存分配器。

当内存分配通过与一个阀值比较，认为它自己管理的空闲内存过多的时，它会收缩。

但是，收缩是要求从 内核已分配给glibc分配器的内存的最大地址，向小地址方向收缩的。

假设，这个时候，有一个堆上对象被分配在了那个最大地址。那么，无法完成收缩，即便是空闲内存非常多，也不能交还给kernel以供其他进程使用。

反之，则可以正常的交还内存给kernel。

应该有一个函数malloc_trim()，可惜我在man malloc_trim时找不到。

对于楼主的问题，一个方案就是考虑mmap()来解决。

具体的可以参考Linux System programming. 第8章。

[dskit]

[Quote=引用 3 楼 alexapples 的回复:]
引用 1 楼 dskit 的回复:
glibc free/delete 并不真正将物理内存规划给操作系统

换句话说，glibc会帮助管理内存，

只有在堆的顶部有大于128K的空间才归还内存给操作系统

因为我的程序是一个类似于守护进程的程序，需要一直运行。有时会出现内存被耗尽，但是用valgrind去检测，发现没有内存泄露的情况。弄得一头雾水。有什么好的方法可以解决吗？
[/Quote]

你再仔细分析分析你的代码，重新审视你的内存分配回收策略吧

看看这篇文章，或许能对你有帮助
http://download.prjcode.com/detail/VcVgcVS

[fibbery]

这个与操作系统对内存的管理有关！只要内存不是疯长就行了，如果是一个Server程序，跑上几天几夜内存使用稳定就没有问题。

[fibbery]

[Quote=引用 3 楼 alexapples 的回复:]
因为我的程序是一个类似于守护进程的程序，需要一直运行。有时会出现内存被耗尽，但是用valgrind去检测，发现没有内存泄露的情况。弄得一头雾水。有什么好的方法可以解决吗？
[/Quote]

那我觉得你的程序在内存管理（不是系统内存管理）上就存在问题，如果要根本解决，我认为你该考虑修改你的程序。

[Caballeroo]

5楼讲的不错！

[Blue_may]

top看到的内存有的时候是假的。需要长时间看看。尤其用stl的时候经常会有这种情况。

[manytao]

[Quote=引用 2 楼 taodm 的回复:]
还有人信top的显示啊。
[/Quote]

lz别信了。。。这是正解。