JVM内功心法-GC垃圾回收之GC垃圾回收过程_end of major gc

JVM内功心法-GC垃圾回收之GC垃圾回收算法

GC 全称garbagecollection，垃圾回收。JAVA 为了屏蔽操作系统和平台之间的差异。选择的是采用 java 虚拟机来运行 java 应用。即 jvm。jvm 既然是一个虚拟机，必然涉及到内存的管理。对于内存中的对象需要进行管理。管理内存的一个很重要的事情就是垃圾回收。即将无用的对象清理掉，释放出内存来给应用继续使用。这个过程就是 GC，为什么要有 gc。因为如果内存只使用不回收的话，很快就会占满，导致应用后续运行出现问题。

1. Minor GC/Young GC【从年轻代空间（包括 Eden 和 Survivor 区域）回收内存被称为 Minor GC】
   
   清理区域：
   清理年轻代空间（包括 Eden 和 Survivor 区域），释放在Eden中所有不活跃的对象，释放后若Eden空间仍然不足以放入新对象，则试图将部分Eden中活跃对象放入Survivor区。Survivor区被用来作为Eden及老年代的中间交换区域，当老年代空间足够时，Survivor区的对象会被移到老年代，否则会被保留在Survivor区。
   触发机制：
   虚拟机给每个对象定义一个对象年龄（Age）计数器。对象在 Eden 生并经过第一次 Minor GC 后仍然存活，并且能被 Survivor 容纳的话，将被移动到 Survivor 空间中，并将对象年龄设为 1。
   对象在 Survivor 区中每熬过一次 Minor GC，年龄就增加 1 岁，当它的年龄增加到一定程度（默认为 15 岁）时，就会被晋升到老年代中。对象晋升老年代的年龄阈值，可以通过参数-XX:MaxTenuringThreshold 来设置。当年轻代满时就会触发Minor GC，这里的年轻代满指的是Eden代满，Survivor满不会引发GC。

所有的 Minor GC 都会触发 “全世界的暂停（stop-the-world）”，停止应用程序的线程。对于大部分应用程序，停顿导致的延迟都是可以忽略不计的。

3. Major GC/Old GC【主要是清理老年代，MajorGC 的速度一般会比 Minor GC 慢 10 倍以上】
   清理区域：
   发生在老年代的 GC，出现了 Major GC，经常
   会伴随至少一次的 Minor GC（但非绝对的，在 ParallelScavenge 收集器的收集策略里
   就有直接进行 Major GC 的策略选择过程） 。MajorGC 的速度一般会比 Minor GC 慢 10
   倍以上。
   触发机制：
   许多 Major GC 是由 Minor GC 触发，所以很多情况下将这两种 GC 分离是不太可能的
4. Full GC【针对整个新生代、老生代、元空间】
   清理区域：
   针对整个新生代、老生代、元空间（metaspace，java8 以上版本取代 perm gen）的全局范围的 GC
   触发机制：
   （1）调用 System.gc 时，系统建议执行 Full GC，但是不必然执行
   （2）老年代空间不足
   （3）方法区空间不足：当永久代/元数据空间满时也会引发 Full GC，会导致 Class、Method 元信息的卸载。
   （4）通过 Minor GC 后进入老年代的平均大小大于老年代的可用内存
   （5）由 Eden 区、survivor space1（From Space）区向 survivor space2（To Space）区复制时，对象大小大于 To Space 可用内存，则把该对象转存到老年代，且老年代的可用内存小于该对象大小
5. Mixed GC【混合回收】
   这个会在GC垃圾回收之垃圾回收器里面详情讲解
6. 打印GC日志，分析GC日志
   vm options处加入-XX:+PrintGCDetails

[GC (Allocation Failure) [PSYoungGen: 666497K->226787K(701440K)] 2315053K->2311696K(2823680K), 0.1370868 secs] [Times: user=0.20 sys=0.33, real=0.14 secs] 
[Full GC (Ergonomics) [PSYoungGen: 226787K->189625K(701440K)] [ParOldGen: 2084908K->2121707K(2770432K)] 2311696K->2311333K(3471872K), [Metaspace: 38247K->38247K(1083392K)], 0.3397157 secs] [Times: user=0.73 sys=0.05, real=0.34 secs] 
[GC (Allocation Failure) [PSYoungGen: 664079K->426816K(889856K)] 2785787K->2768735K(3660288K), 0.1676467 secs] [Times: user=0.19 sys=0.75, real=0.17 secs] 
[GC (Allocation Failure) [PSYoungGen: 888350K->454271K(923648K)] 3230269K->3222454K(3694080K), 0.2892049 secs] [Times: user=0.36 sys=1.13, real=0.29 secs] 
[Full GC (Ergonomics) [PSYoungGen: 454271K->451918K(923648K)] [ParOldGen: 2768182K->2770182K(2770432K)] 3222454K->3222101K(3694080K), [Metaspace: 39234K->39234K(1085440K)], 0.5408364 secs] [Times: user=1.30 sys=0.11, real=0.54 secs] 
[Full GC (Ergonomics) [PSYoungGen: 913907K->898675K(923648K)] [ParOldGen: 2770182K->2770177K(2770432K)] 3684090K->3668852K(3694080K), [Metaspace: 39713K->39713K(1085440K)], 0.4137499 secs] [Times: user=1.17 sys=0.03, real=0.41 secs] 
[Full GC (Allocation Failure) [PSYoungGen: 898675K->896618K(923648K)] [ParOldGen: 2770177K->2769578K(2770432K)] 3668852K->3666197K(3694080K), [Metaspace: 39713K->39506K(1085440K)], 0.4584216 secs] [Times: user=1.67 sys=0.05, real=0.46 secs] 
[Full GC (Ergonomics) [PSYoungGen: 897544K->0K(923648K)] [ParOldGen: 2769584K->14524K(1157632K)] 3667129K->14524K(2081280K), [Metaspace: 39506K->39506K(1085440K)], 0.1651017 secs] [Times: user=0.00 sys=0.13, real=0.16 secs] 

Heap
 PSYoungGen      total 923648K, used 133921K [0x000000076b780000, 0x00000007c0000000, 0x00000007c0000000)
  eden space 462336K, 28% used [0x000000076b780000,0x0000000773a487a8,0x0000000787b00000)
  from space 461312K, 0% used [0x0000000787b00000,0x0000000787b00000,0x00000007a3d80000)
  to   space 461312K, 0% used [0x00000007a3d80000,0x00000007a3d80000,0x00000007c0000000)
 ParOldGen       total 1157632K, used 14524K [0x00000006c2600000, 0x0000000709080000, 0x000000076b780000)
  object space 1157632K, 1% used [0x00000006c2600000,0x00000006c342f0c8,0x0000000709080000)
 Metaspace       used 45008K, capacity 47080K, committed 47280K, reserved 1089536K
  class space    used 6163K, capacity 6523K, committed 6576K, reserved 1048576K
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

1、日志的开头“GC”、“Full GC”表示这次垃圾收集的停顿类型，而不是用来区分新生代GC还是老年代GC的。如果有Full，则说明本次GC停止了其他所有工作线程(Stop-The-World)。
Full GC的写法：
GC (Allocation Failure) ： 发生了一次垃圾回收，这是一次Minor GC 。注意它不表示只GC新生代，括号里的内容是gc发生的原因，这里的Allocation Failure的原因是年轻代中没有足够区域能够存放需要分配的数据而失败。
Full GC (Ergonomics)：这里可以到full gc的reason是Ergonomics，是因为开启了UseAdaptiveSizePolicy，jvm自己进行自适应调整引发的full gc。
GC (System.gc()) ：调用System.gc()方法所触发的GC。

2、“GC”中接下来的“[DefNew”表示GC发生的区域，这里显示的区域名称与使用的GC收集器是密切相关的，例如上面样例所使用的Serial收集器中的新生代名为“Default New Generation”，所以显示的是“[DefNew”。如果是ParNew收集器，新生代名称就会变为“[ParNew”，意为“Parallel New Generation”。如果采用Parallel Scavenge收集器，那它配套的新生代称为“PSYoungGen”，老年代和永久代同理，名称也是由收集器决定的。

3、后面方括号内部的“310K->194K(2368K)”、“2242K->0K(2368K)”，指的是该区域已使用的容量->GC后该内存区域已使用的容量(该内存区总容量)。方括号外面的“310K->194K(7680K)”、“2242K->2241K(7680K)”则指的是GC前Java堆已使用的容量->GC后Java堆已使用的容量(Java堆总容量)。

4、再往后“0.0269163 secs”表示该内存区域GC所占用的时间，单位是秒。最后的“[Times: user=0.00 sys=0.00 real=0.03 secs]”则更具体了，user表示用户态消耗的CPU时间、内核态消耗的CPU时间、操作从开始到结束经过的墙钟时间。后面两个的区别是，墙钟时间包括各种非运算的等待消耗，比如等待磁盘I/O、等待线程阻塞，而CPU时间不包括这些耗时，但当系统有多CPU或者多核的话，多线程操作会叠加这些CPU时间，所以如果看到user或sys时间超过real时间是完全正常的。

5、Heap后面就列举出堆内存目前各个年代的区域的内存情况。