G1收集器

声明:本文摘抄自《深入理解Java虚拟机》一书,本文完全为自我学习,请感兴趣的同学购买正版,支持原创

G1(Grabage-First)收集器是当今收集器技术发展的最前沿成果之一,它已在JDK 1.7 u4版本正式投入使用。G1是一款面向服务端应用的垃圾收集器,它定位于替换JDK1.5中发布的CMS收集器。
与其他收集器相比,G1收集器具有以下特点:

  • 并行与并发:G1能充分利用多CPU,多核环境下的硬件资源,使用多个CPU(CPU或者CPU核心)来缩短Stop-The-World的停顿时间,部分其它收集器原本需要暂停Java执行线程来进行GC,G1收集器可以通过并发的方式让Java执行线程继续运行。
  • 分代收集:与其它收集器一样,分代收集依然在G1中得到保留。虽然G1收集器可以不需要其它收集器配合就能够对整个Java堆进行管理,但它采用不同的方式去处理新创建的对象和已经存活了一段时间,且熬过多次GC的旧对象。
  • 空间整合:与CMS的”标记-清除“算法不同,G1从整体来看是基于”标记-整理“算法的收集器,从局部上来看是基于”复制“算法实现的,但无论如何,这两种算法都意味着G1运行期间不会产生内存空间碎片,收集后能提供规整的可用内存。这种特性有利于程序长时间运行,分配大对象时不会因为无法找到连续的内存空间而提前触发Full GC。
  • 可预测的停顿:这是G1相对CMS的另一大优势。降低停顿时间是G1和CMS共同的关注点,G1除了最求低停顿外,还能提供可预测的停顿时间模型,能让使用者明确指定一个长度为M毫秒的时间片段内,消耗在垃圾收集上的时间不得超过N毫秒。

使用G1收集器时,Java堆内存布局与其他收集器(新生代和老年代)有很大区别。它将整个Java堆划分为大小相等的独立区域(Region),虽然还保留新生代和老年代的概念,但新生代和老年代不再是物理上隔离的了,它们都是一部分Region的集合。

G1之所以可以建立可预测的停顿时间模型,是因为它可以有计划的避免在Java堆中进行全区域的垃圾收集。G1跟踪各个Region中垃圾堆积的价值大小,在后台维护一个优先列表,每次根据允许收集的时间,优先回收价值最大的Region。这种使用Region划分内存空间以及有优先级的区域回收方式,保证了G1收集器在有限时间内可以获取尽可能高的收集效率。

G1把内存”化整为零“的思路,理解起来似乎很容易,但其实现细节远远没有想象中那么简单。把Java堆分为多个Region后,垃圾收集器是否就真能以Region为单位进行垃圾回收?首先Region不可能是孤立的。一个对象被分配在某个Region中,它并非只能被这个Region中的其他对象引用,而是可以与Java堆中任意对象发生引用关系。那在做可达性分析判定对象是否存活的时候,岂不是还得扫描整个Java堆才能保证准确性。

在G1收集器中,Region中对象之间的引用和其他收集器中新生代和老年代中对象之间的引用,虚拟机都是使用Remembered Set来避免全堆扫描的。G1中每一个Region都有一个与之对应的Remembered Set,虚拟机在发现程序对Reference类型的数据进行写操作时,会产生一个Write Barrier暂时中断写操作,检查Reference引用的对象是否处于不同的Region之中,如果是,便通过CardTable把相关引用信息记录到被引用对象所属的Region的Remembered Set之中。当进行内存回收时,在GC根节点的枚举范围加入Remembered Set即可保证不对全堆扫描也不会有遗漏。

如果不计算维护Remembered Set的操作,G1收集器运作大致分为以下几个步骤:

  1. 初始化标记(Initial Marking)
  2. 并发标记(Concurrent Marking)
  3. 最终标记(Final Marking)
  4. 筛选回收(Live Data Counting and Evacuation)
G1收集器运行示意图

初始标记阶段仅仅只是标记一下GC Roots能直接关联上的对象,并且修改TAMS(Next Top at Mark Start)的值,让下一阶段用户程序并发执行时,能在正确可用的Region中创建新对象,这阶段需要停顿线程,但耗时很短。
并发标记阶段是从GC Roots开始对堆中的对象进行可达性分析,找出存活的对象,这阶段耗时较长,但可与用户线程并发执行。
最终标记阶段是为了修正在并发标记阶段期间因用户线程继续运行而导致标记产生变动的那一部分标记记录,虚拟机将这段时间内对象变化记录在线程Remembered Set Logs里面,最终标记需要将Remembered Set Logs的数据合并到Remembered Set中,这阶段需要停顿用户线程,但可以并发执行。
最后是筛选回收阶段,在筛选回收阶段首先对各个Region的回收价值和成本进行排序,根据用户所希望的GC停顿时间来制定回收计划,从Oracle公司透漏的出来的信息来看,这个阶段也可以做到与用户线程一起并行执行,但是因为只回收一部分Region,时间是用户控制的,而且停顿用户线程将大幅提高收集效率。

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 212,029评论 6 492
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 90,395评论 3 385
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 157,570评论 0 348
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 56,535评论 1 284
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 65,650评论 6 386
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 49,850评论 1 290
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 39,006评论 3 408
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 37,747评论 0 268
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 44,207评论 1 303
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 36,536评论 2 327
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 38,683评论 1 341
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 34,342评论 4 330
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 39,964评论 3 315
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 30,772评论 0 21
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,004评论 1 266
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 46,401评论 2 360
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 43,566评论 2 349

推荐阅读更多精彩内容