JVM 性能调优之内存优化与 GC 优化

压测工具 AB

测试 post 请求接口
ab -n100 -c10 -p’post.txt’ -T’application/x-www-form-urlencoded’ ‘http://test.api.com/test/register’
post.txt 为存放 post 参数的文档，存储格式如 usernanme=test&password=test&sex=1
参数的含义：
-n：总请求次数（最小默认为 1）；
-c：并发次数（最小默认为 1 且不能大于总请求次数，例如：10 个请求，10 个并发，实际就是 1 人请求 1 次）；
-p：post 参数文档路径（-p 和 -T 参数要配合使用）；
-T：header 头内容类型（此处切记是大写英文字母 T）；

GC 监控
jstat -gc 8404 5000 | awk ‘{print$13,$14,$15,$16,$17}’

wrk

调整堆内存空间减少 GC：通过分析，堆内存基本被用完了，而且存在大量 MinorGC 和 FullGC，这意味着我们的堆内存严重不足，这个时候我们需要调 大堆内存空间。

一般情况下，高并发业务场景中，需要一个比较大的堆空间，而默认参数情况下，堆空间不会很大。所以我们有必要进行调整。 但是不要单纯的调整堆的总大小，要调整新生代和老年代的比例，以及 Eden 区还有 From 区，还有 To 区的比例。 所以在我们上述的测试中，调整方案二，得到结果是最好的。在三种测试情况下都能够有非常好的性能指标，同时 GC 耗时相对控制也较好。 对于调整方案一，就是单纯的加大堆空间，里面的比例不适合高并发场景，反而导致堆空间变大，没有明显减少 GC 的次数，但是每次 GC 需要检索对象 的堆空间更大，所以 GC 耗时更长。 方案二：调整为一个很大的新生代和一个较小的老年代.原因是,这样可以尽可能回收掉大部分短期对象,减少中期的对象,而老年代尽存放长期存活对象。 由于新生代空间较小，Eden 区很快被填满，就会导致频繁 MinorGC，因此我们可以通过增大新生代空间来降低 MinorGC 的频率。 单次 MinorGC 时间是由两部分组成：T1（扫描新生代）和 T2（复制存活对象）。 默认情况：一个对象在 Eden 区的存活时间为 500ms，MinorGC 的时间间隔是 300ms，因为这个对象存活时间>间隔时间，那么正常情况下，Minor GC 的时间为 ：T1+T2。 方案一：整堆空间加大，但是新生代没有增大多少，对象在 Eden 区的存活时间为 500ms，MinorGC 的时间可能会扩大到 400ms，因为这个对象存 活时间>间隔时间，那么正常情况下，MinorGC 的时间为 ：T11.5（Eden 区加大了）+T2
方案二：当我们增大新生代空间，MinorGC 的时间间隔可能会扩大到 600ms，此时一个存活 500ms 的对象就会在 Eden 区中被回收掉，此时就不 存在复制存活对象了，所以再发生 MinorGC 的时间为：即 T12（空间大了）+T2*0 可见，扩容后，MinorGC 时增加了 T1，但省去了 T2 的时间。 在 JVM 中，复制对象的成本要远高于扫描成本。如果在堆内存中存在较多的长期存活的对象，此时增加年轻代空间，反而会增加 MinorGC 的时间。如 果堆中的短期对象很多，那么扩容新生代，单次 MinorGC 时间不会显著增加。因此，单次 MinorGC 时间更多取决于 GC 后存活对象的数量，而非 Eden 区的大小。 这个就解释了之前的内存调整方案中，方案一为什么性能还差些，但是到了方案二话，性能就有明显的上升。