HotSpot JVM 内存管理

关于 JVM 内存管理或者说垃圾收集，大家可能看过很多的文章了，笔者准备给大家总结下。这算是系列的第一篇，接下来一段时间会持续更新。

本文主要是翻译《Memory Management in the Java HotSpot Virtual Machine》白皮书的前四章内容，这是 2006 的老文章了，当年发布这篇文章的还是 Sun Microsystems，以后应该会越来越少人记得这家曾经无比伟大的公司了。

虽然这个白皮书有点老了，不过那个时候 Sun 在 J2SE 5.0 版本的 HotSpot 虚拟机上已经有了 Parallel 并行垃圾收集器和 CMS 这种并发收集器了，所以其实内容也没那么过时。

其实本文应该有挺多人都翻译过，我大体上是意译的，增、删了部分内容。

其他的知识，包括 Java5 之后的垃圾收集器，如 Java8 的 MetaSpace 取代了永久代、G1 收集器等，将在日后的文章中进行介绍。

 

垃圾收集概念

---

GC 需要做 3 件事情：

• 分配内存，为每个新建的对象分配空间
• 确保还在使用的对象的内存一直还在，不能把有用的空间当垃圾回收了
• 释放不再使用的对象所占用的空间

我们把还被 GC Roots 引用的对象称为活的，把不再被引用的对象认为是死的，也就是我们说的垃圾，GC 的工作就是找到死的对象，回收它们占用的空间。

在这里，我们总结一下 GC Roots 有哪些：

• 当前各线程执行方法中的局部变量（包括形参）引用的对象
• 已被加载的类的 static 域引用的对象
• 方法区中常量引用的对象
• JNI 引用

以上不完全，不过我觉得了解到这些就够了，了解更多

我们把 GC 管理的内存称为 堆（heap），垃圾收集启动的时机取决于各个垃圾收集器，通常，垃圾收集发生于整个堆或堆的部分已经被使用光了，或者使用的空间达到了某个百分比阈值。这些后面都会具体说，这里的每一句话都是对应了某些场景的。

对于内存分配请求，实现的难点在于在堆中找到一块没有被使用的确定大小的内存空间。所以，对于大部分垃圾回收算法来说避免内存碎片化是非常重要的，它将使得空间分配更加高效。

 

垃圾收集器的理想特征

---

1. 安全和全面：活的对象一定不能被清理掉，死的对象一定不能在几个回收周期结束后还在内存中。
2. 高效：不能将我们的应用程序挂起太长时间。我们需要在时间、空间、频次上作出权衡。比如，如果堆内存很小，每次垃圾收集就会很快，但是频次会增加。如果堆内存很大，很久才会被填满，但是每一次回收需要的时间很长。
3. 尽量少的内存碎片：每次将垃圾对象释放以后，这些空间可能分布在各个地方，最糟糕的情况就是，内存中到处都是碎片，在给一个大对象分配空间的时候没有内存可用，实际上内存是够的。消除碎片的方式就是压缩。
4. 可扩展性：在多核多线程应用中，内存分配和垃圾回收都不应该成为可扩展性的瓶颈。原文提到的这一点，我的理解是：单线程垃圾回收在多核系统中会浪费 CPU 资源，如果我理解错误，请指正我。

 

设计上的权衡

---

往下看之前，我们需要先分清楚这里的两个概念：并发和并行

• 并行：多个垃圾回收线程同时工作，而不是只有一个垃圾回收线程在工作
• 并发：垃圾回收线程和应用程序线程同时工作，应用程序不需要挂起

在设计或选择垃圾回收算法的时候，我们需要作出以下几个权衡：

• 串行 vs 并行

  串行收集的情况，即使是多核 CPU，也只有一个核心参与收集。使用并行收集器的话，垃圾收集的工作将分配给多个线程在不同的 CPU 上同时进行。并行可以让收集工作更快，缺点是带来的复杂性和内存碎片问题。

• 并发 vs Stop-the-world

  当 stop-the-world 垃圾收集器工作的时候，应用将完全被挂起。与之相对的，并发收集器在大部分工作中都是并发进行的，也许会有少量的 stop-the-world。

  stop-the-world 垃圾收集器比并发收集器简单很多，因为应用挂起后堆空间不再发生变化，它的缺点是在某些场景下挂起的时间我们是不能接受的（如 web 应用）。

  相应的，并发收集器能够降低挂起时间，但是也更加复杂，因为在收集的过程中，也会有新的垃圾产生，同时，需要有额外的空间用于在垃圾收集过程中应用程序的继续使用。

• 压缩 vs 不压缩 vs 复制

  当垃圾收集器标记出内存中哪些是活的，哪些是垃圾对象后，收集器可以进行压缩，将所有活的对象移到一起，这样新的内存分配就可以在剩余的空间中进行了。经过压缩后，分配新对象的内存空间是非常简单快速的。

  相对的，不压缩的收集器只会就地释放空间，不会移动存活对象。优点就是快速完成垃圾收集，缺点就是潜在的碎片问题。通常，这种情况下，分配对象空间会比较慢比较复杂，比如为新的一个大对象找到合适的空间。

  还有一个选择就是复制收集器，将活的对象复制到另一块空间中，优点就是原空间被清空了，这样后续分配对象空间非常迅速，缺点就是需要进行复制操作和占用额外的空间。

 

 

性能指标

---

以下几个是评估垃圾收集器性能的一些指标：

• 吞吐量：应用程序的执行时间占总时间的百分比，当然是越高越好

• 垃圾收集开销：垃圾收集时间占总时间的百分比（1 - 吞吐量）

• 停顿时间：垃圾收集过程中导致的应用程序挂起时间

• 频次：相对于应用程序来说，垃圾收集的频次

• 空间：垃圾收集占用的内存

• 及时性：一个对象从成为垃圾到该对象空间再次可用的时间

在交互式程序中，通常希望是低延时的，而对于非交互式程序，总运行时间比较重要。实时应用程序既要求每次停顿时间足够短，也要求总的花费在收集的时间足够短。在小型个人计算机和嵌入式系统中，则希望占用更小的空间。

 

分代收集介绍

---

当我们使用分代垃圾收集器时，内存将被分为不同的「代(generation)」，最常见的就是分为「年轻代」和「老年代」。

在不同的分代中，可以根据不同的特点使用不同的算法。分代垃圾收集基于 「weak generational hypothesis」 假设（通常国人会翻译成 「弱分代」假设）：

• 大部分对象都是短命的，它们在年轻的时候就会死去

• 极少老年对象对年轻对象的引用

年轻代中的收集是非常频繁的、高效的、快速的，因为年轻代空间中，通常都是小对象，同时有非常多的不再被引用的对象。

那些「经历过多次年轻代垃圾收集还存活的对象」会晋升到老年代中，老年代的空间更大，而且占用空间增长比较慢。这样，老年代的垃圾收集是不频繁的，但是进行一次垃圾收集需要的时间更长。

对于新生代，需要选择速度比较快的垃圾回收算法，因为新生代的垃圾回收是频繁的。

对于老年代，需要考虑的是空间，因为老年代占用了大部分堆内存，而且针对该部分的垃圾回收算法，需要考虑到这个区域的「垃圾密度比较低」。

 

 J2SE 5.0 HotSpot JVM 中的垃圾收集器

---

J2SE 5.0 HotSpot 虚拟机包含四种垃圾收集器，都是采用分代算法。包括「串行收集器」、「并行收集器」、「并行压缩收集器」 和 「CMS 垃圾收集器」。

 

HotSpot 分代

---

在 HotSpot 虚拟机中，内存被组织成三个分代：年轻代、老年代、永久代。

大部分对象初始化的时候都是在年轻代中的。

老年代存放经过了几次年轻代垃圾收集依然还活着的对象，还有部分大对象因为比较大所以分配的时候直接在老年代分配。

❝ 如 -XX:PretenureSizeThreshold=1024，这样大于 1k 的对象就会直接分配在老年代❞

永久代，通常也叫 「方法区」，用于存储已加载类的元数据，以及存储运行时常量池等。

 

垃圾回收类型

---

当年轻代被填满后，会进行一次年轻代垃圾收集（也叫做 「minor GC」）。

❝ 下面这两段我也没有完全弄明白，弄明白会更新。至少读者要明白一点，"minor gc 收集年轻代，full gc 收集老年代" 这句话是错的。❞

当老年代或永久代被填满了，会触发 「full GC」（也叫做 「major GC」），full GC 会收集所有区域，先进行年轻代的收集，使用年轻代专用的垃圾回收算法，然后使用老年代的垃圾回收算法「回收老年代和永久代」。如果算法带有压缩，每个代分别独立地进行压缩。

如果先进行年轻代垃圾收集，会使得老年代不能容纳要晋升上来的对象，这种情况下，不会先进行 young gc，所有的收集器都会（除了 CMS）「直接采用老年代收集算法对整个堆进行收集」（CMS 收集器比较特殊，因为它不能收集年轻代的垃圾）。

❝ 基于统计，计算出每次年轻代晋升到老年代的平均大小，if (老年代剩余空间 < 平均大小) 触发 full gc ❞

 

快速分配

---

如果垃圾收集完成后，存在大片连续的内存可用于分配给新对象，这种情况下分配空间是非常简单快速的，只要一个简单的指针碰撞就可以了（「bump-the-pointer」），每次分配对象空间只要检测一下是否有足够的空间，如果有，指针往前移动 N 位就分配好空间了，然后就可以初始化这个对象了。

对于多线程应用，对象分配必须要保证线程安全性，如果使用全局锁，那么分配空间将成为瓶颈并降低程序性能。HotSpot 使用了称之为 「Thread-Local Allocation Buffers (TLABs)」 的技术，该技术能改善多线程空间分配的吞吐量。首先，给予每个线程一部分内存作为缓存区，每个线程都在自己的缓存区中进行指针碰撞，这样就不用获取全局锁了。只有当一个线程使用完了它的 TLAB，它才需要使用同步来获取一个新的缓冲区。HotSpot 使用了多项技术来降低 TLAB 对于内存的浪费。比如，TLAB 的平均大小被限制在 Eden 区大小的 1% 之内。TLABs 和使用指针碰撞的线性分配结合，使得内存分配非常简单高效，只需要大概 10 条机器指令就可以完成。

 

串行收集器

---

使用串行收集器，年轻代和老年代都使用单线程进行收集（使用一个 CPU），收集过程中会 stop-the-world。所以当在垃圾收集的时候，应用程序是完全停止的。

「在年轻代中使用串行收集器」

下图展示了年轻代中使用串行收集器的流程。

年轻代分为「一个 Eden 区和两个 Survivor 区（From 区和 To 区）」。年轻代垃圾收集时，将 Eden 中活着的对象复制到空的 Survivor-To 区，Survivor-From 区的对象分两类，一类是年轻的，也是复制到 Survivor-To 区，还有一类是老家伙，晋升到老年代中。

❝ Survivor-From 和 Survivor-To 是我瞎取的名字。。。❞

如果复制的过程中，发现 Survivor-To 空间满了，将剩下还没复制到 Survivor-To 的来自于 Eden 和 Survivor-From 区的对象直接晋升到老年代。

年轻代垃圾收集完成后，Eden 区和 Survivor-From 就干净了，此时，将 Survivor-From 和 Survivor-To 交换一下角色。得到下面这个样子：