UseConcMarkSweepGC已过时，它的替代品是什么？

Question

Java程序使用JRE 10.0.2发出此警告：

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.

此开关的推荐替代品是什么？

Answer 1

  

删除对CMS的支持，然后删除CMS代码，或者至少更彻底地隔离CMS代码，将减轻GC代码库的维护负担，并加速新开发。 从长期来看，G1垃圾收集器旨在替代大多数CMS。

From the Official JEP

Answer 2

以下是给定in this blog的解决方案（如果您使用的是CMS算法）： （1）。切换到G1 GC算法 从Java 9开始，G1 GC已成为默认的GC算法。因此，您可以考虑将应用程序移至该算法。它可能提供比CMS GC算法更好的性能特征。调参相对较少，因此调整起来容易得多。此外，它提供了从内存中消除重复字符串的选项。如果您可以消除重复的字符串，则可以帮助您减少总体内存占用。

（2）。切换到Z GC算法 Z GC是可伸缩的低延迟垃圾收集器。其目标是使GC暂停时间小于10ms。 Java 11、12中提供了对Z GC算法的早期访问。因此，如果您的应用程序在Java 11、12上运行，则可以考虑升级到Z GC算法。我们对Z GC的初步分析显示了出色的结果。

（3）。继续使用CMS 对于某些应用程序，我们已经看到CMS可以提供​​出色的结果，即使经过大量调整，G1 GC也无法实现。因此，如果您已经探究了其他两个选择，并且确信CMS算法是您在天堂的应用程序的必经之路:-)，则可以考虑使用CMS算法本身运行。在此OpenJDK JDK9-dev邮件列表中甚至还有争论继续保持CMS的生命力。根据我的亲身经历，我看到Java 1.1中不推荐使用的功能和API甚至在Java 12中（甚至20年后）仍然存在。似乎所有已弃用的API和功能似乎都可以生存（并且永不消亡）。因此，继续在CMS上运行也是一种选择。当然，这是您的电话，而您的应用程序利益相关者则是电话。