Devops自动化运维知多少系列-jvm与内存泄漏

女爷i 2023-05-28 05:04 18阅读 0赞

#### 今日热点jvm与内存泄漏 ####

jstat -gcutil tomcat的pid 5000

![format_png][]  
查看JVM内存使用和垃圾回收情况  
JVM内存泄漏是性能故障的主要原因之一，由于JVM内存使用情况极易获取，我们将内存作为第一排查对象，在讲如何查看内存使用情况之前，先普及一下JVM内存结构和垃圾回收的相关知识：

JVM内存结构：线程独享内存、线程共享内存  
线程共享内存：新生代（young Gen）、老年代（old Gen）、永久代（perm Gen）一般不会发生内存泄漏  
Java常量刚刚实例的对象在Edenspace 堆区即s0 s1  
java内存泄漏一般发生在线程共享区的老年代（old Gen）

先看下JAVA堆内存是如何划分的，如图

![format_png 1][]

JVM垃圾回收（GC）作用：清理共享内存，将已失去应用的对象从内存中清楚。  
JVM垃圾回收有两种方式：  
1、Young GC ：回收速度快，通常在毫秒级，触发条件Eden space满了。  
2、Full GC ： 回收速度非常慢，测试1.4G的old Gen进行一次回收需要20-40秒，触发条件是old Gen满了。

如图：E是Edenspace满了，发生了Young GC  
![format_png 2][]

如图：O是old Gen满了，发生一次Full GC  
![format_png 3][]

分析JVM内存泄漏导致服务不可用的原因：当出现内存泄漏时,一些对象会占用大量的JVM内存，且长时间无法被JVM回收掉，这些长时间无法被回收的对象通常会在old Gen中；由于old Gen中存在大量的无法被回收的对象，每次full Gc只能释放极少的old Gen空间，回收出的这极少部分old Gen空间很快又被占满，这就会导致JVM频繁的进行Full GC，前文提到过Full GC的速度很慢，而JVM在做Full GC的时候stop-the-world，即在Gc是终止一切工作，所以我们可以假设在内存泄漏发生时，JVM被迫60秒一次Full GC，一次Full GC需要30s，这就代表jvm只有二分之一时间正常工作，此时的性能肯定非常慢，而随着泄漏的对象不断的增多，Full GC加快，最后JVM没有工作时间，一直在Full GC，此时服务彻底不可用。  
实例：  
![format_png 4][]

如果jstat命令输出的信息表示JVM正在频繁的Full Gc,那么基本可以肯定性能故障的原因是内存泄漏，此时需要通过进一步的手段定位内存泄漏点，内存dump文件分析通过jmap -dump:format=b,file=(filename) (pid)命令导出dump文件，一般内存dump文件比较大肉眼是不可读的，需要通过工具进行分析，注意：内存文件输出时，JAVA的虚拟机jvm是不工作的。  
![在这里插入图片描述][20200327145236202.jpg_pic_center]

[format_png]: /images/20230528/f56587e5e50246babe1cf3f429428d87.png
[format_png 1]: /images/20230528/52877bd4f3e64474bab526232406ac4d.png
[format_png 2]: /images/20230528/5a5fa9c38b794c11897e1294fbe53033.png
[format_png 3]: /images/20230528/73069ae5287b41eda42d55d30645ce35.png
[format_png 4]: /images/20230528/6ead6e016e31441486203b741557090b.png
[20200327145236202.jpg_pic_center]: /images/20230528/483bd0a15fbb4b91b5f5e17978489cf2.png