java内存泄露怎么处理（排查＋解决 Java 内存泄漏，最基本的方法，你必须学会！）

来源：zhenbianshu.github.io/

前些日子小组内安排值班 
    
    
  ，轮流看顾我们的服务
     


     


     
，主要做一些报警邮件处理    
    
    
、Bug 排查  


     


     


  、运营 issue 处理的事 
    
    
  。工作日还好 




 




 




，无论干什么都要上班的 

   

   

 ，若是轮到周末
     

     

     ，那这一天算是毁了
     


     


     
。

不知道是公司网络广了就这样还是网络运维组不给力  




  




  




，网络总有问题 


  


  


，不是这边交换机脱网了就是那边路由器坏了
     
     
     ，还偶发地各种超时   




   




   



，而我们灵敏地服务探测服务总能准确地抓住偶现的小问题 



 



 



，给美好的工作加点料 




 




 




。好几次值班组的小伙伴们一起吐槽              ，商量着怎么避过服务保活机制
    




    




    


，偷偷停了探测服务而不让人发现（虽然也并不敢） 

   

   

 。

前些天我就在周末处理了一次探测服务的锅
     

     

     。

问题

网络问题？

晚上七点多开始














，我就开始不停地收到报警邮件              ，邮件显示探测的几个接口有超时情况  




  




  




。多数执行栈都在：

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%
     

     

     。另外
     

     

     ，JVM 系列面试题和答案全部整理好了  




  




  




，微信搜索​Java技术栈 


  


  


，在后台发送：面试
     
     
     ，​可以在线阅读  




  




  




。

我们的 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














，问题圆满解决
     
     
     。

小结

其实还是要反省一下自己的 
    
    
  ，一开始报警邮件里还有这样的线程栈：

groovy.json.internal.JsonParserCharArray.decodeValueInternal(JsonParserCharArray.java:166) groovy.json.internal.JsonParserCharArray.decodeJsonObject(JsonParserCharArray.java:132) groovy.json.internal.JsonParserCharArray.decodeValueInternal(JsonParserCharArray.java:186) groovy.json.internal.JsonParserCharArray.decodeJsonObject(JsonParserCharArray.java:132) groovy.json.internal.JsonParserCharArray.decodeValueInternal(JsonParserCharArray.java:186)

看到这种报错线程栈却没有细想
     


     


     
，要知道 TCP 是能保证消息完整性的 




 




 




，况且消息没有接收完也不会把值赋给变量 

   

   

 ，这种很明显的是内部错误
     

     

     ，如果留意后细查是能提前查出问题所在的  




  




  




，查问题真是差了哪一环都不行啊   




   




   



。

近期热文推荐：

1.1,000+ 道 Java面试题及答案整理(2022最新版)

2.劲爆！Java 协程要来了 



 



 



。              。
    




    




    


。

3.Spring Boot 2.x 教程 


  


  


，太全了！

4.别再写满屏的爆爆爆炸类了
     
     
     ，试试装饰器模式   




   




   



，这才是优雅的方式！！

5.《Java开发手册（嵩山版）》最新发布 



 



 



，速速下载！

觉得不错              ，别忘了随手点赞+转发哦！