GC(Allocation Failure)引发的一些JVM知识点梳理

日前查看某个程序的日志，发现一直在报GC相关的信息，不确定这样的信息是代表正确还是不正确，所以正好借此机会再复习下GC相关的内容：

以其中一行为例来解读下日志信息：

[GC (Allocation Failure) [ParNew: 367523K->1293K(410432K), 0.0023988 secs] 522739K->156516K(1322496K), 0.0025301 secs] [Times: user=0.04 sys=0.00, real=0.01 secs]

 

GC：

表明进行了一次垃圾回收，前面没有Full修饰，表明这是一次Minor GC ,注意它不表示只GC新生代，并且现有的不管是新生代还是老年代都会STW。

Allocation Failure：

表明本次引起GC的原因是因为在年轻代中没有足够的空间能够存储新的数据了。

ParNew：

    表明本次GC发生在年轻代并且使用的是ParNew垃圾收集器。ParNew是一个Serial收集器的多线程版本，会使用多个CPU和线程完成垃圾收集工作（默认使用的线程数和CPU数相同，可以使用-XX：ParallelGCThreads参数限制）。该收集器采用复制算法回收内存，期间会停止其他工作线程，即Stop The World。

367523K->1293K(410432K)：单位是KB

三个参数分别为：GC前该内存区域(这里是年轻代)使用容量，GC后该内存区域使用容量，该内存区域总容量。

0.0023988 secs：

    该内存区域GC耗时，单位是秒

522739K->156516K(1322496K)：

三个参数分别为：堆区垃圾回收前的大小，堆区垃圾回收后的大小，堆区总大小。

0.0025301 secs：

该内存区域GC耗时，单位是秒

[Times: user=0.04 sys=0.00, real=0.01 secs]：

    分别表示用户态耗时，内核态耗时和总耗时

 

分析下可以得出结论：

    该次GC新生代减少了367523-1293=366239K

    Heap区总共减少了522739-156516=366223K

    366239 – 366223 =16K，说明该次共有16K内存从年轻代移到了老年代，可以看出来数量并不多，说明都是生命周期短的对象，只是这种对象有很多。

    我们需要的是尽量避免Full GC的发生，让对象尽可能的在年轻代就回收掉，所以这里可以稍微增加一点年轻代的大小，让那17K的数据也保存在年轻代中。

 

GC时，用什么方法判断哪些对象是需要回收：

1. 引用计数法(已经不用了)
2. 可达性分析法

前一种简而言之就是给对象添加一个引用计数器，有其他地方引用时这个计数器+1，引用失效时-1，为0时就可以删除掉了。但是它不能解决循环引用的问题，所以一般使用的都是后一种算法。

可达性分析法的基本思路就是通过一系列名为GC Roots的对象作为起始点，从这些节点开始向下搜索，搜索所走过的路径称为引用链(Reference Chain)，当一个对象到GC Roots没有任何引用链相连时，则证明此对象是不可用的，那就可以回收掉了。

GC Roots一般都是些堆外指向堆内的引用，例如：

1. JVM栈中引用的对象
2. 方法区中静态属性引用的对象
3. 方法区中常量引用的对象
4. 本地方法栈中引用的对象 

 

 

以CMS为例，补充一些知识点介绍：

复制算法介绍：

因为新生代对象生命周期一般很短，现在一般将该内存区域划分为三块部分，一块大的叫Eden,两块小的叫Survivor。他们之间的比例一般为8:1:1。

使用的时候只使用Eden + 一块Survivor。用Eden区用满时会进行一次minor gc，将存活下面的对象复制到另外一块Survivor上。如果另一块Survivor放不下(对应虚拟机参数为 XX:TargetSurvivorRatio，默认50，即50%)，对象直接进入老年代。

（使用CMS时，默认的新生代收集器是ParNew）(有时新生代GC时，需要找到老年代中引用的新生代对象，这个时候会用到一种叫“卡表”的技术，避免老年代的全表扫描，具体怎么操作的暂时还不知道……)

 

Survivor区的意义：

    如果没有survivor,Eden每进行一次minor gc，存活的对象就会进入老年代，老年代很快被填满就会进入major gc。由于老年代空间一般很大，所以进行一次gc耗时要长的多！尤其是频繁进行full GC，对程序的响应和连接都会有影响！

    Survivor存在就是减少被送到老年代的对象，进而减少Full gc的发生。默认设置是经历了16次minor gc还在新生代中存活的对象才会被送到老年代。

 

为什么要有两个Survivor：

    主要是为了解决内存碎片化和效率问题。如果只有一个Survivor时，每触发一次minor gc都会有数据从Eden放到Survivor，一直这样循环下去。注意的是，Survivor区也会进行垃圾回收，这样就会出现内存碎片化问题。如下图所示：

 

    碎片化会导致堆中可能没有足够大的连续空间存放一个大对象，影响程序性能。如果有两块Survivor就能将剩余对象集中到其中一块Survivor上，避免碎片问题。如下图所示：

 

Minor GC和Full GC的区别以及触发条件：

Minor GC:

    对于复制算法来说，当年轻代Eden区域满的时候会触发一次Minor GC，将Eden和From Survivor的对象复制到另外一块To Survivor上。

    注意：如果某个对象存活的时间超过一定Minor gc次数会直接进入老年代，不在分配到To Survivor上(默认15次，对应虚拟机参数 -XX:+MaxTenuringThreshold)。

 

Full GC:

用于清理整个堆空间。它的触发条件主要有以下几种：

1. 显式调用System.gc方法(建议JVM触发)。
2. 方法区空间不足(JDK8及之后不会有这种情况了，详见下文)
3. 老年代空间不足，引起Full GC。这种情况比较复杂，有以下几种：

3.1 大对象直接进入老年代引起，由-XX:PretenureSizeThreshold参数定义

3.2 Minor GC时，经历过多次Minor GC仍存在的对象进入老年代。上面提过，由-XX:MaxTenuringThreashold参数定义

3.3 Minor GC时，动态对象年龄判定机制会将对象提前转移老年代。年龄从小到大进行累加，当加入某个年龄段后，累加和超过survivor区域 * -XX:TargetSurvivorRatio的时候，从这个年龄段往上的年龄的对象进入老年代

3.4 Minor GC时，Eden和From Space区向To Space区复制时，大于To Space区可用内存，会直接把对象转移到老年代

 

JVM的空间分配担保机制可能会触发Full GC：

在进行Minor GC之前，JVM的空间担保分配机制可能会触发3.2、3.3和3.4发生，即触发一次Full GC。

空间担保分配是指在发生Minor GC之前，虚拟机会检查老年代最大可用的连续空间是否大于新生代所有对象的总空间。

如果大于，则此次Minor GC是安全的。

如果小于，则虚拟机会查看HandlePromotionFailure设置值是否允许担保失败。如果HandlePromotionFailure=true，那么会继续检查老年代最大可用连续空间是否大于历次晋升到老年代的对象的平均大小，如果大于，则尝试进行一次Minor GC，但这次Minor GC依然是有风险的，失败后会重新发起一次Full gc；如果小于或者HandlePromotionFailure=false，则改为直接进行一次Full GC。

所有才会说一次Full GC很有可能是由一次Minor GC触发的。

 

PS:JDK8中HotSpot为什么要取消永久代

    JDK8取消了永久代，新增了一个叫元空间(Metaspace)的区域，对应的还是JVM规范中的方法区(主要存放一些class和元数据的信息)。区别在于元空间使用的并不是JVM中的内存，而是使用本地内存。

    而这么做的原因大致有以下几点：

       1、字符串存在永久代中，容易出现性能问题和内存溢出。

　　2、类及方法的信息等比较难确定其大小，因此对于永久代的大小指定比较困难，太小容易出现永久代溢出，太大则容易导致老年代溢出。

　　3、永久代会为 GC 带来不必要的复杂度，并且回收效率偏低。

　　4、Oracle 可能会将HotSpot 与 JRockit 合二为一。

 

补充下JDK8内存模型图：

 

 

 

 

参考：

 

https://blog.csdn.net/antony9118/article/details/51425581(两个Survivor的意义)

https://zhidao.baidu.com/question/1111800566588999699.html(Full GC什么时候触发)

https://blog.csdn.net/l1394049664/article/details/81486470#%E4%BA%94%E3%80%81java8%E5%86%85%E5%AD%98%E6%A8%A1%E5%9E%8B%E5%9B%BE(JDK8内存模型图)

https://blog.csdn.net/quinnnorris/article/details/75040538(可达性分析算法解析)

https://segmentfault.com/a/1190000007726689(卡表是什么)