glibc内存碎片问题【转】
来源:互联网 发布:超级淘宝系统王铁柱 编辑:程序博客网 时间:2024/06/16 10:41
在dfs修bug的过程中,经常会发现sn节点内存的异常增加。一开始以为是内存泄漏,可是找遍各种工具却 发现不了,终于开始怀疑glibc本身的内存管理,上网查看,果然存在glibc的内存碎片问题。以前一直疑惑不解的sn进程内存非正常增长问题,现在终于找到了答案。汗,看来自己对glibc的了解正是太肤浅了。以下是某高手对glibc的内存管理做的总结:
Linux用户进程是如何释放内存的,下图是Linux进程使用内存的基本流程:
见图1
从图中我们可以看出,进程的堆,并不是直接建立在Linux的内核的内存分配策略上的,而是建立在glibc的堆管理策略上的(也就是glibc的动态内存分配策略上),堆的管理是由glibc进行的。
所以我们调用free对malloc得到的内存进行释放的时候,并不是直接释放给操作系统,而是还给了glibc的堆管理实体,而glibc会在把实际的物理内存归还给系统的策略上做一些优化,以便优化用户任务的动态内存分配过程。
那么glibc的堆管理器在什么时候才把物理内存归还给系统呢?
它会从堆的最大线性地址开始,从后向前计算用户任务当前有多少空闲的堆内存(直到碰到使用中的堆内存地址为止),比如在该图中,
见图2
它会认为有2048k的可释放内存,只有在该值大于某个特定的threshhold时(2.3.6上为64k),它才会把这些内存归还给系统。而在中间的“未使用”内存是不会归还给系统的,所以系统也不可能再利用这块物理内存页(我们假设系统没有swap区和swap文件),也就是说系统的内存会为此减少,除非在它之前的堆内存都用free进行释放以后,glibc的堆管理器才有可能(只是有可能)把该段内存归还给系统。
由此,我们在使用malloc/free时应该小心,特别是在初始化时分配了好多内存,但是在这之后却再也不需要这么多的内存了,而这块内存又没有达到threshhold值或者在堆的最高线性地址处有某块内存没有释放,但是它前面的所有堆内存都释放了;这种情况下,用户任务将会浪费一些物理内存,这在资源比较紧张的嵌入式系统中是不可容忍的。
- glibc内存碎片问题【转】
- glibc内存碎片【转】
- 内存碎片问题
- glibc内存管理 (转)
- 内存泄露 碎片等问题
- 转:内存碎片处理技术
- 内存碎片处理技术(转)
- Linux下malloc/free内存碎片问题
- 内存碎片引发系统问题分析
- glibc 内存池管理 ptmalloc(转)
- [转]glibc 内存池管理 ptmalloc
- glibc 内存池管理 ptmalloc(转)
- 内存碎片
- 内存碎片
- 内存碎片
- 内存碎片
- 内存碎片
- 内存碎片
- 学生成绩管理系统--开发实录
- 2013-01-04
- 2010北邮上机真题——哈夫曼树
- 什么是SAP供应商主数据
- 利用package包管理安装emacs插件
- glibc内存碎片问题【转】
- 描述在视频播放时来电话的解决方案。
- 数据结构_桶排序
- linux系统端口使用查看,与验证端口是否冲突
- C语言 printf格式控制符 完全解析
- 爱在末日后
- LINUX-C成长之路(六):函数要义
- 一段代码的注释
- Andorid Bluetooth State