jvm默认的初始化参数

如今，JVM被认为是智能的。 预期配置不多-只需设置要在启动脚本中使用的最大堆，您就可以进行了。 所有其他默认设置都很好。 大概我们当中有些人误以为。 实际上，在运行时期间发生了很多事情，无法自动调整性能，因此，在我最近遇到的一个案例研究中，我将带您逐步了解哪些内容以及何时进行调整。

但是在讨论案例本身之前，先介绍了有关JVM内部的一些背景知识。 以下所有内容与Oracle Hotspot 7有关。 其他供应商或Hotspot JVM的较早版本很可能附带不同的默认值。

JVM默认选项

第一站 ：JVM尝试确定是否 它正在客户端环境的服务器上运行。 它通过研究体系结构和OS组合来做到这一点。 简单总结：

例如，如果您在32位Linux上的Amazone EC2 m1.medium实例上运行，则默认情况下，您将被视为在客户端计算机上运行。

这很重要，因为JVM在客户端和服务器上的优化方式完全不同-在客户端计算机上，它试图减少启动时间，并在启动过程中跳过一些优化。 在服务器环境上，为了节省以后的吞吐量，会牺牲一些启动时间。

第二组默认值 ：堆大小。 如果您的环境被认为是根据先前准则确定的服务器，则分配的初始堆将是计算机上可用内存的1/64。 在4G机器上，这意味着您的初始堆大小将为64MB。 如果在极低的内存条件下（<1GB）运行，它可能会更小，但是在这种情况下，我将严重怀疑您在做任何合理的事情。 在这个千年中，还没有看到内存少于千兆字节的服务器。 如果有的话，我会提醒您，如今1 GB的DDR成本不到20美元……

但这将是初始堆大小。 最大堆大小将是可用总内存的¼或1GB中的最小值。 因此，在我们的1.7GB Amazon EC2 m1.small实例中，可用于JVM的最大堆大小约为435MB。

下一步 ：使用默认垃圾收集器。 如果认为您正在客户端JVM上运行，则JVM所应用的默认值为串行GC（ -XX：+ UseSerialGC ）。 在服务器级计算机上（同样，请参见第一部分），默认值为并行GC（ -XX：+ UseParallelGC ）。

默认值还有很多其他事情，例如PermGen的大小，不同的世代调整，GC暂停限制等。但是为了保持帖子的大小在受控范围内，请坚持使用上述配置。 对于好奇的用户-您可以从以下材料中进一步了解默认值：

• http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html
• http://docs.oracle.com/javase/7/docs/technotes/guides/vm/gc-ergonomics.html
• http://docs.oracle.com/javase/7/docs/technotes/guides/vm/server-class.html

案例分析

现在让我们看一下案例研究的行为。 以及我们是否应该凭借决策信任JVM还是跳入我们自己。

我们手头的应用程序是一个问题跟踪器。 即JIRA 。 这是一个在后端具有关系数据库的Web应用程序。 部署在Tomcat上。 在我们的一种客户端环境中表现不佳。 并不是由于任何泄漏，而是由于部署中的不同配置问题。 由于GC暂停时间特别长，这种行为不当的配置导致吞吐量和延迟方面的重大损失。 我们设法帮助了客户，但是出于隐私考虑，我们将不在此处介绍确切的详细信息。 但是案例很好，因此我们继续自己下载JIRA ，以演示我们从此实际案例研究中发现的一些概念。

Atlassian的特别好之处在于，他们附带了一些打包好的负载测试 。 因此，我们有一个基准可用于我们的配置。

我们仔细拆箱了我们新收购的JIRA，并将其安装在64位Linux Amazon EC2 m1.medium实例上。 并运行捆绑测试 。 无需更改默认值。 Atlassian小组将其设置为-Xms256m -Xmx768m -XX：MaxPermSize = 256m

在每次运行期间，我们使用-XX：+ PrintGCTimeStamps -Xloggc：/tmp/gc.log -XX：+ PrintGCDetails收集了GC日志，并在GCViewer的帮助下分析了此统计信息。

结果实际上还不错。 我们将测试运行了一个小时，然后由于垃圾收集暂停而损失了仅151秒 。 占总运行时间的4.2％。 在最坏的情况下，gc的暂停时间为2秒 。 因此，GC暂停会影响此特定应用程序的吞吐量和延迟。 但是不要太多。 但是足以作为本案例研究的基准–在我们的实际客户中，GC暂停时间长达25秒。

挖掘GC日志显示了一个直接的问题。 Full GC的大多数运行都是由PermGen大小随时间扩展而引起的。 日志显示，测试期间总共使用了大约155MB的PermGen。 因此，通过在启动脚本中添加-XX：PermSize = 170m ，我们将PermGen的初始大小增加到比实际使用的大小更多。 这使总的暂停时间从151秒减少到134秒 。 并将最大延迟从2,000ms降低到1300ms 。

然后我们发现了完全出乎意料的事情。 我们的JVM使用的GC实际上是串行GC。 如果您认真遵循了我们的文章，则情况并非如此-64位Linux机器应始终被视为服务器级机器，并且所使用的GC应该是并行GC。 但显然并非如此。 到目前为止，我们最好的猜测是–即使JVM以服务器模式启动，它仍然会根据可用的内存和内核来选择所使用的GC。 由于此m1.medium实例具有3.75GB内存，但只有一个虚拟内核，因此所选的GC仍是串行的。 但是，如果你们对这个话题有更多的见解，我们渴望找到更多。

尽管如此，我们将算法更改为-XX：+ UseParallelGC并重新运行测试。 结果–累积的停顿进一步减少到92秒 。 最坏情况的延迟也减少到了1200ms 。

对于最终测试，我们尝试尝试并发标记和扫描模式。 但是该算法对我们完全失败了–暂停时间增加到300秒，延迟增加到5,000毫秒以上。 在这里，我们放弃了，决定叫它一个晚上。

因此，仅使用两个JVM启动参数并花费几个小时来配置和解释结果，我们就有效地提高了应用程序的吞吐量和延迟。 绝对数字听起来并不令人印象深刻– GC暂停从151秒减少到92秒，最坏情况的延迟从2,000ms减少到1200ms ，但是请记住，这只是一个只有两个配置设置的小测试。 从％的角度来看–嘿，我们都提高了与GC暂停相关的吞吐量，并将延迟减少了40％ ！

无论如何–我们现在再有一个案例向您展示–性能调整就是关于设定目标，进行测量，调整和再次测量。 也许您和我们一样幸运，只需更改两个配置选项就可以使您的用户更快乐40％……

参考： 您是否应该信任JVM中的默认设置？ 由我们的JCG合作伙伴 Nikita Salnikov Tarnovski在Plumbr Blog博客上获得。

翻译自: https://www.javacodegeeks.com/2012/12/should-you-trust-the-default-settings-in-jvm.html

jvm默认的初始化参数