基本操作
垃圾回收的算法细节还在不断完善中,性能还会有进一步的提升。下文介绍的内容在不同的.NET版本里会略有不同,但大方向是不会有变动的。
在.net进程里会管理2个类型的内存堆:托管和非托管。本地代码申请的,以及由CLR申请的都是非托管内存,使用Windows API 的 VirtualAlloc 方法进行申请。CLR里分配的托管对象则分配在托管堆里,这些对象可以被垃圾回收处理。
在托管堆里有还进一步分为小对象对和大对象堆(LOH)。每个对象类型都有自己的一段堆内存段。每段的大小根据你的配置或者硬件配置有关,对于一个大型的应用,一个内存段可到几百M。
小对象还可以进一步分为3个世代。0代和1代总是在一个内存段里,2代则可以跨越多个内存段。包含0代和1代的内存段称为暂存段。
下图是堆的图形,分别是A段和B段
A段是小对象堆,B段是大对象堆。2代和1代开始只有几个字节大小,因为他们到目前为止是空的。
在小对象堆里分配对象存在一个3世代的生命周期,CLR在小对象堆里分配小于85000字节的对象(8.5k)。0代内存通常在段内存的结尾开始分配。这就是为什么前面看到的.NET内存分配得很快。如果快速分配失败,则在0代边界范围里找一个合适的分配地址。如果也没有合适的位置,则分配器会扩大0代的在内存段里边界范围。如果扩展范围时超过了内存段的范围,则会触发垃圾回收。
对象创建后都是0代。只要对象还存在,在GC时会将它们标记到下一代。0代和1代称为临时集合。
当触发GC时,可能会同时触发压缩,在这种情况下,GC会将对象移动到另外一个内存地址里,释放当前段的内存空间。如果没有触发压缩,也仅仅只是重新划分边界。在一些没有触发过压缩的GC后,结果如下图:
虽然对象没有移动,但边界有重新划分。
压缩可以发生在任何一代的GC里,这是一个相当耗时的过程,因为它需要重新更新对象的引用关系,这需要暂停所有的线程操作。正因为代价高,压缩操作只会在必要的时候才会进行。
一旦对象到达2代,在剩下的生命周期里会一直保持。这并不意味着2代对象会一直存在,如果所有的2代对象被回收,并且整段内存里都没有对象,则这段内存可以被操作系统回收,或者作为其他内存段的附属段。这通常出现在全回收阶段。
那么对象的活着是什么概念呢?在GC时可以通过任何已知的root节点到达对象,能找到对象的引用关系,就说明这个对象还活着。root节点可以是程序里的某个静态变量,线程里正在执行的方法(指局部对象),GC句柄(被pinned的句柄)以及在finalizer queue里的对象。请注意,如果你的对象在2代,并且可以被回收,但你在做0代GC时,它也不会被回收。他们需要等到一个完整回收时才会被干掉。
如果0代对象已经填充满一个内存段,再做压缩也不能获得足够空间时,gc会重新分配一个新的内存段。新的段将用于放置新分配的1代和0代对象。而之前段的对象都将转为2代对象。所有的0代对象转为1代,1代对象同样降为2代对象(因为不需要复制所以很容易实现)。这个新的内存段看起来如下:
如果2代内存不断增加,那么它可以存放在多个内存段里。LOH也一样可以跨越多个内存段存放。但不管有多少个内存段,0代和1代对象始终在一个内存段里。了解到这些知识对后面的学习会很有帮助。大对象堆使用另外一种规则。通常来说一些字符串或者数组,大小在8500直接以上会自动分配到LOH堆里,它不会走上面的代纪模型。出于性能考虑,LOH分配的对象不会在回收的时候做压缩过程,但从.net4.5.1开始,你可以按需做压缩了。就行2代对象那样,当对象不再LOH里需要时,你还是可以回收它使用的内存空间,但稍后我们会说到,在垃圾回收里,最理想的状态是不要将对象创建到大对象堆上。
在LOH里,分配器都是使用空闲列表的方式来寻找最合适的位置来分配,在本章的后面将探索一些技术来减少在大数据堆上减少内存碎片。
垃圾回收特定代时,会顺带回收它下面的代。例如回收1代时,会把0代的也回收。如果是2代,那么就是把所有的都回收了(包括LOH里的)。如果是0代或者1代回收时,程序会暂停执行到GC过程结束。如果是回收2代,这一部分操作可以可能会在另外一个后台线程里执行,这取决于系统配置。
垃圾回收分为4个阶段:
暂停--所有托管线程需要在回收开始前暂停。
标记--从每个root节点开始,回收器会对每个对象的引用做标记
压缩--移动内存对象,并重新修改引用路径以便释放内存碎片。它通常发生在小对象堆上,并在系统认为需要的时候进行,你不能手动控制。在大对象堆上,压缩不会自动发生,但你可以配置垃圾回收器按需压缩他。
恢复--托管线程回复执行
标记阶段实际上不需要遍历堆上的每个对象,它只会处理需要回收的堆。举个栗子,做0代收集时只会考虑0代的对象,做1代收集时则会标记0代和1代的对象。在做2代或者一次完整回收时,才需要遍历每一个活着的对象,当然这个开销就比较高了。另外需要考虑的是,一个高代的对象可能是低代对象的root节点,这会导致在做遍历时,也会遍历相关的高代对象,当然这个开销会比全回收阶段时小一些。
上面描述的过程会导致以下问题。
首先,垃圾回收所消耗的时间,取决于当前还活着的对象数量,而不是已经分配出去的数量。这就意味着,如果分配了100w个对象在一个root节点上,只要下次GC前,你把它与root切断引用关系,这100w个对象对你的回收耗时不会造成太大影响。
其次,垃圾回收的频率取决于特定的一代里分配了多少内存。一旦超过内部的一个阈值,GC将回收这一代的对象。这个过程GC会根据你的程序做动态调整。如果在某代的回收卓有成效(回收了很多对象),则在这一代的回收会频繁触发,反之则减少。另外一个触发因素就是你的程序在电脑里的可用内存。如果可用内存低于某个阈值,GC也会频繁发生,用来减少堆的总体体积。
从上面的描述里,你可能觉得GC已经超过了你的控制范围。但这其实已经离真相不远了。最简单的优化方式就是,你可以通过控制内存的分配模式来达到。你在了解GC是如何工作后,你可以根据分配速率,对象的生命周期,来选择合适的配置。
相关文章:
原文地址:http://www.cnblogs.com/yahle/p/6552457.html
.NET社区新闻,深度好文,微信中搜索dotNET跨平台或扫描二维码关注