如何对JVM进行优化(下)?

Alleria Windrunner 2021-09-21

187

上一篇我们介绍了JVM优化的基础知识，本篇我们来一起拿一个例子实战一下。

内存调优实战

我们将Java 堆设置得过小，导致频繁的 GC，我们将通过 GC 日志分析工具来观察 GC 活动并定位问题。

首先我们建立一个 Spring Boot 程序，作为我们的调优对象，代码如下：

@RestController
public class GcTestController {


    private Queue<Greeting> objCache =  new ConcurrentLinkedDeque<>();


    @RequestMapping("/greeting")
    public Greeting greeting() {
        Greeting greeting = new Greeting("Hello World!");


        if (objCache.size() >= 200000) {
            objCache.clear();
        } else {
            objCache.add(greeting);
        }
        return greeting;
    }
}


@Data
@AllArgsConstructor
class Greeting {
   private String message;
}

上面的代码就是创建了一个对象池，当对象池中的对象数到达 200000 时才清空一次，用来模拟年老代对象。用下面的命令启动测试程序：

java -Xmx32m -Xss256k -verbosegc -Xlog:gc*,gc+ref=debug,
gc+heap=debug,gc+age=trace:file=gc-%p-%t.log:tags,uptime,time,level:filecount=2,filesize=100m 
-jar target/demo-0.0.1-SNAPSHOT.jar

我给程序设置的堆的大小为 32MB，目的是能让我们看到 Full GC。除此之外，我还打开了 verbosegc 日志，请注意这里我使用的版本是 Java 12，默认的垃圾收集器是 G1。

使用 JMeter 压测工具向程序发送测试请求，访问的路径是/greeting。

使用 GCViewer 工具打开 GC 日志，我们可以看到这样的图：

我来解释一下这张图：

图中上部的蓝线表示已使用堆的大小，我们看到它周期的上下震荡，这是我们的对象池要扩展到 200000 才会清空。
图底部的绿线表示年轻代 GC 活动，从图上看到当堆的使用率上去了，会触发频繁的 GC 活动。
图中的竖线表示 Full GC，从图上看到，伴随着 Full GC，蓝线会下降，这说明 Full GC 收集了年老代中的对象。

基于上面的分析，我们可以得出一个结论，那就是 Java 堆的大小不够。我来解释一下为什么得出这个结论：

GC 活动频繁：年轻代 GC（绿色线）和年老代 GC（黑色线）都比较密集。这说明内存空间不够，也就是 Java 堆的大小不够。
Java 的堆中对象在 GC 之后能够被回收，说明不是内存泄漏。

我们通过 GCViewer 还发现累计 GC 暂停时间有 55.57 秒，如下图所示：

因此我们的解决方案是调大 Java 堆的大小，像下面这样：

java -Xmx2048m -Xss256k -verbosegc -Xlog:gc*,gc+ref=debug,
gc+heap=debug,gc+age=trace:file=gc-%p-%t.log:tags,uptime,time,level:filecount=2,filesize=100m 
-jar target/demo-0.0.1-SNAPSHOT.jar

生成的新的 GC log 分析图如下：

你可以看到，没有发生 Full GC，并且年轻代 GC 也没有那么频繁了，并且累计 GC 暂停时间只有 3.05 秒。

数据库

文章转载自Alleria Windrunner，如果涉嫌侵权，请发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。

如何对JVM进行优化(下)?

评论