如何选择最好的Java垃圾回收器

　　垃圾收集 (GC) 在许多现代编程语言中执行动态内存管理。 对于开发人员来说，复杂的垃圾收集减轻了担心内存管理的负担。
　　本文比较了 Java 垃圾收集器，并解释了如何使用应用程序的吞吐量、延迟和占用空间要求来选择适合您需要的合适的垃圾收集器。
　　选择垃圾收集器
　　应用程序在定义和使用变量时动态分配和释放内存。 在 Java 中，JVM 从操作系统分配内存，并在每次请求新变量时将其提供给应用程序。 在一个或多个后台线程中运行的垃圾收集确定应用程序仍引用内存的哪些部分，并回收未引用的内存以供应用程序重用。
　　Java 提供了许多垃圾收集器来满足不同的应用程序需求。 为您的应用程序选择合适的垃圾收集器主要影响其性能。 基本标准是：吞吐量 ：有用的应用程序活动所花费的总时间与内存分配和垃圾收集的百分比。 例如，如果您的吞吐量为 95%，这意味着应用程序代码在 95% 的时间内运行，而垃圾收集在 5% 的时间内运行。 您希望为任何高负载业务应用程序提供更高的吞吐量。延迟 ：应用程序响应能力，受垃圾收集暂停的影响。 在与人或某个活动进程（例如工厂中的阀门）交互的任何应用程序中，您都希望尽可能降低延迟。足迹 ：进程的工作集，以存储空间和缓存来衡量。
　　不同的用户和应用程序有不同的要求。 有些人想要更高的吞吐量并可以承受更长的交换延迟，而其他人则需要低延迟，因为即使非常短的暂停时间也会对他们的用户体验产生负面影响。 在物理内存有限或有许多进程的系统上，占用空间可能决定了可扩展性。 在接下来的部分中，我们将使用这些应用程序要求来讨论和比较以下垃圾收集器：Serial collectorParallel collectorGarbage-first (G1) collectorZ collectorShenandoah collectorConcurrent Mark Sweep (CMS) collector (deprecated)串行收集器 Serial collector
　　这个垃圾收集器在一个线程上执行它的所有工作。 使用单个线程可以提高效率，因为多个线程之间没有通信开销。
　　串行收集器最适合单处理器机器，因为多处理器机器可以从多线程中受益。 对于具有小数据集的应用程序，也可以在多处理器机器上使用串行收集器。 对于可以容忍暂停并创建非常小的堆的应用程序，此收集器可能是最佳选择。
　　串行收集器是分 代垃圾收集器 。 如 本系列的第 1 部分 所述， 一代 是一组年龄相似的对象。 分代垃圾收集器将所有对象的集合分成几代，并在一次传递中收集一个或多个代中的所有对象。
　　启用串行收集器：-XX:+UseSerialGC
　　在某些硬件和操作系统配置上默认选择串行收集器，您可以使用以下命令显式启用收集器 -XX:+UseSerialGC编译器选项。并行收集器 Parallel collector
　　并行收集器也称为 吞吐量收集器， 因为当吞吐量比延迟更重要时，它通常是最佳选择。 当可以接受长时间的暂停时，您可以使用并行收集器，例如批量数据处理、批处理作业等。
　　并行收集器与串行收集器一样，是一种分代垃圾收集器。 它们之间的主要区别在于并行收集器运行多个线程来加速垃圾收集。
　　如果应用程序要求实现最高吞吐量并且可以接受一秒或更长时间的暂停，则并行收集器可能是合适的。 并行收集器可用于具有在多处理器或多线程机器上运行的大中型数据集的应用程序。
　　启用并行收集器：-XX:+UseParallelGC
　　使用 -XX:+UseParallelGC选项以启用此收集器。 并行收集器还允许您通过其他编译器选项配置其多个参数：-XX:ParallelGCThreads= n 指定垃圾收集器线程的数量。-XX:MaxGCPauseMillis= n 指定最大暂停时间的目标（以毫秒为单位）。 默认情况下，暂停时间没有限制，但使用此选项， 暂停时间为 n 预计 或更少毫秒。-XX:GCTimeRatio= n 有助于实现应用程序的吞吐量目标。 此选项以 1/(1+ 设置用于垃圾收集的时间量 n) 的 比率 。 例如， -XX:GCTimeRatio=24将目标设置为 1/25，因此总时间的 4% 用于垃圾收集。 默认值为 99，这会导致 1% 的时间花在垃圾收集上。垃圾优先 (G1) 收集器
　　G1 是为具有大量内存的多处理器机器设计的服务器式收集器。 收集器试图实现高吞吐量和短暂停时间，同时需要很少的调整。 在某些硬件和操作系统上默认选择 G1，并且可以通过 -XX:+UseG1GC选项。
　　G1 被称为 主要并发收集器， 因为它与应用程序同时执行一些昂贵的工作。 G1 也是一个区域化和分代垃圾收集器，这意味着堆被划分为多个大小相等的区域。 启动时，JVM 会设置区域大小，根据堆大小的不同，区域大小从 1MB 到 32MB 不等。 目标是不超过 2048 个区域。 Eden、survivor 和 old generation（在 描述 本系列的第 1 部分中 ）是这些区域的逻辑集合，并且不连续。
　　G1 收集器可以为满足以下一项或多项标准的应用程序实现高吞吐量和低延迟：大堆大小：具体来说，超过 6GB，其中超过 50% 被活动对象占用。在应用程序运行期间，垃圾收集代之间的分配和提升率可能会有很大差异。堆中有大量碎片。需要将暂停限制在几百毫秒内。
　　字符串重复数据删除：-XX:+UseStringDeduplication
　　从 JDK 8 update 20 开始，G1 收集器通过 提供了另一种优化 字符串重复数据删除 ，这可以将应用程序的堆使用量减少约 10%。 这 -XX:+UseStringDeduplication编译器选项会导致 G1 收集器查找重复字符串并在对重复项执行垃圾收集时保留对一个字符串的单个活动引用。 目前没有其他 Java 垃圾收集器支持字符串重复数据删除。
　　我建议您在测试环境中使用这些选项运行您的应用程序，以查看它们是否实现了内存使用量的减少，然后在生产中启用这些选项。
　　额外的 G1 编译器选项
　　以下是与 G1 收集器相关的选项摘要：-XX:+UseG1GC启用 G1 垃圾收集器。-XX:+UseStringDeduplication启用字符串重复数据删除。-XX:+PrintStringDeduplicationStatistics如果使用上一个选项运行，则打印详细的重复统计信息。-XX:StringDeduplicationAgeThreshold= n 导致达到 的年龄的字符串对象 n 个 垃圾回收周期 被视为重复数据删除的候选对象。 默认值为 3。
　　欲了解更多关于G1垃圾收集器，请参阅 介绍G1垃圾回收 和 收集和阅读G1垃圾收集日志 。 您还可以阅读 G1 收集器调优 以获取 G1 性能改进建议。Z 垃圾收集器 (ZGC)
　　ZGC 是一种低延迟垃圾收集器，适用于非常大（数 TB）的堆。 与 G1 一样，ZGC 与应用程序同时工作。 ZGC 是并发、单代、基于区域、NUMA 感知和压缩。 它不会停止应用线程的执行超过 10 毫秒。
　　此收集器适用于需要非常短暂停时间的具有大量内存的应用程序。 Z 垃圾收集器作为一项实验性功能提供，并通过 -XX:+UnlockExperimentalVMOptions -XX:+UseZGC命令行选项。
　　使用 ZGC 时，设置最大堆大小非常重要，因为收集器的行为取决于分配率差异和数据集的活跃程度。 ZGC 在更大的堆上工作得更好，但浪费不必要的内存也是低效的，因此您需要调整内存使用和可用于垃圾收集的资源之间的平衡。Shenandoah收集器
　　Shenandoah 是另一个暂停时间很短的垃圾收集器。 它通过与应用程序同时执行更多垃圾收集工作来减少暂停时间，包括并发压缩。 Shenandoah 的暂停时间与堆大小无关。 垃圾收集 2GB 堆或 200GB 堆应该有类似的短暂停行为。
　　Shenandoah 最适合需要响应性和短暂停时间的应用程序，而不管堆大小要求。 您可以通过 -XX:+UseShenandoahGC编译器选项。并发标记扫描收集器（已弃用）
　　Concurrent Mark Sweep (CMS) 收集器自 JDK 9 起已被弃用（在两个 JDK 增强提案 JEP-291 和 JEP-363 中进行了讨论 ），建议改用 G1 收集器。
　　该 CMS收集器 已经优选的，这需要很短的垃圾收集暂停时间和可与垃圾收集器共享处理器资源的应用程序运行时的应用程序。 当长寿命年老代很高并且应用程序在具有两个或更多可用处理器的机器上运行时，此收集器提供更多好处。 CMS 收集器可以通过 -XX:+UseConcMarkSweepGC编译器选项。
　　CMS 是一个分代垃圾收集器，收集老年代。 通过与应用程序线程同时执行垃圾收集（特别是标记和清除操作），它可以确保应用程序中的暂停时间较短。 但是，如果 CMS 收集器无法在老年代填满之前清除未引用的对象，或者如果对象分配不能满足老年代的可用空间，CMS 将停止所有应用程序线程执行垃圾收集。 CMS 垃圾收集器无法并发完成垃圾收集的状态称为 并发模式失败 ，这表明 的重要性 调整 CMS 收集器参数 。
　　当 CMS 抛出 OutOfMemoryError 时
　　如果超过 98% 的应用程序总时间花在垃圾收集上，而在连续五个垃圾收集周期中回收的堆不到 2%，则 CMS 会抛出一个 OutOfMemoryError错误。 此功能旨在防止应用程序长时间运行而由于堆太小而进展甚微或没有进展。 如果需要，您可以通过添加选项来禁用错误 -XX:-UseGCOverheadLimit到命令行。
　　CMS 已被弃用，以加速 中其他垃圾收集器的开发 HotSpot 。 消除 CMS 将减轻 GC 代码库的维护负担并加速新的开发。 因此，通过使用 CMS -XX:+UseConcMarkSweepGCJDK 9 中的选项会导致以下警告消息：Java HotSpot(TM) 64-Bit Server VM warning: Ignoring option UseConcMarkSweepGC;   support was removed in 
　　从长远来看，G1 垃圾收集器旨在替代 Concurrent Mark Sweep 收集器的大多数用途。 较新的 Z 和 Shenandoah 收集器也可以与最新的 JDK 而不是 CMS 一起使用。 如果这些收集器都不能满足您的应用程序要求，您仍然可以使用并发标记扫描，只要它在早期版本中仍然受支持。结论
　　选择正确的垃圾收集器在很大程度上取决于您的应用程序的要求及其行为。 本文根据吞吐量、延迟和占用空间对比了六种 Java 垃圾收集器。 您可以使用此信息来选择最适合您的应用程序的垃圾收集器。 有许多垃圾收集器可用，因此您需要在对预期的生产负载进行适当测试后做出选择。