Java JVM GC详解

GC

Gc(Garbage Collection)垃圾回收,为了回收堆内存中不再使用的对象，释放资源,当对象永久地失去引用后，系统会在合适的时候回收它所占的内存。

分区

在jvm规范中,将线程共享的内存区域分为方法区和Java堆
分区目的:
提高GC效率和内存空间使用效率
方法区
作用:
存储已被虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码等数据。
存储运行时常量
实现:
jdk1.7:永久代jdk1.8:元空间,区别是元空间并不在虚拟机中，而是使用本地内存。因此，默认情况下，元空间的大小仅受本地内存限制
Java堆:
存放类实例
分为:
Eden,Survivor,Tenured3部分,其中Eden和Survivor组成新生代部分,Tenured为老年代

Survivor又分为相等的两部分,在运行时,会使用Eden和一部分Survivor,被使用的这部分Survivor叫做FromSpace,未使用的叫做ToSpace.Eden和FromSpace和ToSpace的比例是8:1:1,共占Java堆的1/3.

GC算法

标记清除算法(Mark-Sweep)

最基础的垃圾回收算法，分为两个阶段，标注和清除。标记阶段标记出所有需要回收的对象，清除阶段回收被标记的对象所占用的空间。如图从图中我们就可以发现，该算法最大的问题是内存碎片化严重，后续可能发生大对象不能找到可利用空间的问题。

复制算法(copying)

为了解决Mark-Sweep算法内存碎片化的缺陷而被提出的算法。按内存容量将内存划分为等大小的两块。每次只使用其中一块，当这一块内存满后将尚存活的对象复制到另一块上去，把已使用的内存清掉，如图：

这种算法虽然实现简单，内存效率高，不易产生碎片，但是最大的问题是可用内存被压缩到了原本的一半。且存活对象增多的话，Copying算法的效率会大大降低。

标记整理算法(Mark-Compact)

结合了以上两个算法，为了避免缺陷而提出。标记阶段和Mark-Sweep算法相同，标记后不是清理对象，而是将存活对象移向内存的一端。然后清除端边界外的对象。如图：

因为每个区域的对象要被GC的内容数量不同,比如新生代可能每次有大量的对象要被回收,儿老年代只有1,2个要被回收,所以用在不同的分区使用不同的算法来提高GC效率和空间使用率.

新生代与复制算法,MinorGC

目前大部分JVM的GC对于新生代都采取Copying算法，因为新生代中每次垃圾回收都要回收大部分对象，即要复制的操作比较少，但通常并不是按照1：1来划分新生代。一般将新生代划分为一块较大的Eden空间和两个较小的Survivor空间(FromSpace,ToSpace)，每次使用Eden空间和其中的一块Survivor空间，当进行回收时，将该两块空间中还存活的对象复制到另一块Survivor空间中。
然后这块ToSpace就是下次的FromSpace,而FromSpace就是下次的ToSpace,
这也是为什么新生代按照8:1:1划分的原因,为了提高空间使用率,如果按照上图5:5划分,会导致空间浪费
在新生代进行的GC叫做MinorGC,每次MinorGC存活的对象会年龄+1,当年龄大于15时会被存在老年代,这个年龄可以通过参数手动设置.

老年代与标记整理算法,MajorGC

而老年代因为每次只回收少量对象，因而采用Mark-Compact算法。
MajorGC会对老年代进行回收,这里有点问题,很多博客也没有说明白,我自己理解为MajorGC会对老年代进行垃圾回收,而FullGC会对全局进行垃圾回收,应该包括永久代(元空间).

FullGC

对新生代,老年代,永久代都进行垃圾回收,除直接调用System.gc外，触发FullGC执行的情况有如下四种:
1.老年代空间不足
老年代空间只有在新生代对象转入及创建为大对象、大数组时才会出现不足的现象，当执行FullGC后空间仍然不足，则抛出如下错误：java.lang.OutOfMemoryError:Javaheapspace为避免以上两种状况引起的FullGC，调优时应尽量做到让对象在MinorGC阶段被回收、让对象在新生代多存活一段时间及不要创建过大的对象及数组。

2.永久代(PermanetGeneration)空间满
PermanetGeneration中存放的为一些class的信息等，当系统中要加载的类、反射的类和调用的方法较多时，PermanetGeneration可能会被占满，在未配置为采用CMSGC的情况下会执行FullGC。如果经过FullGC仍然回收不了，那么JVM会抛出如下错误信息：java.lang.OutOfMemoryError:PermGenspace为避免PermGen占满造成FullGC现象，可采用的方法为增大PermGen空间或转为使用CMSGC。

3.CMSGC时出现promotionfailed和concurrentmodefailure
对于采用CMS进行老年代GC的程序而言，尤其要注意GC日志中是否有promotionfailed和concurrentmodefailure两种状况，当这两种状况出现时可能会触发FullGC。promotionfailed是在进行MinorGC时，survivorspace放不下、对象只能放入老年代，而此时老年代也放不下造成的；concurrentmodefailure是在执行CMSGC的过程中同时有对象要放入老年代，而此时老年代空间不足造成的。应对措施为：增大survivorspace、老年代空间或调低触发并发GC的比率，但在JDK5.0+、6.0+的版本中有可能会由于JDK的bug29导致CMS在remark完毕后很久才触发sweeping动作。对于这种状况，可通过设置-XX:CMSMaxAbortablePrecleanTime=5(单位为ms)来避免。

4.统计得到的MinorGC晋升到老年代的平均大小大于老年代的剩余空间
这是一个较为复杂的触发情况，Hotspot为了避免由于新生代对象晋升到老年代导致老年代空间不足的现象，在进行MinorGC时，做了一个判断，如果之前统计所得到的MinorGC晋升到老年代的平均大小大于老年代的剩余空间，那么就直接触发FullGC。例如程序第一次触发MinorGC后，有6MB的对象晋升到老年代，那么当下一次MinorGC发生时，首先检查老年代的剩余空间是否大于6MB，如果小于6MB，则执行FullGC。当新生代采用PSGC时，方式稍有不同，PSGC是在MinorGC后也会检查，例如上面的例子中第一次MinorGC后，PSGC会检查此时老年代的剩余空间是否大于6MB，如小于，则触发对老年代的回收。除了以上4种状况外，对于使用RMI来进行RPC或管理的SunJDK应用而言，默认情况下会一小时执行一次FullGC。可通过在启动时通过-java-Dsun.rmi.dgc.client.gcInterval=3600000来设置FullGC执行的间隔时间或通过-XX:+DisableExplicitGC来禁止RMI调用System.gc