为任务关键型Java应用优化垃圾回收 下 Java开发Java经验技巧.docVIP

为任务关键型Java应用优化垃圾回收（下）-编程开发技术 为任务关键型Java应用优化垃圾回收 （下） 本文由ImportNew -文 学敏 翻译自mgm-tp。欢迎加入翻译小组。转载谙见文末要求。 目录 ?上篇 ?下篇 并行标记清除（CMS）回收器 CMS垃圾冋收器是笫一个广泛使用的低延迟冋收器。虽然在Java 1.4.2中就可 以使用了，但刚开始还不是很稳定。这些问题直到Java 5才得以解决。 从CMS冋收器的名字就可以看出它使用并行方式：大部分冋收工作由一个GC线 程完成，与处理用户请求的工作线程并行执行。老年代原来单一的 stop-the-world回收过程被划分为两个更短的stop-the-world暂停加上5个并 行阶段。在这些并行阶段中，原來的工作线程照常运行（不会被暂停）。关于 CMS更详细的介绍可以参考这篇文章《Java SE 6 HotSpot Virtual Machine Garbage Collection Tuning》。 使用卜?面的参数可以激活CMS回收器： -XX:+UseConcMarkSweepGC 再次应用到上面的测试程序（并提高负载）可以得到以下结果: 图4优化堆大小并使用CMS的JVM在50小时内的GC行为（-Xms 1200m -Xmx 1200m -XX:NewSi ze=400m -XX:MaxNewSi ze=400m -XX:SurvivorRatio=6 -XX:+UseConcMarkSweepGC）） 可以看到，老年代GC的8s左右暂停已经消失了。现在，老年代冋收过程只出现 两次暂停（前-次的结果50小吋内有5次），并且所有暂停都在Is内。 默认情况下，CMS回收器使用ParNew （GC算法）处理新生代回收。如果ParNew 和CMS—起运行，它的暂停会比没有CMS时长一点，因为他们Z间需要额外的协 同工作。与上次的测试结果相比，可以从新生代的平均暂停时间略冇上升发现这 个问题。新生代暂停时间中离群值频繁出现，从这里也可以发现这个问题。离群 值可以达到0.5s左右。但是这些暂停对很多应用来说已经足够短了，所以 CMS/ParNew组合可以作为一个很好的低延迟优化选择。 CMS回收器的一个严重缺陷就是，当老年代空间都被山满时CMS无法启动。一旦 老年代被占满了，启动CMS就太晚了；虚拟机必须使用通常的 stop-thervorld” 策略（在 GC 日志中会出现 concurrent mode failure” 的 记录）。为了实现低延迟目标，当老年代空间占用量达到一定门限值时，就应该 启动CMS回收器，通过以下设置來实现： -XX:CMSInitiati ngOccupancyFrac t i on二80 这表示一旦老年代空间被占用80%时，CMS回收器就会运行。对于我们的应用， 使用这个值（也就是默认值）就可以。但如果把门限值设太高的话，就会产生 uconcurrent mode fa订urc”，导致长时间的老年代GC暂停。反过來，如杲设 的太低（低于活跃空间大小），CMS可能一直并行运行，导致某个CPU核心完全 用在GC上。如果一个应用的对彖创建和堆使用行为变化很快，比如通过交互的 方式或者计吋器启动专门的任务，很难设置一个合适的门限值同吋避免上述两种 问题。 碎片的阴影 然而，CMS最大的一个问题是它不会整理老年代堆空间。这样会产生堆碎片，随 着时间运行，会导致服务严重恶化。有两个因素会导致这种情况：紧缺的老年代 空间大小，以及频繁的CMS回收。第一个因素可以通过增人老年代堆空间来改善, 要大于ParallelGC回收器所需要的空间（我从1024M增加到1200M,从前几幅 图可以看到）。第二个问题可以通过合适地划分各代空间来优化，前面讲过。我 们可以实际看一下这样可以把老年代GC的频率降低多少。 为了证明使用CMS前合理地调整各代堆大小很重要，我们先看看如果不遵守上述 的原则，在图1 （几乎不对堆做优化）的基础上直接使用CMS回收器会怎么样： 图5未优化堆大小的GC行为，以及使用CMS后内存碎片导致的性能恶化（从第 14小时开始） 很明显，JVM在这样设置的负载测试下口J以稳定地工作将近14个小时（在生产 环境以及更小的负载条件卜，这个不稳定的良性阶段可能会持续更久）。接下來, 突然间会出现多次很长的GC暂停，暂停时间几乎占剩余时间的一半。不仅老年 代的暂停时间会达到10s以上，而且新生代的暂停时间也会达到数秒。因为冋收 器为了将新生代的对象移到老年代，需要耗费很长的吋间搜索老年代空间。 CMS低延迟优点的代价就是内存碎片。这个问题口J以最小化，但是不会彻底消失。 你永远不知道它什么时候会被触发。然而，通过合理的优化与监控可以控制它的 风险。 G1 (Ga