无需调优的内存优化

　　 
　　内存管理系统常常被视为实现系统性能最优的一块主要绊脚石，因此在过去的几年里，Java应用环境对高效执行内存调优的需求急剧增长。受此影响JVM供应商开始一哄而上提供配置内存的特殊选项。

获取最优内存性能——没有中断，最大限度地提高吞吐量——已经变得越来越复杂。除了迫切需要高效的调优功能之外，客户也十分明确地提出了简化操作的需求。
　　解决问题的方法是以最小的开销提供自调优和具备自适应性的运行时环境。目前，一些新技术在实现系统性能最优的同时，减少了调优的用户操作复杂性。其中包括由应用程序决定Java堆的大小，动态适应的垃圾回收和智能压缩。
　　这篇文章讨论了内存调优的复杂性，自调优内存系统的优势，其中一些面向BEA WebLogic Jrockit研发的新特性，将来可能会在BEA WebLogic Jrockit运用。

内存调优 － 一个复杂的问题
　　由于Java应用程序具有平台独立性以及多样性的特点，我们不可能创建出一个性能最优的通用内存配置。因此，使JVM针对不同环境实现内存调优的能力已经变得越来越重要。
　　一般来说，调优的目的就是通过调整JVM的某些特性以适应各个不同的应用系统，最终达到优化性能的目的。通常调整JVM到最优状态需要耗费大量的时间。因此，JVM提供商已经为客户提供了一些减少调优工作量的方法。
　　常用的解决方法是为每个客户提供所需的启动选项。为了满足每个客户的需要，启动项目的数目已经增加到一个不可预见的数量。这样做的一个不利影响就是，客户必须首先具备一些JVM的知识，才可以掌握如何使用和组合这些选项。换句话说，如果一个客户并不熟JVM的内部工作，那么对他来说这个解决方法将要耗费大量的时间。
　　另一个解决方法就是通过专门的咨询专家在站点提供调优服务。咨询专家对于JVM的内部工作原理已经了解，他们所要做的就是，了解客户系统以便设置调优选项保证性能最优。然而，咨询专家了解客户系统的需求可能也需要大量的时间，并且可能在与客户沟通的过程中，由于涉及到一些客户不愿透漏的敏感和重要信息而发生冲突。因此这个解决方案的开销同样很大。
　　由于相对前几年来，对性能高效和缩减开销的需求越来越备受关注，没有可调优功能的JVM无法良好运作，因此这样的JVM已经不再被接受。然而现存的解决方案过于昂贵，时间开销过大而且复杂性过高。我们需要一个新的廉价、快捷、简便的解决方案。
目的仍然是在使系统在对于JVM运行的所有平台上任何一个可能的应用程序始终保持性能最优。对于新的发展趋势，您不再需要了解您的系统，相反，您所要做得就是信任JVM可以找到最优的配置。实现思想主要是创建一个JVM，它可以通过利用开销较低的应用程序配置数据进行自调优，自动地适应每一个客户应用程序。

自调优内存系统的优势
　　相对于手动调优来说，自调优内存系统不但减少了调优的时间，而且也减少了调优所需要的开销。除了获取与手动配置系统相当的性能之外，自调优的机制还可以处理一个应用程序环境所需要的各种改变。由于调优策略基于开销较低的应用程序配置数据，因此一旦这些数据发生变化，比如，当一个应用程序需要变化，调优就会发生。因此，自调优内存系统动态改变参数，在任何时候都可以获得更好的性能，而不再为满足某个应用程序系统的系统内存需求而在某个点（启动之前）对 JVM进行调优。
　　自调优内存系统的优势在于JVM在获得，或者说改善整体性能的同时也保持了简单的特性。而唯一的限制就是系统所引入的每个动态参数的实现已经变得越来越复杂。因此，如何进行内存调优以此优化系统性能，这个问题的责任已经回到了它本来该属于的地方：内存系统开发者的办公桌上，而不再成为需要客户所承担的花费，时间或者知识的负担。

自适应的内存管理
　　在JVM提供商中一个新的趋势就是研究自调优的特性。BEA WebLogic Jrockit已经在探索和开发不同的自适应特性方面做了很多工作。不久将会推出一个新的自调优内存管理系统，在这个系统中采用了其中的一些新特性。

由应用环境决定Java堆的调整
　　BEA WebLogic Jrockit实现的特性之一就是在运行时扩展和缩减Java堆。这一动态特性消除了通过明确设置启动选项标志实现优化性能的需要：

-Xms [size] [g|G|m|M|k|K] (initial heap size)
-Xmx [size] [g|G|m|M|k|K] (maximum heap size)

　　这也就意味着用户不再需要充分了解他们应用程序系统的内存需求。相反地，他们可以相信JVM内存系统可以根据应用程序的需求调整堆大小。缩减和扩展通常由堆的使用情况决定。这一特性的发展同时也需要考虑到其他应用程序的内存需求或者JVMs的运行以及应用程序的权限。如果内存的需求突然增加，堆尺寸将动态增长。相反，如果内存需求减少，那么JVM可能会考虑减少Java 堆的尺寸。
　　在一些系统中，应用程序可能会在某些特定的点上处于闲置状态，对于这样的系统考虑应用程序的权限是十分有用的。当权限较低的应用程序进入睡眠状态时，Java 堆可能会暂时收缩，在可能的情况下为权限更高的应用程序提供更多的可用内存。

动态垃圾回收
　　在运行时，更改垃圾回收机制是另一个已经实现的特性，利用这个特性可以增加BEA WebLogic JRockit内存管理系统的灵活性。某个垃圾回收策略对应用程序运行的某个阶段来说是最优的，那么对于另外一个阶段可能会有另一个机制是最优的。通过让JVM决定在每个垃圾回收点上使用哪个垃圾回收机制，可以获得更好的性能。通过使用这个自动配置垃圾回收器的特性可以实现在运行时动态改变垃圾回收策略，因此理论上不再需要用户设置启动选项的标志：

-Xgc: [gencon | singlecon | parallel]

　　另一个可以增加垃圾回收动态特性的方法是自动化nursery管理。在某些情况下，某个nursery可能在一个应用程序的整个运行过程中都没有用到。因此可以在需要时再将一个nuersery置为使能状态以此进一步提高性能。用户不再需要理解垃圾回收机制的内部工作原理就可以获取最优的应用程序性能。
　　由于这一特性仍处在实验阶段，用户目前只能通过使用启动选项标志实现适应性的垃圾回收系统。

-Xgcprio: [throughput | pausetime]

　　我们需要设置优先级为垃圾回收系统提供信息，告诉它当前什么是更重要的：短期的中断(中止时间)还是最大可能的吞吐量。

智能压缩
　　系统碎片是系统性能的另一个绊脚石。比如，离散在Java堆的小的空闲内存碎片可能引起内存分配失败，尽管在理论上当前的空闲内存可能可以满足分配的需要。
　　通过压缩可以防止碎片产生，并且这种方法已经使用了相当长的时间。压缩意味着压缩已经分配的内存碎片到Java堆的特定区域中，以便可以释放更大的连续内存空间。
　　关于Java堆中的哪些区域需要被压缩的启发式算法已经重新设计并且得到了改进，但是目前还没有实现。以前，以某种预定义的顺序决定压缩区域。当然，这的确可以减少碎片，但是使用这种方法即使压缩失败也会耗费很多时间，因为一个不包括任何碎片的区域也可能会被选作压缩对象。新的方法是根据开销的应用程序配置数据决定需要进行压缩的区域，这些应用程序配置数据通常可以反映出哪些区域最有压缩价值。另一个已经设计完成但是尚未实现的改进方法是根据应用程序决定压缩面积的大小。在那些碎片已经成为问题的应用程序系统中，这些新的特性实现代替了明确设置压缩区域大小或者压缩率的需要。

展望未来
　　现在，内存管理发展的一个主要方向就是实现，改进并且探索自调优特性。全面目标是通过去除启动选项开销简化系统，同时保持高性能。
　　进一步考虑发展标准，可能会发现其他一些解决时间消耗和费用开销的问题，比如，动态改善启发避免最坏情况。下一代JVM将吸取原来的经验并且分析运行状况而不断改善性能。
　　再深入考虑一下，可以设想JVM可以查找错误并且自动分析和创建错误报告，发送他们到相关的接收者。最后设想JVM可以针对每个不同的应用系统，自动地实现启发式优化，而不再需要指定任何一个启动选项标志。

结束语
　　正如前面所提到的，今天，客户从技术上使用先进的JVM的主要目标是尽可能简单高效的优化性能。
　　为了实现这个目标，为BEA WebLogic Jrockit设计的自调优内存管理系统可以维护通过强有力的调优获取的高性能，同时减少了调优的复杂性以及用户的开销和工作量。
　　通过解除用户的负担，不再需要他们了解内存管理系统的内部工作原理决定调优决策，在获得系统简便的同时，也实现了一个更加灵活的运行系统，在应用程序的整个生命周期，运行系统都会参考应用程序的各种需求和变化。 打破了实现高效调优和保持操作简便之间的冲突。

原文转自：http://www.ltesting.net