GC-日志_times: user=0.00 sys=0.00, real=0.00 secs] 15.776:-CSDN博客

-XX:+PrintGC 输出GC日志

-XX:+PrintGCDetails 输出GC的详细日志

-XX:+PrintGCTimeStamps 输出GC的时间戳（以基准时间的形式）

-XX:+PrintGCDateStamps 输出GC的时间戳（以日期的形式，如 2013-05-04T21:53:59.234+0800）

-XX:+PrintHeapAtGC 在进行GC的前后打印出堆的信息

-Xloggc:../logs/gc.log 日志文件的输出路径

https://blog.csdn.net/ZYC88888/article/details/80362205

Minor GC

2016-08-23T02:23:07.219-0200: 64.322: [GC (Allocation Failure) 64.322: [ParNew: 613404K->68068K(613440K), 0.1020465 secs] 10885349K->10880154K(12514816K), 0.1021309 secs] [Times: user=0.78 sys=0.01, real=0.11 secs]2016-08-23T02:23:07.321-0200:
gc发生时间-->jvm启动的相对时间，秒---->gc的标识(Minor GC还是 Full GC)---->gc原因--->ParNew收集器名称---->收集前后使用的内存(整个年轻代的容量)--->持续时间--->收集前后整个堆的使用大小(整个堆的容量)--->标记复制年轻代活对象花费时间---->gc在不同维度的耗时。

计算：

开始的时候：整个堆的大小是 10885349K，年轻代大小是613404K，这说明老年代大小是 10885349-613404=10271945K，

收集完成之后：整个堆的大小是 10880154K，年轻代大小是68068K，这说明老年代大小是 10880154-68068=10812086K，

老年代的大小增加了：10812086-10271945=608209K，也就是说年轻代到年老代提升了608209K的数据；

Full/Major GC

2016-08-23T11:23:07.321-0200: 64.425: [GC (CMS Initial Mark)1 [1 CMS-initial-mark: 10812086K(11901376K)] 10887844K(12514816K), 0.0001997 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
2016-08-23T11:23:07.321-0200: 64.425: [CMS-concurrent-mark-start]
2016-08-23T11:23:07.357-0200: 64.460: [: 0.035/0.035 secs] [Times: user=0.07 sys=0.00, real=0.03 secs] ---各个维度持续时间
2016-08-23T11:23:07.357-0200: 64.460: [CMS-concurrent-preclean-start]
2016-08-23T11:23:07.373-0200: 64.476: [CMS-concurrent-preclean3: 0.016/0.016 secs] [Times: user=0.02 sys=0.00, real=0.02 secs]---持续时间
2016-08-23T11:23:07.373-0200: 64.476: [CMS-concurrent-abortable-preclean-start]
2016-08-23T11:23:08.446-0200: 65.550: [CMS-concurrent-abortable-preclean4: 0.167/1.074 secs] [Times: user=0.20 sys=0.00, real=1.07 secs]---持续时间
2016-08-23T11:23:08.447-0200: 65.550: [GC (CMS Final Remark5)
[YG occupancy: 387920 K (613440 K)]65.550: [Rescan (parallel) , 0.0085125 secs]65.559:
[weak refs processing, 0.0000243 secs]65.559: [class unloading, 0.0013120 secs]65.560:
[scrub symbol table, 0.0008345 secs]65.561: [scrub string table, 0.0001759 secs][1 CMS-remark: 10812086K(11901376K)] 11200006K(12514816K), 0.0110730 secs]
[Times: user=0.06 sys=0.00, real=0.01 secs]--各个维度的持续时间
2016-08-23T11:23:08.458-0200: 65.561: [CMS-concurrent-sweep-start] 持续时间和各个维度的持续时间
2016-08-23T11:23:08.485-0200: 65.588: [CMS-concurrent-sweep6: 0.027/0.027 secs] [Times: user=0.03 sys=0.00, real=0.03 secs]
2016-08-23T11:23:08.485-0200: 65.589: [CMS-concurrent-reset-start]
2016-08-23T11:23:08.497-0200: 65.601: [CMS-concurrent-reset7: 0.012/0.012 secs] [Times: user=0.01 sys=0.00, real=0.01 secs]

Initial Mark CMS中的两次stop the world的第一次，(第一阶段)初始化标记，1.标记老年代中所有的GC Roots。2.标记年轻代中活着的对象引用的对象。

1.CMS-initial-mark收集阶段，开始收集所有GC Roots和直接引用到的对象---->当前老年代使用情况(老年代可用容量)--->当前整个堆的使用情况(整个堆的容量)。

2.CMS-concurrent-mark-start(第二阶段)并发标记，这个阶段会遍历整个老年代并且标记所有存活的对象，从“初始化标记”阶段找到的GC Roots开始。并发标记的特点是和应用程序线程同时运行。并不是老年代的所有存活对象都会被标记，因为标记的同时应用程序会改变一些对象的引用等。

3.Concurrent Preclean --这个阶段又是一个并发阶段，和应用线程并行运行，不会中断他们。前一个阶段在并行运行的时候，一些对象的引用已经发生了变化，当这些引用发生变化的时候，JVM会标记堆的这个区域为Dirty Card(包含被标记但是改变了的对象，被认为"dirty")，这就是 Card Marking。

4.Concurrent Abortable Preclean---又一个并发阶段不会停止应用程序线程。这个阶段尝试着去承担STW的Final Remark阶段足够多的工作。这个阶段持续的时间依赖好多的因素，由于这个阶段是重复的做相同的事情直到发生aboart的条件（比如：重复的次数、多少量的工作、持续的时间等等）之一才会停止。这个阶段很大程度的影响着即将来临的Final Remark的停顿，有相当一部分重要的 configuration options 和失败的模式；

5.CMS Final Remark----这个阶段是CMS中第二个并且是最后一个STW的阶段。该阶段的任务是完成标记整个年老代的所有的存活对象。由于之前的预处理是并发的，它可能跟不上应用程序改变的速度，这个时候，STW是非常需要的来完成这个严酷考验的阶段。通常CMS尽量运行Final Remark阶段在年轻代是足够干净的时候，目的是消除紧接着的连续的几个STW阶段,

YG occupancy---年轻代当前占用情况和容量

Rescan (parallel)----这个阶段在应用停止的阶段完成存活对象的标记工作；

weak refs processing----随着这个阶段的进行处理弱引用

class unloading----即卸载未使用的类

scrub string table/scrub string table---清理分别保存类的元数据和内部字符串的符号表和字符串表

CMS-remark: 10812086K(11901376K)] 11200006K(12514816K) 这个阶段后老年代占有的内存大小和老年代的容量--->这个阶段后整个堆的内存大小和整个堆的容量。

CMS-concurrent-sweep-start](并发清除)-----和应用线程同时进行，不需要STW。这个阶段的目的就是移除那些不用的对象，回收他们占用的空间并且为将来使用。

CMS-concurrent-reset-start]-----这个阶段重新设置CMS算法内部的数据结构，为下一个收集阶段做准备；