背景
有个项目最近上线了，为了避免后面访问量突增引发不可预知的问题，按照惯例需要进行压测。我选取了几个请求比较频繁的接口进混合压测，发现了一个性能瓶颈，是垃圾回收配置不合理导致的。
我使用的是G1垃圾回收策略。
正文
我压测的步骤是慢慢增加并发，最终看接口的响应时间和TPS等指标，我发现接口并发从200加到250(每个接口的并发，总的并发量是 200*接口数量)，TPS并没有明显的提升，TPS一直都是700左右，如下图：
这说明遇到了瓶颈导致，于是我通过监控开始排查系统的瓶颈究竟在哪。排查了一圈，找到了一个可疑的点，我发现在压测期间，服务进行了600多次的GC,总的GC时间到达了2~5秒，如下图所示：
我们知道GC的时候会发生stop the world，所以GC的时间过长肯定会影响接口的响应速度，进而影响接口的TPS。
我继续分析，先看看这些GC是young gc还是full gc，根据下面两个图，可以看到在压测期间，老年代都没有满，而年轻代(eden)则是频繁的爆满释放，那基本可以排除full gc了。
为了进一步验证我的猜想，我在服务的启动参数增加如下的选项打印gc日志
-XX:+PrintGC -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -Xloggc:/opt/gc/gc.log
然后进一步分析确认了以上猜想,
确定了问题点，下面就开始分析问题的原因并思考解决问题的办法。
G1垃圾回收其实是比较复杂的，我这里不打算展开细节，这里只提一个点就是，当Eden区的空间占满之后，会触发Young GC。从上面的图可以看出，我的Eden区大小只有 256 mb，这个值确实有点小，因为的总的堆内存是4G.这个数据让我很困惑，因为我配置G1参数的时候，明明是这样配置的：
-XX:G1NewSizePercent=20 -XX:G1MaxNewSizePercent=30
这两个参数分别是，新生代最小值，默认值5%和新生代最大值，默认值60%。这个比例是相对于总的堆大小的，我的堆大小配置的是：
-Xmx4g -Xms4g
按照这个比例，新生代的大小应该是1G左右啊。似乎我的配置没有生效啊。
于是，我再一次检查整个G1的配置，这次看到了一个可疑的点：
-Xmn256m
这是一个JVM的配置参数，表示把年轻代配置成多大空间，很明显这个配置覆盖了我后面的G1对于新生代的配置。
于是我删除这个配置，重启，然后重新压测。发现GC次数下降了5倍以上，GC时间也下降到了1s以下。看下面这个对比图，效果很明显。
