推荐阅读：我凭借这份pdf拿下了蚂蚁金服、字节跳动、小米等大厂的offer
在 JDK 9 中 CMS GC 被废弃后，现有应用程序的最佳处理方法是什么？
流行的 CMS（ Concurrent Mark Sweep） GC 算法在 JDK 9 中被废弃了。根据 JEP-291 中的说明，为了减轻 GC 代码的维护负担以及加速新功能开发，决定在 JDK9 中废弃CMS GC。
因此，从 Java 9 开始，如果您使用 -XX:+UseConcMarkSweepGC（激活 CMS GC 算法的参数）参数启动应用程序，则会在下面显示警告消息：
Java HotSpot(TM) 64-Bit Server VM warning: Option UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in a future release.为什么 CMS GC 会被废弃？
大家都知道轻装上阵，才能加速前行。CMS GC 也是如此。CMS 是一种高度可配置的复杂算法，因此给 JDK 中的 GC代码库带来了很多复杂性。只有 JDK 开发团队简化了 GC 代码库，他们才能在 GC 领域加速和创新。下表总结了可以传递给每个 GC 算法的 JVM 参数的数量：
JVM 大约有 50 个通用的适合所有所有 GC 算法的参数，除了这 50 个参数之外，仅对于 CMS，您还可以传递 72 个额外的参数。如上表所示，此参数比其他任何 GC 算法都要多得多。因此，可想而知，JDK 团队支持所有这些参数所需的编码复杂性。
如果使用了 CMS，后面该怎么办呢？
就目前来看，其实无非就三种选项：
切换到 G1 GC 算法切换到 Z GC 算法（JDK 11、12 中的早期版本）继续使用 CMS接下来，我们来分析下每个选项。
（1）切换到 G1 GC 算法
自 Java 9 以来，G1 GC 已成为默认的 GC 算法。因此，可以考虑将应用程序的 GC 算法移至 G1。它可能会比 CMS GC 算法有更好的性能表现。调参相对较少，因此调整起来容易得多。此外，它还提供了用于从内存中消除重复的字符串的参数选项。如果可以消除重复的字符串，可以减少总体内存占用也是极好的。
（2）切换到 Z GC 算法
Z GC 是一种可扩展的低延迟垃圾回收器。其目标是使 GC 暂停时间小于 10ms。Java 11 和 12 中提供了对 Z GC 算法的早期版本。因此，如果你的应用程序在 Java 11 或 12 上运行，则可以考虑升级到 Z GC 算法。我们对 Z GC 的做了初步实验，都显示了极好的结果。
（3）继续使用CMS
我们发现，对于某些应用程序经过一些参数优化，CMS GC 可以提供 G1 GC 无法提供的出色结果。因此，如果您已经研究过上面两个选项，并且确信只有 CMS GC 算法就是适合你的应用程序，那么可以考虑继续使用 CMS 算法来运行。在 OpenJDK JDK9-dev 邮件列表中，甚至还有继续让 CMS 保持可用状态 的争论。根据我个人的经验，在 Java 1.1 中已废弃的功能和 API 在 Java 12 中仍然还是存在的（即使 20 年之后）。所有已弃用的 API 和功能似乎都可以保留（并且永远不会消失）。因此，继续在使用 CMS GC 也是一种选择。当然，这完全按照你的需要。
结论
请注意，每个应用程序都是唯一且不同的。因此，不要被在互联网上看到的有关 GC 调优（包括本文）的文章所迷惑。当你测试新的 GC 参数配置时，你需要进行彻底的测试，可以看看基准性能特征，然后再做决定。
