jvm内存常见问题的分析和处理

转载:https://www.huaweicloud.com/articles/efaefd3b4cdc45298eb72747893e49c7.html

 

一.前言

各位开发和运维同学,在项目实施落地的过程中,尤其是使用EDAS、DRDS、MQ这些java中间件时,肯定会遇到不少JAVA程序运行和JVM的问题。我结合过去遇到的各种各样的问题和实际处理经验,总结了JAVA问题的处理方式,希望能帮助到大家。

二.问题处理总体概括

如下图所示:

问题处理分为三大类:

1.问题发生后的紧急处理原则

2.问题归类和分析

3.分析排查工具和命令

通常来说,最后的解决方式有两种,

第一种是最普遍的,绝大部分的最终问题原因可以定位到代码层面,修改代码后问题解决。

第二种,调整某些JVM参数,缓解问题发生的频率和时间,但是治标不治本,所以本篇分析文档并未涉及JVM参数的优化调整。

三.紧急处理原则

问题发生后,第一时间是快速保留问题现场供后面排查定位,然后尽快恢复服务。保留现场的具体操作:

//1 打印栈信息

jstack {pid} >stack.txt

kill -3 {pid} 

//2 堆内存信息

打印堆内存镜像,命令行:jmap -dump:format=b,file=heapdump.phrof {pid}
查看JAVA堆内存运行占用情况:命令行:jstat -gcutil {pid} 1000

查看JAVA堆内存运行分配情况和垃圾回收的情况:   命令行:jstat -gc {pid}

//3 运行存留的日志

保留gc日志文件
保留业务日志文件


4 完成以上操作后,尽快重启JAVA进程或回滚,恢复服务。


四.问题归类和分析

当应用系统运行缓慢,页面加载时间变长,后台长时间无影响时,都可以参考以下归类的解决方法。

问题归类:

1 持续发生Full GC,但是系统不抛出OOM错误
2 堆内存溢出:java.lang.OutOfMemoryError:Java heap space
3 线程过多:java.lang.OutOfMemoryError:unable to create new native thread
4 JAVA进程退出
5 CPU占用过高
 

具体是哪种问题呢?可以按照以下步骤

首先查看进程是否存在  确定进程是否退出

然后使用top 命令 查看 进程占用cpu 和内存的 情况。

然后看业务日志 是否有 OutOfMemoryError 异常或者其他异常

最后看垃圾回收日志 是否存在大量full gc

五.分析排查工具和命令

问题排查,除了最重要的解决思路外,合理的运用工具也能达到事半功倍的效果,某些时候用好了工具,甚至能直接定位到导致问题的具体代码。

JDK自带工具

Jstat

实时查看gc的状况,通过jstat -gcutil 可以查看new区、old区等堆空间的内存使用详情,以及gc发生的次数和时间

Jstack

很重要的命令,jstack可以用来查看Java进程里的线程都在干什么,对于应用没反应、响应非常慢等场景都有很大的帮助。几乎所有java问题排查时,我第一选择都是使用jstack命令打印线程信息。

Jmap

jmap -dump用于保存堆内存镜像文件,供后续MAT或其他的内存分析工具使用。jmap -histo:live也可以强制执行full gc。

Jinfo

通常我用它来查看Java的启动参数

堆内存分析工具

MAT

eclipse官方推出的本地内存分析工具,运行需要大量内存,从使用角度来讲,并不方便。我现在已经很少使用。

代码跟踪工具

Btrace

Java代码动态跟踪神器。少数的问题可以mat后直接看出,而多数会需要再用btrace去动态跟踪。比如排查线程创建过多的场景,通过btrace可以直接定位到哪段代码创建了大量线程。

比较麻烦的就是要自行编写脚本,不过现成的脚本也有不少,可以直接使用。

 

六.案例分析一:持续出现Full GC

处理原则

如果发现cms gc或full gc后,存活的对象始终很多,这种情况下可以通过jmap -dump来获取下内存dump文件,也可以通过gcore命令生成core文件,再用jmap从core里导出dump文件。然后通过MAT、ZProfile、EagleEye-MProf来分析内存镜像分布。如果还不能定位,最后使用btrace来定位到具体的原因。对于cms gc而言,还有可能会出现promotion failed或concurrent mode failure问题。

分析过程

  1. 查看GC日志:

发现应用系统一直在做full gc,而且还有报错“concurrent mode failure”,这表示在执行gc过程中,有对象要晋升到老年代,而此时老年代空间不足造成的。

  1. 查看应用访问日志:

有条很可疑的访问记录,响应时间特别长,达到了60S,直接超时了。

  1. 查看JVM内存分配详情:

如何判断JVM垃圾回收是否正常,我通常会使用jstat命令

具体命令行:jstat -gcutil {pid} 1000

发现Eden区、Old区都满了,此时新创建的对象无法存放,晋升到老年代的对象也无法存放,所以系统持续出现Full GC了。

  1. 分析内存镜像:

这种问题比较直观,需要dump内存镜像,然后用MAT或者Zprofiler工具分析heapdump文件。

MAT(Memory Analyzer Tool),一个基于 Eclipse 的内存分析工具,是一个快速、功能丰富的 JAVA heap 分析工具,它可以帮助我们查找内存泄漏问题。

Zprofiler是阿里中间件团队推出的在线JAVA内存分析工具,不用在本地运行,访问 http://zprofiler.alibaba-inc.com/ 即可。

保存内存镜像的命令:jmap -dump:format=b,file=hprof {pid},通常来讲这个文件会比较大,一般都会有好几个G。

用MAT或ZProfile分析结果如下,基本定位了问题的原因

很明显,LinkedHashMap占用了91.41%的内存,里面有大量的ThRoomQuotaDO的引用对象,很有可能是死循环造成了这样的现象。不过要寻找真实原因,还得看看具体的代码。

  1. 查看源代码

查询ThRoomQuotaDO类的源代码,发现了导致死循环的代码,如下:

代码段一:

`if(start == null || end == null || start.before(now)){

start = CalendarUtil.addDate(now, 1);
end = CalendarUtil.addDate(start,1);`
这里的start和end就是之前应用访问日志里的那条get请求带进来的,请求的url如下:

请注意start=2010-04-031061,本来这个start的值是不规范的,但代码还是通过SimpleDateFormat把start解析成的Date为(Fri Apr 15 00:00:00 CST 2095),所以不会进入代码段一的if块中去。

代码段二:

`Map roomQuotaMapFull = new LinkedHashMap();

for (Date d = hotelQuery.getStart(); d.compareTo(hotelQuery.getEnd()) != 0; d = CalendarUtil.addDate(d, 1)) {

ThRoomQuotaDO rq = new ThRoomQuotaDO();
rq.setTheDate(d);
rq.setMock();
roomQuotaMapFull.put(d, rq);
}`

这里就是最终导致full gc的代码:d.compareTo(hotelQuery.getEnd()) != 0,显然start和end是不相等的,所以陷入死循环中,以致把内存塞满了。

因此,最终的原因得到了定位,要解决起来那就很容易了。

  1. 解决

代码段一:

修改导致问题的代码(标红处是修改后的)

if(start == null || end == null || start.before(now))||start.after(end)){

start = CalendarUtil.addDate(now, 1);
end = CalendarUtil.addDate(start,1);
}

代码段二:

for (Date d = hotelQuery.getStart();d.compareTo(hotelQuery.getEnd()) <= 0;d = CalendarUtil.addDate(d, 1)) {

ThRoomQuotaDO rq = new ThRoomQuotaDO();
rq.setTheDate(d);
rq.setMock();
roomQuotaMapFull.put(d, rq);
}

重新打包发布后,内存恢复正常,再也没有发生此类问题。

案例分析二:OOM:unable to create new native thread

处理原则

在日志中可能会看到java.lang.OutOfMemoryError: Unable to create new native thread,可以先统计下目前的线程数(例如

ps -eLf | grep strategy -c),然后可以看看ulimit -u的限制值是多少,如线程数已经达到限制值,如限制值可调整,则可通过调整限制值来解决;如不能调限制值,或者创建的线程已经很多了,那就需要看看线程都是哪里创建出来的,首先用jstack命令打印线程堆栈信息,统计线程状态,然后通过btrace来查出是哪里创建的线程。

如果jstack执行失败的话,可以使用gcore命令生成core文件:gcore javapid > core.**

然后再用jstack和jmap可以导出堆栈和内存镜像文件。

具体命令:jstack $JAVA_HOME/bin/java core.** > jstack.log

分析过程

  1. 查看GC日志:

发现gc都正常,没有full gc,new区,old区都正常,确定不是heap堆出问题。

  1. 查看应用访问日志:

发现业务日志中有很多错误:

  1. 查看线程堆栈:

查看jstack.log堆栈信息发现一共有8204个线程,其中blocked的有8169个,明显不正常。通过堆栈信息不能看出是什么导致创建了这么多线程,但是至少能确定导致oom的原因了:线程创建太多,且全部block了。下面就需要用btrace工具跟进分析具体是什么代码创建了这么多的线程。

  1. 使用Btrace工具分析:

编写btrace脚本ThreadStart.java,内容如下:

import static com.sun.btrace.BTraceUtils.*;

import com.sun.btrace.annotations.*;

@BTrace public class Trace{

@OnMethod(

clazz=“java.lang.Thread”,
method=“start”
)

public static void traceExecute(){

jstack();
}

}`

执行命令:./btrace javapid ThreadStart.java > thread.log

查看thread.log,到这里可以确定问题所在了,基本上所有的线程都在这个类里创建:com.taobao.et.web.ie.module.action.IeOrderCheckAction.doMileageMeta

  1. 查看源代码

从代码里可以看到,每次执行doMileageMeta都会创建一个线程池,但是没有shutdown释放资源。

问题原因就清楚了:应用启动后,每次请求都会创建一个包含3个线程的线程池,但是从不释放资源,涨到8000多个以后,达到线程上限,抛出了"unable to create new native thread"。

  1. 解决

修改代码:每次创建线程池后,调用shutdown方法来释放资源,具体代码就不帖出来了。

案例分析三:OOM:java heap space

处理原则

java.lang.OutOfMemoryError: java heap size也是常见的现象。最重要的是dump出内存,一种方法是通过在启动参数上增加-XX:+HeapDumpOnOutOfMemoryError,另一种方法是在当出现OOM时,通过jmap -dump获取到内存dump,在获取到内存dump文件后,可通过MAT进行分析,但通常来说仅仅靠MAT可能还不能直接定位到具体应用代码中哪个部分造成的问题,例如MAT有可能看到是某个线程创建了很大的ArrayList,但这样是不足以解决问题的,所以通常还需要借助btrace来定位到具体的代码。

案例分析四:Java进程退出

处理原则

对于Java进程退出,最重要的是要让系统自动生成coredump文件,需要设置ulimit -c unlimited,表示core文件为不限制大小,通常会加到java应用的启动脚本里。当进程crash发生时,找到coredump文件,core文件通常位于 /应用部署目录/target (core文件一般在程序工作区产生)下。有可能的原因是代码中出现了无限递归或死循环,可通过jstack来提取出Java的线程堆栈,从而具体定位到具体的代码。

如果以上方法无效时,可以尝试dmesg命令,看看系统出了什么问题,有可能是系统主动杀掉了Java进程(例如内存超出限制)

分析过程

1.生成coredump文件

在将出现crash的服务器上打开ulimit,等待生成core文件,执行命令:ulimit -c unlimited 。

2.分析coredump文件

执行命令:gdb -c $JAVA_HOME/bin/java coredump_file

键入:info threads ----- 获取core文件中线程信息

其中*号前代表是crash时,当前正在运行的线程

即当前正在运行的线程为 9406

3.使用jstack命令分析core文件,获取指定线程id对应的代码信息

具体命令:jstack $JAVA_HOME/bin/java coredump_file > jstack.log,搜索刚才得到的线程编号 9406,发现问题如下:

原因就是代码里出现了无限递归,导致了爆栈。

案例分析五:CPU占用过高

处理原则

从经验上来说,有些时候是由于频繁cms gc或fgc造成的,在gc log是记录的情况下(-Xloggc:),可通过gc log看看,如果没打开gc log,可通过jstat -gcutil来查看,如是gc频繁造成的,则可跳到后面的内存问题 | GC频繁部分看排查方法。

如不是上面的原因,可使用top -H查看线程的cpu消耗状况,这里有可能会看到有个别线程是cpu消耗的主体,这种情况通常会比较好解决,可根据top看到的线程id进行十六进制的转换,用转换出来的值和jstack出来的java线程堆栈的nid=0x[十六进制的线程id]进行关联,即可看到此线程到底在做什么动作,这个时候需要进一步的去排查到底是什么原因造成的,例如有可能是正则计算,有可能是很深的递归或循环,也有可能是错误的在并发场景使用HashMap等。

分析过程

这里分享下如何查看具体导致CPU高的线程名称

1.找到最耗CPU资源的java线程TID

执行命令:ps H -eo user,pid,ppid,tid,time,%cpu,cmd | grep java | sort -k6 -nr |head -1

2.将找到的线程TID进行十六进制的转换

printf “%xn” tid

3.从堆栈文件里找到对应的线程名称

通过命令导出堆栈文件:jstack javapid > jstack.log,根据上一步得到的线程TID,搜索堆栈文件,即可看到此线程到底在做什么动作。

原文地址:https://www.cnblogs.com/to-here/p/14659683.html