编者按：这篇博文自2019年7月17日发布以来，一直在更新。在过去几年中，围绕企业Java部署和管理的方法已经发生了变化。在下面的文章中，我将讨论我们从哪里来，我们将要去哪里，并向您展示我日常布道所依据的数据。如果您来这里是为了找到Jenkins的magicjavavirtualmachine（JVM）参数，您会在这里找到它们：最佳实践和magicjvm参数。JVM管理员角色：不是所有英雄都穿斗篷在职业生涯中的某个时候，大多数DevOps工程师都会很乐意戴上众所周知的JVM管理员帽子。这是一个经常被分配给我们日常职责的角色。它介于确保服务器机房不会着火和回复50封关于自动运行咖啡机的Python脚本的邮件之间。因为JVM管理员角色只是我们作为DevOps工程师谦卑地接受的任务饼图中的一部分，它对项目整体成功的重要性和重要性往往会被低估。我太清楚了。我已经进入了令人兴奋的时刻，临近项目的最后期限，周围是一罐罐山露和几盒冷披萨，我试图解释供应商和甲骨文的混合文档，用最小的设置来启动一个新的JVM集群，祈祷它不会摧毁已经资源不足的虚拟机集群，同时遵循一套严格的指导方针："将方钉插入圆孔中"诚然，我正忙于灭火，不明白JVM调优对于给予它应有的尊重有多重要。这种对企业Java部署的反应式与主动式的方法比许多人意识到的要普遍得多。虽然使用Java的开发人员天生就知道Java字节码是在JRE（Java运行时环境）中运行的，但对于应用程序性能至关重要的那些经常被忽视的事件却发生在JVM中。有争议的是，大多数Java开发人员并不真正需要知道JVM是如何工作的。我曾经在一次JVM培训中读到过一张幻灯片，在那里的800多万Java开发人员中，估计只有不到5%的人了解JVM的内部工作原理。虽然我还没有看到关于这个统计数据的实际引用——我想这类似于一个家族争斗民意调查，"我们问了一百个Java开发人员，他们是否知道垃圾收集的工作原理——如果这是真的，如果不是开发人员，那么谁有责任真正理解这些东西呢？你猜对了。JVM管理员，是的，这是一个真正的角色。历史上的JVM管理：我们是如何做到这一点的2012年是2012年，虽然它并没有像玛雅人所预测的那样带来世界末日，但Facebook还是上市了，如果你在用Java，你可能已经在和JDK1.7合作了，或者拼命地想转向JDK1.7。在我的职业生涯中，我在媒体行业工作，负责安装和支持我公司的Java应用程序的数百个安装。如果我们的平台崩溃了，那么最终用户就没有退路，无法交付他们的工作。电话会响，人们会尖叫，我们会灭火。应用程序的正常运行时间是必不可少的，而迁移到高可用性云解决方案在当时并不是一个现实的选择。由于多种原因，大媒体还没有准备好使用云计算，带宽和成本是前两位。在这段时间里，像我这样的系统管理员会偶然发现一些博客文章，寻找新的、令人兴奋的JVM参数来介绍，这些参数可以为我们节省一些时间，提高应用程序性能，最终改善用户体验。众所周知，JVM需要三样东西才能正常工作：CPU、RAM和磁盘空间。当JVM内存不足时，您需要添加更多内存。如果你没有更多的东西可以给，你必须向老板说明你为什么需要几百块钱来买更多的公羊棍。这是惯例。向JVM提供更多资源。问题解决了…还是没有。 这种过时的思维方式的问题在于，你最终只能得到单片应用程序。JVM堆的大小如此之大，仅垃圾收集周期就足以让您从控制台中休息一下，喝杯咖啡。如果我把垃圾从办公室拿出来，我需要几分钟的时间走到垃圾箱，然后我就可以相对快速地回到我的办公桌上。当垃圾车来把垃圾运到垃圾填埋场的时候，这会涉及到更多的事情，也会花费更多的时间。同样的概念也适用于JVM。堆的大小越大，需要收集的标记为垃圾的对象就越多。魔法是真实的-垃圾收集巫毒那么，为什么这是个问题？现在，我们不再使用JDK1.7，也不再处理PermGen空间等概念。事实上，在Java1.7中，PermGen空间是有限的内存量，PermGen空间是类、线程堆栈和垃圾回收的地方。在Java1.8中，PermGen空间的概念被元空间取代。两者之间的最大区别是元空间没有默认限制，并且可以无限增长。这使人们重新关注垃圾收集，以及JDK1.8提供的不同收集器。在我多年来的许多谈话中，垃圾收集的话题通常被当作算法巫毒科学而忽略。虽然这可能是真的，但我在这里告诉你，魔法是真实的，有巫师在那里确保这些算法的执行和稳定，使每个人的生活更轻松。我鼓励你去探索这个话题的有限资源，这样你会发现理查德·琼斯的垃圾收集手册，写了二十多年前，仍然是这个话题的权威。关于垃圾回收循环，需要记住的重要一点是，它是一个停止世界事件。这意味着在运行时，在GC循环完成之前不会执行其他线程。有没有想过为什么你的应用程序感觉很慢，或者你的登录需要很长时间？很有可能是因为GC循环调整不当而影响到应用程序的所有最终用户。最终，当权衡在应用程序中使用哪一个时，现代垃圾收集器的不同行为将发挥重要作用。在jdk1.7的开发中，大多数系统管理员对于探索G1.7这样的实验性垃圾收集器犹豫不决，因为尽管它在技术上得到了支持，但是没有足够的数据来证明它的优越性，比如并发标记清除（CMS）。我当然不打算在生产环境中使用G1，因为它太新了，而且很可能有缺陷。此外，对App A有效的方法可能不是App B的最佳选择。这里最重要的一点是，作为JVM管理员，您应该彻底测试JVM绑定的默认JVM参数的任何更改，包括选择备用垃圾收集器。对于JDK1.8，如果您使用的是4GB+堆大小，并且您的应用程序具有低延迟和高吞吐量要求，那么使用G1GC收集器是正确的选择。同样重要的是要确保您的JDK是最新的，以便充分利用bug和内存泄漏修复以及G1GC算法的改进。从Java9开始，它成为默认的垃圾收集器。JVM参数：KISS你可能听说过吻原理，与航空工程师凯利·约翰逊（Kelly Johnson）有关，他在现代传奇的秘密"臭鼬工厂"项目中设计了SR-71黑鸟。它指出，如果大多数系统保持简单而不是变得复杂，那么它们工作得最好；因此，简单性应该是设计中的一个关键目标，并且应该避免不必要的复杂性。虽然在设计间谍飞机和系统管理的背景下，这似乎是一个延伸，但在我看来，基本思想是相当健全的。当您考虑在默认值之外实现额外的JVM参数的原因时，一定要记住每个参数都可能产生意外的开销。此外，通过使用超出默认值的百分比或值对垃圾回收器进行复杂的调整实际上表明您正在尝试比算法更聪明。关键词是"尝试"由于所提供的数据，有很多白皮书声称要使用"-XXNewFancyArgument"。请记住，您的应用程序可能不是白皮书中测试过的应用程序。您添加的每个JVM参数都应该被仔细检查，更重要的是，您应该确切地理解它的作用，并彻底测试您引入环境的任何更改。未雨绸缪：我们要去哪里近年来，上述单一应用的思维方式让位于水平伸缩和短暂性等概念，这在很大程度上是由于采用了高可用性的云服务以及Docker和Kubernetes等技术。不久前，在为Jenkins发布JVM调优建议时，我记录了我们当前围绕java8的最佳实践，这要归功于以前的基线分析和实际实现，并发现假设您的主机有32gb的RAM，那么将堆大小限制在16GB是最佳实践。它作为一个指示性的界限，它是时间水平缩放应用程序。这是通过在负载下对应用程序进行性能测试，并研究GC日志、线程转储和堆转储的行为来确定的，这些行为为我们提供了仅从资源消耗角度看不到的指标。理想情况下，在容器化环境中，我建议使用更小的堆大小，并遵循microservices体系结构的方法。performan，找到最适合您的应用程序的最终结果是基线化