最全的GC讲解

GC全称Garbage Collection，译为垃圾收集，它并不是Java语言特有计数，事实上，GC的历史比Java久远，1960年诞生于MIT的Lisp是第一门真正使用动态分配和垃圾收集技术的语言。

GC需要完成的3件事情：

• 哪些内存需要回收？
• 什么时候回收？
• 如何回收？

下面从这三个问题来讲解Java中的GC。

1.哪些内存需要回收？

前面讲到JVM的内存架构图，我们这里再来看下：

程序计数器、虚拟机栈、本地方法栈3个区域随线程而生，随线程而灭，方法结束或者线程结束，内存自然就跟着回收了，所以这三个区域不需要考虑GC。

Java堆和方法区则不一样，一个接口中的多个实现类需要的内存不一样，一个方法中的多个分支需要的内存可能不一样，我们只有在程序运行期间时才能知道知道会创建哪些对象，这部分内存的分配和回收都时动态的，垃圾回收器所关注的就是这部分内存。

2.什么时候回收？

Java中的垃圾简单地说，就是不再被引用的对象！

Person person=null;

所以当这个对象不再被引用时，就需要被回收！常见的判断对象是否存活的方法有引用计数法、可达性算法、引用。

引用计数法

给对象中添加一个引用计数器，每当对象被引用一次，计数器就+1，如果引用失效，则计数器-1，如果为0，则GC可以清理；

这种算法实现简单，判定效率高，在大部分情况下它都是一个不错的算法，，但是JVM不采用这种，原因是很难解决对象间相互引用的问题。

下面来看一段代码：

public class ReferenceCountingGC {
    public Object instance=null;

    private static final int _1MB=1024*1024;

    /**
     * 这个成员属性的唯一意义就是占点内存，以便能在GC日志中看清楚是否被回收过
     */
    private byte[] bigSize=new byte[2*_1MB];


    public static void main(String[] args) {
        ReferenceCountingGC objA=new ReferenceCountingGC();
        ReferenceCountingGC objB=new ReferenceCountingGC();
        objA.instance=objB;
        objB.instance=objA;

        objA=null;
        objB=null;

        //假设在这行发生GC，objA和objB是否能被回收？
        System.gc();
    }
}

上面代码中对象objA和对象objB都有字段instance,赋值令objA.instance=objB及objB.instance=objA,除此之外，这两个对象再无任何引用，但是它们因为互相引用着对方，导致它们的引用计数器都不为0，于是引用计数算法无法通知GC收集器回收它们。

我们通过-XX:+PrintGCDetails参数打印一下GC日志

我们从日志中可以看到GC回收前堆使用的大小为7426k,GC之后使用大小为848k（日志的数字含义后面会讲到），我们可以从侧面看出JVM不是通过引用计数算法来判断对象是否存活的。

缺点：

• 计数器维护麻烦
• 循环引用无法处理！

可达性算法

可达性算法就是通过一系列的称为“GC　Roots”的对象作为起始点，从这些节点开始向下搜索，搜索所走过的路径称为引用链（Reference Chain),当一个对象到GC Roots没有任何引用链相连时，则证明此对象是不可用的。

在Java语言中，可作为GC Roots的对象包括下面几种：

• 虚拟机栈（栈帧中的本地变量表）中引用的对象
• 方法区中类静态属性引用的对象。
• 方法区中常量引用的对象
• 本地方法栈中JNI（即一般说的Native方法）引用的对象

引用

强引用

类似“Object obj=new Object"这类的引用，只要引用还存在，垃圾收集器永远不会收掉被引用的对象

软引用

软引用是用来描述一些还有用但并非必须的对象。对于软引用关联着的对象，在系统将要发生内存溢出异常之前，将会把这些对象列进回收范围之中进行第二次回收。如果这次回收还没有足够的内存，才会抛出内存溢出异常。

弱引用

弱引用也是用来描述非必须对象的，但是它的强度比软引用更弱一些，被弱引用关联的对象只能生存到下一次垃圾收集发生之前。当垃圾收集器工作时，无论当前内存是否足够，都会回收掉只被弱引用关联的对象。

虚引用

虚引用也称为幽灵引用或者幻影引用，它是最弱的一种引用关系。一个对象是否有虚引用的存在，完全不会对其生存时间构成影响，也无法通过虚引用来获得一个对象实例。

3.如何回收？

常见的垃圾收集算法有复制算法、标记清除算法、标记整理算法

复制算法
复制算法就是将可用内存按容量大小划分为大小相等的两块，每次只使用其中的一块。当这一块的内存用万里，就将还存活的对象复制到另一块上面，然后再把已使用过的内存空间一次清理掉。

1、一般普通GC之后，差不多Eden几乎都是空的了！

2、每次存活的对象，都会被从from区和Eden区等复制到to区，from和to会发生一次交换；记住一个点，谁空谁是to,每当幸存一次，就会导致这个对象的年龄+1；如果这个年龄值大于15（默认值），就会进入养老区。

优点：没有标记和清除的过程，效率高，没有内存碎片

缺点：需要浪费双倍的空间

标记-清除算法
如同它的名字一样，算法分为”标记“和”清除“两个阶段：首先标记出所有需要回收的对象，在标记完成后统一回收所有被标记的对象。

优点：不需要额外的空间！

缺点：两次扫描，耗时较为严重，会产生内存碎片，不连续！

标记-整理算法
标记-整理算法是标记-清除算法的一个升级版，弥补了它的不足。标记-整理算法首先会和标记-清除算法一样，将可回收的对象标记出来，然后清除掉，但是最后还将或者的对象向一侧进行移动！

优点：没有内存碎片！

缺点：是耗时比较严重！

分代收集算法
分代收集算法：不同的区域使用不同的算法！

年轻代： 相对老年区，对象存活率低！Eden区，对象存活率极低！统计：99%对象都会在使用一次之后，引用失效！推荐使用复制算法

老年代： 区域比较搭，对象存活率较高！推荐使用：标记清除压缩！

永久代： 不会产生GC

Java种GC主要分为两大类：

普通GC：指针对新生代，是轻量级的GC，也叫Minor GC。

全局GC：主要是针对老年代，偶尔伴随新生代，是重量级的GC，也叫Full GC或者Major GC

谈完GC回收算法之后，我们来看下HotSpot虚拟机所包含的收集器：

图中展示了7种作用于不同分代的收集器，如果两个收集器之间存在连线，则说明它们可以搭配使用。虚拟机所处的区域则表示它是属于新生代还是老年代收集器。

新生代收集器：Serial、ParNew、Parallel Scavenge

老年代收集器：CMS、Serial Old、Parallel Old

整堆收集器： G1

几个相关概念：
并行收集：指多条垃圾收集线程并行工作，但此时用户线程仍处于等待态。

并发收集：指用户线程与垃圾收集线程同时工作（不一定是并行的可能会交替执行）。用户程序在继续运行，而垃圾收集程序运行在另一个CPU上。

吞吐量：即CPU用于运行用户代码的时间与CPU总消耗时间的比值（吞吐量 = 运行用户代码时间 / ( 运行用户代码时间 + 垃圾收集时间 )）。例如：虚拟机共运行100分钟，垃圾收集器花掉1分钟，那么吞吐量就是99%

一：Serial 收集器

Serial收集器是最基本的、发展历史最悠久的收集器。

特点：单线程、简单高效（与其他收集器的单线程相比），对于限定单个CPU的环境来说，Serial收集器由于没有线程交互的开销，专心做垃圾收集自然可以获得最高的单线程手机效率。收集器进行垃圾回收时，必须暂停其他所有的工作线程，直到它结束（Stop The World）。

应用场景：适用于Client模式下的虚拟机。

Serial / Serial Old收集器运行示意图

二：ParNew收集器

ParNew收集器其实就是Serial收集器的多线程版本。

除了使用多线程外其余行为均和Serial收集器一模一样（参数控制、收集算法、Stop The World、对象分配规则、回收策略等）。

特点：多线程、ParNew收集器默认开启的收集线程数与CPU的数量相同，在CPU非常多的环境中，可以使用-XX:ParallelGCThreads参数来限制垃圾收集的线程数。和Serial收集器一样存在Stop The World问题

应用场景：ParNew收集器是许多运行在Server模式下的虚拟机中首选的新生代收集器，因为它是除了Serial收集器外，唯一一个能与CMS收集器配合工作的。

ParNew/Serial Old组合收集器运行示意图如下：

三：Parallel Scavenge 收集器

与吞吐量关系密切，故也称为吞吐量优先收集器。

特点：属于新生代收集器也是采用复制算法的收集器，又是并行的多线程收集器（与ParNew收集器类似）。

该收集器的目标是达到一个可控制的吞吐量。还有一个值得关注的点是：GC自适应调节策略（与ParNew收集器最重要的一个区别）

GC自适应调节策略：Parallel Scavenge收集器可设置-XX:+UseAdptiveSizePolicy参数。当开关打开时不需要手动指定新生代的大小（-Xmn）、Eden与Survivor区的比例（-XX:SurvivorRation）、晋升老年代的对象年龄（-XX:PretenureSizeThreshold）等，虚拟机会根据系统的运行状况收集性能监控信息，动态设置这些参数以提供最优的停顿时间和最高的吞吐量，这种调节方式称为GC的自适应调节策略。

Parallel Scavenge收集器使用两个参数控制吞吐量：

XX:MaxGCPauseMillis 控制最大的垃圾收集停顿时间

XX:GCRatio 直接设置吞吐量的大小。

四：Serial Old 收集器

Serial Old是Serial收集器的老年代版本。

特点：同样是单线程收集器，采用标记-整理算法。

应用场景：主要也是使用在Client模式下的虚拟机中。也可在Server模式下使用。

在JDK1.5以及以前的版本中与Parallel Scavenge收集器搭配使用。
作为CMS收集器的后备方案，在并发收集Concurent Mode Failure时使用。
Serial / Serial Old收集器工作过程图（Serial收集器图示相同）：

五：Parallel Old 收集器

是Parallel Scavenge收集器的老年代版本。

特点：多线程，采用标记-整理算法。

应用场景：注重高吞吐量以及CPU资源敏感的场合，都可以优先考虑Parallel Scavenge+Parallel Old 收集器。

Parallel Scavenge/Parallel Old收集器工作过程图：

六：CMS收集器

一种以获取最短回收停顿时间为目标的收集器。

特点：基于标记-清除算法实现。并发收集、低停顿。

应用场景：适用于注重服务的响应速度，希望系统停顿时间最短，给用户带来更好的体验等场景下。如web程序、b/s服务。

CMS收集器的运行过程分为下列4步：

初始标记：标记GC Roots能直接到的对象。速度很快但是仍存在Stop The World问题。

并发标记：进行GC Roots Tracing 的过程，找出存活对象且用户线程可并发执行。

重新标记：为了修正并发标记期间因用户程序继续运行而导致标记产生变动的那一部分对象的标记记录。仍然存在Stop The World问题。

并发清除：对标记的对象进行清除回收。

CMS收集器的内存回收过程是与用户线程一起并发执行的。

CMS收集器的工作过程图：

CMS收集器的缺点：

对CPU资源非常敏感。无法处理浮动垃圾，可能出现Concurrent Model Failure失败而导致另一次Full GC的产生。因为采用标记-清除算法所以会存在空间碎片的问题，导致大对象无法分配空间，不得不提前触发一次Full GC。

七：G1收集器

一款面向服务端应用的垃圾收集器。

特点如下：

并行与并发：G1能充分利用多CPU、多核环境下的硬件优势，使用多个CPU来缩短Stop-The-World停顿时间。部分收集器原本需要停顿Java线程来执行GC动作，G1收集器仍然可以通过并发的方式让Java程序继续运行。

分代收集：G1能够独自管理整个Java堆，并且采用不同的方式去处理新创建的对象和已经存活了一段时间、熬过多次GC的旧对象以获取更好的收集效果。

空间整合：G1运作期间不会产生空间碎片，收集后能提供规整的可用内存。

可预测的停顿：G1除了追求低停顿外，还能建立可预测的停顿时间模型。能让使用者明确指定在一个长度为M毫秒的时间段内，消耗在垃圾收集上的时间不得超过N毫秒。

G1为什么能建立可预测的停顿时间模型？

因为它有计划的避免在整个Java堆中进行全区域的垃圾收集。G1跟踪各个Region里面的垃圾堆积的大小，在后台维护一个优先列表，每次根据允许的收集时间，优先回收价值最大的Region。这样就保证了在有限的时间内可以获取尽可能高的收集效率。

G1与其他收集器的区别：

其他收集器的工作范围是整个新生代或者老年代、G1收集器的工作范围是整个Java堆。在使用G1收集器时，它将整个Java堆划分为多个大小相等的独立区域（Region）。虽然也保留了新生代、老年代的概念，但新生代和老年代不再是相互隔离的，他们都是一部分Region（不需要连续）的集合。

G1收集器存在的问题：

Region不可能是孤立的，分配在Region中的对象可以与Java堆中的任意对象发生引用关系。在采用可达性分析算法来判断对象是否存活时，得扫描整个Java堆才能保证准确性。其他收集器也存在这种问题（G1更加突出而已）。会导致Minor GC效率下降。

G1收集器是如何解决上述问题的？

采用Remembered Set来避免整堆扫描。G1中每个Region都有一个与之对应的Remembered Set，虚拟机发现程序在对Reference类型进行写操作时，会产生一个Write Barrier暂时中断写操作，检查Reference引用对象是否处于多个Region中（即检查老年代中是否引用了新生代中的对象），如果是，便通过CardTable把相关引用信息记录到被引用对象所属的Region的Remembered Set中。当进行内存回收时，在GC根节点的枚举范围中加入Remembered Set即可保证不对全堆进行扫描也不会有遗漏。

如果不计算维护 Remembered Set 的操作，G1收集器大致可分为如下步骤：

初始标记：仅标记GC Roots能直接到的对象，并且修改TAMS（Next Top at Mark Start）的值，让下一阶段用户程序并发运行时，能在正确可用的Region中创建新对象。（需要线程停顿，但耗时很短。）

并发标记：从GC Roots开始对堆中对象进行可达性分析，找出存活对象。（耗时较长，但可与用户程序并发执行）

最终标记: 为了修正在并发标记期间因用户程序执行而导致标记产生变化的那一部分标记记录。且对象的变化记录在线程Remembered Set Logs里面，把Remembered Set Logs里面的数据合并到Remembered Set中。（需要线程停顿，但可并行执行。）

筛选回收: 对各个Region的回收价值和成本进行排序，根据用户所期望的GC停顿时间来制定回收计划。（可并发执行）

G1收集器运行示意图：

参考：
https://www.cnblogs.com/chenpt/p/9803298.html
和 《深入理解Java虚拟机》