这是我打算写的一系列博客文章的第一部分，其目的是解释垃圾回收在现实世界中的工作方式（特别是在JVM中 ）。 我将介绍一些我认为对于充分理解垃圾收集对于实际目的是必要的理论，但是将其降至最低。

其动机是在各种情况下（例如在Cassandra邮件列表中）不断出现与垃圾回收相关的问题。 尝试提供帮助时的问题是，在针对特定情况定制的邮件列表回复中临时解释垃圾收集的细微差别是一项过多的工作，而您几乎没有关于这种情况的足够信息来告诉某人他们的情况特殊问题是由引起的。

我希望本指南将成为我回答这些问题的参考。 我希望它会足够详细，以便有用，但易于消化，并且对于广泛的读者来说也不够学术性。
我非常感谢您对我需要澄清，改进，彻底淘汰等方面的任何反馈。
这里的许多信息并非特定于Java。 但是，为了避免不断调用通用和抽象术语，我将在可能的地方用Hotspot JVM的具体术语进行发言。

为什么有人要关心垃圾收集器？

这是一个好问题。 完美的垃圾收集器可以在没有人注意到它存在的情况下完成其工作。 不幸的是，没有已知的完美的垃圾回收算法。 此外，实际上对于大多数人可用的垃圾收集器的选择还限于实际上实施的垃圾收集算法的子集。 （类似地， malloc也不是完美的，并且存在其问题，有多种实现方式具有不同的特性。但是，尽管这是一个有趣的话题，但是本文并未尝试对比自动和显式内存管理。）

现实情况是，与许多技术问题一样，需要权衡取舍。 根据经验，如果您使用的是可免费使用的基于Hotspot的JVM：s（Oracle / Sun，OpenJDK）， 那么您最关心的就是垃圾回收器（如果您担心延迟） 。 如果您不这样做，那么垃圾回收器将不会很麻烦–除了可能选择与默认值不同的最大堆大小之外。

所谓等待时间，是指垃圾收集的暂停时间 。 垃圾收集器有时需要暂停应用程序才能完成其某些工作。 这通常被称为停止这世界的停顿（“世界”是从Java应用程序的GC说话的角度，或突变可观测宇宙（因为它是变异堆，而垃圾收集器试图收集重要的是要注意，尽管所有实际可用的垃圾收集器都在应用程序上施加了世界暂停，但这些暂停的频率和持续时间随垃圾收集器，垃圾收集器设置和应用程序行为的选择而变化很大。

就像我们将看到的那样，存在垃圾收集算法，这些算法试图避免需要在停顿世界的暂停中收集整个堆。 这是一个重要属性的原因是，如果在任何时候（即使很少）停止应用程序以完全收集堆，则应用程序所遭受的暂停时间将与堆大小成正比 。 通常，这是您在关心延迟时要避免的主要事情。 也有其他问题，但这通常是一个大问题。

跟踪与参考计数

您可能听说过正在使用引用计数 （例如，cPython在大多数垃圾收集工作中都使用了引用计数方案）。 我不会谈论太多，因为它与JVM：s无关，只说两件事：

• 计数垃圾回收的引用具有的一个属性是，将在删除最后一个引用时立即知道该对象是不可访问的。
• 引用计数将不会检测为不可访问的循环数据结构，并且还有其他一些问题使其无法成为所有垃圾收集的最终选择。

JVM而是使用所谓的跟踪垃圾收集器。 之所以称为跟踪，是因为至少在抽象级别上，识别垃圾的过程涉及获取根集 （例如堆栈上的局部变量或全局变量之类的东西），并跟踪从那些对象到直接或间接所有对象的路径。从所述根集合可以间接到达。 一旦确定了所有可到达的（活动的）对象，就可以通过消除过程来标识符合垃圾收集器释放条件的对象。

基本停止，标记，扫动，恢复

一个非常简单的跟踪垃圾收集器使用以下过程工作：

1. 完全暂停应用程序。
2. 通过跟踪对象图（即，递归地遵循引用），标记所有可到达的对象（从根集开始，参见上文）。
3. 释放所有无法访问的对象。
4. 恢复应用程序。

在单线程环境中，这很容易想象：负责分配新对象的调用将立即返回新对象，或者，如果堆已满，则启动上述过程以释放空间，然后执行通过完成分配并返回对象。
没有一个JVM垃圾收集器像这样工作。 但是，最好理解垃圾收集器的这种基本形式，因为可用的垃圾收集器实质上是上述过程的优化。 JVM不实现这种垃圾回收的两个主要原因是：

• 每个垃圾回收暂停将足以收集整个堆。 换句话说，它的延迟很差。
• 对于几乎所有现实应用程序而言，它都不是执行垃圾回收的最有效方法（它具有很高的CPU开销）。

压缩与非压缩垃圾回收

垃圾收集器之间的一个重要区别是它们是否正在压缩 。 压缩是指将对象移动（在内存中）以将其收集在一个密集的内存区域中，而不是稀疏地散布在较大的区域中。

真实世界的类比：考虑一个随机空间中地板上满是东西的房间。 拿走所有这些东西并将其紧紧塞在角落里实际上就是将它们压实。 释放空间。 记住什么是压实的另一种方法是，设想其中的一台机器会像汽车一样将其压实成一块金属，从而消除了空气所占的全部空间，从而比原来的汽车占用更少的空间（但是有人指出，虽然汽车ID遭到破坏，但堆上的物体却没有！）。

相比之下，非紧凑型收集器从不移动对象。 将对象分配到内存中的特定位置后，该对象将一直保留在那里或直到释放为止。
两者都有一些有趣的属性：

• 执行压缩收集的成本是堆上实时数据量的函数。 如果只有1％的数据处于活动状态，则仅需要压缩1％的数据（复制到内存中）。
• 相比之下，在非紧凑型收集器中，不再可访问的对象仍然意味着记账，因为它们的存储位置必须保持释放状态，以便将来分配使用。
• 在压缩收集器中，分配通常是通过“ 碰到指针”方法来完成的。 您有一些空间区域，并保持当前的分配指针。 如果您分配一个n字节的对象，则只需将该指针加n（我就避免了诸如多线程和暗示的优化之类的复杂性）。
• 在一个非压实集电极，分配涉及找到其中使用一些机构，其依赖于用于跟踪的空闲存储器的可用性的确切机制来分配。 为了满足n字节的分配，必须找到n字节可用空间的连续区域。 如果找不到一个（因为堆是碎片化的 ，这意味着它由可用空间和分配的空间混合在一起），分配将失败。

现实类比：再次考虑您的房间。 假设您是一个压缩收集器。 您可以在闲暇时随意在地板上移动东西。 当您需要为地板中间的那个大沙发腾出空间时，可以四处移动其他东西以腾出适当大小的沙发空间。 另一方面，如果您是一个不紧凑的收藏家，那么地板上的所有东西都会被钉牢，并且无法移动。 尽管您有足够的可用地板空间，但大沙发可能不适合放置–只有一个单独的空间不足以容纳沙发。

分代垃圾收集

大多数现实世界中的应用程序倾向于对短期对象（即已分配的对象，短暂使用的对象，然后不再引用）执行大量分配。 分代垃圾收集器尝试利用此观察结果以提高CPU效率（换句话说，具有更高的吞吐量 ）。 （更正式地说，大多数应用程序具有此行为的假设被称为弱代假设 。）

之所以称其为“世代”，是因为对象分为几代 。 收集器之间的细节会有所不同，但此时的合理近似值是将对象分为两代：

• 年轻的一代是最初分配对象的地方。 换句话说，所有物体都始于年轻一代。
• 老一辈是反对“花钱”的对象，因为他们在年轻一代中度过了一段时间。

代收集者通常更高效的原因是，他们与老一代分开收集年轻一代。 处于稳定状态下进行分配的应用程序的典型行为是，在收集年轻代时经常出现短暂的停顿–不经常出现，但在老一代填满并触发整个堆（旧的和新的）的完整收集时会出现较长的停顿。 如果查看典型应用程序的堆使用情况图，它将类似于以下内容：

锯齿状外观的出现是年轻一代垃圾收集的结果。 接近尾声的时候是老一代人变满了，而JVM对整个堆进行了完整的收集。 该下降结束时的堆使用量是该时间点实际活动集的合理近似值。 （注意：这是针对配置为使用默认JVM吞吐量收集器的Cassandra实例运行压力测试的图；它不反映Cassandra的即开即用行为。）

请注意，仅在该图上的任意时间点选择“当前堆使用情况” 都不会使您了解应用程序的内存使用情况 。 我不能足够强调这一点。 通常认为内存“使用”是活动集 ，而不是任何特定时间的堆使用情况。 堆的使用更多取决于垃圾收集器的实现细节。 应用程序的内存使用量对堆使用量的唯一影响是，它为堆使用量提供了一个下限 。
现在，回到为什么代收集者通常更高效的原因。

假设我们的假设应用是所有物体中有90％ 早逝 ； 换句话说，它们永远无法生存到足以被提升为老一代的程度。 此外，假设我们的年轻一代集合实际上是紧凑的（请参阅前面的部分）。 现在收集年轻一代的成本大约是跟踪和复制它所包含的对象的10％的成本。 剩下的90％的成本很小。 年轻一代的收藏会在充满时发生，并且是世界停下来的停顿。

幸存的对象的10％可能会立即升级为老一代，或者它们可能在年轻一代中再生存一轮或两轮（取决于各种因素）。 但是，要理解的重要总体行为是，对象从年轻一代开始，并由于在年轻一代中生存而提升为老一代。

（精明的读者可能已经注意到，不可能完全分开收集年轻一代–如果旧一代中的对象引用了新一代中的对象该怎么办？这确实是垃圾收集器必须处理的事情；以后的文章会谈论这个。）

优化过程很大程度上取决于年轻一代的规模 。 如果大小太大，则可能太大，以至于与收集它相关的暂停时间是一个明显的问题。 如果大小太小，则可能甚至死得很年轻的物体也不会足够快地死去， 以至于它们死后仍处于年轻一代中。

回想一下，年轻的一代是在变得饱满时收集的； 这意味着它越小，收集它的频率就越高。 进一步回想一下，当对象在年轻一代中幸存下来时，它们将被提升为老一代。 如果大多数对象（尽管早逝）都不会因为其太小而在年轻一代中死亡-他们将被提升到老一代，而代际垃圾收集器试图进行的优化将失败，而您将承担以后在老一代中收集对象的全部费用（加上从年轻一代中复制对象的前期费用）。

平行收集

拥有分代收集器的目的是为了优化吞吐量 ; 换句话说，应用程序在特定时间内完成的工作总量。 副作用是，由于垃圾收集而引起的大多数暂停也会变得更短。 但是，没有尝试消除周期性的完整收集，这意味着完成完整收集所需的暂停时间。

为了减轻这种情况，吞吐量收集器做了一件值得一提的事情：它是并行的 ，这意味着它同时使用多个CPU内核来加速垃圾收集。 确实可以缩短停顿时间，但是您可以走多远还是有一个限制–即使在线性加速的不现实完美情况下（意味着双CPU计数->收集时间的一半），您也会受到数量的限制系统上的CPU内核数。 如果要收集30 GB的堆，即使使用16个并行线程，也将花费大量时间。

用垃圾回收的话来说，并行一词用于表示同时在多个CPU内核上工作的收集器。

增量收集

垃圾回收上下文中的增量是指将需要完成的工作分成较小的块，通常目的是将应用程序暂停多个短暂的时间而不是一个长时间的暂停。 从年轻的一代收集器构成增量功的意义上讲，上述一代收集器的行为是部分增量的。 但是，从总体上看，收集过程不是增量的，因为在旧的一代变满时会发生全部堆收集。
其他形式的增量收集也是可能的； 例如，对于应用程序执行的每个分配，收集器可以执行少量的垃圾收集工作。 该概念与特定的实施策略无关。

并发收集

垃圾回收上下文中的并发是指与应用程序（变异器） 同时执行垃圾回收工作。 例如，在8核系统上，垃圾收集器可能保留两个后台线程，这些线程在应用程序运行时执行垃圾收集工作。 这允许完成大量工作而不会导致应用程序暂停，通常会以一定的吞吐量和实现复杂性为代价（对于垃圾收集器实现者）。

可用的热点垃圾收集器

Hotspot中垃圾收集器的默认选择是吞吐量收集器，它是一个世代的并行压缩收集器。 完全针对吞吐量进行了优化； 在给定时间段内应用程序完成的工作总量。

CMS收集器是解决延迟/暂停时间问题的传统替代方法。 CMS代表并发标记和扫描 ，是指收集器使用的机制。 收集器的目的是最大程度地减少甚至消除长时间的停顿，将垃圾回收工作限制为较短的停顿（通常是并行）停顿，并与应用程序同时执行更长的工作相结合。 CMS收集器的一个重要属性是它不紧凑，因此存在碎片问题（有关详细信息，请参阅后面的博客文章）。

在JDK 1.6和JDK 1.7的更高版本中，有一个新的垃圾收集器，称为G1 （代表Garbage First ）。 像CMS收集器一样，其目的是尝试减轻或消除长时间停顿世界停顿的需求，并且它的大部分工作都是在短暂的停顿世界渐进停顿的同时进行的，其中一些工作也在​​完成中与应用程序同时进行。 与CMS相反，G1 是紧凑的收集器，并且没有碎片问题的困扰-而是有其他折衷的选择（同样，在以后的博客文章中将对此进行更多讨论）。

观察垃圾收集器行为

我鼓励读者尝试使用垃圾收集器的行为。 使用jconsole（与JDK一起提供）或VisualVM （在本文较早的时候生成了该图）来可视化正在运行的JVM上的行为。 但是，尤其要开始运行JVM，以开始熟悉垃圾收集日志的输出（已更新jbellis的反馈–谢谢！）：

• -XX:+PrintGC
• -XX:+PrintGCDetails
• -XX:+PrintGCDateStamps
• -XX:+PrintGCApplicationStoppedTime
• -XX:+PrintPromotionFailure

也有用但冗长（含义在以后的文章中解释）：

• -XX:+PrintHeapAtGC
• -XX:+PrintTenuringDistribution
• -XX:PrintFLSStatistics=1

对于吞吐量收集器，输出非常容易读取。 对于CMS和G1，在没有介绍的情况下，输出对于分析而言更加不透明。 我希望在以后的更新中对此进行介绍。

同时，得出的结论是，每当怀疑与GC相关的问题时，上面的那些选项可能就是您要使用的第一件事。 当人们开始假设GC问题时，这几乎总是我告诉人们的第一件事。 您是否看过GC日志？ 如果您还没有，那可能是在浪费时间猜测GC。

结论

我试图制作一个速成课程介绍，希望对我有启发性，但主要是作为后续文章的背景。 我欢迎任何反馈，尤其是在情况不清楚或我做出太多假设的情况下。 正如我一开始所说的那样，我希望这个系列能够被广泛的读者所接受，尽管我当然确实具有一定的专业水平。 但是，不需要垃圾收集方面的知识。 如果是，我已经失败了-请让我知道。

参考： 实用垃圾收集，第1部分–我们的JCG合作伙伴 Peter Schuller在（mod：world：scode）博客上的介绍