JVM性能优化,提高Java的伸缩性

很多程序员在解决JVM性能问题的时候，花开了很多时间去调优应用程序级别的性能瓶颈，当你读完这本系列文章之后你会发现我可能更加系统地看待这类的问题。我说过JVM的自身技术限制了Java企业级应用的伸缩性。首先我们先列举一些主导因素。

主流的硬件服务器提供了大量的内存
分布式系统有大量内存的需求，而且该需求在持续增长
一个普通Java应用程序所持有的对空间大概在1GB~4GB，这远远低于一个硬件服务器的内存管理能力以及一个分布式应用程序的内存需求量。这被称之为Java内存墙，如下图所示(图中表述Java应用服务器和常规Java应用的内存使用量的演变史)。

图 1 Java内存墙(1980~2010)

Java内存墙

这给我们带来了如下JVM性能课题：

1) 如果分配给应用程序的内存太小，将导致内存不足。JVM 不能及时释放内存空间给应用程序，最终将引发内存不足，或者JVM完全关闭。所以你必须提供更多的内存给应用程序。

2) 如果给对响应时间敏感的应用增加内存，如果不重启你的系统或者优化你的应用，Java堆最终会碎片化。当碎片发生时，可能会导致应用中断100毫秒~100秒，这取决与你的Java应用，Java堆的大小以及其他的JVM调优参数。

关于停顿的讨论大部分都集中在平均停顿或者目标停顿，很少涉及到堆压缩时的最坏停顿时间，在生产环境中堆中每千兆字节的有效数据的都将会发生大约1秒的停顿。

2~4秒的停顿对大多数企业应用来说都是不能接受的，所以尽管实际的Java应用实例可能需要更多的内存空间，但实际只分配2~4GB的内存。在一些64位系统中带有很多关于伸缩性的JVM调优项，使得这些系统可以运行16GB乃至20GB的堆空间，并能满足典型响应时间的SLA。但是这些离现实较远，JVM目前的技术无法在进行堆压缩时避免停顿应用程序。Java应用开发人员苦于处理这两个为我们大多数人所抱怨的任务。

架构/建模在大量的实例池之上，随之而来的是复杂的监控和管理操作。
反复的JVM和应用程序调优以避免“stop the world“引起的停顿。大多数程序员希望停顿不要发生在系统峰值负载期间。我称之为不可能的目标。

现在让我们深入一点Java的可伸缩性问题。

过度供给或过度实例化Java部署

为了充分利用内存资源，普通的做法是将Java应用部署在多个应用服务器实例上而不是一个或者少数应用服务器实例上。当一台Server上运行16 个应用服务器实例可以充分利用所有的内存资源，但如此无法解决的是多实例的监控以及管理所带来的成本，尤其是当你的应用部署在多个Server上。

另一个问题来了，峰值负载时的内存资源不是每天都需要的，这样就形成了巨大的浪费。有些情况下，一台物理机上可能只不是不超过3个“大应用服务器实例”，这样的部署更加不够经济也不够环保，尤其在非峰值负载期间。

让我们来比较一下这两种部署架构，下图中左边是多而小的应用服务器实例部署模式，右边是少而大的应用服务器实例部署模式。两种模式处理同样的负载，究竟哪一种部署架构更具经济性。

图2 大应用服务器部署场景

上图源自：Azul Systems

如我之前说过的，并发压缩使得大应用服务器部署模式变得可行，而且可以突破JVM可伸缩性的限制。目前只有Azul的Zing JVM可以提供并发压缩的技术，另外Zing是Server侧的JVM，我们很乐意看到越来越多的开发者在JVM层面去挑战Java可伸缩性的问题。

由于性能调优仍然是我们解决Java可伸缩性问题的主要手段，我们先来看有哪些主要的调优参数以及通过它们能达到什么样的效果。

调优参数：一些事例

最著名的调优参数莫过于”-Xmx”了，通过该参数可以指定Java的堆空间大小，实际上可能不同的JVM执行结果不太一样。

有的JVM包含了内部结构(如编译器线程，垃圾回收器结构，代码缓存等等)所需要的内存在“-Xmx”的设定中，而有的则不包含。因此用户Java进程的大小不一定跟“-Xmx”的设定相吻合。

如果你的应用程序分配对象的速率，对象的生命周期，或者对象的大小超过了JVM内存相关配置，一旦达到最大可使用内存的阈值将会发生内存溢出，用户进程则会停止。

当你的应用程序纠结于内存的可用性时，最有效的方法就是通过”-Xmx”指定更大的内存去重启当前应用进程。为了避免频繁的重启，大多数企业生产环境都倾向于指定峰值负载时所需要的内存，造成过度配置优化。

提示：生产环境负载的调整

Java开发人员易犯的常见错误是在实验下的做的堆内存设置，在移植到生产环境是忘记重新调整。生产环境和实验室环境是不一样的，谨记根据生产环境的负载重新调整堆内存设置。

分代垃圾回收器调优

还有一些其他的优化选项”-Xns”和”-XX: NewSize”，用来调整年轻代的大小，用来指定堆中专门负责新对象分配的空间大小。

大多数开发者都试图基于实验室环境调整年轻代的大小，这意味着在生产负载下存在失败的风险。一般新生代的大小设置为堆大小的三分之一至二分之一左右，但这不是一个准则，毕竟实际还要视应用程序逻辑而定。因此最好先调查清楚年轻代到年老代的蜕变率以及年老代对象的大小，在此基础上(确保年老代的大小，年老代过小会频繁促发GC导致内存溢出错误)尽可能地调大年轻代的空间。

还有一个与年轻代相关的调优项”-XX:SurvivorRatio”，该选项用来指定年轻代中对象的生命周期，超过指定时长相关对象将被移至年老代。为了”正确”地设定该值，你需要知道年轻代空间回收的频率，能够估算到新对象在应用程序进程中被引用的时长，同时也取决于分配率。

并发垃圾回收调优

针对对停顿敏感的应用，建议使用并发垃圾回收，虽然并行的办法能够带来非常好的吞吐量基准测试分数，但是并行GC不利于缩短响应时间。并发 GC 是目前唯一有效的实现一致性和最少“stop the world”中断的方法。不同的JVM提供不同的并发GC的设定，Oracle JVM(hotspot)提供”-XX:+UseConcMarkSweepGC”,今后G1将成为Oracle JVM默认的并发垃圾回收器。

性能调优并不是真正的解决办法

或许你已经注意到上文中在讨论如何“正确“地设定调优此参数时，我刻意在”正确“二字上加了双引号。那是因为就我个人经验而言一旦涉及到性能参数调优，就没有严格意义上的正确设定。每一个设定值都是针对特定的场景。考虑到应用场景会发生变化，JVM 性能调整充其量是一个权宜之计。

以堆的设置为例：如果2GB的堆可以应对20万并发用户，但是可能不能应付40万的并发用户。

我们再以”-XX:SurvivorRatio”为例：当设定符合一个负载持续增长最高至每毫秒10000个交易的场景，当压力到达每毫秒50000个交易时又会发生什么呢？

大多数企业级应用负载都是动态的，Java语言的动态内存管理以及动态编译等技术使得Java更加适合企业级应用。我们来看看一下两个配置清单。

清单1. 应用程序(1)的启动选项

>java -Xmx12g -XX:MaxPermSize=64M -XX:PermSize=32M -XX:MaxNewSize=2g 

-XX:NewSize=1g -XX:SurvivorRatio=16 -XX:+UseParNewGC 

-XX:+UseConcMarkSweepGC -XX:MaxTenuringThreshold=0 

-XX:CMSInitiatingOccupancyFraction=60 -XX:+CMSParallelRemarkEnabled 

-XX:+UseCMSInitiatingOccupancyOnly -XX:ParallelGCThreads=12 

-XX:LargePageSizeInBytes=256m …

清单 2. 应用程序(2)的启动选项

>java –Xms8g –Xmx8g –Xmn2g -XX:PermSize=64M -XX:MaxPermSize=256M 

-XX:-OmitStackTraceInFastThrow -XX:SurvivorRatio=2 -XX:-UseAdaptiveSizePolicy -XX:+UseConcMarkSweepGC 

-XX:+CMSConcurrentMTEnabled -XX:+CMSParallelRemarkEnabled -XX:+CMSParallelSurvivorRemarkEnabled 

-XX:CMSMaxAbortablePrecleanTime=10000 -XX:+UseCMSInitiatingOccupancyOnly 

-XX:CMSInitiatingOccupancyFraction=63 -XX:+UseParNewGC –Xnoclassgc …

两者的配置区别很大，因为他们是两个不同应用程序。感觉根据各自的应用特设都做了”正确“的配置与调优。在实验室环境下都运行良好，但在生产环境中最终会表现出疲态。清单1由于没有考虑到动态负载，到了生产环境即表现不良。清单2没有考虑到应用程序在生产环境中的特性变化。这两种情况应该归咎于开发团队，但是该归咎于何处呢？

变通办法可行吗？

有些企业通过精确测量交易对象的大小定义极致的对象回收空间并”精简“其架构来适配该空间。这也许是办法来削减碎片以应对一整天的交易(在不做堆压缩的情况下)。还有一个办法就是通过程序设计确保对象被引用的时间在一个比较短的时间内从而阻止其在SurvivorRatio时间之后不被迁往年老代而直接被回收，避免内存压缩的场景。这两种办法都可以，但是对应用开发人员和设计人员有一定的挑战。

谁保障应用程序的性能？

一个门户应用可能会在其活动负载峰值点出现故障；一个交易应用可能会在每次市场下跌和上升时无法正常运行；电子商务网站可能会无法应对节假日购物高峰期。这些都是真实世界的案例基本都是JVM性能参数调优导致的。当产生了经济损失，开发团队就会受到责备。也许某些场合下开发团队应该要受到责备，但是 JVM的提供商又应该负起什么样儿的责任呢？

首先JVM提供商应该要提供调优参数的优先顺序，至少这在短期内还是很有意义的。有一些新的调优选项是针对特定的、新兴的企业应用程序场景。更多的调优选项是为了减轻JVM支持团队的工作负荷而将性能优化转嫁到应用开发者身上。但我个人认为这或将导致更加漫长的支持负荷，一些针对最糟糕场景的调优选项也将被延期，当然不是无限延期。

毋庸置疑JVM的开发团队也在努力地进行着他们的工作，同时也只有应用实施者才会更加清楚他们应用的特定需求。但是应用的实施者或开发者是无法预测期动态的负载需求。在过去，JVM提供商也会去分析关于Java的性能与可扩展性问题，哪些是他们能够解决的。不是提供调优参数，而是直接去优化或创新垃圾回收的算法。更有趣是我们可以想象一下如果OpenJDK的社区聚集在一起重新考虑Java垃圾回收器将会发生什么！

JVM性能的基准测试

调优参数有时被JVM提供商作为其竞争的工具，因为不同的调优可以改善他们的JVM在可预见的环境中的性能表现，本系列的最后一片文章中将调查这些基准测试来衡量JVM的性能。

JVM开发者的挑战

真正的企业级可伸缩性需求是要求JVM能够适应动态灵活的应用负载。这是在特定吞吐量和响应时间内保证持续稳定性能的关键。这是JVM开发者才能完成历史使命，因此是时候号召我们Java开发者社区来迎接真正的Java可伸缩性的挑战。

l 持续调优

对于给定的应用，在一开始需要告知其需要多大的内存，之后的工作都应该有JVM来负责，JVM需要适配动态的应用负载和运行场景。

l JVM实例数 vs. 实例的可扩展性

现在的服务器都支持很大的内存，那么为什么JVM实例不能有效地利用它呢？将应用拆分部署许多小的应用服务器实例上，这从经济和环保角度都是一种浪费。现代的JVM需要跟上硬件和应用的发展潮流。

l 真实世界的性能和可伸缩性

企业不需要为其应用的性能需求去做极致的性能调优。JVM提供商和OpenJDK社区需要去解决Java可伸缩性的核心问题以及消除“stop the world“的操作。

结论

如果JVM做了这样的工作，并且提供了并发压缩的垃圾回收算法，JVM也不再成为Java可伸缩性的限制因素，Java应用开发者不需要花费痛苦的时间理解怎样配置JVM去获得最佳性能，从而将会有更多的有趣的Java应用层面的创新，而不是无休止的JVM调优。我要挑战JVM开发人员以及提供商所需要做的事情来响应甲骨文所提倡的“Make the Java Future“的活动。

关于作者

Eva Andearsson对JVM技术、SOA、云计算和其他企业级中间件解决方案有着10多年的从业经验。在2001年，她以JRockit JVM开发者的身份加盟了创业公司Appeal Virtual Solutions（即BEA公司的前身）。在垃圾回收领域的研究和算法方面，EVA获得了两项专利。此外她还是提出了确定性垃圾回收（Deterministic Garbage Collection），后来形成了JRockit实时系统（JRockit Real Time）。在技术上，Eva与SUN公司和Intel公司合作密切，涉及到很多将JRockit产品线、WebLogic和Coherence整合的项目。2009年，Eva加盟了Azul System公，担任产品经理。负责新的Zing Java平台的开发工作。最近，她改换门庭，以高级产品经理的身份加盟Cloudera公司，负责管理Cloudera公司Hadoop分布式系统，致力于高扩展性、分布式数据处理框架的开发。