13518219792
这篇文章主要介绍“Java内存泄漏实例排查分析”，在日常操作中，相信很多人在Java内存泄漏实例排查分析问题上存在疑惑，小编查阅了各式资料，整理出简单好用的操作方法，希望对大家解答”Java内存泄漏实例排查分析”的疑惑有所帮助！接下来，请跟着小编一起来学习吧！
创新互联公司是一家业务范围包括IDC托管业务,雅安服务器托管、主机租用、主机托管，四川、重庆、广东电信服务器租用,绵阳服务器托管，成都网通服务器托管,成都服务器租用,业务范围遍及中国大陆、港澳台以及欧美等多个国家及地区的互联网数据服务公司。
问题出现
晚上七点多开始，我就开始不停地收到报警邮件，邮件显示探测的几个接口有超时情况。
多数执行栈都在：
java.io.BufferedReader.readLine(BufferedReader.java:371) java.io.BufferedReader.readLine(BufferReader.java:389) java_io_BufferedReader$readLine.call(Unknown Source) com.domain.detect.http.HttpClient.getResponse(HttpClient.groovy:122) com.domain.detect.http.HttpClient.this$2$getResponse(HttpClient.groovy)
这个线程栈的报错我见得多了，我们设置的 HTTP DNS 超时是 1s，connect 超时是 2s，read 超时是 3s。
这种报错都是探测服务正常发送了 HTTP 请求，服务器也在收到请求正常处理后正常响应了，但数据包在网络层层转发中丢失了，所以请求线程的执行栈会停留在获取接口响应的地方。
这种情况的典型特征就是能在服务器上查找到对应的日志记录。而且日志会显示服务器响应完全正常。
与它相对的还有线程栈停留在 Socket connect 处的，这是在建连时就失败了，服务端完全无感知。
我注意到其中一个接口报错更频繁一些，这个接口需要上传一个 4M 的文件到服务器，然后经过一连串的业务逻辑处理，再返回 2M 的文本数据。
而其他的接口则是简单的业务逻辑，我猜测可能是需要上传下载的数据太多，所以超时导致丢包的概率也更大吧。
根据这个猜想，群登上服务器，使用请求的 request_id 在近期服务日志中搜索一下，果不其然，就是网络丢包问题导致的接口超时了。
当然这样 leader 是不会满意的，这个结论还得有人接锅才行。于是赶紧联系运维和网络组，向他们确认一下当时的网络状态。
网络组同学回复说是我们探测服务所在机房的交换机老旧，存在未知的转发瓶颈，正在优化，这让我更放心了，于是在部门群里简单交待一下，算是完成任务。
问题爆发
本以为这次值班就起这么一个小波浪，结果在晚上八点多，各种接口的报警邮件蜂拥而至，打得准备收拾东西过周日单休的我措手不及。
这次几乎所有的接口都在超时，而我们那个大量网络 I/O 的接口则是每次探测必超时，难道是整个机房故障了么?
我再次通过服务器和监控看到各个接口的指标都很正常，自己测试了下接口也完全 OK，既然不影响线上服务，我准备先通过探测服务的接口把探测任务停掉再慢慢排查。
结果给暂停探测任务的接口发请求好久也没有响应，这时候我才知道没这么简单。
解决问题
内存泄漏
于是赶快登陆探测服务器，首先是 top free df 三连，结果还真发现了些异常：
我们的探测进程 CPU 占用率特别高，达到了 900%。
我们的 Java 进程，并不做大量 CPU 运算，正常情况下，CPU 应该在 100~200% 之间，出现这种 CPU 飙升的情况，要么走到了死循环，要么就是在做大量的 GC。
使用 jstat -gc pid [interval] 命令查看了 Java 进程的 GC 状态，果然，FULL GC 达到了每秒一次：
这么多的 FULL GC，应该是内存泄漏没跑了，于是使用 jstack pid > jstack.log 保存了线程栈的现场。
使用 jmap -dump:format=b,file=heap.log pid 保存了堆现场，然后重启了探测服务，报警邮件终于停止了。
jstat
jstat 是一个非常强大的 JVM 监控工具，一般用法是：
jstat [-options] pid interval
它支持的查看项有：
class 查看类加载信息。
compile 编译统计信息。
gc 垃圾回收信息。
gcXXX 各区域 GC 的详细信息，如 -gcold。
使用它，对定位 JVM 的内存问题很有帮助。
排查问题
问题虽然解决了，但为了防止它再次发生，还是要把根源揪出来。
分析栈
栈的分析很简单，看一下线程数是不是过多，多数栈都在干嘛：
> grep 'java.lang.Thread.State' jstack.log | wc -l > 464
才四百多线程，并无异常：
> grep -A 1 'java.lang.Thread.State' jstack.log | grep -v 'java.lang.Thread.State' | sort | uniq -c |sort -n 10 at java.lang.Class.forName0(Native Method) 10 at java.lang.Object.wait(Native Method) 16 at java.lang.ClassLoader.loadClass(ClassLoader.java:404) 44 at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method) 344 at sun.misc.Unsafe.park(Native Method)
线程状态好像也无异常，接下来分析堆文件。
下载堆 dump 文件
堆文件都是一些二进制数据，在命令行查看非常麻烦，Java 为我们提供的工具都是可视化的，Linux 服务器上又没法查看，那么首先要把文件下载到本地。
由于我们设置的堆内存为 4G，所以 dump 出来的堆文件也很大，下载它确实非常费事，不过我们可以先对它进行一次压缩。
gzip 是个功能很强大的压缩命令，特别是我们可以设置 -1~-9 来指定它的压缩级别。
数据越大压缩比率越大，耗时也就越长，推荐使用 -6~7，-9 实在是太慢了，且收益不大，有这个压缩的时间，多出来的文件也下载好了。
使用 MAT 分析 jvm heap
MAT 是分析 Java 堆内存的利器，使用它打开我们的堆文件(将文件后缀改为 .hprof), 它会提示我们要分析的种类。
对于这次分析，果断选择 memory leak suspect：
从上面的饼图中可以看出，绝大多数堆内存都被同一个内存占用了，再查看堆内存详情，向上层追溯，很快就发现了罪魁祸首。
分析代码
找到内存泄漏的对象了，在项目里全局搜索对象名，它是一个 Bean 对象，然后定位到它的一个类型为 Map 的属性。
这个 Map 根据类型用 ArrayList 存储了每次探测接口响应的结果，每次探测完都塞到 ArrayList 里去分析。
由于 Bean 对象不会被回收，这个属性又没有清除逻辑，所以在服务十来天没有上线重启的情况下，这个 Map 越来越大，直至将内存占满。
内存满了之后，无法再给 HTTP 响应结果分配内存了，所以一直卡在 readLine 那里。而我们那个大量 I/O 的接口报警次数特别多，估计跟响应太大需要更多内存有关。
给代码 owner 提了 PR，问题圆满解决。
到此，关于“Java内存泄漏实例排查分析”的学习就结束了，希望能够解决大家的疑惑。理论与实践的搭配能更好的帮助大家学习，快去试试吧！若想继续学习更多相关知识，请继续关注创新互联网站，小编会继续努力为大家带来更多实用的文章！
