深入理解JVM——GC算法与内存分配策略

谁借莪１个温暖的怀抱￠ 2022-04-17 00:27 292阅读 0赞

转载：[https://www.cnblogs.com/smyhvae/p/4744233.html][https_www.cnblogs.com_smyhvae_p_4744233.html]

转载：[https://crowhawk.github.io/2017/08/10/jvm\_2/][https_crowhawk.github.io_2017_08_10_jvm_2]

本文主要内容：

*  GC的概念
 *  GC算法

引用计数法（无法解决循环引用的问题，不被java采纳）

根搜索算法

现代虚拟机中的垃圾搜集算法：

标记-清除

复制算法（新生代）

标记-压缩（老年代）

分代收集

*  Stop-The-World

**一、GC的概念：**

*  GC：Garbage Collection 垃圾收集
 *  1960年 Lisp使用了GC
 *  Java中，**GC的对象是Java堆和方法区**（即永久区）

我们接下来对上面的三句话进行一一的解释：

（1）GC：Garbage Collection 垃圾收集。这里所谓的垃圾指的是**在系统运行过程当中所产生的一些无用的对象，这些对象占据着一定的内存空间，如果长期不被释放，可能导致OOM**。

在C/C++里是由程序猿自己去申请、管理和释放内存空间，因此没有GC的概念。而在Java中，**后台专门有一个专门用于垃圾回收的线程**来进行监控、扫描，自动将一些无用的内存进行释放，这就是垃圾收集的一个基本思想，目的在于防止由程序猿引入的人为的内存泄露。

（2）事实上，GC的历史比Java久远，1960年诞生于MIT的Lisp是第一门真正使用内存动态分配和垃圾收集技术的语言。当Lisp还在胚胎时期时，人们就在思考GC需要完成的3件事情：

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

（3）内存区域中的**程序计数器、虚拟机栈、本地方法栈**这3个区域随着线程而生，线程而灭；**栈中的栈帧**随着方法的进入和退出而有条不紊地执行着出栈和入栈的操作，每个栈帧中分配多少内存基本是**在类结构确定下来时就已知**的。**在这几个区域不需要过多考虑回收的问题，因为方法结束或者线程结束时，内存自然就跟着回收了**。

而**Java堆和方法区**则不同，一个接口中的多个实现类需要的内存可能不同，一个方法中的多个分支需要的内存也可能不一样，我们只有在程序处于运行期间时才能知道会创建哪些对象，**这部分内存的分配和回收都是动态的**，GC关注的也是这部分内存，后面的文章中如果涉及到“内存”分配与回收也仅指着一部分内存。

**二、引用计数算法：（老牌垃圾回收算法。无法处理循环引用，没有被Java采纳）**

**1、引用计数算法的概念：**

给对象中添加一个引用计数器，每当有一个地方引用它时，计数器值就加1；当引用失效时，计数器值就减1；任何时刻计数器为0的对象就是不可能再被使用的。

[![e6217360-0985-46e8-88fd-022f1fc0fba5][]][e6217360-0985-46e8-88fd-022f1fc0fba5 1]

**2、使用者举例：**

引用计数算法的实现简单，判定效率也高，大部分情况下是一个不错的算法。很多地方应用到它。例如：

> 微软公司的COM技术：Computer Object Model
> 
> 使用ActionScript3的FlashPlayer
> 
> Python

但是，主流的java虚拟机并没有选用引用计数算法来管理内存，其中最主要的原因是：**它很难解决对象之间相互循环引用的问题**。

**3、引用计数算法的问题：**

*  引用和去引用伴随加法和减法，影响性能
 *  致命的缺陷：对于**循环引用的对象**无法进行回收

[![1a489e67-e047-408f-a97e-4a141e6ab3b0][]][1a489e67-e047-408f-a97e-4a141e6ab3b0 1]

上面的3个图中，对于最右边的那张图而言：循环引用的计数器都不为0，但是他们对于根对象都已经不可达了，但是无法释放。

**循环引用的代码举例：**

![复制代码][copycode.gif]

1 public class Object {
     2 
     3     Object field = null;
     4     
     5     public static void main(String[] args) {
     6         Thread thread = new Thread(new Runnable() {
     7             public void run() {
     8                 Object objectA = new Object();
     9                 Object objectB = new Object();//位置1
    10                 objectA.field = objectB;
    11                 objectB.field = objectA;//位置2
    12                 //to do something
    13                 objectA = null;
    14                 objectB = null;//位置3
    15             }
    16         });
    17         thread.start();
    18         while (true);
    19     }
    20     
    21 }

![复制代码][copycode.gif]

上方代码看起来有点刻意为之，但其实在实际编程过程当中，是经常出现的，比如两个一对一关系的数据库对象，各自保持着对方的引用。最后一个无限循环只是为了保持JVM不退出，没什么实际意义。

代码解释：

代码中标注了1、2、3三个数字，当位置1的语句执行完以后，两个对象的引用计数全部为1。当位置2的语句执行完以后，两个对象的引用计数就全部变成了2。当位置3的语句执行完以后，也就是将二者全部归为空值以后，二者的引用计数仍然为1。根据引用计数算法的回收规则，引用计数没有归0的时候是不会被回收的。

对于我们现在使用的GC来说，当thread线程运行结束后，会将objectA和objectB全部作为待回收的对象。而**如果我们的GC采用上面所说的引用计数算法，则这两个对象永远不会被回收**，即便我们在使用后显示的将对象归为空值也毫无作用。

**三、根搜索算法：**

**1、根搜索算法的概念：**

由于引用计数算法的缺陷，所以JVM一般会采用一种新的算法，叫做**根搜索算法**。它的处理方式就是，**设立若干种根对象，当任何一个根对象到某一个对象均不可达时，则认为这个对象是可以被回收的**。

[![7ab0f17b-13f7-4886-a24d-3813c2173891][]][7ab0f17b-13f7-4886-a24d-3813c2173891 1]

如上图所示，ObjectD和ObjectE是互相关联的，但是由于GC roots到这两个对象不可达，所以最终D和E还是会被当做GC的对象，上图若是采用引用计数法，则A-E五个对象都不会被回收。

**2、可达性分析：**

我们刚刚提到，设立若干种根对象，当任何一个根对象到某一个对象均不可达时，则认为这个对象是可以被回收的。我们在后面介绍标记-清理算法/标记整理算法时，也会一直强调从根节点开始，对所有可达对象做一次标记，那什么叫做可达呢？这里解释如下：

**可达性分析：**

从根（GC Roots）的对象作为起始点，开始向下搜索，搜索所走过的路径称为“**引用链**”，当一个对象到GC Roots没有任何引用链相连（用图论的概念来讲，就是从GC Roots到这个对象不可达）时，则证明此对象是不可用的。

**3、根（GC Roots）：**

说到GC roots（GC根），在JAVA语言中，可以当做GC roots的对象有以下几种：

> **1、栈（栈帧中的本地变量表）中引用的对象。 **
> 
> **2、方法区中的静态成员。 **
> 
> **3、方法区中的常量引用的对象（全局变量）**
> 
> **4、本地方法栈中JNI（一般说的Native方法）引用的对象。**

注：第一和第四种都是指的方法的本地变量表，第二种表达的意思比较清晰，第三种主要指的是声明为final的常量值。

在根搜索算法的基础上，现代虚拟机的实现当中，**垃圾搜集的算法**主要有三种，分别是**标记-清除算法、复制算法、标记-整理**算法。这三种算法都扩充了根搜索算法，不过它们理解起来还是非常好理解的。

**四、标记-清除算法：**

**1、标记清除算法的概念：**

标记-清除算法是现代垃圾回收算法的思想基础。标记-清除算法将垃圾回收分为两个阶段：标记阶段和清除阶段。一种可行的实现是，在标记阶段，**首先通过根节点，标记所有从根节点开始的可达对象**。因此，未被标记的对象就是未被引用的垃圾对象；然后，在清除阶段，清除所有未被标记的对象。

[![7de44970-2e02-46a1-a5d0-0663b21906c6][]][7de44970-2e02-46a1-a5d0-0663b21906c6 1]

**2、标记-清除算法详解：**

它的做法是当堆中的有效内存空间（available memory）被耗尽的时候，就会停止整个程序（也被成为stop the world），然后进行两项工作，第一项则是标记，第二项则是清除。

*  标记：标记的过程其实就是，遍历所有的GC Roots，然后将所有GC Roots可达的对象标记为存活的对象。
 *  清除：清除的过程将遍历堆中所有的对象，将没有标记的对象全部清除掉。

也就是说，**就是当程序运行期间，若可以使用的内存被耗尽的时候，GC线程就会被触发并将程序暂停，随后将依旧存活的对象标记一遍，最终再将堆中所有没被标记的对象全部清除掉，接下来便让程序恢复运行**。

来看下面这张图：

[![47146934-c3a3-4976-991f-77e84ae008cc][]][47146934-c3a3-4976-991f-77e84ae008cc 1]

上图代表的是程序运行期间所有对象的状态，**它们的标志位全部是0**（也就是未标记，以下默认0就是未标记，1为已标记），假设这会儿**有效内存空间耗尽**了，JVM将会停止应用程序的运行并开启GC线程，然后开始进行标记工作，按照根搜索算法，标记完以后，对象的状态如下图：

[![5cbf57ce-c83a-40d2-b58a-b37d3eee3803][]][5cbf57ce-c83a-40d2-b58a-b37d3eee3803 1]

上图中可以看到，按照根搜索算法，所有从root对象可达的对象就被标记为了存活的对象，此时已经完成了第一阶段标记。接下来，就要执行第二阶段清除了，那么清除完以后，剩下的对象以及对象的状态如下图所示：

[![8654ed59-fc00-446d-8995-a02ab57cf213][]][8654ed59-fc00-446d-8995-a02ab57cf213 1]

上图可以看到，没有被标记的对象将会回收清除掉，而被标记的对象将会留下，并且会将标记位重新归0。接下来就不用说了，唤醒停止的程序线程，让程序继续运行即可。

**疑问：为什么非要停止程序的运行呢？**

答：

这个其实也不难理解，假设我们的程序与GC线程是一起运行的，各位试想这样一种场景。

假设我们刚标记完图中最右边的那个对象，暂且记为A，结果此时在程序当中又new了一个新对象B，且A对象可以到达B对象。但是由于此时A对象已经标记结束，B对象此时的标记位依然是0，因为它错过了标记阶段。因此当接下来轮到清除阶段的时候，新对象B将会被苦逼的清除掉。如此一来，不难想象结果，GC线程将会导致程序无法正常工作。

上面的结果当然令人无法接受，我们刚new了一个对象，结果经过一次GC，忽然变成null了，这还怎么玩？

**3、标记-清除算法的缺点：**

（1）首先，**它的缺点就是效率比较低（递归与全堆对象遍历）**，导致stop the world的时间比较长，尤其对于交互式的应用程序来说简直是无法接受。试想一下，如果你玩一个网站，这个网站一个小时就挂五分钟，你还玩吗？

（2）第二点主要的缺点，则是**这种方式清理出来的空闲内存是不连续的**，这点不难理解，我们的死亡对象都是随即的出现在内存的各个角落的，现在把它们清除之后，内存的布局自然会乱七八糟。而为了应付这一点，JVM就不得不维持一个内存的空闲列表，这又是一种开销。而且在分配数组对象的时候，寻找连续的内存空间会不太好找。

**五、复制算法：（新生代的GC）**

**复制算法的概念：**

将原有的内存空间分为两块，每次只使用其中一块，在垃圾回收时，将正在使用的内存中的存活对象复制到未使用的内存块中，之后，清除正在使用的内存块中的所有对象，交换两个内存的角色，完成垃圾回收。

*  与标记-清除算法相比，复制算法是一种相对高效的回收方法
 *  不适用于存活对象较多的场合，如老年代（复制算法**适合做新生代的GC**）

[![ff1e1846-e49c-4663-aee1-7c63628f567c][]][ff1e1846-e49c-4663-aee1-7c63628f567c 1]

*  **复制算法的最大的问题是：空间的浪费**

复制算法使得每次都只对整个半区进行内存回收，内存分配时也就不用考虑内存碎片等复杂情况，只要移动堆顶指针，按顺序分配内存即可，实现简单，运行高效。只是这种算法的代价是将内存缩小为原来的一半，这个太要命了。

所以从以上描述不难看出，复制算法要想使用，最起码对象的存活率要非常低才行，而且最重要的是，我们必须要克服50%内存的浪费。

现在的商业虚拟机都采用这种收集算法来回收新生代，新生代中的对象98%都是“朝生夕死”的，所以并不需要按照1:1的比例来划分内存空间，而是**将内存分为一块比较大的Eden空间和两块较小的Survivor空间**，每次使用Eden和其中一块Survivor。当回收时，将Eden和Survivor中还存活着的对象一次性地复制到另外一块Survivor空间上，最后清理掉Eden和刚才用过的Survivor空间。HotSpot虚拟机默认Eden和Survivor的大小比例是8:1，也就是说，每次新生代中可用内存空间为整个新生代容量的90%（80%+10%），只有10%的空间会被浪费。

当然，98%的对象可回收只是一般场景下的数据，我们没有办法保证每次回收都只有不多于10%的对象存活**，当Survivor空间不够用时，需要依赖于老年代进行分配担保，所以大对象直接进入老年代**。整个过程如下图所示：

[![7e1f6ed2-e0c4-45e4-b7db-b59c28e1ee9c][]][7e1f6ed2-e0c4-45e4-b7db-b59c28e1ee9c 1]

上图中，绿色箭头的位置代表的是大对象，大对象直接进入老年代。

根据上面的复制算法，现在我们来看下面的这个gc日志的数字，就应该能看得懂了吧：

[![6d59301f-f0c9-4fed-ba36-e66bc6574e8f][]][6d59301f-f0c9-4fed-ba36-e66bc6574e8f 1]

上方GC日志中，新生代的可用空间是13824K（eden区的12288K+from space的1536K）。而根据内存的地址计算得知，新生代的总空间为15M，而这个15M的空间是 = 13824K +to space 的 1536K。

**六、标记-整理算法：（老年代的GC）**

**引入：**

如果在对象存活率较高时就要进行较多的复制操作，效率将会变低。更关键的是，如果不想浪费50%的空间，就需要有额外的空间进行分配担保，以应对被使用的内存中所有对象都100%存活的极端情况，所以在老年代一般不能直接选中这种算法。

**概念：**

标记-压缩算法适合用于存活对象较多的场合，如老年代。它在标记-清除算法的基础上做了一些优化。和标记-清除算法一样，标记-压缩算法也首先需要从根节点开始，对所有可达对象做一次标记；但之后，它并不简单的清理未标记的对象，而是**将所有的存活对象压缩到内存的一端；**之后，清理边界外所有的空间。

[![cc79889a-0856-4018-92c3-c51108c9caea][]][cc79889a-0856-4018-92c3-c51108c9caea 1]

*  **标记：它的第一个阶段与标记/清除算法是一模一样的，均是遍历GC Roots，然后将存活的对象标记。**
 *  **整理：移动所有存活的对象，且按照内存地址次序依次排列，然后将末端内存地址以后的内存全部回收。因此，第二阶段才称为整理阶段。**

上图中可以看到，标记的存活对象将会被整理，按照内存地址依次排列，而未被标记的内存会被清理掉。如此一来，当我们需要给新对象分配内存时，JVM只需要持有一个内存的起始地址即可，这比维护一个空闲列表显然少了许多开销。

**标记/整理算法不仅可以弥补标记/清除算法当中，内存区域分散的缺点，也消除了复制算法当中，内存减半的高额代价。**

*  但是，标记/整理算法唯一的缺点就是效率也不高。

不仅要标记所有存活对象，还要整理所有存活对象的引用地址。从效率上来说，标记/整理算法要低于复制算法。

**标记-清除算法、复制算法、标记整理算法的总结：**

三个算法都基于根搜索算法去判断一个对象是否应该被回收，而支撑根搜索算法可以正常工作的理论依据，就是语法中变量作用域的相关内容。因此，要想防止内存泄露，最根本的办法就是掌握好变量作用域，而不应该使用C/C++式内存管理方式。

在GC线程开启时，或者说GC过程开始时，它们都要暂停应用程序（stop the world）。

它们的区别如下：（>表示前者要优于后者，=表示两者效果一样）

（1）**效率**：**复制算法**>标记/整理算法>标记/清除算法（此处的效率只是简单的对比时间复杂度，实际情况不一定如此）。

（2）**内存整齐度**：复制算法=标记/整理算法>标记/清除算法。

（3）内存利用率：标记/整理算法=标记/清除算法>复制算法。

注1：可以看到标记/清除算法是比较落后的算法了，但是后两种算法却是在此基础上建立的。

注2：**时间与空间不可兼得。**

**七、分代收集算法：（新生代的GC+老年代的GC）**

当前商业虚拟机的GC都是采用的“分代收集算法”，这并不是什么新的思想，只是**根据对象的存活周期的不同将内存划分为几块儿**。一般是把Java堆分为新生代和老年代：**短命对象归为新生代，长命对象归为老年代**。

*  **少量对象存活，适合复制算法**：在**新生代**中，每次GC时都发现有大批对象死去，只有少量存活，那就选用**复制算法**，只需要付出少量存活对象的复制成本就可以完成GC。
 *  **大量对象存活，适合用标记-清理/标记-整理**：在**老年代**中，因为对象存活率高、没有额外空间对他进行分配担保，就必须使用“**标记-清理**”/“标记-整理”算法进行GC。

注：**老年代的对象中，有一小部分是因为在新生代回收时，老年代做担保，进来的对象；绝大部分对象是因为很多次GC都没有被回收掉而进入老年代**。

**八、可触及性：**

所有的算法，需要能够识别一个垃圾对象，因此需要给出一个可触及性的定义。

**可触及的：**

从根节点可以触及到这个对象。

其实就是从根节点扫描，只要这个对象在引用链中，那就是可触及的。

**可复活的：**

一旦所有引用被释放，就是可复活状态

因为在finalize()中可能复活该对象

**不可触及的：**

在finalize()后，可能会进入不可触及状态

不可触及的对象不可能复活

要被回收。

**finalize方法复活对象的代码举例：**

![复制代码][copycode.gif]

1 package test03;
     2 
     3 /**
     4  * Created by smyhvae on 2015/8/19.
     5  */
     6 public class CanReliveObj {
     7     public static CanReliveObj obj;
     8 
     9     //当执行GC时，会执行finalize方法，并且只会执行一次
    10     @Override
    11     protected void finalize() throws Throwable {
    12         super.finalize();
    13         System.out.println("CanReliveObj finalize called");
    14         obj = this;   //当执行GC时，会执行finalize方法，然后这一行代码的作用是将null的object复活一下，然后变成了可触及性
    15     }
    16 
    17     @Override
    18     public String toString() {
    19         return "I am CanReliveObj";
    20     }
    21 
    22     public static void main(String[] args) throws
    23             InterruptedException {
    24         obj = new CanReliveObj();
    25         obj = null;   //可复活
    26         System.out.println("第一次gc");
    27         System.gc();
    28         Thread.sleep(1000);
    29         if (obj == null) {
    30             System.out.println("obj 是 null");
    31         } else {
    32             System.out.println("obj 可用");
    33         }
    34         obj = null;    //不可复活
    35         System.out.println("第二次gc");
    36         System.gc();
    37         Thread.sleep(1000);
    38         if (obj == null) {
    39             System.out.println("obj 是 null");
    40         } else {
    41             System.out.println("obj 可用");
    42         }
    43     }
    44 }

![复制代码][copycode.gif]

我们需要注意第14行的注释。一开始，我们在第25行将obj设置为null，然后执行一次GC，本以为obj会被回收掉，其实并没有，因为GC的时候会调用11行的finalize方法，然后obj在第14行被复活了。紧接着又在第34行设置obj设置为null，然后执行一次GC，此时obj就被回收掉了，因为finalize方法只会执行一次。

[![31011217-d3a2-4e5b-9503-4f0b9bad9161][]][31011217-d3a2-4e5b-9503-4f0b9bad9161 1]

**finalize方法的使用总结：**

*  经验：**避免使用finalize()**，操作不慎可能导致错误。
 *  优先级低，何时被调用，不确定

何时发生GC不确定，自然也就不知道finalize方法什么时候执行

*  如果要使用finalize去释放资源，我们可以使用try-catch-finally来替代它

** **

**九、Stop-The-World：**

**1、Stop-The-World概念：**

Java中一种全局暂停的现象。

**全局停顿，所有Java代码停止**，native代码可以执行，但不能和JVM交互

**多半情况下是由于GC引起**。

少数情况下由其他情况下引起，如：Dump线程、死锁检查、堆Dump。

**2、GC时为什么会有全局停顿？**

（1）避免无法彻底清理干净

打个比方：类比在聚会，突然GC要过来打扫房间，聚会时很乱，又有新的垃圾产生，房间永远打扫不干净，只有让大家停止活动了，才能将房间打扫干净。

况且，如果没有全局停顿，会给GC线程造成很大的负担，GC算法的难度也会增加，GC很难去判断哪些是垃圾。

（2）GC的工作必须在一个能确保**一致性**的快照中进行。

这里的一致性的意思是：在整个分析期间整个执行系统看起来就像被冻结在某个时间点上，不可以出现**分析过程中对象引用关系还在不断变化**的情况，该点不满足的话分析结果的准确性无法得到保证。

这点是导致GC进行时必须停顿所有Java执行线程的其中一个重要原因。

**3、Stop-The-World的****危害：**

> **长时间服务停止，没有响应（将用户正常工作的线程全部暂停掉）**
> 
> 遇到HA系统，可能引起主备切换，严重危害生产环境。
> 
> 　　备注：HA：High Available, 高可用性集群。

[![d07bb3ea-1235-41d5-9fb1-56b4087d1acf][]][d07bb3ea-1235-41d5-9fb1-56b4087d1acf 1]

比如上面的这主机和备机：现在是主机在工作，此时如果主机正在GC造成长时间停顿，那么备机就会监测到主机没有工作，于是备机开始工作了；但是主机不工作只是暂时的，当GC结束之后，主机又开始工作了，那么这样的话，主机和备机就同时工作了。**主机和备机同时工作其实是非常危险**的，很有可能会导致应用程序不一致、不能提供正常的服务等，进而影响生产环境。

**代码举例：**

（1）打印日志的代码：（每隔100ms打印一条）

![复制代码][copycode.gif]

public static class PrintThread extends Thread{
        public static final long starttime=System.currentTimeMillis();
        @Override
        public void run(){
            try{
                while(true){
                    long t=System.currentTimeMillis()-starttime;
                    System.out.println("time:"+t);
                    Thread.sleep(100);
                }
            }catch(Exception e){
    
            }
        }
    }

![复制代码][copycode.gif]

上方代码中，是负责打印日志的代码，每隔100ms打印一条，并计算打印的时间。

（2）工作线程的代码：（工作线程，专门用来消耗内存）

![复制代码][copycode.gif]

public static class MyThread extends Thread{
        HashMap<Long,byte[]> map=new HashMap<Long,byte[]>();
        @Override
        public void run(){
            try{
                while(true){
                    if(map.size()*512/1024/1024>=450){   //如果map消耗的内存消耗大于450时，那就清理内存
                        System.out.println("=====准备清理=====:"+map.size());
                        map.clear();
                    }
    
                    for(int i=0;i<1024;i++){
                        map.put(System.nanoTime(), new byte[512]);
                    }
                    Thread.sleep(1);
                }
            }catch(Exception e){
                e.printStackTrace();
            }
        }
    }

![复制代码][copycode.gif]

然后，我们设置gc的参数为：

-Xmx512M -Xms512M -XX:+UseSerialGC -Xloggc:gc.log -XX:+PrintGCDetails -Xmn1m -XX:PretenureSizeThreshold=50 -XX:MaxTenuringThreshold=1

打印日志如下：

[![8a8de388-7989-47f2-a7e1-496487e4be57][]][8a8de388-7989-47f2-a7e1-496487e4be57 1]

上图中，红色字体代表的正在GC。按道理来说，应该是每隔100ms会打印输出一条日志，但是当执行GC的时候，会出现全局停顿的情况，导致没有按时输出。

下篇文章中，我们将对各种垃圾收集器进行介绍。

说起**垃圾收集（Garbage Collection, GC）**，想必大家都不陌生，它是JVM实现里非常重要的一环，JVM成熟的内存动态分配与回收技术使Java（当然还有其他运行在JVM上的语言，如Scala等）程序员在提升开发效率上获得了惊人的便利。理解GC，对于理解JVM和Java语言有着非常重要的作用。并且当我们需要排查各种内存溢出、内存泄漏问题时，当垃圾收集称为系统达到更高并发量的瓶颈时，只有深入理解GC和内存分配，才能对这些“自动化”的技术实施必要的监控和调节。

在Java的运行时数据区中，程序计数器、虚拟机栈、本地方法栈三个区域都是线程私有的，随线程而生，随线程而灭，在方法结束或线程结束时，内存自然就跟着回收了，不需要过多考虑回收的问题。而**Java堆**和**方法区**则不一样，一个接口中的多个实现类需要的内存可能不一样，一个方法中的多个分支需要的内存也可能不一样，我们只有在程序处于运行期间才能知道会创建哪些对象，这部分内存的分配和回收都是动态的，垃圾回收器关注的是这部分内存，后续讨论的“内存”分配回收也是指这一块，尤其需要注意。

GC主要回答了以下三个问题：

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

这三个问题的具体解决方案，也就是本文接下来要讲解的内容。

# 对象存活判定算法 #

在堆里存放着Java世界中几乎所有的对象实例，垃圾收集器在对堆进行回收前，首要的就是确定这些对象中哪些还“存活”着，哪些已经“死去”（即不可能再被任何途径使用的对象）。

引用计数算法

引用计数算法是在JVM中被摒弃的一种对象存活判定算法，不过它也有一些知名的应用场景（如Python、FlashPlayer），因此在这里也简单介绍一下。

用引用计数器判断对象是否存活的过程是这样的：**给对象中添加一个引用计数器，每当有一个地方引用它时，计数器加1；当引用失效时，计数器减1；任何时刻计数器为0的对象就是不可能再被使用的。**

引用计数算法的实现简单，判定效率也很高，大部分情况下是一个不错的算法。它没有被JVM采用的原因是**它很难解决对象之间循环引用的问题**。例如以下例子：

/** * testGC()方法执行后，objA和objB会不会被GC呢？ */
    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 testGC() {
            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;`，除此之外，这两个对象再无引用。如果JVM采用引用计数算法来管理内存，**这两个对象不可能再被访问，但是他们互相引用着对方，导致它们引用计数不为0，所以引用计数器无法通知GC收集器回收它们**。

而事实上执行这段代码，objA和objB是可以被回收的，下面一节将介绍JVM实际使用的存活判定算法。

可达性分析算法

在主流商用程序语言的实现中，都是通过**可达性分析（tracing GC）**来判定对象是否存活的。此算法的基本思路是：通过一系列的称为**“GC Roots”**的对象作为起点，从这些节点向下搜索，搜索所走过的路径称为**引用链（Reference Chain）**，当一个对象到GC Roots没有任何引用链相连（用图论的话来说，就是GC Roots 到这个对象不可达）时，则证明此对象时不可用的。用下图来加以说明：

![0635cbe8.png_29][]

上图中，对象object 5、object 6、object 7虽然互有关联，但是它们到GC Roots是不可达的，所以它们将会被判定为是可回收的对象。

可以看到，GC Roots在对象图之外，是特别定义的**“起点”**，不可能被对象图内的对象所引用。

准确地说，**GC Roots其实不是一组对象，而通常是一组特别管理的指向引用类型对象的指针**，这些指针是tracing GC的trace的起点。它们不是对象图里的对象，对象也不可能引用到这些“外部”的指针，这也是tracing GC算法不会出现循环引用问题的基本保证。因此也容易得出，**只有引用类型的变量才被认为是Roots，值类型的变量永远不被认为是Roots**。只有深刻理解引用类型和值类型的内存分配和管理的不同，才能知道为什么root只能是引用类型。

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

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

看到这里你可能要问，选择这些对象的依据是什么呢？

可以概括得出，可作为GC Roots的节点主要在**全局性的引用**与**执行上下文**中。要明确的是，tracing gc必须**以当前存活的对象集为Roots**，因此必须选取确定存活的引用类型对象。GC管理的区域是Java堆，**虚拟机栈**、**方法区**和**本地方法栈**不被GC所管理，因此选用这些区域内引用的对象作为GC Roots，是**不会被GC所回收**的。其中虚拟机栈和本地方法栈都是线程私有的内存区域，只要线程没有终止，就能确保它们中引用的对象的存活。而方法区中类静态属性引用的对象是显然存活的。常量引用的对象在当前可能存活，因此，也可能是GC roots的一部分。

两次标记与 finalize()方法

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

如果对象在进行可达性分析后发现没有与 GC Roots相连接的引用链，那它将会被**第一次标记**并且进行一次筛选，筛选的条件是**此对象是否有必要执行`finaliza()`方法**。当对象没有覆盖`finaliza()`方法，或者`finaliza()`方法已经被虚拟机调用过，虚拟机将这两种情况都视为“没有必要执行”。

如果这个对象被判定为有必要执行`finaliza()`方法，那么此对象将会放置在一个叫做 F-Queue 的队列中，并在稍后由一个虚拟机自动建立的、低优先级的Finalizer线程去执行它。这里所谓的“执行”是指虚拟机会触发此方法，但并不承诺会等待它运行结束，原因是：如果一个对象在`finaliza()`方法中执行缓慢，或者发生了死循环（更极端的情况），将很可能导致F-Queue 队列中的其它对象永久处于等待，甚至导致整个内存回收系统崩溃。

`finaliza()`方法是对象逃脱死亡命运的最后一次机会，稍后GC将对F-Queue 队列中的对象进行**第二次小规模的标记**。如果对象想在`finaliza()`方法中成功拯救自己，**只要重新与引用链上的任何一个对象建立关联即可，例如把自己（this关键字）赋值给某个类变量或者对象的成员变量，这样在第二次标记时它将被移出“即将回收”的集合**；如果对象这时候还没有逃脱，基本上它就真的被回收了。

值得注意的是，如果代码中有两段一模一样的代码段，执行结果却是一次逃脱成功，一次失败。这是因为任何一个对象的`finalize()`方法都只会被系统调用一次，如果对象面临下一次回收，它的`finalize()`方法不会再被执行，因此第二次逃脱行动失败。

需要说明的是，使用`finalize()`方法来“拯救”对象是不值得提倡的，因为它不是C/C++中的析构函数，而是Java刚诞生时为了使C/C++程序员更容易接受它所做的一个妥协。**它的运行代价高昂，不确定性大，无法保证各个对象的调用顺序。**`finalize() `能做的工作，使用`try-finally`或者其它方法都更适合、及时，所以笔者建议大家可以忘掉此方法存在。

回收方法区

很多人认为方法区没有垃圾回收，Java虚拟机规范中确实说过不要求，而且在方法区中进行垃圾收集的“性价比”较低：在堆中，尤其是新生代，常规应用进行一次垃圾收集可以回收70%~95%的空间，而方法区的效率远低于此。在JDK 1.8中，JVM摒弃了永久代，用元空间来作为方法区的实现，下面介绍的将是元空间的垃圾回收。

元空间的内存管理由**元空间虚拟机**来完成。先前，对于类的元数据我们需要不同的垃圾回收器进行处理，现在只需要执行元空间虚拟机的C++代码即可完成。**在元空间中，类和其元数据的生命周期**和**其对应的类加载器**是相同的。话句话说，**只要类加载器存活，其加载的类的元数据也是存活的**，因而不会被回收掉。

我们从行文到现在提到的元空间稍微有点不严谨。准确的来说，**每一个*类加载器的存储区域*都称作一个元空间，所有的元空间合在一起就是我们一直说的元空间。**当一个类加载器被垃圾回收器标记为不再存活，其对应的元空间会被回收。在元空间的回收过程中没有重定位和压缩等操作。但是元空间内的元数据会进行扫描来确定Java引用。

# 垃圾收集算法 #

本节将介绍几种垃圾收集算法的思想及其发展过程，具体的实现将在稍后介绍。

标记－清除（Mark-Sweep）算法

**标记－清除（Mark-Sweep）**算法是最基础的垃圾收集算法，后续的收集算法都是基于它的思路并对其不足进行改进而得到的。顾名思义，算法分成“标记”、“清除”两个阶段：首先标记出所有需要回收的对象，在标记完成后统一回收所有被标记的对象，标记过程在前一节讲述对象标记判定时已经讲过了。

标记－清除算法的不足主要有以下两点：

*  **空间问题**，标记清除之后会产生大量不连续的**内存碎片**，空间碎片太多可能会导致以后在程序运行过程中需要分配较大对象时，无法找到足够的连续内存而不得不触发另一次垃圾收集动作。
 *  **效率问题**，因为内存碎片的存在，操作会变得更加费时，因为查找下一个可用空闲块已不再是一个简单操作。

标记－清除算法的执行过程如下图所示：

![efc6204a.png][]

复制（Copying）算法

为了解决标记-清除算法的效率问题，一种称为**“复制”（Copying）**的收集算法出现了，思想为：它**将可用内存按容量分成大小相等的两块**，每次只使用其中的一块。**当这一块内存用完，就将还存活着的对象复制到另一块上面**，然后再把已使用过的内存空间一次清理掉。

这样做使得**每次都是对整个半区进行内存回收**，内存分配时也就**不用考虑内存碎片**等复杂情况，只要**移动堆顶指针，按顺序分配内存**即可，实现简单，运行高效。只是这种算法的代价是**将内存缩小为原来的一半**，代价可能过高了。复制算法的执行过程如下图所示：

![f1cada8a.png][]

**Minor GC与复制算法**

**现在的商业虚拟机都使用复制算法来回收新生代。**新生代的GC又叫**“Minor GC”**，IBM公司的专门研究表明：新生代中的对象98%是**“朝生夕死”**的，所以Minor GC非常频繁，一般回收速度也比较快，同时**“朝生夕死”**的特性也使得Minor GC使用复制算法时不需要按照1:1的比例来划分新生代内存空间。

**Minor GC过程**

事实上，新生代将内存分为**一块较大的Eden空间**和**两块较小的Survivor空间（From Survivor和To Survivor）**，**每次Minor GC都使用Eden和From Survivor**，当回收时，**将Eden和From Survivor中还存活着的对象都一次性地复制到另外一块To Survivor空间上**，最后清理掉Eden和刚使用的Survivor空间。**一次Minor GC结束的时候**，**Eden**空间和**From Survivor**空间都是空的，而**To Survivor**空间里面存储着存活的对象。**在下次MinorGC的时候**，两个Survivor空间交换他们的标签，现在是空的**“From” Survivor**标记成为**“To”**，**“To” Survivor**标记为**“From”**。因此，在MinorGC结束的时候，Eden空间是空的，两个Survivor空间中的一个是空的，而另一个存储着存活的对象。

HotSpot虚拟机默认的**Eden : Survivor**的比例是**8 : 1**，由于一共有两块Survivor，所以**每次新生代中可用内存空间为整个新生代容量的90%（80%＋10%）**，只有10%的容量会被“浪费”。

**分配担保**

上文说的98%的对象可回收只是一般场景下的数据，我们没有办法保证每次回收都只有不多于10%的对象存活，**当Survivor空间不够用时**，需要依赖**老年代内存**进行**分配担保（Handle Promotion）**。如果另外一块Survivor上没有足够空间存放上一次新生代收集下来的存活对象，这些对象将直接通过分配担保机制进入老年代。

标记－整理（Mark-Compact）算法

复制算法在对象存活率较高时要进行较多的复制操作，效率将会变低。更关键的是：如果不想浪费50%的空间，就需要有额外的空间进行分配担保，以应对被使用的内存中所有对象都100%存活的极端情况，所以在**老年代一般不能直接选用复制算法**。

根据老年代的特点，**标记－整理（Mark-Compact）**算法被提出来，主要思想为：此算法的标记过程与**标记－清除**算法一样，但后续步骤不是直接对可回收对象进行清理，而是**让所有存活的对象都向一端移动，然后直接清理掉边界以外的内存。**具体示意图如下所示：

![d3d3277f.png][]

分代收集（Generational Collection）算法

当前商业虚拟机的垃圾收集都采用**分代收集（Generational Collection）算法**，此算法相较于前几种没有什么新的特征，主要思想为：根据对象存活周期的不同将内存划分为几块，一般是把Java堆分为新生代和老年代，这样就可以根据各个年代的特点采用最适合的收集算法：

*  **新生代** 在新生代中，每次垃圾收集时都发现有大批对象死去，只有少量存活，那就选用**复制算法**，只需要付出少量存活对象的复制成本就可以完成收集。
 *  **老年代** 在老年代中，因为对象存活率高、没有额外空间对它进行分配担保，就必须使用**“标记-清除”**或**“标记-整理”**算法来进行回收。

# HotSpot的算法实现 #

前面两大节主要从理论上介绍了对象存活判定算法和垃圾收集算法，而在HotSpot虚拟机上实现这些算法时，必须对算法的执行效率有严格的考量，才能保证虚拟机高效运行。

枚举根节点

从可达性分析中**从GC Roots节点找引用链**这个操作为例，可作为GC Roots的节点主要在**全局性的引用**（例如常量或类静态属性）与**执行上下文**（例如栈帧中的局部变量表）中，现在很多应用仅仅方法区就有数百兆，如果要逐个检查这里面的引用，那么必然会消耗很多时间。

**GC停顿（”Stop The World”）**

另外，可达性分析工作必须在一个**能确保一致性的快照**中进行——这里**“一致性”**的意思是指**在整个分析期间整个执行系统看起来就像被冻结在某个时间点上**，不可以出现分析过程中对象引用关系还在不断变化的情况，这是保证分析结果准确性的基础。这点是导致GC进行时必须**停顿所有Java执行线程**（Sun将这件事情称为**“Stop The World”**）的其中一个重要原因，即使是在号称（几乎）不会发生停顿的CMS收集器中，枚举根节点时也是必须要停顿的。

**准确式GC与OopMap**

由于目前的主流Java虚拟机使用的都是**准确式GC（即使用准确式内存管理，虚拟机可用知道内存中某个位置的数据具体是什么类型）**，所以当执行系统停顿下来后，并不需要一个不漏地检查完所有执行上下文和全局的引用位置，虚拟机应当是有办法直接得知哪些地方存放着对象引用。在HotSpot的实现中，是使用一组称为**OopMap**的数据结构来达到这个目的的，在类加载完成的时候，HotSpot就把**对象内什么偏移量上是什么类型的数据**计算出来，在JIT编译过程中，也会在特定的位置记录下**栈和寄存器中哪些位置是引用**。这样，GC在扫描时就可以直接得知这些信息了。

安全点（Safepoint）——进行GC时程序停顿的位置

在OopMap的协助下，HotSpot可以快速且准确地完成GC Roots枚举，但一个很现实的问题随之而来：可能导致引用关系变化，或者说OopMap内容变化的指令非常多，**如果为每一条指令都生成对应的OopMap，那将会需要大量的额外空间，这样GC的空间成本将会变得很高。**

为此，HotSpot选择不为每条指令都生成OopMap，而是只在“特定的位置”记录这些信息，这些位置便被称为**安全点（Safepoint）**。也就是说，**程序执行时并非在所有地方都能停顿下来开始GC，只有在到达安全点时才能暂停**。Safepoint的选定既不能太少以致于让GC等待时间太长，也不能过于频繁以致于过分增大运行时的负荷。所以，安全点的选定基本上是以程序**“是否具有让程序长时间执行的特征”**为标准进行选定的——因为每条指令执行的时间都非常短暂，程序不太可能因为指令流长度太长这个原因而过长时间运行，“长时间执行”的最明显特征就是**指令序列复用**，例如**方法调用**、**循环跳转**、**异常跳转**等，所以具有这些功能的指令才会产生Safepoint。

对于Sefepoint，另一个需要考虑的问题是如何**在GC发生时让所有线程（这里不包括执行JNI调用的线程）都“跑”到最近的安全点上再停顿下来**。这里有两种方案可供选择：

*  **抢先式中断（Preemptive Suspension）** 抢先式中断不需要线程的执行代码主动去配合，**在GC发生时，首先把所有线程全部中断，如果发现有线程中断的地方不在安全点上，就恢复线程，让它“跑”到安全点上。**现在几乎没有虚拟机实现采用抢先式中断来暂停线程从而响应GC事件。
 *  **主动式中断（Voluntary Suspension）**： 主动式中断的思想是当GC需要中断线程的时候，不直接对线程操作，仅仅简单地**设置一个标志**，各个线程执行时主动去轮询这个标志，发现中断标志为真时就自己中断挂起。**轮询标志的地方和安全点是重合的**，另外**再加上创建对象需要分配内存的地方**。

安全区域（Safe Region）

**Safepoint**机制保证了**程序执行时**，在不太长的时间内就会遇到可进入GC的Safepoint。但是，**程序“不执行”的时候（如线程处于Sleep状态或Blocked状态）**，这时线程无法响应JVM的中断请求，“走到”安全的地方去中断挂起，这时候就需要**安全区域（Safe Region）**来解决。

安全区域是指**在一段代码片段之中，引用关系不会发生变化。在这个区域中的任意地方开始GC都是安全的。**我们也可以把Safe Region看做是被扩展了的Safepoint。

在线程执行到Safe Region中的代码时，首先**标识自己已经进入了Safe Region**，那样，当在这段时间里JVM要发起GC时，就不用管标识自己为Safe Region状态的线程了。**在线程要离开Safe Region时，它要检查系统是否已经完成了根节点枚举（或者是整个GC过程）**，如果完成了，那线程就继续执行，否则它就必须等待直到收到可以安全离开Safe Region的信号为止。

# 内存分配策略 #

Java的自动内存管理最终可以归结为自动化地解决了两个问题：

*  **给对象分配内存**
 *  **回收分配给对象的内存**

对象的内存分配通常是在堆上分配（除此以外还有可能经过JIT编译后被拆散为标量类型并间接地栈上分配），对象主要分配在新生代的Eden区上，如果启动了本地线程分配缓冲，将按线程优先在TLAB上分配。少数情况下也可能会直接分配在老年代中，分配的规则并不是固定的，实际取决于垃圾收集器的具体组合以及虚拟机中与内存相关的参数的设置。至于内存回收策略，在上文已经描述得很详尽了。

下面以使用Serial/Serial Old收集器（将在下一篇文章中讲解）为例，介绍内存分配的策略。

对象优先在Eden区分配

大多数情况下，对象在新生代的Eden区中分配。**当Eden区没有足够空间进行分配时，虚拟机将发起一次Minor GC。**

大对象直接进入老年代

所谓的大对象是指，需要大量连续内存空间的Java对象，最典型的大对象就是很长的字符串以及数组。大对象对虚拟机的内存分配来说是一个坏消息（尤其是遇到朝生夕灭的“短命大对象”，写程序时应避免），**经常出现大对象容易导致内存还有不少空间时就提前触发GC以获取足够的连续空间来安置它们**。

虚拟机提供了一个**-XX:PretenureSizeThreshold**参数，令大于这个设置值的对象直接在老年代分配。这样做的目的是**避免在Eden区及两个Survivor区之间发生大量的内存复制**（新生代采用复制算法回收内存）。

长期存活的对象将进入老年代

既然虚拟机采用了分代收集的思想来管理内存，那么内存回收时就必须能识别哪些对象应放在新生代，哪些对象应放在老年代中。为了做到这点，虚拟机给每个对象定义了一个**对象年龄（Age）计数器**。**如果对象在Eden出生并经过第一次Minor GC后仍然存活，并且能被Survivor容纳的话，将被移动到Survivor空间中，并且对象年龄设为1。对象在Survivor区中每“熬过”一次Minor GC，年龄就增加1岁，当它的年龄增加到一定程度（默认为15岁），就将会被晋升到老年代中。**对象晋升老年代的年龄阈值，可以通过参数**-XX:MaxTenuringThreshold**设置。

动态对象年龄判定

为了能更好地适应不同程序的内存状况，虚拟机并不是永远地要求对象的年龄必须达到了**MaxTenuringThreshold**才能晋升老年代，**如果在Survivor空间中相同年龄所有对象大小的总和大于Survivor空间的一半，年龄大于或等于该年龄的对象就可以直接进入老年代**，无须等到**MaxTenuringThreshold**中要求的年龄。

空间分配担保

**在发生Minor GC之前**，虚拟机会先检查老年代最大可用的连续空间是否大于新生代所有对象总空间，如果这个条件成立，那么Minor GC可以确保是安全的。如果不成立，则虚拟机会查看**HandlePromotionFailure**设置值是否允许担保失败。如果允许，那么会继续检查老年代最大可用的连续空间是否大于历次晋升到老年代对象的平均大小，如果大于，将尝试着进行一次Minor GC，尽管这次Minor GC是有风险的；如果小于，或者**HandlePromotionFailure**设置不允许冒险，那这时也要改为进行一次**Full GC**。

前面提到过，新生代使用复制收集算法，但为了内存利用率，只使用其中一个Survivor空间来作为轮换备份，因此**当出现大量对象在Minor GC后仍然存活的情况（最极端的情况就是内存回收后新生代中所有对象都存活），就需要老年代进行分配担保，把Survivor无法容纳的对象直接进入老年代。**与生活中的贷款担保类似，老年代要进行这样的担保，前提是老年代本身还有容纳这些对象的剩余空间，一共有多少对象会活下来在实际完成内存回收之前是无法明确知道的，所以只好取之前每一次回收晋升到老年代对象容量的平均大小值作为经验值，与老年代的剩余空间进行比较，决定是否进行Full GC来让老年代腾出更多空间。

取平均值进行比较其实仍然是一种动态概率的手段，也就是说，如果某次Minor GC存活后的对象突增，远远高于平均值的话，依然会导致**担保失败（Handle Promotion Failure）**。如果出现了**HandlePromotionFailure**失败，那就只好在失败后重新发起一次Full GC。虽然担保失败时绕的圈子是最大的，但大部分情况下都还是会将**HandlePromotionFailure**开关打开，避免Full GC过于频繁。

# Full GC的触发条件 #

对于Minor GC，其触发条件非常简单，当Eden区空间满时，就将触发一次Minor GC。而Full GC则相对复杂，因此本节我们主要介绍Full GC的触发条件。

调用System.gc()

此方法的调用是建议JVM进行Full GC,虽然只是建议而非一定,但很多情况下它会触发 Full GC,从而增加Full GC的频率,也即增加了间歇性停顿的次数。因此强烈建议能不使用此方法就不要使用，让虚拟机自己去管理它的内存，可通过**-XX:+ DisableExplicitGC**来禁止RMI调用System.gc()。

老年代空间不足

老年代空间不足的常见场景为前文所讲的**大对象直接进入老年代**、**长期存活的对象进入老年代**等，当执行Full GC后空间仍然不足，则抛出如下错误： `Java.lang.OutOfMemoryError: Java heap space `为避免以上两种状况引起的Full GC，调优时应尽量做到让对象在Minor GC阶段被回收、让对象在新生代多存活一段时间及不要创建过大的对象及数组。

空间分配担保失败

前文介绍过，使用复制算法的Minor GC需要老年代的内存空间作担保，如果出现了**HandlePromotionFailure**担保失败，则会触发Full GC。

JDK 1.7及以前的永久代空间不足

在JDK 1.7及以前，HotSpot虚拟机中的方法区是用永久代实现的，永久代中存放的为一些class的信息、常量、静态变量等数据，当系统中要加载的类、反射的类和调用的方法较多时，Permanet Generation可能会被占满，在未配置为采用CMS GC的情况下也会执行Full GC。如果经过Full GC仍然回收不了，那么JVM会抛出如下错误信息： `java.lang.OutOfMemoryError: PermGen space` 为避免PermGen占满造成Full GC现象，可采用的方法为增大PermGen空间或转为使用CMS GC。

在JDK 1.8中用元空间替换了永久代作为方法区的实现，元空间是本地内存，因此减少了一种Full GC触发的可能性。

Concurrent Mode Failure

执行CMS GC的过程中同时有对象要放入老年代，而此时老年代空间不足（有时候“空间不足”是CMS GC时当前的浮动垃圾过多导致暂时性的空间不足触发Full GC），便会报`Concurrent Mode Failure`错误，并触发Full GC。

# 小结 #

本文简要地介绍了HotSpot虚拟机如何去发起内存回收的问题，也解答了文章开头提出的三个问题中的前两个——“哪些内存需要回收”和“何时回收”，同时对于第三个问题——“如何回收”，在原理层面作出了解答。在下一篇文章中，笔者将通过介绍几种具体的垃圾收集器，来更深入地回答第三个问题。

[https_www.cnblogs.com_smyhvae_p_4744233.html]: https://www.cnblogs.com/smyhvae/p/4744233.html
[https_crowhawk.github.io_2017_08_10_jvm_2]: https://crowhawk.github.io/2017/08/10/jvm_2/
[e6217360-0985-46e8-88fd-022f1fc0fba5]: /images/20220417/f88f71ff62e249eca54790f304530c44.png
[e6217360-0985-46e8-88fd-022f1fc0fba5 1]: http://images0.cnblogs.com/blog/641601/201508/201002443781597.png
[1a489e67-e047-408f-a97e-4a141e6ab3b0]: /images/20220417/0552997f5eb44a0b9ad85f8f03af52ee.png
[1a489e67-e047-408f-a97e-4a141e6ab3b0 1]: http://images0.cnblogs.com/blog/641601/201508/201002456281312.png
[copycode.gif]: /images/20220417/b7e26a8cf90f490896f54bb4caa2e476.png
[7ab0f17b-13f7-4886-a24d-3813c2173891]: /images/20220417/820e88dda1b0496a99bcf27b8554a5ae.png
[7ab0f17b-13f7-4886-a24d-3813c2173891 1]: http://images0.cnblogs.com/blog/641601/201508/201002468169242.jpg
[7de44970-2e02-46a1-a5d0-0663b21906c6]: /images/20220417/a322d001a5ed41ac85ca8b754720f043.png
[7de44970-2e02-46a1-a5d0-0663b21906c6 1]: http://images0.cnblogs.com/blog/641601/201508/201002487061086.png
[47146934-c3a3-4976-991f-77e84ae008cc]: /images/20220417/8701a83fcfa54a008f92ce08eddf581d.png
[47146934-c3a3-4976-991f-77e84ae008cc 1]: http://images0.cnblogs.com/blog/641601/201508/201002507223903.jpg
[5cbf57ce-c83a-40d2-b58a-b37d3eee3803]: /images/20220417/63a3541f77c94e05a7811ae935a0778f.png
[5cbf57ce-c83a-40d2-b58a-b37d3eee3803 1]: http://images0.cnblogs.com/blog/641601/201508/201002520662647.jpg
[8654ed59-fc00-446d-8995-a02ab57cf213]: /images/20220417/fcbd7487450b4839b88489e0c8675734.png
[8654ed59-fc00-446d-8995-a02ab57cf213 1]: http://images0.cnblogs.com/blog/641601/201508/201002539108475.jpg
[ff1e1846-e49c-4663-aee1-7c63628f567c]: /images/20220417/ef1de692a83e46178a228d8ee1e6c6be.png
[ff1e1846-e49c-4663-aee1-7c63628f567c 1]: http://images0.cnblogs.com/blog/641601/201508/201002555814020.png
[7e1f6ed2-e0c4-45e4-b7db-b59c28e1ee9c]: /images/20220417/2ea1401a34b54265becdce8dfd6af9d9.png
[7e1f6ed2-e0c4-45e4-b7db-b59c28e1ee9c 1]: http://images0.cnblogs.com/blog/641601/201508/201002565501949.png
[6d59301f-f0c9-4fed-ba36-e66bc6574e8f]: /images/20220417/86f2e75a44a149c4a4204c6928cdcdaf.png
[6d59301f-f0c9-4fed-ba36-e66bc6574e8f 1]: http://images0.cnblogs.com/blog/641601/201508/201002579102165.png
[cc79889a-0856-4018-92c3-c51108c9caea]: /images/20220417/bf6e2c924b994609a69512a1f1bc66d3.png
[cc79889a-0856-4018-92c3-c51108c9caea 1]: http://images0.cnblogs.com/blog/641601/201508/201002594252194.png
[31011217-d3a2-4e5b-9503-4f0b9bad9161]: /images/20220417/e5e39b7462554f4e905a49799c577349.png
[31011217-d3a2-4e5b-9503-4f0b9bad9161 1]: http://images0.cnblogs.com/blog/641601/201508/201003018639839.png
[d07bb3ea-1235-41d5-9fb1-56b4087d1acf]: /images/20220417/1cdc50a3d6054451b8209d8a720a6166.png
[d07bb3ea-1235-41d5-9fb1-56b4087d1acf 1]: http://images0.cnblogs.com/blog/641601/201508/201003035037139.png
[8a8de388-7989-47f2-a7e1-496487e4be57]: /images/20220417/8cd8eec51be043c3848d8ed9732fcf2b.png
[8a8de388-7989-47f2-a7e1-496487e4be57 1]: http://images0.cnblogs.com/blog/641601/201508/201003048163342.png
[0635cbe8.png_29]: /images/20220417/f0ab91365c8547209dba749735d7c37b.png
[efc6204a.png]: /images/20220417/35204315a7bb4165ab1f0d3fa00b3f3b.png
[f1cada8a.png]: /images/20220417/1df3f25385254f7199eae36ba1059d1b.png
[d3d3277f.png]: /images/20220417/efdfaca4852c46648c7d48c7cb26f10a.png