jvm oom 泄露排查

jvm oom 泄露排查

用户方系统宕机。分析堆内存中的老年代非常高，90%左右。然后知道是系统本身的问题。我们就把dump日志搞下来了。然后导入mat，mat中的某个内存占有率很高的对象，它的incoming处显示了一堆LogRecord对象。然后就知道原因了

我们的系统。如果需要记录日志，要自己配置数据源。客户那边上线后，有一次更换数据源，这个地方忘记了。导致系统频繁连接数据源连接不上，后台也没打日志。所以不停的重试，内存中积累了大量的日志对象。

然后老年代对象高，然后OOM，宕机

总结

1 top 命令找到 对应 进程id

2 ps -mp tid time

3 jstask

4 jmap dump 文件 到 mat 进行分析 一般都能找到原因

CPU过高怎么解决：

​ 1.top 查看哪个进程Id cpu比较高

​ 2）然后通过 top-Hp来查看该进程中有哪些线程CPU过高，一般超过80%就是比较高的。这样我们就能得到CPU消耗比较高的线程id；

​ 3）接着通过该线程id转化为十六进制表示（printf “%x\n” tid tid是线程Id 输出：7082

），在 jstack日志中查看当前线程具体的堆栈信息。（jstack pid |grep tid -A 30 ：pid进程Id tid线程Id 可以具体查看堆栈信息）

​ 4）之后可以区分导致CPU过高的原因具体是Full GC次数过多还是代码中有比较耗时的计算了。

​ 如果是Full GC次数过多，那么通过 jstack得到的线程信息会是类似于VM Thread之类的线程，而如果是代码中有比较耗时的计算，那么我们得到的就是一个线程的具体堆栈信息。

​ 5）我们可以根据堆栈信息，直接定位到UserController的34行，查看代码中具体是什么原因导致计算量如此之高。

​ 总结下：最后，总结下排查CPU故障的方法和技巧有哪些：

​ jstack：Java提供的命令。可以查看某个进程的当前线程栈运行情况。根据这个命令的输出可以定位某个进程的所有线程的当前运行状态、运行代码，以及是否死锁等等。

​ 内存过高怎么解决：

1）用 top命令查看系统CPU的占用情况，找到CPU占用量最大的进程id；

2）用top -Hp pid 查看该进程的各个线程运行情况，找到最大的线程id；

3）用jstack查看这个线程大的原因，出现VM Thread代表垃圾回收的线程，需将线程id转换为16进制查看；

4）用jstack-gcutil pid 1000 线程id查看实时GC情况，这里FGC指的是Full GC数量，进一步证实了是由于内存溢出导致的系统缓慢；

5）用jmap -dump:format=b,file=temp.dump pid 下载dump文件到本地，通过MAT分析对象的引用链的方式来定位具体频繁创建对象的地方，进行处理即可。

​

​ jmap命令——jmap命令有下面几种常用的用法：

​ jmap -histo:live [pid] >a.log，然后分析具体的对象数目和占用内存大小，从而定位代码。

​ jmap -dump:live,format=b,file=xxx.xxx [pid]，然后利用MAT工具分析是否存在内存泄漏等等。

​ 其中，jmap -histo:live [pid] 可以查看当前Java进程创建的活跃对象数目和占用内存大小。jmap -dump:live,format=b,file=xxx.xxx [pid] 则可以将当前Java进程的内存占用情况导出来，方便用专门的内存分析工具（例如：MAT）来分析。这个命令对于分析是否有内存泄漏很有帮助。