优化案例
Service S 优化
现在看一下执行jstat -gcutil的结果
S0 S1 E O P YGC YGCT FGC FGCT GCT
12.16 0.00 5.18 63.78 20.32 54 2.047 5 6.946 8.993
左边的Perm区的值对于最初的GC优化并不重要，而YGC参数的值更加对于这次优化更为重要。
平均执行一次Minor GC和Full GC消耗的时间如下表所示：
Service S的Minor GC 和Full GC的平均执行时间
| GC类型 | GC执行次数 | GC执行时间 | 平均值 |
|---|---|---|---|
| Minor GC | 54 | 2.047s | 37ms |
| Full GC | 5 | 6.946s | 1.389s |
37ms对于Minor GC来说还不赖，但1.389s对于Full GC来说意味着当GC发生在数据库Timeout设置为1s的系统中时，可能会频繁出现超时现象。
首先，你需要检查开始GC优化前内存的使用情况。
使用jstat -gccapacity命令可以检查内存用量情况。在笔者的服务器上查看到的结果如下：
NGCMN NGCMX NGC S0C S1C EC OGCMN OGCMX OGC OC PGCMN PGCMX PGC PC YGC FGC
212992.0 212992.0 212992.0 21248.0 21248.0 170496.0 1884160.0 1884160.0 1884160.0 1884160.0 262144.0 262144.0 262144.0 262144.0 54 5
其中的关键值如下：
- 新生代内存用量：212,992 KB
- 老年代内存用量：1,884,160 KB
因此，除了永久代以外，被分配的内存空间加起来有2GB，并且新生代：老年代=1：9，为了得到比使用jstat更细致的结果，还需加上-verbosegc参数获取日志，并把三台服务器按照如下方式设置（除此以外没有使用任何其他参数）：
- NewRatio=2
- NewRatio=3
- NewRatio=4
一天后我得到了系统的GC log，幸运的是，在设置完NewRatio后系统没有发生任何Full GC。
这是为什么呢？这是因为大部分对象在创建后很快就被回收了，所有这些对象没有被传入老年代，而是在新生代就被销毁回收了。
在这样的情况下，就没有必要去改变其他的参数值了，只要选择一个最合适的NewRatio值即可。
那么，如何确定最佳的NewRatio值呢？为此，我们分析一下每种NewRatio值下Minor GC的平均响应时间。
在每种参数下Minor GC的平均响应时间如下：
- NewRatio=2：45ms
- NewRatio=3：34ms
- NewRatio=4：30ms
我们可以根据GC时间的长短得出NewRatio=4是最佳的参数值（尽管NewRatio=4时新生代空间是最小的）。
在设置完GC参数后，服务器没有发生Full GC。
为了说明这个问题，下面是服务执行一段时间后执行jstat –gcutil的结果:
S0 S1 E O P YGC YGCT FGC FGCT GCT
8.61 0.00 30.67 24.62 22.38 2424 30.219 0 0.000 30.219
你可能会认为是服务器接收的请求少才使得GC发生的频率较低，实际上，虽然Full GC没有执行过，但Minor GC被执行了2424次。