详解为任务关键型Java应用优化垃圾回收（上）
从垃圾回收的角度来看，Java服务器程序可以有广泛多样的需求：
一些高流量应用需要响应大量请求并创建非常多的对象。有时候，一些使用了高资源消耗框架的中等流量应用也会遇到同样的问题。总之，对垃圾回收来说，如何有效地清理这些生成的对象是一个很大的挑战。
另外，一些应用需要长时间运行并且在运行过程提供稳定的服务，要求性能不会随着时间而慢慢变差或者突然恶化。
某些场景需要严格限制用户响应时间（比如网络游戏或者投注应用等），几乎不允许额外的GC暂停。
在很多场景中，你可以通过不同的优先级将几种需求结合起来。我的几个样例程序对第一点要求比第二点要高很多，但是绝大部分程序不会同时对这三方面要求都高。这给你留下了足够权衡的空间。
默认配置下JVM GC的性能
JVM有很多改进，但仍然不能在程序运行时对任务做优化。除了上面提到的三点，默认的JVM设置还有一个优先级仅次于它们的需求：减小内存占用。考虑到成千上万的用户并不是在内存充足的服务器上运行。对很多电子商务产品也很重要，因为这些应用大部分时间被配置在开发笔记本上运行，而不是在商用服务器上。因此，如果你的服务器配置着最小的堆空间和GC参数，比如下面这样配置，
java -Xmx1024m -XX:MaxPermSize=256m -cp Portal.jar my.portal.Portal
这样肯定会导致系统运行不够高效。首先，好的做法不仅配置内存最大限制，也需要配置初始内存大小，以避免服务器在启动过程中逐步增加内存。否则代价会很大。当知道服务器需要多少内存时（你应该及时地查明），最好将初始内存大小与最大内存设置相等。可以通过以下JVM参数来设置：
-Xms1024m -XX:PermSize=256m
最后一个经常在JVM配置的基本选项是配置新生代堆内存大小，与上面设置的方式类似：
-XX:NewSize=200m -XX:MaxNewSize=200m
下面的章节会对上面的配置以及更复杂的配置给出解释。首先，让我们看一个门户网站的应用，它运行在一台相当慢的测试主机上。当进行负载测试时，它的垃圾回收是怎么工作的：
图1 堆大小稍微优化后的JVM在25小时左右的GC行为（-Xms1024m -Xmx1024m -XX:NewSize=200m -XX:MaxNewSize=200m）
其中，蓝色的曲线表示总的堆内存占用量随时间的变化，垂直的灰色线条表示GC暂停的间隔。
除了曲线图，GC操作的关键指标和性能显示在最右边。首先我们看一下在这次测试中，垃圾被创建（和回收）的平均量。30.5MB/s的数值被标为黄色，因为这是一个相当大但还可以的垃圾生成速率，对一个引导性的GC调优例子而言还算可以。其他值表示JVM在清理这些垃圾时的表现：99.55%的垃圾是在新生代中被清理的，老年代的只占0.45%。这个结果相当不错，因此标为绿色。
之所以有这样的结果，可以从GC引入的暂停间隔看出来（以及处理用户请求的工作线程）：有很多但很短暂的新生代GC间隔，平均每6s一次，持续时间不会超过50ms。这些暂停使JVM停止运行的时间占总时间的0.77%，但是每次暂停对等待服务器响应的用户来说完全感觉不到。
另一方面，老年代GC的暂停只占总时间的0.19%。但是，在这段时间内老年代GC只清理了0.45%的垃圾，而新生代GC用占0.77%的时间清理了99.55%的垃圾。可见，与新生代GC相比，老年代GC是多么低效。另外，老年代GC的暂停平均触发速率不到一个小时一次，但平均持续时间可达到8s，最大异常值甚至达到19s。由于这些暂停会真正地停止JVM处理用户请求的线程，因此暂停应尽量不频发且持续时间短。
通过以上观察可以得出分代垃圾回收的基本调优目标：
新生代GC尽量回收多的垃圾，避免老年代GC频发且持续时间较短。
分代垃圾回收的基本思想与堆内存大小调整
先从下图开始。这个图可以通过JDK工具得到，比如jstat或者jvisualvm以及它的visualgc插件：
图2 JVM的堆内存结构，包括新生代的子分区（最左列）
Java的堆内存由永久代（Perm），老年代（Old）和新生代（New or Young）组成。新生代进一步划分为一个Eden空间和两个Survivor空间S0、S1。Eden空间是对象被创建时的地方，经过几轮新生代GC后，他们有可能被存放在Survivor空间。如果想了解更多，可以读一下Sun/Oracle的白皮书Memory Management in the Java HotSpot Virtual Machine
默认情况下，作为整体的新生代特别是Survivor空间太小，导致在GC清理大部分内存之前就无法保存更多对象。因此，这些对象被过早地保存在老年代中，这会导致老年代被迅速填满，必须频繁地清理垃圾。这也是图1中产生较多的Full GC暂停的原因。
（译者注：一般新生代的垃圾回收也称为Minor GC，老年代的垃圾回收称为Major GC或Full GC）
优化新生代内存大小
优化分代垃圾回收意味着让新生代，特别是Survivor空间，比默认情形大。但是同时也要考虑虚拟机使用的具体GC算法。
当前硬件上运行的Sun/Oracle虚拟机使用了ParallelGC作为默认GC算法。如果使用的不是默认算法，可以通过显式配置JVM参数来实现：
-XX:+UseParallelGC
默认情况下，这个算法并不在固定大小的Eden和Survivor空间中运行。它使用了一种自适应调整大小的策略，称为“AdaptiveSizePolicy”策略。正如描述的那样，它可以适应很多场景，包括服务器以外的机器的使用。但在服务器上运行时，这并不是最优策略。为了可以显式地设置固定的Survivor空间大小，可以通过以下JVM参数关闭它：
-XX:-UseAdaptiveSizePolicy
一旦这么设置后，就不能进一步增加新生代空间的大小，但我们可以有效地为Survivor空间设置合适的大小：
-XX:NewSize=400m -XX:MaxNewSize=400m -XX:SurvivorRatio=6
“SurvivorRatio=6”表示Survivor空间是Eden空间的1/6或者是整个新生代空间的1/8，在这个例子中就是50MB，而自适应大小策略经常运行在非常小的空间上，大约只有几MB。使用现在的配置，重复上面的负载测试，我们得到了下面的结果：
图3 堆内存优化后的JVM在50小时内的GC行为（-Xms1024m -Xmx1024m -XX:NewSize=400m -XX:MaxNewSize=400m -XX:-UseAdapativeSizePolicy -XX:SurvivorRatio=6）
这次的测试时间是上次的两倍，而垃圾的平均创建速率和之前基本一致（30.2MB/s，之前是30.5MB/s）。然而，整个过程只有两次老年代（Full）GC暂停，25小时左右才发生一次。这是因为老年代垃圾死亡速率（所谓的promation rate）从137kB/s减小到了6kB/s，老年代的垃圾回收只占整体的0.02%。同时新生代GC的暂停持续时间仅仅从平均48ms增加到57ms，两次暂停的间隔从6s增长到10s。总之，关闭了自适应大小调整，合理地优化堆内存大小，使GC暂停占总时间的比例从0.95%减小到0.59%，这是一个非常棒的结果。
优化后，使用ParNew算法作为默认ParallelGC的替代，也能得到相似的结果。这个算法是为了与CMS算法兼容而开发的，可以通过JVM参数来配置-XX:+UseParNewGC。关于CMS下面会提到。这个算法不使用自适应大小策略，可以运行在固定Survivor大小的空间上。因此，即使使用默认的配置SurvivorRatio=8，也比ParallelGC拥有更高的服务器利用率。
避免老年代GC的长时间暂停
上述结果的最后一个问题就是，老年代GC的长时间暂停平均为8s左右。通过适当的优化，老年代GC暂停已经很少了，但是一旦触发，对用户来说还是很烦人的。因为在暂停期间，JVM不能执行工作线程。在我们的例子中，8s的长度是由低速老旧的测试机导致的，在现代硬件上速度能快3倍左右。另一方面，现在的应用一般使用1G以上的堆内存，可以容纳更多的对象。当前的网络应用使用的堆内存能达到64GB，（至少）需要一半的内存来保存存活的对象。在这种情况下，8s对老年代暂停来说是很短的。这些应用中的老年代GC可以很随意地就接近1分钟，对于交互式网络应用来说是绝对不能接受的。
缓解这个问题的一个选择就是采用并行的方式处理老年代GC。默认情况下，在Java 6中，ParallelGC和ParNew GC算法使用多个GC线程来处理新生代GC，而老年代GC是单线程的。以ParallelGC回收器为例，可以在使用时添加以下参数：
-XX:+UseParallelOldGC
从Java 7开始，这个选项和-XX:+UseParallelGC默认被激活。但是，即使你的系统是4核或8核，也不要期望性能可以提高2倍以上。通常的结果会比2被小一些。在某些例子中，比如上述例子中的8s，这种提高还是比较有效的。但在很多极端的例子中，这还远远不够。解决方法是使用低延迟GC算法。
下篇中会讨论CMS（The Concurrent Mark and Sweep Collector）、幽灵般的碎片、G1（Garbage First）垃圾收集器和垃圾收集器的量化比较，最后给出总结。
以上就是详解为任务关键型Java应用优化垃圾回收（上）的详细内容，更多请关注其它相关文章！