面试官：你这JVM调优，回答的很有问题啊！！！

旧城等待， 2023-09-23 21:38 127阅读 0赞

## 1.写在前面 ##

前段时间一位读者面了阿里，在二面中被问到 GC 日志分析，感觉回答的不是很好，过来找我复盘，大致听了他的回答，虽然回答出了部分，但是没抓到重点。

GC 日志分析算是 JVM 调优中比较难的部分，今天这篇文章就来聊聊如何利用 JDK 现有的命令并且借助可视化工具如何去分析 GC 日志。

## 2.JVM 调优实践 ##

### 2.1 JVM 实践调优主要步骤 ###

> 默认的策略是最普用，但不是最佳的。

*  **第一步：监控分析 GC 日志**
 *  **第二步：判断 JVM 问题** ：
    
     *  如果各项参数设置合理，系统没有超时日志出现，GC 频率不高，GC 耗时不高，那么没有必要进行 GC 优化
     *  如果 GC 时间超过 1-3 秒，或者频繁 GC，则必须优化。
 *  **第三步：确定调优目标**
 *  **第四步：调整参数**
    
     *  调优一般是从满足程序的内存使用需求开始，之后是时间延迟要求，最后才是吞吐量要求，要基于这个步骤来不断优化，每一个步骤都是进行下一步的基础，不可逆行之。
 *  **第五步：对比调优前后差距**
 *  **第六步：重复：1 、 2 、 3 、 4 、 5 步骤**
    
     *  找到最佳 JVM 参数设置
 *  **第七步：应用 JVM 到应用服务器** ：
    
     *  找到最合适的参数，将这些参数应用到所有服务器，并进行后续跟踪。

> 以上，就是我们进行 jvm 调优得一些步骤了。
> 
> 那我们就从第一步开始喽！！！^\_^

### 2.2 分析 GC 日志 ###

2.2.1 初始参数设置

**机器环境：**

Jvm 调优典型参数设置;

1.  **-Xms 堆内存的最小值** ：默认情况下，当堆中可用内存小于 40%时，堆内存会开始增加，一直增加到-Xmx 的大小。
2.  **-Xmx 堆内存的最大值**：默认值是总内存/64（且小于 1G）,默认情况下，当堆中可用内存大于 70%时，堆内存会开始减少，一直减小到-Xms 的大小；
3.  **-Xmn 新生代内存的最大值**：包括 Eden 区和两个 Survivor 区的总和，配置写法如：-Xmn1024k，-Xmn1024m，-Xmn1g
4.  **-Xss 每个线程的栈内存**：默认 1M，一般来说是不需要改。线程栈越小意味着可以创建的线程数越多

整个堆的大小 = 年轻代大小 + 年老代大小，堆的大小不包含元空间大小，如果增大了年轻代，年老代相应就会减小，官方默认的配置为年老代大小/年轻代大小=2/1 左右；

建议在开发测试环境可以用 Xms 和 Xmx 分别设置最小值最大值，但是在线上生产环境，**Xms 和 Xmx 设置的值必须一样，防止抖动；**

> 这里比较重要喔，一般我们都是将 Xms 和 Xmx 的值设置为一样的！！！

![bec76db24f78822126f8f248ad6a08e3.png][]

**JVM 调优设置合大小堆内存空间，既不能太大，也不能太小。那么应该设置为多少呢？**

默认的配置是否存在性能瓶颈。如果想要确定 JVM 性能问题瓶颈，需要进一步分析**GC 日志**

1.  **-XX:+PrintGCDetails** 开启 GC 日志创建更详细的 GC 日志 ，默认情况下，GC 日志是关闭的
2.  **-XX:+PrintGCTimeStamps，-XX:+PrintGCDateStamps** ：开启 GC 时间提示
    
     *  开启时间便于我们更精确地判断几次 GC 操作之间的时两个参数的区别
     *  时间戳是相对于 0 （依据 JVM 启动的时间）的值，而日期戳（date stamp）是实际的日期字符串
     *  由于日期戳需要进行格式化，所以它的效率可能会受轻微的影响，不过这种操作并不频繁，它造成的影响也很难被我们感知。
3.  **-XX:+PrintHeapAtGC** 打印堆的 GC 日志
4.  **-Xloggc:./logs/gc.log** 指定 GC 日志路径

这里，我们是在 windows 下面进行测试，idea 配置如下：

![487b9fcac610f9597f4ea03fbad96c49.png][]

> \-XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintGCDateStamps -XX:+PrintHeapAtGC -Xloggc:E:/logs/gc-default.log
> 
> 这样就会在 e 盘下 logs 文件夹下面，生成 gc-default.log 日志

![c6b09d383e9a8eed1f14f0cd6b347e83.png][]

2.2.2 GC 日志解读

**Young GC 日志含义**

2022-08-05T13:45:23.336+0800: 4.866: [GC (Metadata GC Threshold) [PSYoungGen: 136353K->20975K(405504K)] 160049K->48437K(720384K), 0.0092260 secs] [Times: user=0.00 sys=0.02, real=0.02 secs]

这里的内容，我们一个一个解析：

2022-08-05T13:45:23.336+0800: 本次GC发生时间
    4.866: 举例启动应用的时间
    [GC【表示GC的类型，youngGC】 (Metadata GC Threshold) 元空间超阈值
    [PSYoungGen: 136353K->20975K(405504K年轻代总空间)] 160049K->48437K(720384K)整堆), 0.0092260 secs本次垃圾回收耗时]
    [Times: user=0.00本次GC消耗CPU的时间 sys=0.02系统暂停时间, real=0.02 secs实际应用暂停时间]

> 这里的解析，应该很详细了吧，还有谁看不懂的呢？

![68747dbdb6ab73707a7107fb1b4284bb.png][]

**FullGC 日志含义**

2022-08-05T20:24:47.815+0800: 6.955: [Full GC (Metadata GC Threshold) [PSYoungGen: 701K->0K(72704K)] [ParOldGen: 38678K->35960K(175104K)] 39380K->35960K(247808K), [Metaspace: 56706K->56706K(1099776K)], 0.1921975 secs] [Times: user=1.03 sys=0.00, real=0.19 secs]

这里的内容，我们也是一个一个解析：

2022-08-05T20:24:47.815+0800:
    6.955: 刚启动服务就Full GC【整堆回收！！】
    
    [Full GC (Metadata GC Threshold) Metaspace空间超限！
    [PSYoungGen: 701K->0K(72704K)] 年轻代没有回收空间
    [ParOldGen: 38678K->35960K(175104K)] 39380K->35960K(247808K), 老年代也没有到阈值，整堆更没有到阈值
    [Metaspace: 56706K->56706K(1099776K)], 0.1921975 secs]
    [Times: user=1.03本次GC消耗CPU的时间 sys=0.00系统暂停时间, real=0.19 secs实际应用暂停时间]

看到这里，有些哥们就会说，这么看，也太恶心了吧，密密麻麻的日志，看着头疼！！！

![9f782f61e3adaad31a94a7fab0129034.png][]

> 那么接下来我们来学一个 GC 日志可视化工具

![a923cd17afaeedbe74ceae9999bd662c.png][]

2.2.3 GC 日志可视化分析

分析 GC 日志，就必须让 GC 日志输出到一个文件中，然后使用 GC 日志分析工具（gceasy.io/) 进行分析

![c28ffac4fc3f8855ef13f11a75939167.png][]

> 这里分析完之后，可以下载分析报告

![1ba07d7848c663e51f19f9ed4b3af487.png][]

**1) JVM 内存占用情况：**

![81e2fe2a09b894f2fe2dcf628f5f491a.png][]

<table> 
 <thead> 
  <tr> 
   <th>Generation【区域】</th> 
   <th>Allocated【最大值】</th> 
   <th>Peak【占用峰值】</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>Young Generation【年轻代】</td> 
   <td>74.5 mb</td> 
   <td>74.47 mb</td> 
  </tr> 
  <tr> 
   <td>Old Generation【老年轻代】</td> 
   <td>171 mb</td> 
   <td>95.62 mb</td> 
  </tr> 
  <tr> 
   <td>Meta Space【元空间】</td> 
   <td>1.05 gb</td> 
   <td>55.38 mb</td> 
  </tr> 
  <tr> 
   <td>Young + Old + Meta space【整体】</td> 
   <td>1.3 gb</td> 
   <td>212.64 mb</td> 
  </tr> 
 </tbody> 
</table>

2) 关键性能指标：

![92e9636f2e5b6ab3c59dd3218787c8eb.png][]

image.png

1 、**吞吐量**：百分比越高表明 GC 开销越低。这个指标反映了 JVM 的吞吐量。

*  **Throughput**：**97.043%**

2 、**GC 延迟**：**Latency**

*  Avg Pause GC Time：**7.80 ms** 平均 GC 暂停时间
 *  Max Pause GC Time：**190 ms** 最大 GC 暂停时间

3) GC 可视化交互聚合结果

![1aba60ccd74144064158b660d2b47ff7.png][]

由上图可以看到，发生了 3 次 full gc

存在问题：一开始就发生了 3 次 full gc , 很明显不太正常；

4) GC 统计

![053cd0424fcd2dc994b8118a3672fe56.png][]

**GC Statistics**：GC 统计

由上图可以得到，发生 gc 的总次数，young gc，full gc 的统计，gc 暂停时间统计。

5) GC 原因：

![657d09c9aec9cfa82d49d97b3d62c73d.png][]

<table> 
 <thead> 
  <tr> 
   <th>原因</th> 
   <th>次数</th> 
   <th>平均时间</th> 
   <th>最大时间</th> 
   <th>总耗时</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>Metadata GC Threshold</td> 
   <td>6</td> 
   <td>43.3 ms</td> 
   <td>190 ms</td> 
   <td>260 ms</td> 
  </tr> 
  <tr> 
   <td>Allocation Failure</td> 
   <td>53</td> 
   <td>3.77 ms</td> 
   <td>10.0 ms</td> 
   <td>200 ms</td> 
  </tr> 
 </tbody> 
</table>

这里对这些原因解析一下：

1.  **Metadata GC Threshold**：元空间超阈值
2.  **Allocation Failure** ：年轻代空间不足

这里补充一个原因，本案例还没出现的：

*  **Ergonomics**：译文是“人体工程学”，GC 中的 Ergonomics 含义是负责自动调解 gc 暂停时间和吞吐量之间平衡从而产生的 GC。

由此可见，通过可视化的工具，可以快速的帮我们分析 GC 的日志。我们得善于利用工具。

因为 gc 的日志文件，内容太多，都是密密麻麻的数字，文本。看得实在是头疼。

有了**gc easy**可视化工具，而且还是在线的，十分的方便。**GC 日志分析是免费的**

[bec76db24f78822126f8f248ad6a08e3.png]: https://img-blog.csdnimg.cn/img_convert/bec76db24f78822126f8f248ad6a08e3.png
[487b9fcac610f9597f4ea03fbad96c49.png]: https://img-blog.csdnimg.cn/img_convert/487b9fcac610f9597f4ea03fbad96c49.png
[c6b09d383e9a8eed1f14f0cd6b347e83.png]: https://img-blog.csdnimg.cn/img_convert/c6b09d383e9a8eed1f14f0cd6b347e83.png
[68747dbdb6ab73707a7107fb1b4284bb.png]: https://img-blog.csdnimg.cn/img_convert/68747dbdb6ab73707a7107fb1b4284bb.png
[9f782f61e3adaad31a94a7fab0129034.png]: https://img-blog.csdnimg.cn/img_convert/9f782f61e3adaad31a94a7fab0129034.png
[a923cd17afaeedbe74ceae9999bd662c.png]: https://img-blog.csdnimg.cn/img_convert/a923cd17afaeedbe74ceae9999bd662c.png
[c28ffac4fc3f8855ef13f11a75939167.png]: https://img-blog.csdnimg.cn/img_convert/c28ffac4fc3f8855ef13f11a75939167.png
[1ba07d7848c663e51f19f9ed4b3af487.png]: https://img-blog.csdnimg.cn/img_convert/1ba07d7848c663e51f19f9ed4b3af487.png
[81e2fe2a09b894f2fe2dcf628f5f491a.png]: https://img-blog.csdnimg.cn/img_convert/81e2fe2a09b894f2fe2dcf628f5f491a.png
[92e9636f2e5b6ab3c59dd3218787c8eb.png]: https://img-blog.csdnimg.cn/img_convert/92e9636f2e5b6ab3c59dd3218787c8eb.png
[1aba60ccd74144064158b660d2b47ff7.png]: https://img-blog.csdnimg.cn/img_convert/1aba60ccd74144064158b660d2b47ff7.png
[053cd0424fcd2dc994b8118a3672fe56.png]: https://img-blog.csdnimg.cn/img_convert/053cd0424fcd2dc994b8118a3672fe56.png
[657d09c9aec9cfa82d49d97b3d62c73d.png]: https://img-blog.csdnimg.cn/img_convert/657d09c9aec9cfa82d49d97b3d62c73d.png