GC垃圾回收 | 深入理解G1垃圾收集器和GC日志
来源:并发编程网
链接:http://ifeve.com/深入理解G1垃圾收集器/
G1 GC是Jdk7的新特性之一、Jdk7+版本都可以自主配置G1作为JVM GC选项;作为JVM GC算法的一次重大升级、DK7u后G1已相对稳定、且未来计划替代CMS、所以有必要深入了解下:
不同于其他的分代回收算法、G1将堆空间划分成了互相独立的区块。每块区域既有可能属于O区、也有可能是Y区,且每类区域空间可以是不连续的(对比CMS的O区和Y区都必须是连续的)。这种将O区划分成多块的理念源于:当并发后台线程寻找可回收的对象时、有些区块包含可回收的对象要比其他区块多很多。虽然在清理这些区块时G1仍然需要暂停应用线程、但可以用相对较少的时间优先回收包含垃圾最多区块。这也是为什么G1命名为Garbage First的原因:第一时间处理垃圾最多的区块。
平时工作中大多数系统都使用CMS、即使静默升级到JDK7默认仍然采用CMS、那么G1相对于CMS的区别在:
- G1在压缩空间方面有优势
- G1通过将内存空间分成区域(Region)的方式避免内存碎片问题
- Eden, Survivor, Old区不再固定、在内存使用效率上来说更灵活
- G1可以通过设置预期停顿时间(Pause Time)来控制垃圾收集时间避免应用雪崩现象
- G1在回收内存后会马上同时做合并空闲内存的工作、而CMS默认是在STW(stop the world)的时候做
- G1会在Young GC中使用、而CMS只能在O区使用
就目前而言、CMS还是默认首选的GC策略、可能在以下场景下G1更适合:
- 服务端多核CPU、JVM内存占用较大的应用(至少大于4G)
- 应用在运行过程中会产生大量内存碎片、需要经常压缩空间
- 想要更可控、可预期的GC停顿周期;防止高并发下应用雪崩现象
一次完整G1GC的详细过程:
G1在运行过程中主要包含如下4种操作方式:
- YGC(不同于CMS)
- 并发阶段
- 混合模式
- full GC (一般是G1出现问题时发生)
YGC:
下面是一次YGC前后内存区域是示意图:
图中每个小区块都代表G1的一个区域(Region),区块里面的字母代表不同的分代内存空间类型(如[E]Eden,[O]Old,[S]Survivor)空白的区块不属于任何一个分区;G1可以在需要的时候任意指定这个区域属于Eden或是O区之类的。
G1 YoungGC在Eden充满时触发,在回收之后所有之前属于Eden的区块全变成空白。然后至少有一个区块是属于S区的(如图半满的那个区域),同时可能有一些数据移到了O区。
目前淘系的应用大都使用PrintGCDetails参数打出GC日志、这个参数对G1同样有效、但日志内容颇为不同;下面是一个Young GC的例子:
23.430: [GC pause (young), 0.23094400 secs]
...
[Eden: 1286M(1286M)->0B(1212M)
Survivors: 78M->152M Heap: 1454M(4096M)->242M(4096M)]
[Times: user=0.85 sys=0.05, real=0.23 secs]
上面日志的内容解析:Young GC实际占用230毫秒、其中GC线程占用850毫秒的CPU时间
E:内存占用从1286MB变成0、都被移出
S:从78M增长到了152M、说明从Eden移过来74M
Heap:占用从1454变成242M、说明这次Young GC一共释放了1212M内存空间
很多情况下,S区的对象会有部分晋升到Old区,另外如果S区已满、Eden存活的对象会直接晋升到Old区,这种情况下Old的空间就会涨
并发阶段:
一个并发G1回收周期前后内存占用情况如下图所示:
从上面的图表可以看出以下几点:
1、Young区发生了变化、这意味着在G1并发阶段内至少发生了一次YGC(这点和CMS就有区别),Eden在标记之前已经被完全清空,因为在并发阶段应用线程同时在工作、所以可以看到Eden又有新的占用
2、一些区域被X标记,这些区域属于O区,此时仍然有数据存放、不同之处在G1已标记出这些区域包含的垃圾最多、也就是回收收益最高的区域
3、在并发阶段完成之后实际上O区的容量变得更大了(O+X的方块)。这时因为这个过程中发生了YGC有新的对象进入所致。此外,这个阶段在O区没有回收任何对象:它的作用主要是标记出垃圾最多的区块出来。对象实际上是在后面的阶段真正开始被回收
G1并发标记周期可以分成几个阶段、其中有些需要暂停应用线程。第一个阶段是初始标记阶段。这个阶段会暂停所有应用线程-部分原因是这个过程会执行一次YGC、下面是一个日志示例:
50.541: [GC pause (young) (initial-mark), 0.27767100 secs]
[Eden: 1220M(1220M)->0B(1220M)
Survivors: 144M->144M Heap: 3242M(4096M)->2093M(4096M)]
[Times: user=1.02 sys=0.04, real=0.28 secs]
上面的日志表明发生了YGC、应用线程为此暂停了280毫秒,Eden区被清空(71MB从Young区移到了O区)。
日志里面initial-mark的字样表明后台的并发GC阶段开始了。因为初始标记阶段本身也是要暂停应用线程的,
G1正好在YGC的过程中把这个事情也一起干了。为此带来的额外开销不是很大、增加了20%的CPU,暂停时间相应的略微变长了些。
接下来,G1开始扫描根区域、日志示例:
50.819: [GC concurrent-root-region-scan-start]
51.408: [GC concurrent-root-region-scan-end, 0.5890230]
一共花了580毫秒,这个过程没有暂停应用线程;是后台线程并行处理的。这个阶段不能被YGC所打断、因此后台线程有足够的CPU时间很关键。如果Young区空间恰好在Root扫描的时候
满了、YGC必须等待root扫描之后才能进行。带来的影响是YGC暂停时间会相应的增加。这时的GC日志是这样的:
350.994: [GC pause (young)
351.093: [GC concurrent-root-region-scan-end, 0.6100090]
351.093: [GC concurrent-mark-start],0.37559600 secs]
GC暂停这里可以看出在root扫描结束之前就发生了,表明YGC发生了等待,等待时间大概是100毫秒。
在root扫描完成后,G1进入了一个并发标记阶段。这个阶段也是完全后台进行的;GC日志里面下面的信息代表这个阶段的开始和结束:
111.382: [GC concurrent-mark-start]
....
120.905: [GC concurrent-mark-end, 9.5225160 sec]
并发标记阶段是可以被打断的,比如这个过程中发生了YGC就会。这个阶段之后会有一个二次标记阶段和清理阶段:
120.910: [GC remark 120.959:
[GC ref-PRC, 0.0000890 secs], 0.0718990 secs]
[Times: user=0.23 sys=0.01, real=0.08 secs]
120.985: [GC cleanup 3510M->3434M(4096M), 0.0111040 secs]
[Times: user=0.04 sys=0.00, real=0.01 secs]
这两个阶段同样会暂停应用线程,但时间很短。接下来还有额外的一次并发清理阶段:
120.996: [GC concurrent-cleanup-start]
120.996: [GC concurrent-cleanup-end, 0.0004520]
到此为止,正常的一个G1周期已完成–这个周期主要做的是发现哪些区域包含可回收的垃圾最多(标记为X),实际空间释放较少。
混合GC:
接下来G1执行一系列的混合GC。这个时期因为会同时进行YGC和清理上面已标记为X的区域,所以称之为混合阶段,下面是一个混合GC执行的前后示意图:
像普通的YGC那样、G1完全清空掉Eden同时调整survivor区。另外,两个标记也被回收了,他们有个共同的特点是包含最多可回收的对象,因此这两个区域绝对部分空间都被释放了。这两个区域任何存活的对象都被移到了其他区域(和YGC存活对象晋升到O区类似)。这就是为什么G1的堆比CMS内存碎片要少很多的原因–移动这些对象的同时也就是在压缩对内存。下面是一个混合GC的日志:
79.826: [GC pause (mixed), 0.26161600 secs]
....
[Eden: 1222M(1222M)->0B(1220M)
Survivors: 142M->144M Heap: 3200M(4096M)->1964M(4096M)]
[Times: user=1.01 sys=0.00, real=0.26 secs]
上面的日志可以注意到Eden释放了1222MB、但整个堆的空间释放内存要大于这个数目。数量相差看起来比较少、只有16MB,但是要考虑同时有survivor区的对象晋升到O区;另外,每次混合GC只是清理一部分的O区内存,整个GC会一直持续到几乎所有的标记区域垃圾对象都被回收,这个阶段完了之后G1会重新回到正常的YGC阶段。周期性的,当O区内存占用达到一定数量之后G1又会开启一次新的并行GC阶段.
GC垃圾回收 | 深入理解G1垃圾收集器和GC日志的更多相关文章
- Java虚拟机垃圾回收(三) 7种垃圾收集器
Java虚拟机垃圾回收(三) 7种垃圾收集器 主要特点 应用场景 设置参数 基本运行原理 在<Java虚拟机垃圾回收(一) 基础>中了解到如何判断对象是存活还是已经死亡?在<Java ...
- JVM(十一),垃圾回收之老年代垃圾收集器
十一.垃圾回收之老年代垃圾收集器 1.Serial Old收集器(标记整理算法-单线程-Client模式下) 2.Paraller Old收集器(标记整理算法-多线程-) 3.CMS收集器(标记清除算 ...
- JVM(三) 垃圾回收时间点和垃圾收集器
收集器组合章节来自第一篇参考文章,非原创,作者总结地非常好! 分代收集相关概念来自参考文章第二篇,非原创 第二篇参考资料的文章质量很高,推荐阅读! 分代收集(Ge ...
- Java虚拟机垃圾回收(三): 7种垃圾收集器(转载)
1.垃圾收集器概述 垃圾收集器是垃圾回收算法(标记-清除算法.复制算法.标记-整理算法.火车算法)的具体实现,不同商家.不同版本的JVM所提供的垃圾收集器可能会有很在差别,本文主要介绍HotSpot虚 ...
- Java垃圾回收之老年代垃圾收集器
1.Serial Old 收集器(-XX: +UseSerialOldGC, 标记-整理算法) 1.1 单线程收集,进行垃圾收集时,必须暂停所有工作线程 1.2 简单高效,Client模式下默认的老年 ...
- 详解 JVM Garbage First(G1) 垃圾收集器(转载)
前言 Garbage First(G1)是垃圾收集领域的最新成果,同时也是HotSpot在JVM上力推的垃圾收集器,并赋予取代CMS的使命.如果使用Java 8/9,那么有很大可能希望对G1收集器进行 ...
- GC垃圾回收机制,iOS内存管理。
问题: MRC中通过调用静态方法创建的新对象,不再使用时需要对其发送release消息吗? 不需要,因为约定静态方法创建的对象会自动将其放入自动释放池,即已对其发送autorelease消息,因此不可 ...
- 深入理解 Java G1 垃圾收集器--转
原文地址:http://blog.jobbole.com/109170/?utm_source=hao.jobbole.com&utm_medium=relatedArticle 本文首先简单 ...
- 【JVM】7、深入理解Java G1垃圾收集器
本文首先简单介绍了垃圾收集的常见方式,然后再分析了G1收集器的收集原理,相比其他垃圾收集器的优势,最后给出了一些调优实践. 一,什么是垃圾回收 首先,在了解G1之前,我们需要清楚的知道,垃圾回收是什么 ...
随机推荐
- vscode go开发主要插件
• Colorization 代码着彩色 • Completion Lists 代码自动完成(使用gocode) • Snippets 代码片段 • Quick Info 快速提示信息(使用godef ...
- touchgfx MVP
- redis——java访问redis
1,使用jedis的java客户端来访问redis服务器,有点类似于通过jdbc访问mysql一样: 2,如果是spring集成时,可以使用spring data 来访问redis,spring da ...
- Educational Codeforces Round 37 (Rated for Div. 2)C. Swap Adjacent Elements (思维,前缀和)
Educational Codeforces Round 37 (Rated for Div. 2)C. Swap Adjacent Elements time limit per test 1 se ...
- HTML禁用一块区域点击
style="pointer-events: none;" 此方法可以禁止鼠标点击指定区域,但是对于键盘事件无法屏蔽,最好禁用一下键盘事件,如:tab
- BFS和DFS
1.图的两种遍历方式 图的遍历通常有两种方式,即深度优先搜索(Depth First Search)和广度优先搜索(Breadth First Search).前者类似于树的先序遍历,而后者类似于树的 ...
- C# 泛型(4) 持续更新
泛型可以创建独立于被包含类型的类和方法. C++模板与泛型相似. 泛型优点性能 System.Collections 和 System.Collections.Generic 名称空间泛型和非泛型集合 ...
- BZOJ 1180 [CROATIAN 2009]OTOCI // BZOJ 2843 极地旅行社 // Luogu P4321 [COCI 2009] OTOCI / 极地旅行社 (LCA板题)
emmm-标题卡着长度上限- LCT板题-(ε=ε=ε=┏(゜ロ゜;)┛) CODE #include <cctype> #include <cmath> #include & ...
- String替换占位符
/** * 依次替换占位符 * 例如: 姓名:{s},电话:{s},邮箱:{s} --> 姓名:小张,电话:18800000001,邮箱:abc@123.com * pattern = &quo ...
- POI读取格式化后的单元格数据
public static String getFormattedValue(Cell cell) { FormulaEvaluator evaluator = cell.getSheet().get ...