fullgc（你必须要知道FullGC是什么）

本文共3198字，是本人前几天面试被提问到的一个问题，将在该文中阐述关于Java垃圾回收——Full GC的相关知识，包括定义、触发条件、具体过程。

前几天面试的时候，面试官在最后问了我一个有关Full GC的垃圾回收问题，希望我说明下该GC的定义、以及是如何触发的问题，有感便记下这篇文章。

垃圾回收的定义

首先我们要知道GC这个概念，即就是我们常说的Java垃圾回收机制，Java通过可达性分析一个对象的引用是否存在，当不存在的时候，将回收堆中的对象。

目前主流的JVM，也就是HotSpot，采用的是分代收集算法。分代的含义涉及到Java的运行时数据区域，在下面几个环节我们来简单描述下Java的内存结构、FullGC的触发以及分代收集算法是对应的哪些内存区域。

垃圾回收相关基础知识

一般而言，GC主要是针对运行的数据区的。作为程序员要关注的区域主要有5块，分别是方法区(Method Area)，Java栈(Java stack)，本地方法栈(Native Method Stack)，堆(Heap)，程序计数器(Program Counter Register)。实际jvm在管理内存的时候，比这个分的更细致，只不过做应用程序开发，我们只需要关注这5块就可以了。

可以关注到，其中有一个区域叫做“堆”，也就是Heap了，它是Jvm管理的内存中最大的一块。程序的主要数据也都是存放在堆内存中的，也就是说程序所创建的对象基本上都在该区域进行内存分配，这一块区域被所有的线程所共享，通常出现线程安全问题的一般都是这个区域的数据出现的问题。通常我们所说的gc主要是针对java heap这块区域的。下面来了解一下heap区。

可见，Heap区在设计上是分代设计的，其划分为了Eden、Survivor 和 Tenured/Old ，其中Eden区、Survivor（存活）属于年轻代，Tenured/Old区属于老年代或者持久代。

一般我们将年轻代发生的GC称为Minor GC，对老年代进行GC称为Major GC。

而本文所要阐述的FullGC是对整个堆来说的，在最近几个版本的JDK里默认包括了对永生带即方法区的回收（JDK8中无永生带了），出现Full GC的时候经常伴随至少一次的Minor GC,但非绝对的。Major GC的速度一般会比Minor GC慢10倍以上。

到这里，可能会有些人对heap分区的意义不太理解，我们在这里就简单介绍下年轻代和老年代是如何进行工作的，我们需要知道关于JVM的堆区对象分配的一般规则：

1. 对象优先在Eden区分配

2. 大对象直接进入老年代（-XX:PretenureSizeThreshold=3145728 这个参数来定义多大的对象直接进入老年代）

3. 长期存活的对象将进入老年代(在JDK8中测试，-XX:MaxTenuringThreshold=1的阀值设定根本没用)

4. 动态对象年龄判定（虚拟机并不会永远地要求对象的年龄都必须达到MaxTenuringThreshold才能晋升老年代，如果Survivor空间中相同年龄的所有对象的大小总和大于Survivor的一半，年龄大于或等于该年龄的对象就可以直接进入老年代）

5. 空间分配担保

6. 只要老年代的连续空间大于（新生代所有对象的总大小或者历次晋升的平均大小）就会进行minor GC，否则会进行full GC。

FullGC的触发条件

在了解了关于GC的一些相关知识后，我们需要知道FullGC的触发条件（这个是主要提问到点）。

上个环节我们知道了，FullGC是针对整个Heap区而言的，它将在以下几种情况被触发：

在程序中调用了System.gc()方法。此方法的调用是建议JVM进行Full GC,虽然只是建议而非一定，但很多情况下它会触发 Full GC,从而增加Full GC的频率，也即增加了间歇性停顿的次数。强烈影响系建议能不使用此方法就别使用，让虚拟机自己去管理它的内存，可通过通过-XX:+ DisableExplicitGC来禁止RMI（Java远程方法调用）调用System.gc。老年代空间不足。老年代空间只有在新生代对象转入及创建为大对象、大数组时才会出现不足的现象，当执行Full GC后空间仍然不足，则抛出如下错误【java.lang.OutOfMemoryError: Java heap space】，而为避免以上两种状况引起的Full GC，调优时应尽量做到让对象在Minor GC阶段被回收、让对象在新生代多存活一段时间及不要创建过大的对象及数组。Permanet Generation空间满了。也就是以前所说的方法区，Permanet Generation中存放的为一些class的信息等，当系统中要加载的类、反射的类和调用的方法较多时，Permanet Generation可能会被占满，在未配置为采用CMS GC的情况下会执行Full GC。如果经过Full GC仍然回收不了，那么JVM会抛出错误信息：java.lang.OutOfMemoryError: PermGen space 。为避免Perm Gen占满造成Full GC现象，可采用的方法为增大Perm Gen空间或转为使用CMS GC。通过Minor GC后进入老年代的平均大小大于老年代的可用内存。如果发现统计数据说之前Minor GC的平均晋升大小比目前old gen剩余的空间大，则不会触发Minor GC而是转为触发full GC。由Eden区、From Space区向To Space区复制时，对象大小大于To Space可用内存，则把该对象转存到老年代，且老年代的可用内存小于该对象大小。分配很大的对象。所谓大对象，是指需要大量连续内存空间的java对象，例如很长的数组，此种对象会直接进入老年代，而老年代虽然有很大的剩余空间，但是无法找到足够大的连续空间来分配给当前对象，此种情况就会触发JVM进行Full GC。为了解决这个问题，CMS垃圾收集器提供了一个可配置的参数，即-XX:+UseCMSCompactAtFullCollection开关参数，用于在“享受”完Full GC服务之后额外免费赠送一个碎片整理的过程，内存整理的过程无法并发的，空间碎片问题没有了，但停顿时间不得不变长了，JVM设计者们还提供了另外一个参数 -XX:CMSFullGCsBeforeCompaction，这个参数用于设置在执行多少次不压缩的Full GC后，跟着来一次带压缩的。

常见的垃圾回收器——回收过程

垃圾回收器并不是本文的主题，但还是想简单列举一下：

Serial收集器

ParNew收集器

Parallel Scavenge收集器

CMS(Concurrent Mark Sweep)收集器

G1(Garbage First)收集器(从JDK1.7 Update 14之后的HotSpot虚拟机正式提供了商用的G1收集器)

不知道各位还好不好奇上上个环节说到的分代收集算法。

大致我们也能猜到，其实就是针对年轻代和老年代，JVM将使用不同的垃圾收集算法进行收集，达到高效的垃圾回收。

年轻代采用的是标记-复制算法，将需要回收的对象标记，将不需要的对象移动到Survivor空间，然后将标记对象回收，该算法可以实现对大多数会失效的对象进行回收，对少部分不需要回收的对象进行转移，保证eden区拥有连续的内存空间，而且复制的效率高。

因为在年轻代不需要回收的对象一般是很少的，每次垃圾收集时都有大批对象死去，只有少量存活，选用复制算法，只需要付出少量存活对象的复制成本就可以完成收集。

老年代采用的是标记-整理算法，将需要回收的对象标记，将不需要的对象进行移动整理，使不需要回收的对象占用连续的内存空间，再清除回收对象，保证老年代拥有连续的内存空间，而且整理效率高。

因为在老年代需要回收的对象一般是很少的，其存活率较高、没有额外空间对它进行分配担保。