（转）JVM垃圾回收机制

一、技术背景

　　GC的历史比Java久远，早在1960年Lisp这门语言中就使用了内存动态分配和垃圾回收技术

二、那些内存需要回收？

　　JVM的内存结构包括五大区域：程序计数器、虚拟机栈、本地方法栈、堆区、方法区。其中程序计数器、虚拟机栈、本地方法栈3个区域岁线程生灭，因此这几个区域的内存分配和回收都具备确定性，就不需要过多考虑回收的问题，因为方法借宿或者线程结束时，内存自然就跟着回收了。而Java堆和方法区不一样，这部分内存的分配和回收是动态的，正是垃圾收集器所需要关注的。

　　垃圾收集器在对堆区和方法区进行回收前，首先要确定这些区域的对象哪些可以被回收，哪些暂时不能被回收，这就要用到判断对象是否存活的算法！

2.1 引用计数算法

2.1.1 算法分析

　　引用计数是垃圾收集器中的早期策略。在这种方法中，堆中每个对象实例都有一个引用计数。当一个对象被创建时，就将该对象实例分配给一个变量，该变量计数设置为1.当任何其它变量被复制为这个对象的引用时，计数加1（a=b，则b引用的对象实例的计数器+1），但当一个对象实例的某个引用超过了生命周期或者被设置为一个新值时，对象实例的引用计数器减1。任何引用计数器为0的对象实例可以被当做垃圾收集。当一个对象实例被垃圾收集时，它引用的任何对象实例的引用计数器减1。

2.1.2 优缺点

优点：引用计数收集器可以很快的执行，交织在程序运行中。对程序需要不被长时间打断的实时环境比较有利

缺点：无法检测出循环引用。如父对象有一个对子对象的引用，子对象反过来引用父对象。这样，他们的引用计数永远不可能为0。

public class ReferenceFindTest {
    public static void main(String[] args) {
        MyObject object1 = new MyObject();
        MyObject object2 = new MyObject();

        object1.object = object2;
        object2.object = object1;

        object1 = null;
        object2 = null;
    }
}

　　这段代码是用来验证循环引用，最后两句代码将object1和object2赋值为null，也就是说object1和object2指向的对象已经不可能再被访问，但是由于它们互相引用对方，导致它们的引用计数器都不为0，那么垃圾收集器就永远不会回收它们

2.2 可达性分析算法

　　可达性分析算法是从离散数学中的图论引入的，程序把所有的引用关系看做一张图，从一个节点GC Root开始，寻找对应的引用节点，找到这个节点以后，继续寻找这个节点的引用节点，当所有引用节点寻找完毕之后，剩余的节点则被认为是没有被引用到的节点，即无用的节点，无用的节点将会被判定为可回收的对象。

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

　　a）虚拟机栈中引用的对象（栈帧中的本地变量表）；

　　b）方法区中类静态属性引用的对象；

　　c）方法区中常量引用的对象；

　　d）本地方法栈中JNI（Native方法）引用的对象。

2.3 Java中的引用

　　无论是通过引用计数算法判断对象的引用数量，还是通过可达性分析算法判断对象的引用链是否可达，判定对象是否存活都与“引用”有关。在Java语言中，将引用又分为强引用、软引用、弱引用、虚引用四种，这四种引用强度依次逐渐减弱。

• 强引用

　　在程序代码中普遍存在的，类似Object obj = new Object()这类引用，只要强引用还存在，垃圾收集器永远不会回收掉被引用的对象。

• 软引用

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

• 弱引用

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

• 虚引用

　　也叫幽灵引用或幻影引用，是最弱的一种引用关系。一个对象是否有虚引用的存在，完全不会对其生存时间构成影响，也无法通过虚引用来取得一个对象实例。它的作用是能在这个对象被收集时收到一个系统通知。

　　通过对这四个概念的解释，说明无论引用计数算法还是可达性分析算法都是基于强引用而言的。

2.4 对象被回收前的最后一次挣扎

　　即使在可达性分析算法中不可达的对象，也并非是“非死不可”，这时候它们暂时处于“缓刑”阶段，要真正宣告一个对象死亡，至少需要经历两次标记过程。

　　第一次标记：如果对象在进行可达性分析算法分析后发现没有与GC Roots相连接的引用链，那它将会被第一次标记；

　　第二次标记：第一次标记后接着会进行一次筛选，筛选的条件是此对象是否有必要执行finalize()方法。在finalize()方法中没有重新与引用链建立关联关系的，将会被第二次标记。

　　第二次标记成功的对象将会真的被回收，如果对象在finalize()方法中重新与引用链建立了关联，那么将会逃离本次回收，继续存活。

2.5 方法区如何判断是否需要回收

　　方法区存储内容是否需要回收的判断可就不一样咯。方法区主要回收的内容有：废弃常量和无用的类。对于废弃常量也可通过引用的可达性来判断，但是对于无用的类则需要同时满足下面3个条件：

• 该类所有的实例都已经被回收，也就是Java堆中不存在该类的任何实例；
• 加载该类的ClassLoader已经被回收；
• 该类对应的java.lang.Class对象没有在任何地方被引用，无法在任何地方通过反射访问该类的方法。（类在内存中是占4个字节的）

三、常用的垃圾收集算法

3.1 标记-清除算法

　　标记-清除算法此阿勇从根集合（GC Roots）进行扫描，对存活的对象进行标记，标记完毕后，再扫描整个空间中未被标记的对象，进行回收，如下图所示。标记-清除算法不需要进行对象的移动，只需对不存活的对象进行处理，在存活对象比较多的情况下极为高效，但是由于标记-清除算法直接回收不存活的对象，因此会造成内存碎片。

3.2 复制算法

　　复制算法的提出是为了克服句柄的开销和解决内存碎片的问题。它开始时把堆分成一个对象面和多个空闲面，程序从对象面为对象分配空间，当对象满了，基于copying算法的垃圾收集就从根集合（GC Roots）中扫描存活的对象，并将每个活动对象复制到空闲面（使得活动对象所占的内存之间没有空闲洞），这样空闲面变成了对象面，原来的对象面变成了空闲面，程序会在新的对象面中分配内存。

3.3 标记-整理算法

　　标记-整理算法采用标记-清除算法一样的方式进行对象的标记，但在清除时不同，在回收不存活的对象占用的空间后，会将所有的存活对象往左端空闲空间移动，并更新对应的指针。标记-整理算法是在标记-清除算法的基础上，又进行了对象的移动，因此成本更高，但是却解决了内存碎片的问题。具体流程如下图：

3.4 分代收集算法

　　分代收集算法是目前大部分JVM的垃圾收集器采用的算法。它的核心思想是根据对象存活的生命周期将内存划分为若干个不同的区域。一般情况下将堆区分为老年代（Tenured Generation）和新生代（Young Generation），在堆区之外还有一个代就是永久代（Permanet Generation）。老年代的特点是每次垃圾收集时只有少量对象需要被回收，而新生代的特点是每次垃圾回收时都有大量的对象需要被回收，那么就可以根据不同代的特点采取最适合的收集算法。

3.4.1 年轻代（Young Generation）的回收算法

a）所有新生成的对象首先都是放在年轻代的。年轻代的目标就是尽可能快速的收集掉那些生命周期短的对象；

b）新生代内存按照8:1:1的比例分为一个eden区和亮哥survivor（survivor0，survivor1）区。一个Eden区，亮哥Survivor区（一般而言）。大部分对象在Eden区中生成。回收时先将eden区存活对象复制到一个survivor0区，然后清空eden区，当这个survivor0区也存放满了时，则将eden区和survivor区存活对象复制到另一个survivor1区，然后清空eden和这个survivor0区，此时survivor0区是空的，然后将survivor0区和survivor1区交换，即保持survivor1区为空，如此往复。

c）当survivor1区不足以存放eden和survivor0的存活对象时，就将存活对象直接存放到老年代。若是老年代也满了就会触发一次Full GC，也就是新生代、老年代都进行回收。

d）新生代发生的GC也叫做Minor GC，Minor GC发生频率比较高（不一定等Eden区满了才触发）

3.4.2 老年代（Old Generation）的回收算法

a）在年轻代中经历了N次垃圾回收后仍然存活的对象，就会放到老年代中。因此，可以认为年老代中存放的都是一些生命周期较长的对象。

b）内存比新生代也大很多（大概比例是1:2），当老年代内存满时触发Major GC即Full GC，Full GC发生频率比较低，老年代对象存活时间比较长，存活率比较高

3.4.4 持久代（Permanent Generation）的回收算法

用于存放静态文件，如Java类、方法等。持久代对垃圾回收没有显著影响，但是有些应用可能动态生成或者调用一些class，例如Hibernate等，在这种时候需要设置一个比较大的持久代空间来存放这些运行过程中新增的类。持久代也称方法区，具体参见上文2.5节。

四、常见的垃圾收集器

下图是HotSpot虚拟机包含的所有收集器：

1、Serial收集器（复制算法）

新生代单线程收集器，优点简单高效。它在进行垃圾收集时，必须暂停其他所有工作线程（用户线程）。是JVM client模式下默认的新生代收集器。可以通过 -XX:+UseSerialGC 来强制指定

2、Serial Old收集器（标记-整理算法）

老年代单线程收集器，Serial收集器的老年代版本。主要使用在Client模式下的虚拟机。对于Server模式下有两个用途：1、在JDK1.5以及之前的版本中与Parallel Scavenge收集器搭配使用；2.作为CMS收集器的后备预案，在并发收集发生Concurrent Mode Failure时使用。

3、ParNew收集器（并行回收）

新生代收集器，Serial的多线程版本，除了使用多条线程进行垃圾收集外，其余行为与Seria收集器一样，在单CPU工作环境内绝对不会有比Serial收集器有更好的效果。随着CPU数量的增加，它对于GC时系统资源的有效利用还是很有好处的，它默认开启的收集线程数和CPU的数量相同，可以使用 -XX:ParallelGCThreads 参数来限制线程数

4、Parallel Scavenge收集器（复制算法，并行回收）

也是一个新生代收集器，使用复制算法，且是并行多线程收集器。特点是它的关注点与其他收集器不同，CMS等收集器的关注点是尽可能缩短垃圾收集时用户线程的停顿时间，二Parallel Scavenge收集器的目标则是达到一个可控制的吞吐量。吞吐量=程序运行时间/(程序运行时间 + 垃圾收集时间)，虚拟机总共运行了100分钟。垃圾收集花费1分钟，吞吐量就是99%。它的吞吐量一般为99%。Parallel Scavenge提供了两个参数用于精确控制吞吐量，分别是控制最大垃圾收集停顿时间的 -XX:MaxGCPauseMillis 和直接设置吞吐量大小的 -XXGCTimeRatio 参数

收集器还有一个开关： -XX:+UseAdaptiveSizePolicy 值得关注。这个开关打开后，虚拟机会根据当前系统的运行情况收集性能监控信息自动调整新生代的大小（-Xmn）、Eden与Survivor区的比例（-XX：SurvivorRation）、晋升老年代对象大小（-XX：PretenureSizeThreshold）等细节参数。

自适应策略，只需要设置最大堆（-Xmx）,利用最大停顿时间或者吞吐量给虚拟机设置一个优化目标。

此收集器适合后台应用等对交互相应要求不高的场景，是server级别默认采用的GC方式，可用 -XX:+UseParallelGC 来强制指定，用 -XX:ParallelGCThreads=4 来指定线程数

5、Parallel Old收集器（标记-整理算法，并行）

是Parallel Scavenge收集器的老年代版本，使用多线程和“标记-整理”算法。

6、CMS（Concurrent Mark Sweep）收集器（标记-清除算法，并发GC）

是一种以获取最短回收停顿时间为目标的收集器。适合应用在互联网站或者B/S系统的服务器上，这类应用尤其重视服务器的响应速度，希望系统停顿时间最短。高并发、低停顿，追求最短GC回收停顿时间，cpu占用比较高，响应时间快，停顿时间短，多核cpu追求高响应时间的选择。

• Concurrent Mark Sweep 并发标记清除，并发低停顿
• 标记-清除算法
• 并发阶段会降低吞吐量（因为停顿时间减少了，于是GC的频率会变高）
• 老年代收集器（新生代使用ParNew）
• -XX:+UseConcMarkSweepGC   打开这收集器

注：这里的并发指的是与用户线程一起执行。

整个收集过程分为4个步骤：（着重实现了标记的过程）

① 初始标记（CMS initial mark）

根可以直接关联到的对象

速度快

② 并发标记（CMS concurrent mark）（和用户线程一起）

主要标记过程，标记全部对象

③ 重新标记（CMS remark）

由于并发标记时，用户线程依然运行，因此在正式清理前，再做修正

④ 并发清除（CMS）（和用户线程一起）

基于标记结果，直接清理对象

整个过程如下图所示：

其中，初始标记和重新标记时，需要stop the world。

整个过程中耗时最长的是并发标记和并发清除，这两个过程都可以和用户线程一起工作。

CMS收集器的优点：并发收集、低停顿

缺点：

1. CMS收集器对CPU资源非常敏感。在并发阶段，虽然不会导致用户线程停顿，但是会占用CPU资源而导致引用程序变慢，总吞吐量下降。CMS默认启动的回收线程数是：(CPU数量+3) / 4。虚拟机提供了一种称为“增量式并发收集器”的CMS收集器变种，可以在并发标记、清理的时候让GC线程、用户线程交替运行，尽量减少GC线程的独占资源的时间。
2. CMS收集器无法处理浮动垃圾，可能出现“Concurrent Mode Failure“，失败后而导致另一次Full GC的产生。由于CMS并发清理阶段用户线程还在运行，伴随程序的运行自热会有新的垃圾不断产生，这一部分垃圾出现在标记过程之后，CMS无法在本次收集中处理它们，只好留待下一次GC时将其清理掉。这一部分垃圾称为“浮动垃圾”。也是由于在垃圾收集阶段用户线程还需要运行，即需要预留足够的内存空间给用户线程使用，因此CMS收集器不能像其他收集器那样等到老年代几乎完全被填满了再进行收集，需要预留一部分内存空间提供并发收集时的程序运作使用。在默认设置下，CMS收集器在老年代使用了68%的空间时就会被激活，也可以通过参数-XX:CMSInitiatingOccupancyFraction的值来提供触发百分比，以降低内存回收次数提高性能。要是CMS运行期间预留的内存无法满足程序其他线程需要，就会出现“Concurrent Mode Failure”失败，这时候虚拟机将启动后备预案：临时启用Serial Old收集器来重新进行老年代的垃圾收集，这样停顿时间就很长了。所以说参数-XX:CMSInitiatingOccupancyFraction设置的过高将会很容易致“Concurrent Mode Failure”失败，性能反而降低。
3. 碎片化，最后一个缺点，CMS是基于“标记-清除”算法实现的收集器，使用“标记-清除”算法收集后，会产生大量碎片。空间碎片太多时，将会给对象分配带来很多麻烦，比如说大对象，内存空间找不到连续的空间来分配不得不提前触发一次Full GC。为了解决这个问题，CMS收集器提供了一个-XX:UseCMSCompactAtFullCollection开关参数，用于在Full GC之后增加一个碎片整理过程，还可通过-XX:CMSFullGCBeforeCompaction参数设置执行多少次不压缩的Full GC之后，跟着来一次碎片整理过程。

既然标记清除算法会造成内存空间的碎片化，CMS收集器为什么使用标记清除算法而不是使用标记整理算法：

答案：

CMS收集器更加关注停顿，它在做GC的时候是和用户线程一起工作的（并发执行），如果使用标记整理算法的话，那么在清理的时候就会去移动可用对象的内存空间，那么应用程序的线程就很有可能找不到应用对象在哪里。

7、G1收集器（标记-整理）

G1(Garbage First)收集器是JDK1.7提供的一个新收集器，G1收集器基于“标记-整理”算法实现，也就是说不会产生内存碎片。还有一个特点之前的收集器进行收集的范围都是整个新生代或老年代，而G1将整个Java堆(包括新生代，老年代)。

G1收集器的特点：

**并行与并发：**G1利用多CPU、多核环境下的硬件优势，缩小stop-the-world的时间。
**分代收集：**G1不需要其他收集器配合就可以独立管理整个GC堆，但它能够采用不同的方式来处理。
空间整合：整体上是“标记-整理”，局部上是基于“复制”的算法来实现的
可预测的停顿：降低停顿时间，G1建立了可预测的停顿时间模型，能让使用者明确的指定在一个长度M毫秒内的时间片段，消耗在垃圾收集的时间不得超过N毫秒，这已经适实时java（RTSJ）的垃圾收集器的特征了
G1收集的步骤：

　　初始标记
　　并发标记
　　最终标记
　　筛选回收

五、GC是什么时候出发的（面试最常见的问题之一）

由于对象进行了分代处理，因此垃圾回收区域、时间也不一样。GC有两种类型：Scavenge GC和Full GC。

5.1 Scavenge GC

一般情况下，当新对象生成，并且在Eden申请空间失败时，就会触发Scavenge GC，对Eden区域进行GC，清除非存活对象，并且把尚且存活的对象移动到Survivor区。然后整理Survivor的两个区。这种方式的GC是对年轻代的Eden区进行，不会影响到年老代。因为大部分对象都是从Eden区开始的，同时Eden区不会分配的很大，所以Eden区的GC会频繁进行。因而，一般在这里需要使用速度快、效率高的算法，使Eden去能尽快空闲出来。

5.2 Full GC

对整个堆进行整理，包括Young、Tenured和Perm。Full GC因为需要对整个堆进行回收，所以比Scavenge GC要慢，因此应该尽可能减少Full GC的次数。在对JVM调优的过程中，很大一部分工作就是对于Full GC的调节。有如下原因可能导致Full GC：

a) 年老代（Tenured）被写满；

b) 持久代（Perm）被写满；

c) System.gc()被显示调用；

d) 上一次GC之后Heap的各域分配策略动态变化；

原文链接：

　　https://www.cnblogs.com/1024Community/p/honery.html

参考链接：

　　https://blog.csdn.net/qq_27035123/article/details/72857739

　　https://www.cnblogs.com/pony1223/p/9201625.html