`
IXHONG
  • 浏览: 450116 次
  • 性别: Icon_minigender_1
  • 来自: 北京
社区版块
存档分类
最新评论

【转】深入理解Major GC, Full GC, CMS

    博客分类：
  • Java
jvm 
阅读更多

声明：本文转自http://blog.csdn.net/iter_zc/article/details/41825395，转载务必声明。

 

很多人都分不清Major GC, Full GC的概念，事实上我查了下资料，也没有查到非常精确的Major GC和Full GC的概念定义。分不清这两个概念可能就会对这个问题疑惑：Full GC会引起Minor GC吗？

经过一系列的查找和对JVM表现的分析，基本可以给Full GC和Major GC下一个定义了，这篇说一说概念和理由。

 

这篇文章Major GCs – Separating Myth from Reality 基本讨论的也是这个问题，但是它没有给出实际的证明。

 

我们可以认为Major GC == Full GC，他们是一个概念，就是针对老年代/永久代进行GC。因为取名叫Full就会让人疑惑，到底会不会先Minor GC。事实上Full GC本身不会先进行Minor GC，我们可以配置，让Full GC之前先进行一次Minor GC，因为老年代很多对象都会引用到新生代的对象，先进行一次Minor GC可以提高老年代GC的速度。比如老年代使用CMS时，设置CMSScavengeBeforeRemark优化，让CMS remark之前先进行一次Minor GC。

 

弄清楚了Full GC本意单纯就是针对老年代了之后，我们再进一步深入理解Full GC的含义。因为CMS主要可以分为initial mark(stop the world), concurrent mark, remark(stop the world), concurrent sweep几个阶段，其中initial mark和remark会stop the world。

在这篇聊聊JVM（二）说说GC的一些常见概念 我们说了一次CMS至少会给Full GC的次数 + 2，因为Full GC的次数是按照老年代GC时stop the world的次数而定的。

 

再来看Full GC的Time的定义，可以理解它也指的是老年代GC时stop the world的时间。我们看一个实例来证明一下。

 

这段日志是我从一个tomcat的JVM GC日志中抓取的，老年代使用了CMS收集器

 

[html] view plain copy
 
  1. 2014-12-08T17:24:18.514+0800: 77443.326: [GC [1 <strong><span style="color:#FF0000;">CMS-initial-mark: 1382782K(1843200K)] 1978934K(4710400K), 0.0702700 secs] [Times: user=0.07 sys=0.00, real=0.07 secs]</span></strong>   
  2. 2014-12-08T17:24:18.586+0800: 77443.398: [CMS-concurrent-mark-start]  
  3. 2014-12-08T17:24:19.890+0800: 77444.702: [CMS-concurrent-mark: 1.206/1.303 secs] [Times: user=2.80 sys=0.07, real=1.30 secs]   
  4. 2014-12-08T17:24:19.890+0800: 77444.702: [CMS-concurrent-preclean-start]  
  5. 2014-12-08T17:24:19.906+0800: 77444.718: [CMS-concurrent-preclean: 0.015/0.015 secs] [Times: user=0.02 sys=0.00, real=0.02 secs]   
  6. 2014-12-08T17:24:19.906+0800: 77444.718: [CMS-concurrent-abortable-preclean-start]  
  7.  CMS: abort preclean due to time 2014-12-08T17:24:25.181+0800: 77449.993: [CMS-concurrent-abortable-preclean: 5.241/5.275 secs] [Times: user=6.03 sys=0.09, real=5.27 secs]   
  8. 2014-12-08T17:24:25.187+0800: 77449.999: [GC[YG occupancy: 749244 K (2867200 K)]77450.000: [Rescan (parallel) , 0.0276780 secs]77450.028: [weak refs processing, 0.2029030 secs]  
  9.  [<span style="color:#FF0000;"><strong>1 CMS-remark: 1382782K(1843200K)] 2132027K(4710400K), 0.2340660 secs] [Times: user=0.43 sys=0.00, real=0.23 secs</strong></span>]   
  10. 2014-12-08T17:24:25.424+0800: 77450.236: [CMS-concurrent-sweep-start]  
  11. 2014-12-08T17:24:27.420+0800: 77452.232: [CMS-concurrent-sweep: 1.918/1.996 secs] [Times: user=2.61 sys=0.05, real=2.00 secs]   
  12. 2014-12-08T17:24:27.421+0800: 77452.233: [CMS-concurrent-reset-start]  
  13. 2014-12-08T17:24:27.430+0800: 77452.242: [CMS-concurrent-reset: 0.010/0.010 secs] [Times: user=0.01 sys=0.00, real=0.01 secs]   
  14. 2014-12-09T12:45:05.545+0800: 147090.358: [GC [<span style="color:#FF0000;"><strong>1 CMS-initial-mark: 1384080K(1843200K)] 2013429K(4710400K), 0.0656230 secs] [Times: user=0.06 sys=0.00, real=0.07 secs</strong></span>]   
  15. 2014-12-09T12:45:05.613+0800: 147090.425: [CMS-concurrent-mark-start]  
  16. 2014-12-09T12:45:06.848+0800: 147091.660: [CMS-concurrent-mark: 1.196/1.235 secs] [Times: user=2.77 sys=0.03, real=1.23 secs]   
  17. 2014-12-09T12:45:06.849+0800: 147091.661: [CMS-concurrent-preclean-start]  
  18. 2014-12-09T12:45:06.862+0800: 147091.674: [CMS-concurrent-preclean: 0.013/0.013 secs] [Times: user=0.02 sys=0.00, real=0.02 secs]   
  19. 2014-12-09T12:45:06.862+0800: 147091.674: [CMS-concurrent-abortable-preclean-start]  
  20.  CMS: abort preclean due to time 2014-12-09T12:45:11.874+0800: 147096.686: [CMS-concurrent-abortable-preclean: 4.948/5.012 secs] [Times: user=6.04 sys=0.10, real=5.01 secs]   
  21. 2014-12-09T12:45:11.882+0800: 147096.694: [GC[YG occupancy: 815312 K (2867200 K)]147096.695: [Rescan (parallel) , 0.0476710 secs]147096.743: [weak refs processing, 0.1565260 secs]   
  22. [1 <span style="color:#FF0000;"><strong>CMS-remark: 1384080K(1843200K)] 2199393K(4710400K), 0.2064660 secs] [Times: user=0.48 sys=0.00, real=0.20 secs</strong></span>]   
  23. 2014-12-09T12:45:12.091+0800: 147096.903: [CMS-concurrent-sweep-start]  
  24. 2014-12-09T12:45:14.078+0800: 147098.890: [CMS-concurrent-sweep: 1.934/1.986 secs] [Times: user=2.43 sys=0.04, real=1.99 secs]   
  25. 2014-12-09T12:45:14.078+0800: 147098.890: [CMS-concurrent-reset-start]  
  26. 2014-12-09T12:45:14.084+0800: 147098.896: [CMS-concurrent-reset: 0.006/0.006 secs] [Times: user=0.00 sys=0.00, real=0.01 secs]  

 

我把CMS的initial mark和remark的日志都标记了。

我们可以看到总共发生了两次CMS，所以Full GC的次数应该是4

Full GC的时间 = 0.07 secs(第一次initial mark)+ 0.23 secs(第一次remark) + 0.07 secs(第二次initial mark) + 0.20 secs(第二次remark) = 0.57s

 

用jstat -gc 得到的时间Full GC的次数和时间也是吻合的。

 

所以jstat是Java官方提供的工具，所以我们可以说得出的结论是和官方的一致的。

下面是Visual GC的截图，看Old Gen的统计数据： 4 collections, 576.421ms

再来看一个更加直接的例子，从OpenJDK里面找线索：

这段代码来自openjdk/hotspot/src/share/vm/services/memoryService.cpp，从代码中可以看到JVM使用了一个_fullGC的布尔值来表示是否是Full GC

DefNew, ParNew, ASParNew都是新生代的收集器算法，当使用它们时，_fullGC = false

MarkSweepCompact(Serial Old收集器)， ConcurrentMarkSweep(CMS), ASConcurrentMarkSweep时_fullGC = true。所以只有收集老年代的时候，才算Full GC

 

 

我们可以安全的说：

1. Full GC == Major GC指的是对老年代/永久代的stop the world的GC

2. Full GC的次数 = 老年代GC时 stop the world的次数

3. Full GC的时间 = 老年代GC时 stop the world的总时间

4. CMS 不等于Full GC，我们可以看到CMS分为多个阶段，只有stop the world的阶段被计算到了Full GC的次数和时间，而和业务线程并发的GC的次数和时间则不被认为是Full GC

 

我们可以看到正常的CMS的stop the world的时间很短，都是在几十到几百ms的级别，对Full GC的时间影响很小。但是有时候我们用jstat看到的Full GC的时间很长。比如下面这个例子，和上面的Tomcat是同一个应用，只是是我调优之前的数据。

 

我们看到调优之前的Full GC的评价时间 = 1188 / 223 = 5秒，也就是说单次Full GC的stop the world的时间达到了5s! 进一步分析日志，得到如下日志：

 

[html] view plain copy
 
  1. 54090.152: [Full GC (System) 54090.153: [CMS: 1211220K->1428569K(4096000K), 5.4936890 secs] 3483935K->1428569K(7168000K),   
  2. [CMS Perm : 148045K->147921K(262144K)], 5.4963160 secs] [Times: user=5.50 sys=0.00, real=5.50 secs]   
  3. 57696.218: [Full GC (System) 57696.219: [CMS: 1513461K->1213731K(4096000K), 4.7293810 secs] 3283076K->1213731K(7168000K),   
  4. [CMS Perm : 148019K->147881K(262144K)], 4.7317730 secs] [Times: user=4.73 sys=0.00, real=4.74 secs]   
  5. 61301.483: [Full GC (System) 61301.484: [CMS: 1288630K->968887K(4096000K), 4.5720170 secs] 2466308K->968887K(7168000K),   
  6. [CMS Perm : 147996K->147835K(262144K)], 4.5743720 secs] [Times: user=4.57 sys=0.00, real=4.57 secs]   
  7. 64906.588: [Full GC (System) 64906.590: [CMS: 1026456K->1568407K(4096000K), 5.0347600 secs] 3769961K->1568407K(7168000K),   
  8. [CMS Perm : 148004K->147903K(262144K)], 5.0373410 secs] [Times: user=5.02 sys=0.00, real=5.04 secs]   
  9. 68512.160: [Full GC (System) 68512.161: [CMS: 1631217K->838700K(4096000K), 4.7239290 secs] 2552874K->838700K(7168000K),   
  10. [CMS Perm : 148017K->147829K(262144K)], 4.7261610 secs] [Times: user=4.72 sys=0.00, real=4.72 secs]   
  11. 72117.421: [Full GC (System) 72117.423: [CMS: 905025K->1529502K(4096000K), 5.3562640 secs] 3556285K->1529502K(7168000K),   
  12. [CMS Perm : 148049K->147945K(262144K)], 5.3587790 secs] [Times: user=5.36 sys=0.00, real=5.36 secs]   


我们看到是System.gc引起的Full GC，而老年代的GC时间到达了5秒多，它显示的是CMS，但是实际上不是CMS并发的收集器，而是CMS发生了concurrent mode fail之后退化成了Serial Old收集器，它是单线程的标记-压缩收集器，所以耗时非常的长。

 

 

最后再次强调一下结论:

 

1. Full GC == Major GC指的是对老年代/永久代的stop the world的GC

2. Full GC的次数 = 老年代GC时 stop the world的次数

3. Full GC的时间 = 老年代GC时 stop the world的总时间

4. CMS 不等于Full GC，我们可以看到CMS分为多个阶段，只有stop the world的阶段被计算到了Full GC的次数和时间，而和业务线程并发的GC的次数和时间则不被认为是Full GC

5. Full GC本身不会先进行Minor GC，我们可以配置，让Full GC之前先进行一次Minor GC，因为老年代很多对象都会引用到新生代的对象，先进行一次Minor GC可以提高老年代GC的速度。比如老年代使用CMS时，设置CMSScavengeBeforeRemark优化，让CMS remark之前先进行一次Minor GC。

0
顶
1
踩
分享到：
| 一步步优化JVM六：优化吞吐量
评论
发表评论

您还没有登录,请您登录后再发表评论

相关推荐

    jvm-full-gc.zip

    《深入解析JVM Full GC与调优》 在Java开发中，JVM（Java Virtual Machine）扮演着至关重要的角色，它是Java程序运行的基础。而Full GC作为JVM内存管理的一部分，是每个Java开发者都需要理解的重要概念。本篇将详细...

    jvm-full-gc调优-jvm-full-gc.zip

    本资料"jvm-full-gc调优-jvm-full-gc.zip"显然是针对如何减少和优化JVM的Full GC进行深入探讨的。以下将详细介绍JVM Full GC的相关知识点。 1. **理解JVM内存结构**：Java内存主要分为堆内存（Heap）和非堆内存...

    gcviewer-1.37-SNAPSHOT.jar

    用于分析 java gc日志文件。根据日志中的CMS GC统计信息可得到Full GC（也可以理解为Major GC）以及Minor GC相关数据

    深入JVM内核—原理、诊断与优化视频教程-4.GC算法与种类

    总结，JVM内核的深入理解和GC的精通对于Java开发者至关重要。通过学习“深入JVM内核—原理、诊断与优化视频教程”，可以提升对JVM工作的理解，从而更好地优化应用性能，减少系统停顿，提高用户体验。通过实践和研究...

    jvm 参数及gc详解

    2. 老年代GC（Major GC 或 Full GC） 老年代GC处理的是长期存活的对象，使用标记-整理或标记-压缩算法。当老年代空间不足或系统请求Full GC时，会执行此操作。Full GC开销大，应尽量避免频繁触发。 3. 垃圾收集器 ...

    JAVA中对GC的理解

    - 老年代GC（Major GC/Full GC）：当老年代空间不足或者系统请求时发生，涉及整个堆的垃圾回收，可能导致较长的停顿时间。 理解GC对于Java开发者至关重要，因为它直接影响程序的性能和稳定性。通过调整JVM参数，...

    jvm gc

    老年代的空间更大，如果老年代也满了，就会触发Major GC或Full GC，这会清理整个堆内存，包括新生代和老年代。 3. **垃圾收集器（Garbage Collector）**：JVM提供了多种垃圾收集器，如Serial GC、Parallel GC、...

    深入JVM内核—原理、诊断与优化视频教程-5. GC参数

    1. **GC的基本概念**：讲解GC的工作原理，包括新生代、老年代、持久代的概念，以及Minor GC、Major GC和Full GC的区别。 2. **GC算法**：介绍常用的垃圾收集算法，如Serial、Parallel、CMS（Concurrent Mark Sweep...

    JVM、GC详解及调优

    3. **GC类型**：主要分为 Minor GC（年轻代GC）、Major GC（老年代GC）和Full GC（全局GC），针对不同区域进行垃圾回收。 4. **GC触发条件**：内存分配达到阈值、手动触发、System.gc()调用等都可能导致GC启动。 5...

    gc回收机制

    GC的类型主要有 Minor GC（针对新生代的垃圾收集）、Major GC（针对老年代的垃圾收集）和 Full GC（包括新生代和老年代的全面清理）。不同的GC策略会影响应用的性能，例如，吞吐量优先、响应时间优先或者平衡策略。 ...

    JVM、GC详解及调优_jvm_JVM、GC详解及调优_

    2. ** Major GC / Full GC**：涉及老年代（Tenured Generation）的垃圾收集，可能涉及到整个堆，速度较慢，应尽量减少其发生。 3. ** CMS（Concurrent Mark Sweep）GC**：并发标记清除，减少STW（Stop-The-World）...

    思维导图-详细了解JVM和GC过程

    《深入理解JVM与垃圾收集过程》 JVM（Java Virtual Machine）是Java程序的运行环境，它将Java代码编译成字节码后，在JVM上解释执行。理解JVM的工作原理对于优化代码性能、排查问题至关重要。本文将详细探讨JVM的...

    JVM_GC调优

    通过对JVM_GC调优的深入探讨，我们可以看出JVM内存管理和垃圾回收机制的复杂性。合理的GC策略和参数调整对于提高Java应用的性能至关重要。理解不同GC算法的特点和适用场景，可以帮助开发者选择最适合特定应用场景的...

    Java的GC机制探微.pdf

    在深入理解Java的GC机制之前，我们首先要知道Java内存模型的几个关键区域：堆内存（Heap）、栈内存（Stack）、方法区（Method Area）、本地方法栈（Native Method Stack）以及程序计数器（Program Counter Register...

    Java 内存区域和GC机制

    - **GC类型**：主要分为Minor GC（年轻代GC）、Major GC（老年代GC）和Full GC（全局GC）。 - **GC策略**：包括复制算法、标记-清除算法、标记-整理算法、分代收集策略等，根据JVM版本和配置不同而有所不同。 - *...

    深入理解java虚拟机

    《深入理解Java虚拟机》这本书主要探讨了Java内存管理和垃圾收集机制。在Java虚拟机（JVM）中，内存管理是至关重要的，因为它直接影响到程序的性能和稳定性。以下是书中涉及的一些关键知识点： 1. **分代收集理论**...

    java gc

    - Major GC或Full GC：清理整个堆，包括新生代和老年代，可能使用标记-整理或标记-清除算法，执行速度慢，停顿时间长。 4. 调优策略： - 设置合理的堆大小：过大可能导致GC频繁，过小可能导致内存溢出。 - 选择...

    第6节： GC垃圾回收-02

    3. **Full GC**：包括Minor GC和Major GC，对整个堆和方法区进行回收。 ### **JVM内存分配担保** 当新生代（Eden + 一个Survivor区）在Minor GC后仍无法容纳存活对象时，这些对象会被晋升到老年代。如果老年代空间...

    ga16.zip-分析GC日志native_stderr.log(可分析WAS6.1版本)

    3. **日志模式与指标**：理解不同GC日志模式，如CMS、Parallel、G1等，关注关键指标如吞吐量、暂停时间和内存利用率。 **WAS6.1的配置调整：** 要优化WAS6.1的GC行为，可能需要修改JVM启动参数，如： 1. `-XX:+...

    JVM-GC全面知识系统详解

    总的来说，掌握JVM-GC全面知识不仅有助于优化Java应用性能，也能帮助开发者深入理解Java程序的运行机制。了解这些内容，可以有效避免内存溢出、提高应用响应速度，并能更好地应对多线程环境下的数据同步问题。对于...

Magicbox
Global site tag (gtag.js) - Google Analytics