一步步优化JVM五：优化延迟或者响应时间

本节的目标是做一些优化以满足对应用对延迟的需求。这次需要几个步骤，包括完善Java堆大小的配置，评估垃圾回收占用的时间和频率，也许还要尝试切换到不同的垃圾回收器，以及由于使用了不同的垃圾回收器，需要重新优化Java堆空间大小。

 

    这一步有如下可能的结果：

 

    1、应用的延迟需求被满足了。如果这一步的优化操作满足了应用的延迟需求，你可以继续下一步优化（优化吞吐量）。

 

    2、应用的延迟需求未被满足。如果这一步的优化操作未能满足延迟需求，你可能需要重新看看延迟需求是否合理或者修改应用程序。一些可能的问题可以帮助改善应用的延迟问题：

    a、优化Java堆以及修改应用以减少对象的分配和对象的长时间存活。

    b、修改JVM的部署结构，让每一个JVM做更少的工作。

 

    上面的两个步骤都可以减少JVM的对象分配，因此减少垃圾回收的频率。

 

    这一步从查看垃圾回收对应用的延迟的影响开始，基于前面一节“决定内存消耗”计算出来的Java堆大小。

 

    下面列出了评估垃圾回收对延迟的影响需要进行的几个事情：

    1、测量MinorGC的时间。

    2、测量MinorGC的频率。

    3、测量FullGC的时间。

    4、测量FullGC的频率。

 

    测量垃圾回收的时间的和频率对于改善Java堆大小配置来说是非常重要的。MinorGC的时间和频率的测量结果可以用来改善young代的空间大小。测量最坏情况下FullGC的时间和频率可以用来决定old代的大小，以及是否需要切换成吞吐量垃圾回收器（通过使用-XX:+UseParalleOldGC或者-XX:+UseParallelGC）或者并发垃圾回收器（CMS，通过使用-XX:+UseConcMarkSweepGC）。在使用吞吐量垃圾回收器的时候，如果垃圾回收的延迟和频率太高以导致应用的延迟需求无法满足的时候才切换到CMS，如果选择了切换，需要对CMS垃圾回收器进行优化，后面会详细介绍这个问题。

 

    接下来详细介绍前面提到的各种情况。

    需求

    下面列举了几个这一步优化操作需求，它们来源于应用的系统需求：

    1、可以接收的平均暂停时间。平均暂停时间需求用于和MinorGC消耗的时间比较。

    2、可以接收的MinorGC的频率。其实频道对于应用负责人来说，没有平均延迟时间重要。

    3、应用负责人能够接受的最大延迟时间。这个时间受到FullGC的影响。

    4、应用负责人能够接收的最大延迟的频率，即FullGC的频率。其实，大多数时间应用管理员还是更加关心应用的的最大延迟时间超过了最大延迟的频率。

 

    一旦确定了需求，这些垃圾回收器的时间消耗和频率都可以通过垃圾回收日志收集到。先把垃圾回收器设置为吞吐量垃圾回收器（设置-XX:+UseParallelOldeGC或者-XX:+UseParallelGC）。通过反复测试，可以让young代和old代满足上面的要求。下面2节介绍如何优化young代和old代空间大小来观察MinorGC和最坏情况的FullGC的消耗时间和频率。

   

    改善young代的大小

    确定young代的大小是通过评估垃圾回收的统计信息以及观察MinorGC的消耗时间和频率，下面举例说明如何通过垃圾回收的统计信息来确定young代的大小。

 

    尽管MinorGC消耗的时间和young代里面的存活的对象数量有直接关系，但是一般情况下，更小young代空间，更短的MinorGC时间。如果不考虑MinorGC的时间消耗，减少young代的大小会导致MinorGC变得更加频繁，由于更小的空间，用玩空间会用更少的时间。同理，提高young代的大小会降低MinorGC的频率。

 

    当测试垃圾回收数据的时候，发现MinorGC的时间太长了，正确的做法就是减少young代的空间大小。如果MinorGC太频繁了就增加young代的空间大小。

 

   

    上图是一个展示了MinorGC的例子，这个例子是运行在如下的HotSpot VM命令参数下的。

 

    -Xms6144m -Xmx6144m -Xmn2048m -XX:PermSize=96m -XX:MaxPermSize=96m -XX:+UserParallelOldGC

 

    上图显示了MinorGC平均的消耗时间是0.05秒，平均的频率是2.147秒1次。当计算MinorGC的消耗时间和频率的时候，越多的数据参与计算，准确性会越高。并且应用要处于稳定运行状态下来收集MinorGC信息也是非常重要的。

 

    下一步是比较MinorGC的平均时间和系统对延迟的要求，如果MinorGC的平均时间大于了系统的要求，减少young代的空间大小，然后继续测试，再收集数据以及重新评估。

 

    如果MinorGC的频率大于了系统的要求，就增加young代的空间大小，然后继续测试，再收集以及重新评估。

 

    也许需要数次重复才能够让系统达到延迟要求。当你改变young代的空间大小的时候，尽量保持old代的空间大小不要改变。

 

    从上图的垃圾回收信息来看，如果应用的延迟要求是40毫秒的话，观察到的MinorGC的延迟是58毫秒，比系统的要求高出了不少。上面例子使用的命令选项是

   

 

    -Xms6144m -Xmx6144m -Xmn2048m -XX:PermSize=96m -XX:MaxPermSize=96m -XX:+UserParallelOldGC

 

 

    意味着old代的空间大小是4096M，减小young代的空间大小的10%而且要保持old代的空间大小不变，可以使用如下选项。

 

 

    -Xms5940m -Xmx5940m -Xmn1844m -XX:PermSize=96 -XX:MaxPermSize=96 -XX:+UserParallelOldGC

 

    注意的是young代的空间大小从2048M减少到1844M，整个Java堆的大小从6144M减少到5940M，两者都是减少了204m。

 

    无论是young的空间调大还是调小，都需要重新收集垃圾回收信息和重新计算MinorGC的平均时间和频率，以达到应用的延迟要求，可能需要几个轮回来达到这个要求。

 

    为了说明了增加young代的大小以降低MinorGC的频率，我们下面举一个例子。如果系统要求的频率是5秒一次，这个上面的例子中是2.147秒一次，也就是说它用了2.147秒，填充满了2048M空间，如果需要5秒一次的频率，那么就需要5/2.147倍的空间，即2048*5/2.147等于4700M。因此young代的空间需要调整到4700M。下面是一个示例来说明配置这个：

 

 

    -Xms8796m -Xmx8796m -Xmn4700m -XX:PermSize=96m -XX:MaxPermSize=96m -XX:+UsePrallelOldGC

 

    注意是-Xms和-Xmx也同步调整了。

 

    另外一些调整young代的空间需要注意的事项：

    1、old代的空间一定不能小于活动对象的大小的1.5倍。

    2、young代的空间至少要有Java堆大小的10%，太小的Java空间会导致过于频繁的MinorGC。

    3、当提高Java堆大小的时候，不要超过JVM可以使用的物理内存大小。如果使用过多的物理内存，会导致使用交换区，这个会严重影响性能。

 

    如果在仅仅是MinorGC导致了延迟的情况下，你无法通过调整young代的空间来满足系统的需求，那么你需要重 新修改应用程序、修改JVM部署模型把应用部署到多个JVM上面（通常得要多机器了）或者重新评估系统的需求。

 

    如果通过调整MinorGC能够满足应用的延迟需求，接下来就可以调整old代了，以达到最坏情况下的延迟和延迟频率的需求。下一节详细说明这个问题。

    

完善old代的大小

    这一节的目标是评估由于FullGC引起的最差暂停时间和频率。

 

    同前面一个节“完善young代大小”一样，垃圾回收的统计信息是必须的，在稳定状态下，FullGC的时间表明了应用最差的延迟，如果发生了多个FullGC，计算多个FullGC的平均消耗时间，更多数据能够更好的评估。

 

    计算两次不同的FullGC之间的时间差，可以提供出FullGC的频率，下图用一个列子来说明两个FullGC：

 

   

 

    如果没有FullGC，可以人为的去干预，前面说过，可以使用VisualVM来触发FullGC。另外，评估FullGC的频率需要知道对象的转移率，这个转移率说明对象从young代转移到old代。接下来的介绍如何评估转移率。

 

    接下有个几个MinorGC的例子，他们被用来评估FullGC的频率。

 

 

2010-12-05T14:40:29.564-0800: [GC
[PSYoungGen: 2045989K->249795K(2097152K)]
3634533K->1838430K(6291456K), 0.0543798 secs]
[Times: user=0.38 sys=0.01, real=0.05 secs]

2010-12-05T14:40:31.949-0800: [GC
[PSYoungGen: 2047896K->247788K(2097152K)]
3655319K->1859216K(6291456K), 0.0539614 secs]
[Times: user=0.35 sys=0.01, real=0.05 secs]

2010-12-05T14:40:34.346-0800 [GC
[PSYoungGen: 2045889K->248993K(2097152K)]
3677202K->1881099K(6291456K), 0.0532377 secs]
[Times: user=0.39 sys=0.01, real=0.05 secs]

2010-12-05T14:40:36.815-0800 [GC
[PSYoungGen: 2047094K->247765K(2097152K)]
3696985K->1900882K(6291456K), 0.0543332 secs]
[Times: user=0.37 sys=0.01, real=0.05 secs]

 

 

    从上面的例子可以看出：

    1、Java堆的大小是6291456K或6144M

    2、young代的大小是2097152K或2048M

    3、old代的大小是6144M-2048M = 4096M

 

    在这个例子中，活动对象的大小差不多是1370M。那么old代还有2726M剩余空间（4096M-1370M=2726M）。

 

    填充完成2736M空间需要多长时间是由young代向old代的转移率决定的。这个转移率的计算通过查看每次MinorGC后old代的占用空间的增长情况以及MinorGC发生的时间。old代的空间占用是MinorGC之后Java堆中对象大小减去young代的大小，通过这个公式计算，可以看出在这个例子中每次MinorGC之后，old代的空间占用情况是：

 

    1588635K，第一个MinorGC

    1611428K，第二次MinorGC

    1632106K，第三次MinorGC

    1653117K，第四次MinorGC

 

    每次的增量分别是

    22793K，第一次和第二次的增量

    20678K，第二次和第三次的增量

    21011K，第三次和第四次的增量

 

    平均每次MinorGC转移大概201494K或者叫21M。

 

    如果剩余的空间都是按照设个转移率来转移到old代的话，且知道MinorGC的频率是每2.147秒一次。因此，这个转移率是201494K/2.147s差不多10M/s,那么一共的空间是2736M空间需要273.6s差不多4.5分钟一次。

 

    因此，通过前面的案例分析，应用的最差延迟的频率是4.5分钟。这个评估可以通过让应用处于稳定运行状态超过4.5分钟来验证。

 

    如果评估和观察的FullGC的频率高于了应用对最坏延迟频率的要求，那么可以提高old代的空间大小。如果改变old代的大小，保持young代的空间恒定，在优化young代的时候也说这个问题，两者应该独立优化，以保证有高效。

 

    如果这步已经达到了你最坏延迟的要求，那么这一步调优延迟就算已经完成了，就可以进入下一步去调优“吞吐量”了。

   

    如果你未能达到了应用对最坏延迟时间和频率的性能要求，由于FullGC的执行时间太长了，然后你可以把垃圾回收器切换CMS（concurrent garbage collection）。CMS有能力让垃圾回收尽量是多线程的，即让程序保持在运行状态。要使用CMS可以通过下面这条命令选项:-XX:+UseConcMarkSweepGC。

    

    后面详细说明如何调优CMS。

 

优化CMS（concurrent garbage collection）

 

 

   使用CMS，old代的垃圾回收执行线程会和应用程序的线程最大程度的并发执行。这个提供了一个机会来减少最坏延迟的频率和最坏延迟的时间消耗。CMS没有执行压缩，所以可以避免old代空间的stop-the-world压缩（会让整个应用暂停运行）。

 

 

 

   优化CMS的目标就是避开stop-the-world压缩垃圾回收，然而，这个说比做起来容易。在一些的部署情况下，这个是不可避免的，尤其是当内存分配受限的时候。

 

 

 

   在一些特殊的情况下，CMS比其他类型的垃圾回收需要更多优化，更需要优化young代的空间，以及潜在的优化该什么时候初始化old代的垃圾回收循环。

 

 

 

   当从吞吐量垃圾回收器（Throughput）迁移到CMS的时候，有可能会获得更慢的MinorGC,由于对象从young代转移到old会更慢 ，由于CMS在old代里面分配的内存是一个不连续的列表，相反，吞吐量垃圾回收器只是在本地线程的分配缓存里面指定一个指针。另外，由于old代的垃圾回收线程和应用的线程是尽可能的并发运行的，所以吞吐量会更小一些。然而，最坏的延迟的频率会少很多，由于在old代的不可获取的对象能够在应用运行的过程被垃圾回收，这样可以避免old代的空间溢出。

 

 

 

   使用CMS，如果old代能够使用的空间有限，单线程的stop-the-world压缩垃圾回收会执行。这种情况下，FullGC的时间会比吞吐量垃圾回收器的FullGC时间还要长，导致的结果是，CMS的绝对最差延迟会比吞吐量垃圾回收器的最差延迟严重很多。old代的空间溢出以及运行了stop-the-world垃圾回收必须被应用负责人重视，由于在响应上会有更长的中断。因此，不要让old代运行得溢出就非常重要了。对于从吞吐量垃圾回收器迁移到CMS的一个比较重要的建议就是提升old代20%到30%的容量。

 

 

 

   在优化CMS的时候有几个注意点，首先，对象从young代转移到old代的转移率。其次，CMS重新分配内存的概率。再次，CMS回收对象时候产生的old代的分隔，这个会在可获得的对象中间产生一些空隙，从而导致了分隔空间。

 

 

 

   碎片可以被下面的几种方法寻址。第一办法是压缩old代，压缩old代空间是通过stop-the-world垃圾回收压缩完成的，就像前面所说的那样，stop-the-world垃圾回收会执行很长时间，会严重影响应用的响应时间，应该避开。第二种办法是，对碎片编址，提高old代的空间，这个办法不能完全解决碎片的问题的，但是可以延迟old代压缩的时间。通常来讲，old代越多内存，由于碎片导致需要执行的压缩的时间久越长。努力把old的空间增大的目标是在应用的生命周期中，避免堆碎片导致stop-the-world压缩垃圾回收，换句话说，应用GC最大内存原则。另外一种处理碎片的办法是减少对象从young代移动到old的概率，就是减少MinorGC，应用MinorGC回收原则。

 

 

 

   任期阀值（tenuring threshold）控制了对象该什么时候从young代移动到old代。任期阀值会在后面详细的介绍，它是HotSpot VM基于young代的占用空间来计算的，尤其是survivor（幸存者）空间的占用量。下面详细介绍一下survivor空间以及讨论任期阀值。

 

 

 

survivor空间

 

 

 

   survivor空间是young代的一部分，如下图所示。young代被分成了一个eden区域和两个survivor空间。

   

   两个survivor空间的中一个被标记为“from”，另外一个标记为“to”。新的Java对象被分配到Eden空间。比如说，下面的一条语句：

 

   

   Map<String,String> map = new HashMap<String,String>();

 

   一个新的HashMap对象会被放到eden空间，当eden空间满了的时候，MinorGC就会执行,任何存活的对象，都从eden空间复制到“to” survivor空间，任何在“from” survivor空间里面的存活对象也会被复制到“to” survivor。MinorGC结束的时候，eden空间和“from” survivor空间都是空的，“to” survivor空间里面存储存活的对象，然后，在下次MinorGC的时候，两个survivor空间交换他们的标签，现在是空的“from” survivor标记成为“to”，“to” survivor标记为“from”。因此，在MinorGC结束的时候，eden空间是空的，两个survivor空间中的一个是空的。

 

   在MinorGC过程，如果“to” survivor空间不够大，不能够存储所有的从eden空间和from suvivor空间复制过来活动对象，溢出的对象会被复制到old代。溢出迁移到old代，会导致old代的空间快速增长，会导致stop-the-world压缩垃圾回收，所以，这里要使用MinorGC回收原则。

 

   避免survivor空间溢出可以通过指定survivor空间的大小来实现，以使得survivor有足够的空间来让对象存活足够的岁数。高效的岁数控制会导致只有长时间存活的对象转移到old代空间。

 

   岁数控制是指一个对象保持在young代里面直到无法获取，所以让old代只是存储长时间保存的对象。

 

   survivor的空间可以大小设置可以用HotSpot命令行参数：-XX:SurvivorRatio=<ratio>

 

   <ratio>必须是以一个大于0的值，-XX:SurvivorRatio=<ratio>表示了每一个survivor的空间和eden空间的比值。下面这个公式可以用来计算survivor空间的大小

 

   

   survivor spave size = -Xmn<value>/(-XX:SurvivorRatio=<ratio>+2)

 

   这里有一个+2的理由是有两个survivor空间，是一个调节参数。ratio设置的越大，survivor的空间越小。为了说明这个问题，假设young代的大小是-Xmn512m而且-XX:SurvivorRatio=6.那么，young代有两个survivor空间且空间大小是64M，那么eden空间的大小是384M。

 

   同样假如young代的大小是512M，但是修改-XX:SurvivorRatio=2，这样的配置会使得每一个survivor空间的大小是128m而eden空间的大小是256M。

 

   对于一个给定大小young代空间大小，减小ratio参数增加survivor空间的大小而且减少eden空间的大小。反之，增加ratio会导致survivor空间减少而且eden空间增大。减少eden空间会导致MinorGC更加频繁，相反，增加eden空间的大小会导致更小的MinorGC，越多的MinorGC，对象的岁数增长得越快。

 

   为了更好的优化survivor空间的大小和完善young代空间的大小，需要监控任期阀值，任期阀值决定了对象会再young代保存多久。怎么样来监控和优化任期阀值将在下一节中介绍。

   

任期阀值

   “任期”是转移的代名词，换句话说，任期阀值意味着对象移动到old代空间里面。HotSpot VM每次MinorGC的时候都会计算任期，以决定对象是否需要移动到old代去。任期阀值就是对象的岁数。对象的岁数是指他存活过的MinorGC次数。当一个对象被分配的时候，它的岁数是0。在下次MinorGC的时候之后，如果对象还是存活在young代里面，它的岁数就是1。如果再经历过一次MinorGC，它的岁数变成2，依此类推。在young代里面的岁数超过HotSpot VM指定阀值的对象会被移动到old代里面。换句话说，任期阀值决定对象在young代里面保存多久。

 

   任期阀值的计算依赖于young代里面能够存放的对象数以及MinorGC之后，“to” servivor的空间占用。HotSpot VM有一个选项-XX:MaxTenuringThreshold=<n>，可以用来指定当时对象的岁数超过<n>的时候，HotSpot VM会把对象移动到old代去。内部计算的任期阀值一定不会超过指定的最大任期阀值。最大任期阀值在可以被设定为0-15，不过在Java 5 update 5之前可以设置为1-31。

 

   不推荐把最大任期阀值设定成0或者超过15，这样会导致GC的低效率。

 

   如果HotSpot VM它无法保持目标survivor 空间的占用量，它会使用一个小于最大值的任期阀值来维持目标survivor空间的占用量，任何比这个任期阀值的大的对象都会被移动到old代。话句话说，当存活对象的量大于目标survivor空间能够接受的量的时候，溢出发生了，溢出会导致对象快速的移动到old代，导致不期望的FullGC。甚至会导致更频繁的stop-the-world压缩垃圾回收。哪些对象会被移动到old代是根据评估对象的岁数和任期阀值来确定的。因此，很有必要监控任期阀值以避免survivor空间溢出，接下来详细讨论。

 

监控任期阀值

 

   为了不被内部计算的任期阀值迷惑，我们可以使用命令选项-XX:MaxTenuringThreshod=<n>来指定最大的任期阀值。为了决定出最大的任期阀值，需要监控任期阀值的分布和对象岁数的分布，通过使用下面的选项实现

 

 

 -XX:+PrintTenuringDistribution

 

   -XX:+PrintTenuringDistribution的输出显示在survivor空间里面有效的对象的岁数情况。阅读-XX:+PrintTenuringDistribution输出的方式是观察在每一个岁数上面，对象的存活的数量，以及其增减情况，以及HotSpot VM计算的任期阀值是不是等于或者近似于设定的最大任期阀值。

 

   -XX:+PrintTenuringDistribution在MinorGC的时候产生任期分布信息。它可以同其他选项一同使用，比如-XX:+PrintGCDateStamps，-XX:+PrintGCTimeStamps以及-XX:+PringGCDetails。当调整survivor空间大小以获得有效的对象岁数分布，你应该使用-XX:+PrintTenuringDistribution。在生产环境中，它同样非常有用，可以用来判断stop-the-world的垃圾回收是否发生。

 

   下面是一个输出的例子：

 

   Desired survivor size 8388608 bytes, new threshold 1 (max 15) 

   - age 1: 16690480 bytes, 16690480 total

 

   在这里例子中，最大任期阀值被设置为15,（通过max 15表示）。内部计算出来的任期阀值是1，通过threshold 1表示。Desired survivor size 8388608 bytes表示一个survivor的空间大小。目标survivor的占有率是指目标survivor和两个survivor空间总和的比值。怎么样指定期望的survivor空间大小在后面会详细介绍。在第一行下面，会列出一个对象的岁数列表。每行会列出每一个岁数的字节数，在这个例子中，岁数是1的对象有16690480字节，而且每行后面有一个总的字节数，如果有多行输出的话，总字节数是前面的每行的累加数。后面举例说明。

 

   在前面的例子中，由于期望的survivor大小（8388608）比实际总共survivor字节数（16690480）小，也就是说，survivor空间溢出了，这次MinorGC会有一些对象移动到old代。这个就意味着survivor的空间太小了。另外，设定的最大任期阀值是15，但是实际上JVM使用的是1，也表明了survivor的空间太小了。

 

   如果发现survivor区域太小，就增大survivor的空间，下面详细介绍如何操作。

   

设定survivor空间

   当修改survivor空间的大小的时候，有一点需要记住。当修改survivor空间大小的时候，如果young代的大小不改变，那么eden空间会减小，进一步会导致更频繁的MinorGC。因此，增加survivor空间的时候，如果young代的空间大小违背了MinorGC频率的需求，eden空间的大小同需要需要增加。换句话说，当survivor空间增加的时候，young代的大小需要增加。

 

   如果有空间来增加MinorGC的频率，有两种选择，一是拿一些eden空间来增加survivor的空间，二是让young的空间更大一些。常规来讲，更好的选择是如果有可以使用的内存，增加young代的空间会比减少eden的空间更好一些。让eden空间大小保持恒定，MinorGC的频率不会改变，即使调整survivor空间的大小。

 

   使用-XX:+PrintTenuringDistribution选项，对象的总字节数和目标survivor空间占用可以用来计算survivor空间的大小。重复前面的例子：

   Desired survivor size 8388608 bytes, new threshold 1 (max 15) 

   - age 1: 16690480 bytes, 16690480 total

 

   存活对象的总字节数是1669048，这个并发垃圾回收器（CMS）的目标survivor默认使用50%的survivor空间。通过这个信息，我们可以知道survivor空间至少应该是33380960字节，大概是32M。这个计算让我们知道对survivor空间的预估值需要计算对象的岁数更高效以及防止溢出。为了更好的预估survivor的可用空间，你应该监控应用稳定运行情况下的任期分布，并且使用所有的额外总存活对象的字节数来作为survivor空间的大小。

 

   在这个例子，为了让应用计算岁数更加有效，survivor空间需要至少提升32M。前面使用的选项是：

 

 

 -Xmx1536m -Xms1536m -Xmn512m -XX:SurvivorRatio=30

 

   那么为了保持MinorGC的频率不发生变化，然后增加survivor空间的大小到32M,那么修改后的选项如下：

 

 

 -Xmx1568m -Xms1568m -Xmn544m -XX:SurvivvorRatio=15

 

   当时young代空间增加了，eden空间的大小保持大概相同，且survivor的空间大小增减了。需要注意的时候，-Xmx、-Xms、-Xmn都增加了32m。另外，-XX:SurvivvorRatio=15让每一个survivor空间的大小都是32m （544/(15+2) = 32）。

 

   如果存在不能增加young代空间大小的限制，那么增加survivor空间大小需要以减少eden空间的大小为代价。下面是一个增加survivor空间大小，每一个survivor空间从16m增减加到32m，那么会见减少eden的空间，从480m减少到448m（512-32-32=448，512-16-16=480）。

 

   

-Xms1536m -Xms1536m -Xmn1512m -XX:SurvivorRatio=14

 

   再次强调，减少eden空间大小会增加MinorGC的频率。但是，对象会在young代里面保持更长的时间，由于提升survivor的空间。

 

   假如运行同样的应用，我们保持eden的空间不变，增加survivor空间的大小，如下面选项：

 

 

 -Xmx1568m -Xms1568m -Xmn544m -XX:SurvivorRatio=15

 

   可以产生如下的任期分布:

   Desired survivor size 16777216 bytes, new threshold 15 (max 15)

 - age 1: 6115072 bytes, 6115072 total
- age 2: 286672 bytes, 6401744 total
- age 3: 115704 bytes, 6517448 total
- age 4: 95932 bytes, 6613380 total
- age 5: 89465 bytes, 6702845 total
- age 6: 88322 bytes, 6791167 total
- age 7: 88201 bytes, 6879368 total
- age 8: 88176 bytes, 6967544 total
- age 9: 88176 bytes, 7055720 total
- age 10: 88176 bytes, 7143896 total
- age 11: 88176 bytes, 7232072 total
- age 12: 88176 bytes, 7320248 total

 

   从任期分布的情况来看，survivor空间没有溢出，由于存活的总大小是7320248，但是预期的survivor空间大小是16777216以及任期阀值和最大任期阀值是相等的。这个表明，对象的老化速度是高效的，而且survivor空间没有溢出。

   在这个例子中，由于岁数超过3的对象很少，你可能像把最大任期阀值设置为3来测试一下，即设置选项-XX:MaxTenuringThreshhold=3,那么整个选项可以设置为：

 

 

 -Xmx1568m -Xms1658m -Xmn544m -XX:SurvivorRatio=15 -XX:MaxTenuringThreshold=3

 

   这个选项设置和之前的选项设置的权衡是，后面这个选择可以避免在MinorGC的时候不必要地把对象从“from” survivor复制到“to” survivor。在应用运行在稳定状态的情况下，观察多次MinorGC任期分布情况，看是否有对象最终移动到old代或者显示的结果还是和前面的结果类似。如果你观察得到和前面的任期分布情况相同，基本没有对象的岁数达到15，也没有survivor的空间溢出，你应该自己设置最大任期阀值以代替JVM默认的15。在这个例子中，没有长时间存活的对象，由于在他们的岁数没有到达15的时候就被垃圾回收了。这些对象在MinorGC中被回收了，而不是移动到old代里面。使用并发垃圾回收（CMS）的时候，对象从young代移动到old代最终会导致old的碎片增加，有可能导致stop-the-world压缩垃圾回收，这些都是不希望出现的。宁可选择让对象在“from” survivor和“to” survivor中复制，也不要太快的移动到old代。

 

   你可能需要重复数次监控任期分布、修改survivor空间大小或者重新配置young代的空间大小直到你对应用由于MinorGC引起的延迟满意为止。如果你发现MinorGC的时间太长，你可以通过减少young代的大小直到你满意为止。尽管，减少young代的大小，会导致更快地移动对象到old代，可能导致更多的碎片，如果CMS的并发垃圾回收能够跟上对象的转移率，这种情况就比不能满足应用的延迟需求更好。如果这步不能满足应用的MinorGC的延迟和频率需求，这个时候就有必要重新审视需求以及修改应用程序了。

 

   如果满足对MinorGC延迟的需求，包括延迟时间和延迟频率，你可以进入下一步，优化CMS垃圾回收周期的启动，下节详细介绍。

CMS垃圾回收器周期   

   一旦young的空间大小（包含eden和survivor空间）已经完善得满足应用对MinorGC产生延迟要求，注意力可以转移到优化CMS垃圾回收器，降低最差延迟时间的时间长度以及最小化最差延迟的频率。目标是保持可用的old代空间和并发垃圾回收，避免stop-the-world压缩垃圾回收。

   stop-the-world压缩垃圾回收是垃圾回收影响延迟的最差情况，对某些应用来说，恐怕无法完全避免开这些，但是本节提供的优化信息至少可以减少他们的频率。

 

   成功的优化CMS垃圾回收器需要达到的效果是old代的里面的垃圾回收的效率要和young代转移对象到old代的效率相同，没有能够完成这个标准可以称为“比赛失败”，比赛失败的结果就是导致stop-the-world压缩垃圾回收。不比赛中失败的一个关键是让下面两个事情结合起来：1、old代有足够的空间。2、启动CMS垃圾回收周期开始时机——快到回收对象的速度比较转移对象来的速度更快。

 

   CMS周期的启动是基于old代的空间大小的。如果CMS周期开始的太晚，他就会输掉比赛，没有能够快速的回收对象以避免溢出old代空间。如果CMS周期开始得太早，会造成不必要的压力以及影响应用的吞吐量。但是，通常来讲过早的启动总比过晚的启动好。

 

   HotSpot VM自动地计算出当占用是多少时启动CMS垃圾回收周期。不过在一些场景下，对于避免stop-the-world垃圾回收，他做得并不好。如果观察到stop-the-world垃圾回收，你可以优化该什么时候启动CMS周期。在CMS垃圾回收中，stop-the-world压缩垃圾回收在垃圾回收日志中输出是“concurrent mode failure”，下面一个例子：

 

   174.445: [GC 174.446: [ParNew: 66408K->66408K(66416K), 0.0000618

   secs]174.446: [CMS ( concurrent mode failure): 161928K->162118K(175104K),

   4.0975124 secs] 228336K->162118K(241520K)

 

   如果你发现有concurrent mode failure你可以通过下面这个选项来控制什么时候启动CMS垃圾回收：

 

   

-XX:CMSInitiatingOccupancyFraction=<percent>

 

   这个值指定了CMS垃圾回收时old代的空间占用率该是什么值。举例说明，如果你希望old代占用率是65%的时候，启动CMS垃圾回收，你可以设置-XX:CMSInitiatingOccupancyFraction=65。另外一个可以同时使用的选项是

 

   

-XX:+UseCMSInitiatingOccupancyOnly

 

   -XX:+UseCMSInitiatingOccupancyOnly指定HotSpot VM总是使用-XX:CMSInitiatingOccupancyFraction的值作为old的空间使用率限制来启动CMS垃圾回收。如果没有使用-XX:+UseCMSInitiatingOccupancyOnly，那么HotSpot VM只是利用这个值来启动第一次CMS垃圾回收，后面都是使用HotSpot VM自动计算出来的值。

 

   -XX:CMSInitiatingOccupancyFraction=<percent>这个指定的值，应该比垃圾回收之后存活对象的占用率更高，怎么样计算存活对象的大小前面在“决定内存占用”的章节已经说过了。如果<percent>不比存活对象的占用量大，CMS垃圾回收器会一直运行。通常的建议是-XX:CMSInitiatingOccupancyFraction的值应该是存活对象的占用率的1.5倍。举例说明一下，假如用下面的Java堆选项配置：

 

   

-Xmx1536m -Xms1536m -Xmn512m

 

   那么old代的空间大小是1024M（1536-512 = 1024m）。如果存活对象的大小是350M的话，CMS垃圾回收周期的启动阀值应该是old代占用空间是525M，那么占用率就应该是51%（525/1024=51%），这个只是初始值，后面还可能根据垃圾回收日志进行修改。那么修改后的命令行选项是：

 

   

-Xmx1536m -Xms1536m -Xmn512m  -XX:+UseCMSInitiatingOccupancyOnly 
   -XX:CMSInitiatingOccupancyFraction=51

 

 

   该多早或者多迟启动CMS周期依赖于对象从young代转移到old代的速率，也就是说，old代空间的增长率。如果old代填充速度比较缓慢，你可以晚一些启动CMS周期，如果填充速度很快，那么就需要早一点启动CMS周期，但是不能小于存活对象的占用率。如果需要设置得比存活对象的占用率小，应该是增加old代的空间。

 

   想知道CMS周期是开始的太早还是太晚，可以通过评估垃圾回收信息识别出来。下面是一个CMS周期开始得太晚的例子。为了更好阅读，稍微修改了输出内容：

 

[ParNew 742993K->648506K(773376K), 0.1688876 secs]

[ParNew 753466K->659042K(773376K), 0.1695921 secs]

[CMS-initial-mark 661142K(773376K), 0.0861029 secs]

[Full GC 645986K->234335K(655360K), 8.9112629 secs]

[ParNew 339295K->247490K(773376K), 0.0230993 secs]

[ParNew 352450K->259959K(773376K), 0.1933945 secs]

 

   注意FullGC在CMS-inital-mark之后很快就发生了。CMS-initial-mark是报告CMS周期多个字段中的一个。下面的例子会使用到更多的字段。

    下面是一个CMS开始的太早了的情况：

 

[ParNew 390868K->296358K(773376K), 0.1882258 secs]

[CMS-initial-mark 298458K(773376K), 0.0847541 secs]

[ParNew 401318K->306863K(773376K), 0.1933159 secs]

[CMS-concurrent-mark: 0.787/0.981 secs]

[CMS-concurrent-preclean: 0.149/0.152 secs]

[CMS-concurrent-abortable-preclean: 0.105/0.183 secs]

[CMS-remark 374049K(773376K), 0.0353394 secs]

[ParNew 407285K->312829K(773376K), 0.1969370 secs]

[ParNew 405554K->311100K(773376K), 0.1922082 secs]

[ParNew 404913K->310361K(773376K), 0.1909849 secs]

[ParNew 406005K->311878K(773376K), 0.2012884 secs]

[CMS-concurrent-sweep: 2.179/2.963 secs]

[CMS-concurrent-reset: 0.010/0.010 secs]

[ParNew 387767K->292925K(773376K), 0.1843175 secs]

[CMS-initial-mark 295026K(773376K), 0.0865858 secs]

[ParNew 397885K->303822K(773376K), 0.1995878 secs]

 

   CMS-initial-mark表示CMS周期的开始， CMS-initial-sweep和CMS-concurrent-reset表示周期的结束。注意第一个CMS-initial-mark报告堆大小是298458K，然后注意，ParNew MinorGC报告在CMS-initial-mark和CMS-concurrent-reset之间只有很少的占用量变化，堆的占用量可以通过ParNew的->的右边的数值来表示。在这个例子中，CMS周期回收了很少的垃圾，通过在CMS-initial-mark和CMS-concurrent-reset之间只有很少的占用量变化可看出来。这里正确的做法是启动CMS周期用更大的old代空间占用率，通过使用参数

-XX:+UseCMSInitiatingOccupancyOnly和-XX:CMSInitiatingOccupancyFraction=<percent>。基于初始（CMS-initial-mark）占用量是298458K以及Java堆的大小是773376K，就是CMS发生的占用率是35%到40%（298458K/773376K=38.5%），可以使用选项来强制提高占用率的值。

 

   下面是一个CMS周期回收了大量old代空间的例子，而且没有经历stop-the-world压缩垃圾回收，也就没有并发错误（concurrent mode failure）。同样的修改输出格式：

 

[ParNew 640710K->546360K(773376K), 0.1839508 secs]

[CMS-initial-mark 548460K(773376K), 0.0883685 secs]

[ParNew 651320K->556690K(773376K), 0.2052309 secs]

[CMS-concurrent-mark: 0.832/1.038 secs]

[CMS-concurrent-preclean: 0.146/0.151 secs]

[CMS-concurrent-abortable-preclean: 0.181/0.181 secs]

[CMS-remark 623877K(773376K), 0.0328863 secs]

[ParNew 655656K->561336K(773376K), 0.2088224 secs]

[ParNew 648882K->554390K(773376K), 0.2053158 secs]

[ParNew 489586K->395012K(773376K), 0.2050494 secs]

[ParNew 463096K->368901K(773376K), 0.2137257 secs]

[CMS-concurrent-sweep: 4.873/6.745 secs]

[CMS-concurrent-reset: 0.010/0.010 secs]

[ParNew 445124K->350518K(773376K), 0.1800791 secs]

[ParNew 455478K->361141K(773376K), 0.1849950 secs]

 

   在这个例子中，在CMS周期开始的时候，CMS-initial-mark表明占用量是548460K。在CMS周期开始和结束（CMS-concurrent-reset）之间，ParNew MinorGC报告显著的减少了对象的占用量。尤其，在CMS-concurrent-sweep之前，占用量从561336K降低到了368901K。这个表明在CMS周期中，有190M空间被垃圾回收。需要注意的是，在CMS-concurrent-sweep之后的第一个ParNew MinorGC报告的占用量是350518K。这个说明超过190M被垃圾回收（561336K-350518K=210818K=205.88M）。

 

   如果你决定优化CMS周期的启动，多尝试几个不同的old代占用率。监控垃圾回收信息以及分析这些信息可以帮助你做出正确的决定。

 

强制的垃圾回收

   如果你想要观察通过调用System.gc()来启动的FullGC，当使用用CMS的时候，有两种方法来处理这种情况。

 

   1、你可以请求HotSpot VM执行System.gc()的时候使用CMS周期，使用如下命令选项：

 

 

 -XX:+ExplicitGCInvokesConcurrent
   或者
   -XX:+ExplicitGCInvokesConcurrentAndUnloadsClasses

 

 

   第一个选项在Java 6及更新版本中能够使用，第二选项在从Java 6 Update 4之后才有。如果可以，建议使用后者。

 

   2、你可以请求HotSpot VM选项忽视强制的调用System.gc()，可以使用如下选项:

 

   

-XX:+DisableExplicitGC

 

   这个选项用来让其他垃圾回收器忽略System.gc()请求。

   

   当关闭的强制垃圾回收需要小心，这样做可能对Java性能产生很大的影响，关闭这个功能就像使用System.gc()一样需要明确的理由。

 

   在垃圾回收日志里面找出明确的垃圾回收信息是非常容易的。垃圾回收的输出里面包含了一段文字来说明FullGC是用于调用System.gc().下面是一个例子:

 

2010-12-16T23:04:39.452-0600: [Full GC (System)

[CMS: 418061K->428608K(16384K), 0.2539726 secs]

418749K->4288608K(31168K),

[CMS Perm : 32428K->32428K(65536K)],0.2540393 secs]

[Times: user=0.12 sys=0.01, real=0.25 secs]

 

   注意Full GC后面的（System）标签，这个说明是System.gc()引起的FullGC。如果你在垃圾回收日志里面观察到了明确的FullGC，想想为什么会出现、是否需要关闭、是否需要把应用源代码里面的相关代码删除掉，对CMS垃圾回收周期是否有意义。

并发的Permanent代垃圾回收

 

    FullGC发生可能是由于permanent空间满了引起的，监控FullGC垃圾回收信息，然后观察Permanent代的占用量，判断FullGC是否是由于permanent区域满了引起的。下面是一个由于permanent代满了引起的FullGC的例子:

 

2010-12-16T17:14:32.533-0600: [Full GC

[CMS: 95401K->287072K(1048576K), 0.5317934 secs]

482111K->287072K(5190464K),

[CMS Perm : 65534K->58281K(65536K)], 0.5319635 secs]

[Times: user=0.53 sys=0.00, real=0.53 secs]

 

    注意permanent代的空间占用量，通过CMS Perm :标签识别。permanent代空间大小是括号里面的值，65536K。在FullGC之前permanent代的占用量是->左边的值，65534K，FullGC之后的值是58281K。可以看到的是，在FullGC之前，permanent代的占用量以及基本上和permanent代的容量非常接近了，这个说明，FullGC是由Permanent代空间溢出导致的。同样需要注意的是，old代还没有到溢出空间的时候，而且没有证据说明CMS周期启动了。

 

   HotSpot VM默认情况下，CMS不会垃圾回收permanent代空间，尽管垃圾回收日志里面有CMS Perm标签。为让CMS回收permanent代的空间，可以用过下面这个命令选项来做到:

 

   

-XX:+CMSClassUnloadingEnabled

 

   如果使用Java 6 update 3及之前的版本，你必须指定一个命令选项:

 

 

 -XX:+CMSPermGenSweepingEnabled

 

   你可以控制permanent的空间占用率来启动CMS permanent代垃圾回收通过下面这个命令选项:

 

   

-XX:CMSInitiatingPermOccupancyFraction=<percent>

 

   这个参数的功能和-XX:CMSInitiatingOccupancyFraction很像，他指的是启动CMS周期的permanent代的占用率。这个参数同样需要和-XX:+CMSClassUnloadingEnabled配合使用。如果你想一直使用-XX:CMSInitiatingPermOccupancyFraction的值作为启动CMS周期的条件，你必须要指定另外一个选项:

 

   

-XX:+UseCMSInitiatingOccupancyOnly

 

CMS暂停时间优化

 

   在CMS周期里面，有两个阶段是stop-the-world阶段，这个阶段所有的应用线程都被阻塞了。这两阶段是“初始标记”阶段和“再标记”阶段，尽管初始标记解决是单线程的，但是通过不需要花费太长时间，至少比其他垃圾回收的时间短。再标记阶段是多线程的，线程数可通过命令选项来控制：

 

   

-XX:ParallelGCThreads=<n>

 

   在Java 6 update 23之后，默认值是通过Runtime.availableProcessors()来确定的，不过是建立在返回值小于等于8的情况下，反之，会使用Runtime.availableProcessors()*5/8作为线程数。如果有多个程序运行在同一个机器上面，建议使用比默认线程数更少的线程数。否则，垃圾回收可能会引起其他应用的性能下降，由于在同一个时刻，垃圾回收器使用太多的线程。

 

   在某些情况下设置下面这个选项可以减少再标记的时间：

 

   

-XX:+CMSScavengeBeforeRemark

 

   这个选项强制HotSpot VM在FullGC之前执行MinorGC，在再标记步骤之前做MinorGC，可以减少再标记的工作量，由于减少了young代的对象数，这些对象能够在old代获取到的。

 

   如果应用有大量的引用或者finalizable对象需要处理，指定下面这个选项可以减少垃圾回收的时间:

 

   

-XX:+ParallelRefProcEnabled

 

   这个选项可以用HotSpot VM的任何一种垃圾回收器上，他会是用多个的引用处理线程，而不是单个线程。这个选项不会启用多线程运行方法的finalizer。他会使用很多线程去发现需要排队通知的finalizable对象。

 

下一步

 

   这一步结束，你需要看看应用的延迟需要是否满足了,无论是使用throughput垃圾回收器或者并发垃圾回收器。如果没有能够满足应用的需要，那么回头看看需求是否合理或者修改应用程序。如果满足了应用的需求，那么我们就进入下一步——优化吞吐量。