本文详细说明了Java应用运行过程中几种常见的JVM相关问题,并给出了问题排查步骤。
一、堆中OOM
现象:Java线程负载过高,JVM内存几乎占满,甚至抛出java.lang.OutOfMemoryError错误。
思路:通过jmap能查看到对内存中实例,可以查看到哪些类的实例比较多,排查出OOM原因。
工具:jmap
步骤:
1.查看实例信息:
jmap -histo 14660 #查看历史生成的实例
jmap -histo:live 14660 #查看当前存活的实例,执行过程中可能会触发一次full gc
2.查看堆信息:jmap -heap
3.堆内存dump下来:
(1)jmap -dump:format=b,file=eureka.hprof 14660
(2)使用jvisualvm命令工具导入该dump文件分析
二、死锁排查
现象:多个线程处于死锁状态,无法再正常执行。
背景:当两个线程互相加了对方所依赖的锁时就会进入死锁状态,例如执行以下代码会进入死锁状态:
public class Test1 {
public static void main(String[] args) {
Object lock = new Object();
Object lock1 = new Object();
new Thread(new Runnable() {
@Override
public void run() {
synchronized (lock) {
try {
Thread.sleep(3000);
} catch (InterruptedException e) {
e.printStackTrace();
}
synchronized (lock1) {
}
}
}
}).start();
new Thread(new Runnable() {
@Override
public void run() {
synchronized (lock1) {
try {
Thread.sleep(3000);
} catch (InterruptedException e) {
e.printStackTrace();
}
synchronized (lock) {
}
}
}
}).start();
}
}
思路:通过jmap能看到所有线程的状态,但线程状态处于blocked时候就是被加锁的状态中。
工具:jmap
步骤:
-
jps 查看进程号
-
用jstack 查找死锁状态中线程。
"Thread-1" 线程名
tid=0x000000079582bc98 线程id
nid=0x3e03 线程对应的本地线程标识nid
java.lang.Thread.State: BLOCKED 线程状态
三、CPU飙升
现象:JVM的CPU飙升
思路:通过top查看出占用最大的java线程id,再通过命令top -Hp找到该线程下关联的进程id,找到占用cpu最高的线程id,将其转换为十六进制,在通过jstack来查看进程状态
工具:top+jstack
步骤:
- 用top命令查找出CPU占用最大的java进程和下面的线程;
查找CPU占用最高的进程:top 查找该进程下面的线程:top -Hp <java_pid>
,可以看到该进程下所有子线程,可以找到占用CPU最高的线程Id,可以用命令:printf "%x\n" <线程id>
将十进制线程id转为十六进制,便于后面jstack命令使用打印GC日志:jstat -gc <java_pid> 5000
- 用jstack查找出对应线程的日志信息;
通过进程id查看栈内信息:jstack <java_pid> | grep <线程id十六进制值> -A 30
(-A 30表示向下打印30行)
总结:cpu飙升可能的原因大概为:
-
代码存在死循环,导致消耗cpu;
-
代码一直在创建大对象,导致频繁GC,这个时候内存占用率也会很高;
四、频繁Full GC
问题说明:系统中某服务为图方便缓存使用一个hashmap,运行过程中会不断往里面放缓存数据,但是没有考虑这个map的容量问题,结果这个缓存map越来越大,一直占用着老年代的很多空间,时间长了就会导致full gc非常频繁,这就是一种内存泄漏,对于一些老旧数据没有及时清理导致一直占用着宝贵的内存资源,时间长了除了导致full gc,还有可能导致OOM。
这种情况完全可以考虑采用一些成熟的JVM级缓存框架来解决,比如guava、ehcache等自带一些LRU数据淘汰算法的框架来作为JVM级的缓存。
工具:jstat
步骤:
- jstat -gc 可以评估程序内存使用及GC压力整体情况
- S0C:第一个幸存区的大小,单位KB
- S1C:第二个幸存区的大小
- S0U:第一个幸存区的使用大小
- S1U:第二个幸存区的使用大小
- EC:伊甸园区的大小
- EU:伊甸园区的使用大小
- OC:老年代大小
- OU:老年代使用大小
- MC:方法区大小(元空间)
- MU:方法区使用大小
- CCSC:压缩类空间大小
- CCSU:压缩类空间使用大小
- YGC:年轻代垃圾回收次数
- YGCT:年轻代垃圾回收消耗时间,单位s
- FGC:老年代垃圾回收次数
- FGCT:老年代垃圾回收消耗时间,单位s
- GCT:垃圾回收消耗总时间,单位s
优化思路:简单来说就是尽量让每次Young GC后的存活对象都留存在年轻代里,尽量别让对象进入老年代,尽量减少Full GC的频率,避免频繁Full GC对JVM性能的影响。
JVM参数说明:
-Xms1536M -Xmx1536M -Xmn512M -Xss256K -XX:SurvivorRatio=6 -XX:MetaspaceSize=256M -XX:MaxMetaspaceSize=256M
-XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=75 -XX:+UseCMSInitiatingOccupancyOnly
文章来源:https://www.toymoban.com/news/detail-699807.html
本文由博客一文多发平台 OpenWrite 发布!文章来源地址https://www.toymoban.com/news/detail-699807.html
到了这里,关于JVM问题排查的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!