分享一次 Java 内存泄漏的排查
由来
前些日子小组内安排值班,轮流看顾我们的服务,主要做一些报警邮件处理、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%。
我们的 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 -n10 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 是能保证消息完整性的,况且消息没有接收完也不会把值赋给变量,这种很明显的是内部错误,如果留意后细查是能提前查出问题所在的,查问题真是差了哪一环都不行啊。
分享一次 Java 内存泄漏的排查相关推荐
- Java内存泄漏的排查
1.内存溢出 一种通俗的说法. 1.内存溢出:你申请了10个字节的空间,但是你在这个空间写入11或以上字节的数据,出现溢出. 2.内存泄漏:你用new申请了一块内存,后来很长时间都不再使用了(按理应该 ...
- 一次 Java 内存泄漏的排查
由来 前些日子小组内安排值班,轮流看顾我们的服务,主要做一些报警邮件处理.Bug 排查.运营 issue 处理的事.工作日还好,无论干什么都要上班的,若是轮到周末,那这一天算是毁了. 不知道是公司网络 ...
- jstat 内存泄漏_一次Java内存泄漏的排查!要了自己的老命!
点击上方"Java之间",选择"置顶或者星标" 你关注的就是我关心的! 作者:枕边书 来源:https://zhenbianshu.github.io 一.由来 ...
- java 内存泄露对象排查_记录一次 java内存泄漏的排查
1.问题:jar进程会随着时间由 30% 上涨到 70% 直到虚机报警.重启过后,还是会缓慢上涨: 进程数也在上涨: 2.在排查内存问题时,可能会使用的命令 1)查看 java 进程:jps -l 可 ...
- java内存泄漏问题排查
背景:程序部署在客户机器上,不定期异常崩溃,且无日错误异常日志记录. day1:初步排查是内存问题导致的,考虑使用分析工具记录分析.另外代码review仔细排查,怀疑有可能跟大量网络socket没有释 ...
- 一次恐怖的 Java 内存泄漏排查实战
转载自 一次恐怖的 Java 内存泄漏排查实战 最近在看<深入理解Java虚拟机:JVM高级特性与最佳实践>(第二版)这本书,理论+实践结合,深入浅出,强烈推荐给大家. 这两天对JVM内 ...
- unity如何检测内存泄漏_如何排查Java内存泄漏?看懂这一篇就够用了
原文:https://www.toptal.com/java/hunting-memory-leaks-in-java 作者:Jose Ferreirade Souza Filho 译者:Emma来源 ...
- 什么是内存泄露?该怎么排查?Java内存泄漏策略
什么是内存泄漏 内存泄漏:对象已经没有被应用程序使用,但是垃圾回收器没办法移除它们,因为还在被引用着. 在Java中,内存泄漏就是存在一些被分配的对象,这些对象有下面两个特点,首先,这些对象是可达的, ...
- 一次完整的JVM堆外内存泄漏故障排查记录
前言 记录一次线上JVM堆外内存泄漏问题的排查过程与思路,其中夹带一些JVM内存分配机制以及常用的JVM问题排查指令和工具分享,希望对大家有所帮助. 在整个排查过程中,我也走了不少弯路,但是在文章中我 ...
最新文章
- Spring Cloud构建微服务架构:消息驱动的微服务(消费组)【Dalston版】
- mkimage工具讲解
- 通过Pax考试对JBoss Fuse 6.x进行集成测试,第一部分
- java 8 lambda reduce_java8种的reduce方法和lambda表达式结合使用
- 干加个偏旁可以变成什么字_字好看的孩子,都是用了这些小学生学写字的方法...
- win11亮度调节不见了怎么办 windows亮度调节不见了的解决方法
- JAVA编程规范-命名规范
- 【Flutter】基础组件【07】Appbar
- php操作字符串(移除字符,计算字符串中字符个数,分割字符串,字符串序列化...
- MATLAB编程实例
- 分享112个留言聊天PHP源码,总有一款适合你
- 用php打印出日历_PHP完成一个日历
- ubuntu 20.04 | 美化主题、图标、光标、壁纸、登录背景
- 一文教你如何快速高效画出技术架构图
- Python爬虫-爬取豆瓣TOP250
- Goldendict 崩溃退出问题
- VB中数组的大小排序解析
- docker 查询ip
- iphone6 和 iphone6 plus 屏幕适配问题
- 基于python 的电影票房可视化系统
热门文章
- 2015年浪潮面试题
- Docker问题记录
- php excel文件导出之二 图像导出
- SQL_由创建表引出
- 最简单的分形图像生成算法
- [Nhibernate]SchemaExport工具的使用(二)——创建表及其约束、存储过程、视图
- Linux内核目录结构(2.6版本以上的kernel)
- python自定义函数详解_Python自定义函数
- kwvcprojparser不是内部_在盗版window xp上安装的visual studio 2010学习版编译ace6.1时出现如下问题...
- python深入与提高_Python深入01 特殊方法与多范式