Java VM –提防YoungGen空间

您可能从我们以前的面向性能的文章中看到，健康的JVM是实现最佳应用程序性能和稳定性的最重要目标之一。这样的健康评估通常仅关注主要收集的频率（避免）或检测内存泄漏的存在。年轻一代空间或短寿命物体的大小和足迹如何？

本文基于一个真实的故事和我们与一位IT客户的最新故障排除经验。它将通过一个示例应用程序证明，过多的内存占用空间和次要收集的频率可能会引发性能问题，就像其老兄，旧一代或使用期限的空间一样严重。

JVM健康状况诊断

如果您不熟悉JVM调优领域，那么您很快就会意识到，没有适用于所有应用程序的通用解决方案。无论您可以从各种来源从Web上找到高质量的材料，您仍需要进行尽职调查并正确了解您正在处理的应用程序类型，包括其对JVM GC暂停的敏感性（某些应用程序需要非常较低的JVM暂停时间<1％）。

Java性能分析（包括内存泄漏检测）以及性能和负载测试是为收集所有正确数据以及有关应用程序内存占用量和JVM运行时运行状况的事实而需要执行的额外工作的良好示例。

话虽这么说，“健康的” JVM是什么意思？请尽您所能回答以下问题。

**如果回答“否”，请假设置信度为90％+，否则回答“我不知道”。

您的Java堆或OldGen空间是否随着时间的流逝而泄漏（在进行重大收集之后）？
您的应用程序当前受大型和/或频繁的JVM GC暂停影响吗？
JVM的总体暂停时间是否高于5％或高于已建立的理想基准？
当前，您的应用程序响应时间是否经常受到JVM GC活动的定期影响，并且超出了应用程序的承受能力？
在最近3个月中，您是否观察到java.lang.OutOfMemoryError错误的发生？
您是否在最近3个月内观察到JVM崩溃的发生（带有核心转储和崩溃报告的JVM突然故障）？
您是否认为您的JVM当前不稳定并且/或者需要过多的人工干预（定期重启等）？

如果您回答“是”或“我不知道”，这意味着您或您的生产性能调整团队可以在这里做一些工作，包括查看当前的JVM GC策略。

如果您对所有具有高置信度级别的用户回答“否”，则意味着您可能已经获得了可靠的应用程序和JVM稳定性，祝贺您。我仍然建议您重新评估主要版本和增量负载预测之间的情况。

青年一代：真的停止世界吗？

正如我们从快速的JVM健康状况评估练习中看到的那样，要点之一是指JVM的总体暂停时间。这实际上意味着JVM在“停止世界”事件期间花费了多少时间。在此期间，应用程序线程将被挂起并且不执行任何工作，从而增加了应用程序的响应时间。该指标至关重要，因为较大的JVM暂停将触发不稳定且不可预测的响应时间。

我在过去几年中看到的一个普遍误解是，YoungGen或次要集合是完全透明的，并且不会影响应用程序的响应时间。如果您的Java堆大小很小（YG空间<1 GB），并且处理的对象生存期或分配率适中，则此语句几乎是正确的。在这种情况下，如果次要收集执行得非常快（<20 ms）并且执行得不太频繁（每30秒以上），则YoungGen空间贡献的总体JVM暂停时间将保持很小（<< 1％）。但是，如果YG内存分配率提高（每个请求的占用空间增加，流量激增等），情况可能会很快改变。

我建议以下文章，以获取有关可用于HotSpot JVM的YoungGen空间和并发收集器的更多详细信息。

＃Oracle HotSpot主要是并发收集器：CMS vs. G1

http://www.oracle.com/webfolder/technetwork/tutorials/obe/java/G1GettingStarted/index.html

＃Oracle HotSpot次要收藏详尽介绍

http://www.oracle.com/technetwork/java/javase/gc-tuning-6-140523.html
http://blog.griddynamics.com/2011/06/understanding-gc-pauses-in-jvm-hotspots_02.html

无论您使用的HotSpot GC策略如何，包括大多数并发的收集器（例如CMS或G1），YoungGen空间收集仍然是“世界停止”事件。据我们所知， Azul Zing C4是唯一宣传为真正的连续并发压缩收集器的JVM收集器。目前，我们还没有机会尝试使用该收集器。我欢迎任何具有C4调优经验的人分享他们的观察结果，尤其是真实的事实数据，而不是像G1这样的大多数并发收集器。

现在，我们已经涵盖了一些理论，下面让我们深入研究示例应用程序，并针对各种YoungGen占用空间和分配比率来回顾性能测试结果。

样本应用规范

为了比较各种YG分配率之间的响应性和JVM暂停时间％，我们根据以下规范创建了一个示例应用程序：

根据以下属性，已创建JAX-RS（REST）Web服务，并通过jvm URI公开了该服务。

@GET@Path("/jvm")@Produces(MediaType.APPLICATION_JSON)public Integer jvm() {}

每次对jvm的调用都执行以下逻辑：

1.分配短期对象的预定大小（适用于快速YG GC）。

此外，在类加载时会分配1 GB的长寿命对象（不适合GC）的初始内存占用空间，以便为CMS收集器创建一些噪音。

YG短期对象的内存分配和OldGen静态保留仅通过按照下面的代码片段创建原始字节值的静态数组即可实现。根据使用MAT进行的JVM堆转储分析，可以观察到真正的内存占用量。

private final static int LONG_LIVED_OBJ_FOOTPRINT = (1024 * 1024 * 1024);
private final static int SHORT_LIVED_OBJ_FOOTPRINT = (100 * 1024 * 1024);// 1 GB static memory footprint
private final static byte byteArrayLongLivedObj[] = new byte[LONG_LIVED_OBJ_FOOTPRINT];// 100 MB memory allocation (waste) created per execution
public void generateShortLivedObj(String objId) {          byte byteArrayShortLivedObj[] = new byte[SHORT_LIVED_OBJ_FOOTPRINT];
}

最后，在下面找到环境规格和用于创建，执行和监视此YG比较性能测试的软件。

作业系统：Windows 7 @ 64-bit
Java EE容器： WildFly 8 Beta1
JVM：Oracle HotSpot 1.7 @ 64位，Java堆大小为5 GB（YG空间：1152 MB XX：NewRatio = 3）。 GC收集器：CMS
IDE： JBoss Developer Studio 7.0.0.GA
JVM监视： JVisualVM
JVM内存泄漏分析器： Plumbr 3.0
JVM verbose：gc日志分析器： GCMV
性能和负载测试： Apache JMeter 2.9

性能测试结果和观察

以下性能测试模拟了一个现实生活中的应用程序，该应用程序需要处理大量的JVM暂停时间以及在峰值负载下的严重降级。在模拟每个请求的应用程序内存占用量的改善（减少）之后，执行了3次运行，其中1次作为基线运行，另外2次运行。

基准线

10个并发线程
每个JVM进程每次执行创建100 MB的短期对象

寿命短的对象的内存占用空间可能看起来很极端，但这确实是我们最初要解决的问题。

结果

平均响应时间：140毫秒
吞吐量：68请求/秒
JVM总体暂停时间： 25.8％
YG收集频率：每秒7个收集
GC速度：每分钟308909 MB

根据JVisualVM，JVM看起来很健康（没有内存泄漏，稳定且OldGen低等）。但是，当您在verbose：gc日志中进一步深入研究时，您会发现JVM的总体暂停时间为25.8％，这都是由于YG收集频率过高所致。这有力地证明了正确分析verbose：gc日志和仅关注JVM持久空间趋势的意义。

测试与调整＃1

10个并发线程
每个JVM进程每次执行创建50 MB的短期对象

此运行模拟了应用程序占用空间和内存分配率从每个分配的100 MB到50 MB的初始改善。通过简单地减少每个请求的应用程序内存占用量，我们可以清楚地看到所有数字的改进，特别是吞吐量。

结果

平均响应时间：119 ms -21
吞吐量：79要求/秒+11
JVM整体暂停时间： 15.59％-10.21
YG收集频率：每秒3-4次收集-3
GC速度：每分钟164950 MB -143959

测试与调整＃2

10个并发线程
每个JVM进程每次执行创建5 MB的短期对象

此运行模拟了将应用程序占用空间和内存分配率从100 MB大大降低到每个分配仅5 MB的情况。

结果

平均响应时间：107毫秒-33
吞吐量：90请求/秒+22
JVM总体暂停时间： 1.9％-23.9
YG收集频率：每2-3秒收集1次*大幅减少
GC速度：每分钟15841 MB -293068

如您所见，对应用程序占用空间和内存分配的最终改进确实将JVM暂停时间显着减少到了可接受的1.9％。重要的是要注意，在这3个测试中，OldGen占用空间和CMS活动对JVM暂停时间没有任何实质性影响，性能问题是由于活动过多以及与YG相关的世界停止事件数量过多所致集合。

解决方案和建议

我们的问题案例表明，通过调整和减少每个应用程序请求的内存占用空间，可以减少与过多的YG收集活动相关的JVM暂停时间，从而降低分配率和YG GC频率。

但是，当短期内无法使用这种调整策略时，值得探索其他解决方案。通过以下能力改进策略可以潜在地获得类似的结果：

水平和垂直扩展：通过增加数量的JVM进程来拆分流量，但以可用硬件为代价，从而降低了YG集合的分配率和频率。从本质上讲，这意味着将硬件投入该问题。我的建议始终是先微调您的应用程序内存占用量，然后并行探索其他扩展选项。
Java堆大小和YG比率调整：增大YG空间的大小肯定会有助于减少停止世界YG集合的频率。现在请小心，不要使“旧Gen”空间“饿死”，否则您将直接解决问题，并产生更严重的后果，例如JVM抖动和OOM事件。

最后的话

我希望您喜欢本文，并且现在更好地了解过多的JVM YG集合对性能的潜在影响。

我建议您阅读本文后做以下练习：

选择您最繁忙的应用程序之一。
查看verbose：gc日志，并通过GCMV确定JVM暂停时间。
确定YG收集的频率和影响，并确定调整机会。

期待您的意见，并分享您的JVM调优经验。

参考： Java VM –在Java EE支持模式博客上，请我们的JCG合作伙伴 Pierre Hugues Charbonneau 注意YoungGen领域。

翻译自: https://www.javacodegeeks.com/2013/11/java-vm-beware-of-the-younggen-space.html