jvm ide_通过微调JVM Garbage Collector减少Java IDE滞后

jvm ide

有没有想过为什么Eclipse / Netbeans会一直暂停一段时间？特别是当您想向亲爱的同事展示代码中的内容时？感到尴尬和尴尬，不是吗？

我发现大多数情况下IDE会由于执行垃圾收集器而暂停。 JVM设计中的微妙元素很少起作用，通常可以使我们的开发人员免于担心内存消耗，并且大多数人都高兴地知道它可以很好地完成工作，并且在大多数情况下会忽略它。但是，如果我们只是忽略它，运行垃圾收集器的后果可能会让我们感到惊讶。

简而言之，当GC运行时，它将暂停应用程序的执行，直到完成释放内存为止。对于Java绝对不是第一选择的实时系统，这肯定是不可接受的。但是，即使在非关键的大型桌面应用程序中（现代Java IDE确实如此），GC也会使整个应用程序停止运行几秒钟。这可能在一天中发生几次。您可以想象，使用IDE之类的生产力工具，只会降低其“生产力”效果。

一个解决方案是进行一些调整：

增加运行IDE的JVM的内存（请注意，这只会降低调用GC的频率，但是会延长单个GC运行的执行时间–从较大的堆中收集垃圾需要更长的时间…）
将默认的GC引擎切换为更并发的引擎，即使在完整GC停止一切执行之前，它也会尝试连续收集垃圾

第一个选项是大多数Java程序员所熟知的-只需为MaxPermSize及其系列定义合理的值即可。

但是，第二种选择不是很为人所知。关键是Oracle Java Hotspot JVM提供了几种可供选择的GC引擎，我们可以从中选择。而且，它们与默认值不同，即使在大型GC执行之间也会提供连续的垃圾收集，这会减慢一切。

G1垃圾收集器

从Java 7更新4开始，Oracle 在JVM中提供了G1垃圾收集器。

您可以使用以下命令行参数简单地启用它：

-XX:+UseG1GC

G1还有一个有趣的选项来限制GC处理的时间，因此限制了由于GC导致的暂停时间。

-XX:MaxGCPauseMillis=n

我建议将其设置为2000，因为使用IDE时通常可以接受2秒的暂停。请注意，这只是G1收集器的一个软提示-如果GC周期需要更多时间，则不会尊重它，但是在大多数情况下，G1应该尊重它。

有关如何配置G1的更多信息，请参阅Java Hotspot VM G1选项。

CMS垃圾收集器

在某些基准测试中，较早的CMS收集器性能优于较新的G1收集器。

您可以使用以下选项来启用它而不是G1：

-XX:+UseConcMarkSweepGC

特殊的Eclipse调整

GC调整确实有助于提高Netbeans安装的性能。但是，说实话，在Eclipse IDE中，GC调整只是优化性能的众多步骤之一，不幸的是，这只是次要的步骤。有助于做更多事情的是配置方面的调整，例如关闭代码中的某些验证，减小控制台输出的大小。就我而言，控制台输出冻结了Eclipse，以至于我需要将应用程序服务器的标准输出重定向到文件并完全绕过控制台:(

翻译自: https://www.javacodegeeks.com/2016/02/decrease-java-ide-lagging-fine-tuning-jvm-garbage-collector.html

jvm ide