减少Full GC执行时间

Full GC的执行时间比Minor GC要长很多。因此，如果Full GC花费了太多的时间（超过1秒），一些连接的部分可能会发生超时错误。

• 如果你试图通过消减老年代空间来减少Full GC的执行时间，可能会导致OutOfMemoryError 或者 Full GC执行的次数会增加。
• 与之相反，如果你试图通过增加老年代空间来减少Full GC执行次数，执行时间会增加。

因此，你需要将老年代空间设定为一个“合适”的值。

影响GC性能的参数

正如我们在第二篇文章结尾提到的，不要幻想“某个人设定了GC参数后性能得到极大的提高，我们为什么不和他用一样的参数？”，因为不同的Web服务所创建对象的大小和他们的生命周期都不尽相同。

简单来说，如果一个任务的执行条件是A，B，C，D和E，同样的任务执行条件换为A和B，你会觉得哪个更快？从一般人的直觉来看，在A和B条件下执行的任务会更快。

Java GC参数也是相同的道理，设定一些参数不但没有提高GC执行速度，反而可能导致他更慢。GC优化的最基本原则是将不同的GC参数用于2台或者多台服务器，并进行对比，并将那些被证明提高了性能或者减少了GC执行时间的参数应用于服务器。请谨记这一点。

下面这个表格列出了GC参数中与内存大小相关的，可以影响性能的参数。

表1：GC优化需要考虑的Java参数

我在进行GC优化时经常使用-Xms，-Xmx和-XX:NewRatio。-Xms和-Xmx是必须的。你如何设定NewRatio 会对GC性能产生十分显著的影响。有些人可能会问如何设定Perm区域的大小？你可以通过-XX:PermSize 和-XX:MaxPermSize参数来设定，

当OutOfMemoryError 错误发生并且是由于Perm空间不足导致时，另一个可能影响GC性能的参数是GC类型。下表列出了所有可选的GC类型（基于JDK6.0）

在分析监控结果后，决定是否进行GC优化

在检查GC状态的过程中，你应该分析监控结果以便决定是否进行GC优化，如果分析结果表明执行GC的时间只有0.1-0.3秒，那你就没必要浪费时间去进行GC优化。但是，如果GC的执行时间是1-3秒，或者超过10秒，GC将势在必行。

但是，如果你已经为Java分配了10GB的内存，并且不能再减少内存大小，你将无法再对GC进行优化。在进行GC优化 之前，你必须想清楚你为什么要分配如此大的内存空间。假如当你分1 GB 或 2 GB内存时出现OutOfMemoryError ，你应该执行堆内存转储（heap dump），并消除隐患。

注意：

堆内存转储是一个用来检查Java内存中的对象和数据的文件。该文件可以通过执行JDK中的jmap命令来创建。在创建文件的过程中，Java程序会暂停，因此不要再系统执行过程中创建该文件。

如果GC执行时间满足下面所有的条件，就意味着无需进行GC优化了。

• Minor GC执行的很快（小于50ms）
• Minor GC执行的并不频繁（大概10秒一次）
• Full GC执行的很快（小于1s）
• Full GC执行的并不频繁（10分钟一次）

上面提到的数字并不是绝对的；他们根据服务状态的不同而有所区别，某些服务可能满足于Full GC每次0.9秒的速度，但另一些可能不是。因此，针对不同的服务设定不同的值以决定是否进行GC优化。

下表展示了内存空间大小，GC执行次数以及GC执行时间三者间的关系。

• 大内存空间
  • 减小GC执行次数
  • 增加GC执行时间
• 小内存空间
  • 减小GC执行时间
  • 增加GC执行次数

关于如何设置内存空间的大小，没有唯一的标准答案。如果服务 器资源足够，而且Full GC也可能在1秒内完成，设置为10GB当然可行。。但绝大多数服务器并不是这样，当内存设为10GB时，可能要花费10~30秒来执行Full GC。当然，执行时间会随对象的大小而改变。

鉴于如此，我们应该如何设定内存空间大小呢？一 般来说，我建议为500MB。不过请注意这不是让你将WAS的内存参数设置为–Xms500m 和–Xmx500m。根据优化GC之前的状态，如果 Full GC执行之后内存空间剩余300MB，那么最好将内存设置为1GB（300MB（默认程序占用）+ 500MB（老年代最小空间）+200MB（空闲内存））。也就是说你要为老年代额外设置500MB。因此，如果你有三个执行服务器，内存分别设置为 1GB，1.5GB，2GB，并且检查结果。

理论上来讲，GC执行速度应该遵循1GB> 1.5GB> 2GB,因此1GB执行GC速度最快。但是并不说明1GB空间的Full GC会花费1秒而2GB空间会花费2秒。时间取决于服务器的性能和对象的大小。因此，最佳的方式是建立尽可能多的衡量指标来监控他们。

对于内存空间大小，你应该额外设定NewRatio参数。 NewRatio参数是新生代和老年代空间的比例，即XX:NewRatio=1意味着新生代与老年代之比为1:1。对于1GB来说就是新生代和老年代各 500MB。如果NewRatio为2，意味着新生代老年代之比为1:2，因此该值越大，老年代空间越大，新生代空间越小。

这看似一件不是很重要的事情，但NewRatio参数会显著地影响整个GC的性能。如果新生代空间很小，会用更多的对象被转移到老年代空间，这样导致频繁的Full GC，增加暂停时间。

你可以简单的认为NewRatio 为1是最佳的选择，但是，有时可能设置为2或3更好，我就见过很多这样的例子。

如何最快的完成GC优化？对比性能测试的结果 应该是最快地方法，为每一台服务器设置不同的参数并监控他们的状态，强烈建议至少监控1或2天的数据。但是，当你对GC优化是，你要确保每次执行相同的负 载。并且请求的比率，例如URL都应该是一致的。不过，即便对于专业测试人员要想精确的控制负载也是很难的，并要花费大量的时间准备。因此，相对来说比较 方便和容易的方法是调整才参数，之后花费较长的时间收集结果。 

最左边的Perm 空间对于最初的GC优化不是很重要，这一次YGC参数的值更加有用。

Minor GC和Full GC的平均值如下表所示

表3：Service S的Minor GC 和Full GC的平均执行时间

最重要的是下面两个数据

• 新生代实际使用空间: 212,992 KB
• 老年代实际使用空间: 1,884,160 KB

因此，总的内存空间为2GB,不算Perm空间的话，新生代与老年代之比为1:9。通过jstat和-verbosegc 日志进行数据收集，并把三台服务器按照如下方式设置。

• NewRatio=2
• NewRatio=3
• NewRatio=4

一天之后，检查系统的GC日志后发现，在设置了NewRatio参数后很幸运的没有发生Full GC，

为什么？

• NewRatio=2: 45 ms
• NewRatio=3: 34 ms
• NewRatio=4: 30 ms

我们看到NewRatio=4 是最佳的参数，虽然它的新生代空间最小，但GC时间确最短。设定这个参数之后，系统没有执行过Full GC。

为了说明这个问题，下面是服务之星一段时间后执行jstat –gcutil的结果

你可能会认为因为服务器接受的请求少才导致的GC执行频率下降。实际上，虽然Full GC没有执行，但是Minor GC被执行了 2,424次。

示例2

这是一个针对ServiceA的例子，我们通过公司内部的应用性能管理系统（APM）发现JVM暂停了相当长的时间（超过8秒），因此我们进行了GC优化。我们找到了Full GC执行时间过长的原因，并着手解决。

进行GC优化的第一步，就是我们添加了-verbosegc参数，并得到如下结果。

图1：进行GC优化之前的STW时间

如上图所示，由HPJMeter自动生成的图片之一。X坐标表示JVM执行的时间。Y坐标表示每次GC的时间。CMS绿点，表示Full GC结果。Parallel Scavenge蓝点，表示Minor GC结果。

之前我曾经说过CMS GC是最快的，但是上面的的结果显示出于某种原因，它最多花费了15秒。是什么导致这个结果？是否想起我之前提过的，CMS在进行内存清理时，会变慢。与此同时，服务的内存被设定为 –Xms1g和–Xmx4g ，且实际分配了4GB内存。

因此，我将GC类型从CMS改为Parallel GC。并且将内存改为2GB，设定NewRatio 为3。几小时之后我使用 jstat –gcutil得到如下结果

相对于4GB时的15秒，Full GC变成了平均每次3秒。但是3秒一样比较慢，因此我设计了如下6种场景。

• Case 1: -XX:+UseParallelGC -Xms1536m -Xmx1536m -XX:NewRatio=2
• Case 2: -XX:+UseParallelGC -Xms1536m -Xmx1536m -XX:NewRatio=3
• Case 3: -XX:+UseParallelGC -Xms1g -Xmx1g -XX:NewRatio=3
• Case 4: -XX:+UseParallelOldGC -Xms1536m -Xmx1536m -XX:NewRatio=2
• Case 5: -XX:+UseParallelOldGC -Xms1536m -Xmx1536m -XX:NewRatio=3
• Case 6: -XX:+UseParallelOldGC -Xms1g -Xmx1g -XX:NewRatio=3

那一个最快呢？结果显示，内存越小，结果越好。下图展示了Case6的结果。这是GC的性能最好。最长的响应时间只有1.7秒。平均时间在1秒之内。

图2：Case6的时间图表

基于以上结果。我们按照Case6调整了GC参数。但是，这导致了每天晚上都会发生OutOfMemoryError。在这里很难解释具体的原因。简单来说，批处理程序导致了内存泄漏。相关的问题已经被解决。

如果对GC日志只分析很短的时间就贸然对所有服务器进行优化是非常危险的。请时刻牢记，你必须同时分析GC日志和应用程序。

我们回顾了两个关于GC优化的例子，正如我之前提到的，例子中提到的GC参数，可以设置在相同的服务器之上，但前提是他们具有相同的CPU，操作系统，JDK版本以及运行着相同的服务。但是不要直接把我用过的参数用到你的服务至上，它们未必能很好的工作。

切实地调优

如果测试的结果满足了预期，那么你不需要对程序进行性能调优。如果没有达到预期结果，你就应该执行调优来解决问题。接下来会通过实例讲解方法。

stop-the-world耗时过长

stop-the-world耗时过长可能是由于GC参数不合理或者代码实现不正确。你可以通过分析工具或堆内存转储文件（Heap dump）来定位问题，比如检查堆内存中对象的类型和数量。如果在其中找到了很多不必要的对象，那么最好去改进代码。如果没有发现创建对象的过程中有特别 的问题，那么最好单纯地修改GC参数。

为了适当地调整GC参数，你需要获取一段足够长时间的GC日志，还必须知道哪些情况会导致长时间的stop-the-world。想了解更多关于如何选择合适的GC参数，可以阅读我同事的一篇博文：How to Monitor Java Garbage Collection。

CPU使用率过低

当系统发生阻塞，吞吐量和CPU使用率都会降低。这可能是由于网络系统或者并发的问题。为了解决这个问题，你可以分析线程转储信息（Thread dump）或者使用分析工具。阅读这篇文章可以获得更多关于线程转储分析的知识：How to Analyze Java Thread Dumps。

你可以使用商业的分析工具对线程锁进行精确的分析，不过大部分时候，只需使用JVisualVM中的CPU分析器，就能获得足够的信息。

CPU使用率过高

如果吞吐量很低但是CPU使用率却很高，很可能是低效率代码导致的。这种情况下，你应该使用分析工具定位代码中性能的瓶颈。可使用的工具有：JVisualVM、Eclipse TPTP或者JProbe。

调优方法

建议你使用如下方法对程序进行调优。

首先，检查性能调优是否必要。测量性能不是一件简单的工作，你也不能保证每次都获得满意的结果。因此如果程序已经满足预期性能需求，不必在调优上增加额外的投入了。

问题只出在一个地方，你要做的就是去解决掉它。二八定律（Pareto principle）对性能调优同样适用。这不是说某个模块的低性能一定只源于一个问题，而是强调我们应该在调优时把注意力放在影响最大的那个问题上。在处理好了最重要的之后，你才应该去解决剩下其他的。也就是建议一次只对一个问题进行修复。

另外需要考虑到气球效应（Balloon effect），有得必有失。你可以通过使用缓存来提高响应能力，但是当缓存逐渐增大，执行一次Full GC的时间也会更长。一般而言，如果你希望内存使用率比较低，那么吞吐量和响应能力可能都会恶化。因此，要知道什么对自己程序来说最重要的，而哪些又是次要的。

到此为止，你应该已经了解了如何对Java程序进行性能调优。为了介绍性能测定的具体过程，我不得不省略其中一些细节，不过我认为这些也足够应对大多数Java Web服务端程序了