Linux平台写Daemon程序时，频繁使用malloc会不会因为内存碎片导致内存枯竭？

isjfk

26 楼的用那两个例子作为内存碎片对系统影响的证据，未免缺乏说服力。毕竟没有人知道 Office 或者 IE 是如何工作的（除了他们的开发人员），至于他们为什么会崩溃，那就更是无从考证。

如果程序是多线程的，那就基本上根本无法保证 malloc 和 free 的顺序（就算有，恐怕其代价也远远超过其价值）。而且 free 会自动把回收的内存同两边的空闲区域合并，因此除非是非常大规模的进程，频繁 malloc、free 大量不同大小的内存，才有可能产生碎片问题。这种规模的应用应该考虑到单进程最大内存使用量的限制，改为多进程恐怕更为合适。对于一般的应用，内存碎片产生问题的可能性微乎其微，担心忘记回收内存的情况更为实际一些。

PS：26楼讲的 malloc 和 free 原理（以及代码）恐怕是从 TCPL 上看到的，是不是？

[ 本帖最后由 isjfk 于 2006-6-20 09:08 编辑 ]

isjfk

演变成口水战了，偶还是及早脱身的妙...

FH

原帖由 isjfk 于 2006-6-20 09:06 发表
26 楼的用那两个例子作为内存碎片对系统影响的证据，未免缺乏说服力。毕竟没有人知道 Office 或者 IE 是如何工作的（除了他们的开发人员），至于他们为什么会崩溃，那就更是无从考证。

如果程序是多线程的，那 ...

一般程序可以不讲究malloc/free的顺序，但是LZ提到的是daemon，那么这个问题就不能不考虑。
俺看的源码来自《Turbo C 2.0函数库源代码分析》。

[ 本帖最后由 FH 于 2006-6-20 09:11 编辑 ]

isjfk

原帖由 FH 于 2006-6-20 09:10 发表


一般程序可以不讲究malloc/free的顺序，但是LZ提到的是daemon，那么这个问题就不能不考虑。
俺看的源码来自《Turbo C 2.0函数库源代码分析》。

算我没说。你说的那些东西同 TCPL 最后一章的内容恐怕一模一样。看过这本书的人（很多吧？）应该都知道是怎么回事。而且 TCPL 作者也说了，真实的 malloc 和 free 工作情况比这个复杂，只不过基本原理是差不多的。

wind_lq

TC???Linux???

我没什么说的了

to lz：如果你的程序没有频繁或者大块分配内存的情况，那就不要去担心碎片问题。

思一克

malloc/free使用基本不考虑“谇片”问题。这正是malloc/free的设计目的。
也不用去遵循后进先出原则。

如果真要严格遵守次序，那么malloc/free两个函数就不需要了。因为你自己brk()一个个大区域，自己用一个指针后进先出地自己分配释放，比malloc/free要高效的多。

malloc/free的设计目的就是使使用者可以任意次序使用。

至于内存不够了。一个是程序设计有问题。2是有BUG。

kuaizaifeng

都是牛人阿

pinyin

讨论技术，何必吵架。
fh大法师的技术咱是相当佩服滴，不过说句公道话，此帖里面fh显得有点咄咄逼人了。

思一克

malloc/free使用基本不考虑“谇片”问题。这正是malloc/free的设计目的。
也不用去遵循后进先出原则。

如果真要严格遵守次序，那么malloc/free两个函数就不需要了。因为你自己brk()一个个大区域，自己用一个指针后进先出地自己分配释放，比malloc/free要高效的多。

malloc/free的设计目的就是使使用者可以任意次序使用。

至于内存不够了。一是程序设计有问题。二是程序有BUG。

isjfk

楼上的不用说两次吧？


碎片是肯定会有的，只不过一般不用考虑而已（我倒是确实看到过相关的材料，说的就是因为频繁 m/f 造成的碎片引起内存耗尽）。