问调优JVM (GC)以实现高响应服务器应用程序

EN

结果:次要GC耗时0.01 ~ 0.02秒，次要GC耗时1~3秒，次要GC持续发生。

除非您报告暂停，否则我会说CMS收集器正在执行您要求它执行的操作。根据定义，CMS将使用比串行和并行收集器更大的CPU百分比。这是您为较低的暂停时间付出的代价。

如果你看到1到3秒的暂停时间，我会说你需要做一些调整。我不是专家，但是看起来您应该从减少CMSInitiatingOccupancyFraction的默认值92开始。

增加堆大小将提高GC的“吞吐量”。但是，如果您的问题是长时间停顿，那么增加堆大小可能会使问题变得更糟。

小心..。如果你不小心的话，GC可能会成为一个棘手的话题。在任何运行时(JVM for Java / CLR for .Net)中，都会发生几个进程。通常存在内存的早期优化(年轻一代垃圾收集/年轻一代垃圾收集和老一代垃圾收集/老一代GC)。年轻一代的gc定期发生，通常归因于你较小的停顿/打呃。旧的gen gc通常是当你看到长时间的"stop The world“暂停时正在发生的事情。

你为什么会问呢？运行时/ JVM暂停的原因是，当运行时清理堆时，它必须经历所谓的阶段变化。它会停止运行应用程序的线程，以便标记和交换指针以优化可用内存。Yong gen的速度更快，因为它主要释放临时的对象。然而，旧的gen会评估堆上的所有对象，当你耗尽内存时，它将释放急需的内存。

为什么要如此谨慎？随着你使用的堆越多，旧的gen在暂停时间上会变得指数级的糟糕。在总堆大小为2-4 GB的情况下，您应该可以在Java6 (JDK 1.6+)等现代运行时上运行。一旦你超过了这个限制，你会看到暂停时间呈指数级增长。我遇到过一些必须重新启动服务器的客户端--在极少数情况下，堆很大，GC暂停时间可能比完全重新启动花费更长的时间。

有一些新的工具非常酷，可以让你在评估GC是否是你的痛苦时处于领先地位。JHiccup就是其中之一，它可以从azulsystems网站上免费下载。不过，目前我认为它只适用于Linux。他们也有一个JVM，它有一个重新构建的GC算法，可以运行pauseless ...但是，如果您使用的是带有非关键应用程序的单服务器部署，则可能不符合成本效益(该应用程序不是免费的)。

总而言之，如果您的运行时/ JVM / CLR堆小于2 GB，添加更多内存将有所帮助。一定要给自己留点开销。如果可能，你永远不会想要达到100%的堆大小/内存大小。这就是长时间停顿时间最长的时候。给你自己额外的20%+内存，而不是你认为你需要的东西。这样，您就有空间让GC算法移动对象以进行优化。如果你打算做大的..。有一个工具可以修复大约1990年的JVM技术(Azul Systems Zing JVM)，但它不是免费的。他们确实提供了一个开源工具来诊断GC问题。JVM (正如我已经尝试过的)还有一个非常酷的线程级可见性工具，它允许您报告生产中的任何泄漏、错误或锁定，而不会产生开销(一些关于卸载JVM已经处理的数据和时间戳的技巧)。这节省了大量的开发测试时间。但再说一次，不是为小应用程序准备的。

保持在4 GB以下。留出额外的余量。如果需要，您可以打开这些标志来监视Java /JVM的GC：

java -verbose:gc myProgram
java -Xloggc:D:/log/myLogFile.log -XX:+PrintGCDetails myProgram

你可以试试Hotspot使用的其他收集器。有不止一个。

如果您使用的是Linux，那么也可以尝试使用JHiccup工具。它是免费的。

您可能对尝试低暂停Garbage-First collector而不是并发标记清除感兴趣(尽管它不一定对所有集合都有更高的性能，但它应该有更好的最坏情况)。它是由-XX:+UseG1GC启用的，应该是非常棒的，但在将其用于生产之前，您可能想要对其进行彻底的评估。从那以后，它可能有所改善，但一年前似乎有点but，如Experience with JDK 1.6.x G1 (“Garbage First”)所示