一次极好的JVM日常实践分析

短命女 2023-10-12 11:39 12阅读 0赞

## 一. 前言 ##

JVM 的概率背了不少，但是对于一个系统来说，出现JVM问题通常都是早期刚搭建时，或者代码写错了导致各种问题的出现。

一旦代码写的稳了，系统成熟了，反而很少碰到这类问题，陆陆续续也忘了不少。

这一次属于修改配置后发现JVM变化比较明显，想一想后也大概明白了原因，但是却是一次难得的机会去巩固一下各种概念。

## 二. 重新理解分代 ##

### 2.1 概念复习 ###

要做一个简单的JVM 分析，我们只需要知道这些概念 ：

> 堆内存是什么

*  堆内存用于存储对象实例和数组
 *  堆内存在程序运行时动态分配和扩展，但是可以通过 Xms 和 Xmx 进行初始分配
 *  垃圾回收会对堆内存的对象进行管理

> 堆内存的垃圾回收

*  当JVM中的堆内存空间不足时，可能会触发垃圾回收
 *  当某个分代的内存不足时，也可能触发垃圾回收
 *  当系统处于空闲状态时，JVM可能会选择在此时触发垃圾回收

> 并行和并发的区别

*  并行 ： 利用多个线程并行地执行垃圾回收操作，并行垃圾回收需要暂停应用程序的执行，因为它需要对整个堆进行扫描和处理。 并行的垃圾回收器吞吐更快
 *  并发 ： 在应用程序运行的同时进行垃圾回收，可以在不停止应用程序的情况下，与应用程序并发地执行可以在不停止应用程序的情况下，与应用程序并发地执行

并发的目标是尽量减少应用程序的停顿时间，以提高系统的响应性能、

> FullGC 和 YoungGC 的区别

java复制代码// Young GC
    - 针对Java堆中的年轻代进行的垃圾回收操作
    
    
    // Full GC
    - 对整个Java堆，包括年轻代和老年代，进行的垃圾回收操作
    - 耗时长，需要暂停应用的执行，会导致较长的停顿时间

### 2.2 从结果看过程 ：运行异常的系统 ###

以下是监控上截下来的一些图 ：

![format_png][]

**从这个图可以明显看到前后2个分段:**

*  老年代基本上占了使用总和
 *  年轻代Survivor区和 年轻代Eden区 几乎为空

**而随着重启，老年代清空，新生代基本上正常》》》**

--------------------

下面结合一个 GC 图来看具体的原因 ：

![format_png 1][]

*  首先 : 明显可以看到，老年代占用非常多，基本上等于全部内存
 *  所以 : 当有新的对象创建的时候，由于老年代已经满了，无法接纳更多的对象，年轻代就无法被复制到老年代，从而频繁的发生youngGC

**而这种变化也可以通过下面的具体变化图可以看到>>>>>>**

![format_png 2][]

以上是一个时间周期更短的图，包含了20个小时的分代情况，可以看到 ：

*  修改前youngGC非常频繁，但是效果很差，基本上没什么变化
 *  修改后youngGC变少了，但是内存回收的效果反而更好了

> 结论

**系统中存在异常**，或者没有正确的配置JVM最大堆内 ， **导致老年代一直增多而没有被正确的回收**，导致年轻代频繁的发生youngGC.

基于这个思路，把时间周期拉长，就可以看到一个更清晰的变化曲线了 ：

![format_png 3][]

## 三. 分析问题的原因 ##

所以，**老年代越来越多**，是问题的根源。其实结论也很容易得到，就是代码和配置的问题。

但是既然要学，就把中间的弯弯绕绕全部理清楚。

### 3.1 概念储备 ###

> 问题一 ： 老年代什么环节被回收？

*  老年代是在FullGC环节或者老年代内存空间不足时被回收的
 *  FullGC 会对整个内存进行回收，包括年轻和老年代
 *  老年代通常采用标记-清除（Mark-Sweep）或标记-整理（Mark-Compact）的垃圾回收算法

> 问题二 ：那么老年代为什么不被回收？

*  对象仍然被引用 ：被其他代码引用的对象是不能被垃圾回收给正确回收的，类似的还是长生命周期的对象
 *  未满足GC策略 ： 如果条件未满足或策略未触发，老年代也不会被回收

> 问题三 ： 老年代要是满了会怎样

*  内存泄漏 ： 不同于内存溢出，内存泄漏指无效对象仍然被引用，最终导致内存溢出
 *  内存溢出 ： OutOfMemoryError ，新生代和老年代都无法继续分配内存
 *  系统性能下降 ： 系统性能下降的根源是如果内存满了，会频繁的进行 FullGC , Stop the world 每次都会导致系统暂停，同时影响系统的吞吐量

### 3.2 再看问题 ###

*  S1 : 可以看到，fullGC 很少发生 = **说明还没到内存边界**，并没有触发 fullGC
 *  S2 : 老年代逐渐变多 = **说明代码中确实存在问题**
 *  S3 : 当老年代占用较少时，新生代的波动非常大 = **说明配置有问题**，没有为应用配置合理的内存空间

**基于上述得到的三个结论，开始对代码和配置进行梳理**

> 上道具 ： Arthas 好东西

[juejin.cn/post/719358…][juejin.cn_post_719358]

用 Arthas Dump 下载后，执行分析后不难发现端倪 ：

![format_png 4][]

ConcurrentHashMap 和 地下的 ServiceImpl 占用空间都太大了，往里面翻一下代码就发现了问题 ： HashMap 内的数据一直在插入，没有进行 remove 操作，而Map又还有应用，导致永久代一直增加。

### 3.3 那么正常的结果是什么样的 ###

![format_png 5][]

**首先，年轻代会占大多数，永久代占一小部分，所以年轻代的波动和总理差不多。**

![format_png 6][]

**其次由于GC，就会使年轻代一次次被回收一部分，形成波动**

![format_png 7][]

而随着老年代增加，则年轻代和总量就会逐渐分开，形成上下的结构。

## 总结 ##

如果有相关的经验，其实这样的图像一眼就能看出问题，同时大概也能猜出原因。

上文的3种原因基本上在开始就猜测出来了，后面分析Dump 也是在往那个方向猜测，最后得出的结论也差不多。

## 补充 ： ##

> 常见引起内存溢出的原因

*  分配的对象过大，超过了可用内存的限制。
 *  内存泄漏导致无效对象占用了大量内存空间。
 *  程序中存在死循环或递归调用，导致内存消耗过快。
 *  虚拟机参数配置不当，导致内存不足

[format_png]: https://img-blog.csdnimg.cn/img_convert/62e85fbe0f6659ed84cf2a4d2c61d334.webp?x-oss-process=image/format,png
[format_png 1]: https://img-blog.csdnimg.cn/img_convert/a7f2414f70567b9bfbdb3367be117320.webp?x-oss-process=image/format,png
[format_png 2]: https://img-blog.csdnimg.cn/img_convert/e35fc00f421673d23903330cd9912e6a.webp?x-oss-process=image/format,png
[format_png 3]: https://img-blog.csdnimg.cn/img_convert/bc9a7f10e17167ee5490440983f2fab3.webp?x-oss-process=image/format,png
[juejin.cn_post_719358]: https://juejin.cn/post/7193589542278922295
[format_png 4]: https://img-blog.csdnimg.cn/img_convert/6cc2b433ab1bd37de7a6a19d173ba31f.webp?x-oss-process=image/format,png
[format_png 5]: https://img-blog.csdnimg.cn/img_convert/05c7e3db22dac070e8fca61c6431cea9.webp?x-oss-process=image/format,png
[format_png 6]: https://img-blog.csdnimg.cn/img_convert/cc7c276e4e62eeaae8685ac969e3cb69.webp?x-oss-process=image/format,png
[format_png 7]: https://img-blog.csdnimg.cn/img_convert/bd3fdecf50149d0f96beae4a290bd61b.webp?x-oss-process=image/format,png