解析JDK7的Garbage-First收集器.docVIP

Garbage-First（后文简称G1）收集器是当今收集器技术发展的最前沿成果，在Sun公司给出的JDK RoadMap里面，它被视作JDK 7的HotSpot VM 的一项重要进化特征。从JDK 6u14中开始就有Early Access版本的G1收集器供开发人员实验、试用，虽然在JDK 7正式版发布时，G1收集器仍然没有摆脱“Experimental”的标签，但是相信不久后将会有一个成熟的商用版本跟随某个JDK 7的更新包发布出来。 相关厂商内容  HYPERLINK /cn/vendorcontent/show.action?vcr=2065utm_source=infoqutm_medium=VCRutm_campaign=vcr_articles_click \t _blank InfoQ《深入浅出Node.js》专栏作者，CNode社区朴灵确认主持并参与分享QCon Node.js专题  HYPERLINK /cn/vendorcontent/show.action?vcr=2064utm_source=infoqutm_medium=VCRutm_campaign=vcr_articles_click \t _blank 个性能测试专家，7创始人高楼（Zee）主持出品2013北京QCon“优秀测试实践分析”专场 因版面篇幅限制，笔者行文过程中假设读者对HotSpot其他收集器（例如CMS）及相关JVM内存模型已有基本的了解，涉及到基础概念时，没有再延伸介绍，读者可参考相关资料。 G1收集器的特点 G1是一款面向服务端应用的垃圾收集器，Sun（Oracle）赋予它的使命是（在比较长期的）未来可以替换掉JDK 5中发布的CMS（Concurrent Mark Sweep）收集器，与其他GC收集器相比，G1具备如下特点： 并行与并发：G1能充分利用多CPU、多核环境下的硬件优势，使用多个CPU（CPU或者CPU核心）来缩短Stop-The-World停顿的时间，部分其他收集器原本需要停顿Java线程执行的GC动作，G1收集器仍然可以通过并发的方式让Java程序继续执行。 分代收集：与其他收集器一样，分代概念在G1中依然得以保留。虽然G1可以不需其他收集器配合就能独立管理整个GC堆，但它能够采用不同的方式去处理新创建的对象和已经存活了一段时间、熬过多次GC的旧对象以获取更好的收集效果。 空间整合：与CMS的“标记-清理”算法不同，G1从整体看来是基于“标记-整理”算法实现的收集器，从局部（两个Region之间）上看是基于“复制”算法实现，无论如何，这两种算法都意味着G1运作期间不会产生内存空间碎片，收集后能提供规整的可用内存。这种特??有利于程序长时间运行，分配大对象时不会因为无法找到连续内存空间而提前触发下一次GC。 可预测的停顿：这是G1相对于CMS的另外一大优势，降低停顿时间是G1和CMS共同的关注点，但G1除了追求低停顿外，还能建立可预测的停顿时间模型，能让使用者明确指定在一个长度为M毫秒的时间片段内，消耗在垃圾收集上的时间不得超过N毫秒，这几乎已经是实时Java（RTSJ）的垃圾收集器特征了。 实现思路 在G1之前的其他收集器进行收集的范围都是整个新生代或者老年代，而G1不再是这样。使用G1收集器时，Java堆的内存布局与就与其他收集器有很大差别，它将整个Java堆划分为多个大小相等的独立区域（Region），虽然还保留有新生代和老年代的概念，但新生代和老年代不再是物理隔离的了，它们都是一部分Region（不需要连续）的集合。 G1收集器之所以能建立可预测的停顿时间模型，是因为它可以有计划地避免在整个Java堆中进行全区域的垃圾收集。G1跟踪各个Region里面的垃圾堆积的价值大小（回收所获得的空间大小以及回收所需时间的经验值），在后台维护一个优先列表，每次根据允许的收集时间，优先回价值最大的Region（这也就是Garbage-First名称的来由）。这种使用Region划分内存空间以及有优先级的区域回收方式，保证了G1收集器在有限的时间内获可以获取尽可能高的收集效率。 G1把内存“化整为零”的思路，理解起来似乎很容易理解，但其中的实现细节却远远没有现象中简单，否则也不会从04年Sun实验室发表第一篇G1的论文拖至今将近8年时间都还没有开发出G1的商用版。笔者举个一个细节为例：把Java堆分为多个Region后，垃圾收集是否就真的能以Region为单位进行了？听起来顺理成章，再仔细想想就很容易发现问题所在：Region不可能是孤立的。一个对象分配在某个Region中，它并非只能被本Region中的其他对象引用，而是可以与整个Java堆任意的对象发生引用关系。那在做可达性判定确定对象是否存活的时候