优化目标与策略(Ergonomics)

垃圾收集器、堆和运行时编译器默认选择

• G1(Garbage First)收集器
• GC线程的最大值受限于堆大小和可用的CPU资源
• 初始堆空间为物理内存的1/64
• 最大堆空间为物理内存的1/4
• 分层编译器，同时使用C1和C2

可以将 Java HotSpot VM 垃圾收集器配置为优先满足两个目标之一：最大暂停时间和应用吞吐量。 如果首选目标得到满足，收集器将尝试最大化其他目标。

最大暂停时间目标(Maximum Pause-Time Goal)

暂停时间是垃圾收集器停止应用程序并恢复不再使用的空间的持续时间。 最大暂停时间目标的意图是限制这些暂停的最长时间。

使用命令行选项 -XX:MaxGCPauseMillis=<nnn> 指定最大暂停时间目标。这被解释为向垃圾回收器提示，需要的暂停时间为 nnn 毫秒或更短。 垃圾收集器调整 Java 堆大小和其他与垃圾收集相关的参数，以使垃圾收集暂停时间小于 nnn 毫秒。 最大暂停时间目标的缺省值随收集器的不同而变化。 这些调整可能会导致垃圾收集更频繁地发生，从而降低应用程序的总吞吐量。 但是，在某些情况下，暂停时间的预期目标无法实现。

吞吐量目标(Throughput Goal)

吞吐量目标是根据收集垃圾所花费的时间来度量的，而垃圾收集之外所花费的时间是应用程序时间。

目标由命令行选项 -XX:GCTimeRatio=nnn 指定。垃圾收集时间与应用程序时间的比值为 1/ (1+nnn)。 例如, -XX:GCTimeRatio=19 设置了垃圾收集总时间的 1/20 或 5% 的目标。

用于垃圾收集的时间是所有垃圾收集引起的暂停的总时间。如果吞吐量目标没有达到，那么垃圾收集器可能采取的一个行动是增加堆的大小，以便应用程序在收集暂停之间花费的时间可以更长。

使用空间（Footprint）

如果吞吐量和最大停顿时间目标已经达到，那么垃圾收集器就会减少堆的大小，直到其中一个目标(总是吞吐量目标)无法达到为止。垃圾收集器可以使用的最小和最大堆大小可以分别使用 -Xms=<nnn> 和 -Xmx=<mmm> 来设置最小和最大堆大小。

垃圾收集器实现(Garbage Collector Implementation)

分代垃圾收集（Generational Garbage Collection）

一个对象被认为是垃圾，当无法从正在运行的程序中的任何其他活跃对象的引用访问到它时，VM 可以重用它的内存。

理论上，最简单的垃圾收集算法在每次运行时遍历每个可达对象。任何剩下的东西都被认为是垃圾。这种方法花费的时间与活跃对象的数量成正比，这对于维护大量活跃数据的大型应用程序来说是禁止的。

Java HotSpot 虚拟机合并了许多不同的垃圾收集算法，除了 ZGC 之外，这些算法都使用一种称为分代收集的技术。虽然简单的垃圾收集每次都会检查堆中的每个活动对象，但分代收集利用了大多数应用程序的一些经验观察到的属性，以最小化回收未使用(垃圾)对象所需的工作。这些被观察到的性质中最重要的是弱世代假说，即大多数对象只能存活很短的时间。

图3-1中的蓝色区域是对象生命周期的典型分布。X轴显示以分配的字节为单位的对象生存时间。Y 轴上的字节数是对象中具有相应生存期的总字节数。左边的尖峰表示可以回收的对象(换句话说，已经“死亡”)。 例如，迭代器对象通常只在单个循环期间保持活动。

图3-1 对象生命周期的典型分布

有些对象确实存活时间更长，因此分布向右延伸。例如，通常有一些在初始化时分配的对象会一直存在直到 VM 退出。介于这两个极端之间的是在某些中间计算期间存活的对象，这里看到的是初始峰值右侧的块。有些应用程序具有非常不同的外观分布，但令人惊讶的是，大量应用程序具有这种一般形状。通过关注大多数对象“早逝”这一事实，高效的收集成为可能。

世代（Generations）

为了对此场景进行优化，对内存进行分代管理(存放不同年龄段对象的内存池)。垃圾回收在每一代填满时发生。

绝大多数对象分配在一个专门用于年轻对象的池中(年轻代) ，大多数对象死在那里。 当年轻代的垃圾填满时，触发minor回收，只有年轻代的垃圾会被回收，而其他代的垃圾则不会被回收。这种收集的成本，在第一阶段，与被收集的活对象数量成正比; 年轻代回收垃圾非常快。通常，在每次minor回收期间，年轻代幸存的对象中的一部分被移动到老年代。最终，老年代将被填满并且必须被回收，从而造成major回收，在这个回收中将收集整个堆。major回收通常比minor集合持续时间长得多，因为涉及的对象数量要大得多。图3-2 显示了串行垃圾收集器中代的默认安排:

图3-2 串行收集器中各代的默认安排

在启动时，Java HotSpot VM将整个Java堆保留在地址空间中，但除非需要，否则不为其分配任何物理内存。覆盖 Java 堆的整个地址空间在逻辑上被划分为年轻代和老年代。保留给对象存储的完整地址空间可以分为年轻代和老年代。

年轻代由伊甸园(eden)和两个幸存者(survivor)空间组成。大多数对象最初是在伊甸园中分配的。一个幸存者空间在任何时候都是空的，并且在垃圾收集过程中作为伊甸园和另一个幸存者空间中活动对象的目的地; 在垃圾回收之后，伊甸园和源幸存者空间都是空的。 在下一次垃圾收集中，将交换两个幸存者空间的用途。最近填充的一个空间是将活动对象复制到其他幸存者空间的源。对象以这种方式在幸存者空间之间复制，直到它们被复制了一定次数，或者那里没有足够的空间。这些对象被复制到老年区域中。这个过程也被称为衰老。

性能考虑因素

垃圾收集的主要度量指标是吞吐量和延迟。

• 吞吐量是在长时间内没有花在垃圾收集总时间的百分比。吞吐量包括分配所花费的时间(但通常不需要对分配速度进行调优)。
• 延迟是应用程序的响应能力。垃圾收集暂停会影响应用程序的响应能力。

用户对垃圾回收有不同的要求。

吞吐量和占用空间测量(Throughput and Footprint Measurement)

吞吐量和占用空间最好使用特定于应用程序的指标来度量。

例如，web 服务器的吞吐量可以使用一个客户端负载生成器进行测试。 但是，通过检查虚拟机本身的诊断输出，很容易估计垃圾收集引起的暂停。命令行选项 -verbose:gc 打印有关堆和垃圾收集的信息。下面是一个例子:

[15,651s][info ][gc] GC(36) Pause Young (G1 Evacuation Pause) 239M->57M(307M) (15,646s, 15,651s) 5,048ms
[16,162s][info ][gc] GC(37) Pause Young (G1 Evacuation Pause) 238M->57M(307M) (16,146s, 16,162s) 16,565ms
[16,367s][info ][gc] GC(38) Pause Full (System.gc()) 69M->31M(104M) (16,202s, 16,367s) 164,581ms

输出显示了两个年轻代的回收，接着是应用程序通过调用 System.gc() 启动的full回收。这些行以一个时间戳开始，表示从应用程序启动时开始的时间。 接下来是关于这一行的日志级别(info)和标记(gc)的信息。 然后是 GC 标识号。 在本例中，有三个 gc，分别为36、37和38。 然后记录 GC 的类型和声明 GC 的原因。 在此之后，将记录有关内存消耗的一些信息。该日志使用的格式：“GC之前使用的堆空间” -> “GC后使用的堆空间”。

示例的第一行是239M->57M(307M)，这意味着在GC前使用239MB，并且GC清除了大部分内存，但是57 MB保留了下来。堆大小为307 MB。注意，在这个示例中，full GC 将堆从307 MB 缩小到104 MB。在内存使用信息之后，记录 GC 的开始和结束时间以及持续时间(end-start)。

-verbose:gc 命令是 -Xlog:gc 的别名。-Xlog 是 HotSpot JVM 中日志记录的通用日志记录配置选项。 这是一个基于标记的系统，其中 gc 是标记之一。要获得有关 GC 正在做什么的更多信息，可以配置日志记录，以打印包含 GC 标记和任何其他标记的任何消息。此选项的命令行选项是-Xlog:gc*。

下面是一个用-Xlog:gc* 记录的 G1 年轻代回收的示例:

[10.178s][info][gc,start ] GC(36) Pause Young (G1 Evacuation Pause) 
[10.178s][info][gc,task ] GC(36) Using 28 workers of 28 for evacuation 
[10.191s][info][gc,phases ] GC(36) Pre Evacuate Collection Set: 0.0ms
[10.191s][info][gc,phases ] GC(36) Evacuate Collection Set: 6.9ms 
[10.191s][info][gc,phases ] GC(36) Post Evacuate Collection Set: 5.9ms 
[10.191s][info][gc,phases ] GC(36) Other: 0.2ms 
[10.191s][info][gc,heap ] GC(36) Eden regions: 286->0(276) 
[10.191s][info][gc,heap ] GC(36) Survivor regions: 15->26(38)
[10.191s][info][gc,heap ] GC(36) Old regions: 88->88 
[10.191s][info][gc,heap ] GC(36) Humongous regions: 3->1 
[10.191s][info][gc,metaspace ] GC(36) Metaspace: 8152K->8152K(1056768K)
[10.191s][info][gc ] GC(36) Pause Young (G1 Evacuation Pause) 391M->114M(508M) 13.075ms 
[10.191s][info][gc,cpu ] GC(36) User=0.20s Sys=0.00s Real=0.01s

影响垃圾收集性能的因素

影响垃圾收集性能的两个最重要的因素是总可用内存和专用于年轻代的堆的比例。

总堆（Total Heap）

影响垃圾收集性能的最重要因素是总可用内存。 由于收集发生在代填满时，因此吞吐量与可用内存量成反比。

影响生成代大小的堆选项

许多选项影响代大小。图4-1说明了堆中提交的空间和虚拟空间之间的区别。在初始化虚拟机时，将保留堆的整个空间。可以使用 -Xmx 选项指定保留空间的大小。 如果 -Xms 参数的值小于 -Xmx 参数的值，那么并非所有保留的空间都立即提交给虚拟机。未提交的空间在这个图中被标记为“virtual”。堆的不同部分，即老年代和年轻代，可以根据需要增长到虚拟空间的极限。

其中一些参数是堆的一部分与另一部分的比率。例如，参数 –XX:NewRatio 表示老年代与年轻代的相对大小。

图4-1 堆选项

堆大小的默认选项值

默认情况下，虚拟机在每次回收中增加或缩小堆，以便将每次回收中的可用空间与活动对象的比例保持在特定范围内。

此目标范围由选项 -XX:MinHeapFreeRatio=<minimum> 和 -XX:MaxHeapFreeRatio=<maximum> 设置为百分比，总大小限制在 –Xms<min> 和 –Xmx<max>之间。

使用这些选项，如果一代中的可用空间比例低于40% ，那么这一代将扩展到保持40% 的可用空间，直到这一代的最大允许空间大小。类似地，如果可用空间超过70% ，那么这一代就会收缩，以便只有70% 的空间是可用的，这取决于这一代的最小大小。

Java SE 中用于并行收集器的计算现在用于所有的垃圾收集器。计算的一部分是64位平台的最大堆大小的上限。对于客户端JVM也有类似的计算，这会导致堆的最大空间小于服务器JVM。

以下是关于服务器应用程序堆大小的一般准则:

• 除非你有暂停问题，否则请尝试向虚拟机授予尽可能多的内存。 默认大小通常太小。
• 将 -Xms 和 -Xmx设置为相同的值可以从虚拟机中删除最重要的大小调整决策，从而提高可预测性。但是，如果你做了一个糟糕的选择，那么虚拟机就无法进行补偿。
• 通常，随着处理器数量的增加而增加内存，因为分配可以并行进行。

通过最小化 Java 堆大小来节约动态内存占用

如果你需要最小化应用程序的动态内存占用(执行过程中消耗的最大 RAM) ，那么可以通过最小化 Java 堆大小来实现这一点。

使用命令行选项-XX:MaxHeapFreeRatio(默认值为70%) 和 -XX:MinHeapFreeRatio (默认值为40%)降低相关比例，从而最小化 Java 堆大小。

年轻代

除了总的可用内存之外，影响垃圾收集性能的第二个最重要的因素是专用于年轻代的堆的比例。

年轻代规模的选择

默认情况下，年轻代的大小由选项 -XX:NewRatio 控制。

例如，设置 -XX:NewRatio=3 意味着年轻代和老年代之间的比例为1:3。 换句话说，伊甸园 和 幸存者空间的总和将是堆总大小的四分之一。

选项 -XX:NewSize 和 -XX:MaxNewSize设置了年轻代的下限和上限。 将这些值设置为相同的值可以固定年轻代，就像将 -Xms 和 -Xmx 设置为相同的值可以固定堆总大小一样。这有助于以比 -XX:NewRatio 所允许的整数倍更细的粒度调优年轻代。

幸存者空间调整

你可以使用选项 -XX:SurvivorRatio 来调整幸存者空间的大小，但这通常对性能并不重要。

例如, -XX:SurvivorRatio=6 将伊甸园和幸存者空间之间的比率设置为1:6。 换句话说，每个幸存者的空间是伊甸园的1/6，也就是年轻代的1/8(不是1/7，因为存在两个幸存者的空间)。

如果幸存者空间太小，那么复制收集将直接溢出到老年代中。如果幸存者空间太大，那么它们就是无用的空。在每次垃圾收集时，虚拟机都会选择一个阈值数字，这是一个对象在老化之前可以复制的次数。选择这个门槛是为了让幸存者保持半满状态。 你可以使用日志配置 -Xlog:gc，age可用于显示此阈值以及新生成的对象的年龄。这对于观察应用程序的生命周期分布也很有用。

表4-1 提供了幸存者空间大小的默认值。

年轻代的最大空间是根据总堆的最大空间和 -XX:NewRatio 参数的值计算出来的。-XX:MaxNewSize 参数的默认值"not limited" 意味着计算值不受 -XX:MaxNewSize 的限制，除非在命令行上指定了 -XX:MaxNewSize 的值。

可用的收集器（Available Collectors）

Java HotSpot虚拟机包含3种不同类型的收集器，每种收集器具有不同的性能特征。

• 串行收集器（Serial Collector）
• 并行收集器（Parallel Collector）
• G1收集器（Garbage-First Garbage Collector）

串行收集器（Serial Collector）

串行收集器使用单个线程执行所有垃圾收集工作，这使得它相对高效，因为线程之间没有通信开销。

它最适合于单处理器机器，因为它不能利用多处理器硬件，尽管它可以在多处理器上用于具有小数据集(大约100MB)的应用程序。在某些硬件和操作系统配置上，串行收集器是默认选择的，或者可以使用选项 -XX:+UseSerialGC 显式启用串行收集器。

并行收集器（Parallel Collector）

并行收集器也称为吞吐量收集器，它是一个类似于串行收集器的分代收集器。 串行和并行收集器之间的主要区别是，并行收集器有多个线程，用于加速垃圾收集。

并行收集器用于在多处理器或多线程硬件上运行的具有中等到大型数据集的应用程序。 您可以使用 -XX:+UseParallelGC 选项启用它。

并行压缩是使并行收集器能够并行执行major回收的一个特性。如果不进行并行压缩，major回收将使用单个线程执行，这将极大地限制可伸缩性。如果指定了 -XX:+UseParallelGC 选项，则默认情况下启用并行压缩。 您可以使用 -XX:-UseParallelOldGC 选项禁用它。

G1收集器（Garbage-First Garbage Collector）

G1主要是一个并发收集器。大多数并发收集器并发执行一些代价高昂的工作到应用程序。 此收集器设计用于从小型机器扩展到大型具有大量内存的多处理器机器。 它提供了以高概率满足停顿时间目标的能力，同时实现高吞吐量。

在大多数硬件和操作系统配置中，默认选择 G1，或者可以使用 -XX:+UseG1GC 显式启用 G1。

Z收集器（The Z Garbage Collector）

Z垃圾收集器(ZGC)是一个可伸缩的低延迟垃圾收集器。ZGC并发地执行所有昂贵的工作，而不停止应用程序线程的执行。

ZGC 适用于需要低延迟(少于10毫秒的暂停) 或 使用非常大的堆(TB级)的应用程序。 可以通过使用 -XX:+UseZGC 选项启用。

ZGC是一个实验性的特性，从 JDK 11开始。

选择收集器

如果需要，调整堆大小以提高性能。如果性能仍然不能达到你的目标，那么使用下面的准则作为选择收集器的起点:

• 如果应用程序有一个小的数据集(大约100 MB) ，那么使用选项 -XX:+UseSerialGC 选择串行收集器。
• 如果应用程序将在单处理器上运行，并且没有暂停时间要求，那么使用选项 -XX:+UseSerialGC 选择串行收集器。
• 如果(a)峰值应用程序性能是第一优先级，并且(b)没有暂停时间要求或者一秒或更长的暂停是可以接受的，那么让 虚拟机 选择收集器或者用 -XX:+UseParallelGC选择并行收集器。
• 如果响应时间比总吞吐量更重要，并且垃圾收集暂停时间必须更短，那么选择主要并发的收集器，使用 -XX:+UseG1GC。
• 如果响应时间是一个高优先级，或者你正在使用一个非常大的堆，那么选择一个完全并发的收集器，使用 -XX:UseZGC。

这些准则只是选择收集器的起点，因为性能取决于堆的大小、应用程序维护的实时数据量以及可用处理器的数量和速度。

如果推荐的收集器没有达到预期的性能，那么首先尝试调整堆和分代大小，以满足预期的目标。 如果性能仍然不足，那么尝试另一个收集器: 使用并发收集器来减少暂停时间，并使用并行收集器来增加多处理器硬件上的总吞吐量。

小结：

• 如果应用程序是小数据集或是单处理器上运行，选择串行收集器。
• 如果吞吐量是第一优先级，而没有暂停时间要求，选择并行收集器。
• 如果响应时间比吞吐量更重要，选择G1收集器。
• 如果最关注响应时间，或者堆非常大（TB级），则使用Z收集器。

并行收集器

并行收集器(也称为吞吐量收集器)是类似于串行收集器的分代收集器。 串行和并行收集器之间的主要区别是，并行收集器有多个线程，用于加速垃圾回收。

通过命令行选项 -XX:+UseParallelGC 启用并行收集器。 默认情况下，使用此选项，次要(minor)和主要(major)回收都将并行运行，以进一步减少垃圾回收开销。

并行垃圾收集器线程数

可以使用命令行选项 -XX:ParallelGCThreads=<N> 控制垃圾收集器线程的数量。

并行收集器中分代的排列

在并行收集器中，各代的排列方式是不同的。

图6-1 并行收集器中各代的排列

并行收集器调优（Parallel Collector Ergonomics）

当使用 -XX:+UseParallelGC 选择并行收集器时，它支持自动调优方法，允许您指定行为，而不是分代大小和其他低级调优细节。

指定并行收集器行为的选项

• 最大垃圾收集暂停时间: 使用命令行选项 -XX:MaxGCPauseMillis=<N> 指定最大暂停时间目标。这被解释为需要 毫秒或更少的暂停时间；默认情况下，没有最大暂停时间目标。如果指定了暂停时间目标，则会调整堆大小和与垃圾收集有关的其他参数，以使垃圾收集暂停时间短于指定值; 但是，可能并不总是能够达到所需的暂停时间目标。 这些调整可能会导致垃圾收集器降低应用程序的总吞吐量。

• 吞吐量: 吞吐量目标是根据执行垃圾回收所花费的时间与垃圾回收之外所花费的时间(称为应用程序时间)来度量的。目标由命令行选项 -XX:GCTimeRatio=<N> 指定，该选项将垃圾收集时间与应用程序时间的比率设置为1 / (1 + )。

  例如, -XX:GCTimeRatio=19 设置了垃圾收集占总时间的1/20或5%的目标。 默认值为99，结果是垃圾回收时间的目标为1%。

• 内存空间: 使用选项 -Xmx<N> 指定最大堆内存占用。此外，收集器还有一个隐式目标，即在满足其他目标的情况下最小化堆的大小。

并行收集器目标的优先级

目标是最大暂停时间目标、吞吐量目标和最小占用空间目标，目标按照这个顺序实现:

首先实现最大暂停时间目标。只有在满足了这个要求之后，吞吐量目标才能实现。 同样，只有在前两个目标已经实现之后，才会考虑内存大小目标。

并行收集器默认堆大小

除非在命令行中指定了初始堆大小和最大堆大小，否则将根据计算机上的内存量计算它们。默认的最大堆大小是物理内存的1/4，而初始堆大小是物理内存的1/64。 分配给年轻代的最大空间是总堆大小的1/3。

并行收集器初始和最大堆大小的规范

你可以使用选项 -Xms和 -Xmx 指定初始堆大小和最大堆大小。

如果您知道应用程序需要多少堆才能正常工作，那么可以将 -Xms 和 -Xmx 设置为相同的值。如果您不知道，那么 JVM 将开始使用初始堆大小，然后增加 Java 堆，直到找到堆使用量和性能之间的平衡。

其他参数和选项可能会影响这些默认值。要验证默认值，请使用 -XX:+PrintFlagsFinal 选项并在输出中查找 -XX:MaxHeapSize。 例如，在 Linux 上你可以运行以下命令:

java -XX:+PrintFlagsFinal <GC options> -version | grep MaxHeapSize

过长的并行收集器时间和OutOfMemoryError

如果在垃圾回收(GC)上花费了太多时间，并行收集器将抛出 OutOfMemoryError 错误。

如果超过98% 的总时间用于垃圾回收，而回收的堆不到2%，则抛出 OutOfMemoryError。此特性旨在防止应用程序在较长时间内运行，同时由于堆太小而几乎或根本没有进展。如果需要，可以通过向命令行添加选项 -XX:-UseGCOverheadLimit 来禁用此特性。

G1垃圾收集器

G1垃圾收集器的目标是将多处理器机器扩展到大量内存。它试图以较高的概率满足垃圾收集暂停时间目标，同时实现较高的吞吐量而不需要进行配置。G1的目标是使用当前的目标应用程序和环境，在延迟和吞吐量之间提供最佳的平衡。

与吞吐量收集器相比，虽然G1收集器的垃圾收集暂停时间通常要短得多，但应用程序吞吐量也往往略低。

G1是默认收集器。

启用G1

G1垃圾回收器是默认回收器，因此通常不需要执行任何其他操作。您可以通过在命令行上提供 -XX:+UseG1GC 来显式启用它。

基本概念

G1是一个分代的、递增的、并行的、大部分并发的、stop-the-world和疏散垃圾收集器，它监视每个stop-the-world暂停的时间目标。与其他收集器类似，G1将堆分为(虚拟的)年轻代和老年代。空间回收的努力集中在年轻代身上，这样做效率最高，偶尔的空间回收在老年代中。

有些操作总是在stop-the-world暂停中执行，以提高吞吐量。应用程序停止的其他操作会花费更多时间，比如全局标记之类的整堆操作会与应用程序并行执行。 为了使stop-the-world在空间回收方面的停顿时间缩短，G1逐步并行地进行空间回收。 G1通过跟踪以前应用程序行为的信息和垃圾收集暂停来构建相关成本的模型，从而实现可预测性。它利用这个信息来计算停顿时所做的工作量。例如，G1首先在效率最高的区域回收空间(这些区域大部分都是垃圾，因此取名为 G1)。

G1主要通过撤离来回收空间: 在选定的内存区域内找到的活动对象被复制到新的内存区域，并在处理过程中对其进行压缩。在完成疏散之后，以前被活动对象占用的空间将被应用程序重用以进行分配。

G1收集器不是实时收集器。它试图在更长的时间内以高概率实现设定的暂停时间目标，但在给定的暂停时间内并不总是绝对确定。

堆布局

G1将堆划分为一组大小相同的堆区域，每个区域都有一个连续的虚拟内存范围，如图7-1所示。区域是内存分配和内存回收的单位。在任何给定的时间，这些区域中的每一个都可以是空的(浅灰色) ，或者分配给特定的一代，年轻的或老年的。当内存请求进入时，内存管理器分配空闲区域。内存管理器将它们分配给一个代，然后将它们作为可用空间返回给应用程序，应用程序可以将其分配给自己。

图7-1 G1垃圾收集器堆布局

年轻代包含伊甸园区域(红色)和幸存者区域(红色带有"S")。这些区域提供了与其他收集器中的相应连续空间相同的功能，不同之处在于，在G1中，这些区域通常以非连续的模式布局在内存中。老区域(浅蓝色)组成了老年代。对于跨越多个区域的对象，老年代区域可能非常巨大(浅蓝色带"H")。

应用程序总是分配给年轻代，即伊甸园区域，但直接分配给老年代的大型对象除外。

垃圾回收周期

在较高的水平上，G1收集器在两个阶段之间交替。只有年轻（young-only）阶段包含垃圾回收，这些垃圾回收会逐渐用老年代中的对象填充当前可用的内存。在空间回收阶段，除了处理年轻代的问题外，G1逐步收回老年代的空间。然后循环重新开始，只有年轻的阶段。

Figure 9-2 gives an overview about this cycle with an example of the sequence of garbage collection pauses that could occur:

图7-2给出了这个循环的概述，并举例说明了可能发生的垃圾收集暂停的顺序:

图7-2 垃圾收集周期概览

下面的列表详细描述了G1垃圾收集周期的各个阶段，它们之间的停顿和过渡:

1. 纯年轻(Young-only)阶段

   这个阶段从几个普通(Normal)的年轻代回收开始，将对象升级到老年代。 当老年代占有率达到一定阈值时，即初始堆占有率阈值，纯年轻(young-only)阶段和空间回收(space-reclamation)阶段开始转换。此时，G1计划一个并发启动(Concurrent Start)年轻代回收，而不是普通(Normal)的年轻代回收。

   • 并发启动(Concurrent Start)：这种类型的回收除了执行普通年轻代回收之外，还启动标记(marking)过程。
   • 重标记(Remark)：此暂停将自行确定标记，执行全局引用处理和类卸载，回收完全空的区域并清理内部数据结构。
   • 清理(Cleanup)：这个暂停决定了是否会真正进入空间回收阶段。

2. 空间回收(Space-reclamation)阶段：这一阶段包括多个混合(Mixed)回收，除了年轻代区域，还删除老一代区域的成套活动对象。当G1认为删除更多的老年代区域不会产生足够的自由空间时，空间回收阶段就结束了。

在空间回收之后，收集周期从另一个young-only的阶段重新开始。作为备份，如果应用程序在收集存活信息时耗尽了内存，G1会像其他收集器一样执行就地stop-the-world的完全堆压缩(Full GC)。

G1内部细节

Java堆大小调整

G1在调整Java堆大小时遵循标准规则，使用 -XX:InitialHeapSize 作为最小的 Java 堆空间, -XX:MaxHeapSize 作为最大的 Java 堆空间, -XX:MinHeapFreeRatio 作为最小的可用内存百分比, -XX:MaxHeapFreeRatio 用于确定调整大小后可用内存的最大百分比。 G1收集器仅在执行重标记(Remark) 和 Full GC 暂停期间考虑调整 Java 堆的大小。 这个过程可以从操作系统释放内存或分配内存。

Young-Only阶段代调整

G1总是在下一个突变子阶段的正常年轻代回收结束时测量年轻代的大小。通过这种方式，G1可以满足使用 -XX:MaxGCPauseTimeMillis 和 -XX:PauseTimeIntervalMillis 设置的暂停时间目标，该目标基于对实际暂停时间的长期观察。它考虑到了同样规模的年轻代需要多长时间才能删除。这包括在回收过程中需要复制多少对象以及这些对象之间的互联程度等信息。

如果没有其他限制，那么 G1可以在 -XX:G1NewSizePercent 和 -XX:G1MaxNewSizePercent 确定的值之间自适应地调整年轻代大小，以满足暂停时间的要求。

或者，可以使用 -XX:NewSize 和 -XX:MaxNewSize 分别设置年轻代的最小值和最大值。

注意: 只指定后面这些选项中的一个，就可以将年轻代大小精确地固定为分别使用 -XX:NewSize 和 -XX:MaxNewSize 传递的值。这将禁用暂停时间控制。

空间回收阶段的代调整

在空间回收阶段，G1试图在一次垃圾回收暂停中最大化在老年代中回收的空间量。 年轻年代的大小设置为允许的最小值，通常由 -XX:G1NewSizePercent 确定。

周期性的垃圾收集

如果由于应用程序不活跃而导致长时间没有垃圾收集，那么虚拟机可能会长时间保留大量未使用的内存，这些内存可以在其他地方使用。为了避免这种情况，可以强制 G1使用 -XX:G1PeriodicGCInterval 选项执行常规垃圾收集。此选项确定 G1考虑执行垃圾回收的最小间隔(毫秒)。如果自以前任何垃圾收集暂停以来已经过去了这段时间，并且没有正在进行的并发循环，G1将触发额外的垃圾回收。

确定初始堆占用率

启动堆占用百分比(Initiating Heap Occupancy Percent, IHOP)是触发初始标记回收的阈值，它被定义为老年代大小的百分比。

默认情况下，G1通过在标记周期中观察标记需要多长时间以及在老年代中通常分配多少内存来自动确定最佳IHOP。这个特性称为自适应IHOP。如果这个特性是活动的，那么选项 -XX:InitiatingHeapOccupancyPercent 确定初始值作为当前老年代代大小的百分比，只要没有足够的观测值来很好地预测启动堆占用阈值。 使用 -XX:-G1UseAdaptiveIHOP 选项关闭 G1的此行为。 在这种情况下, -XX:InitiatingHeapOccupancyPercent 的值总是决定这个阈值。

标记

G1标记使用一种称为“初始快照”(Snapshot-At-The-Beginning，SATB)的算法。 它在初始标记暂停时拍摄堆的虚拟快照，此时所有在标记开始时处于活动状态的对象都被认为在标记的剩余时间处于活动状态。这意味着，为了空间回收的目的(除了一些例外) ，在标记期间变为死的(不可到达的)对象仍然被认为是活的。与其他收集器相比，这可能会导致一些额外的内存被错误地保留。但是，SATB 可能在Remark暂停期间提供更好的延迟。在这个标记期间过于保守地考虑活动对象将在下一个标记期间被回收。

G1 GC的默认选项

与其它收集器的比较

这是G1与其他收集器之间主要区别的摘要：

• 并行 GC 只能作为一个整体压缩和回收老年代中的空间。G1增量地将这些工作分配到多个更短的回收中。这大大缩短了暂停时间，但是却降低了吞吐量。
• G1并发执行部分老年代空间回收。
• G1可能比上述收集器显示更高的开销，由于并发性而影响吞吐量。
• ZGC针对非常大的堆，目的是以更高的吞吐量成本提供更小的停顿时间。

由于它的工作原理，G1有一些独特的机制来提高垃圾回收效率:

• 在任何回收过程中，G1都可以回收老年代中一些完全空置的、大的区域。 这可以避免许多其他不必要的垃圾回收，不需要太多努力就可以释放大量空间
• G1可以选择尝试同时对Java堆上的重复字符串进行重复数据删除。

从老年代回收空的大型对象始终处于启用状态。您可以使用 -XX:-G1EagerReclaimHumongousObjects 选项禁用此功能。 默认情况下禁用字符串重复数据删除。 您可以使用选项 -XX:+G1EnableStringDeduplication 启用它。

Z垃圾收集器

Z垃圾收集器(ZGC)是一个可伸缩的低延迟垃圾收集器。ZGC并发地执行所有昂贵的工作，而不需要停止应用程序线程的执行超过10ms，这使得它适合于需要低延迟或使用非常大的堆(TB级)的应用程序。

Z垃圾收集器是一个实验性特性，可以通过命令行选项 -XX:+UnlockExperimentalVMOptions -XX:+UseZGC 启用。

设置堆大小

ZGC最重要的调优选项是设置最大堆大小(-Xmx)。

设置并发GC线程数

可能需要考虑的第二个调优选项是设置并发GC线程的数量(-XX:ConcGCThreads)。

其它考虑因素

显式垃圾回收

应用程序与垃圾回收交互的另一种方式是使用 System.gc() 显式调用full垃圾回收。

类元数据(Class Metadata)

Java类在 Java Hotspot虚拟机中有一个内部表示，称为类元数据。

在Java Hotspot虚拟机的以前版本中，类元数据是在所谓的永久代(permanent generation)中分配的。从JDK 8开始，永久代被删除，类元数据在本机内存中(native memory)分配。默认情况下，可用于类元数据的本机内存量是无限的。使用选项 -XX:MaxMetaspaceSize 对用于类元数据的本机内存量设置上限。

来源：http://dwz.date/dMSu