JVM内存GC的骗局
此文已由作者尧飘海授权网易云社区发布。
欢迎访问网易云社区,了解更多网易技术产品运营经验。
概述
在日常程序开发中,很多JAVA程度员不太关心内存的使用情况。当然,如果程序员运气较好或者系统没有大规模的被测试或者被用户使用时,这个问题或许永远不出现,使得程序员一直认为内存反正是无限的,可以一直使用。确实,JVM的垃圾回收器会帮我们处理好所有的事情,可如果运气不是那么好,不幸就有可能发生在我们的身上,比如:进程会抛出OOM异常,不再接收新的请求;响应时间在固定时间段内变长,超时或者不响应,CPU使用率时常像过山车一样等。内存使用在大部分的工作时间可以正常工作,这样会导致很多的人对JAVA应用的内存使用情况不明了或者得不到充分的性能测试,而导致程序无法正常工作。出现上面的情况程序员一般会比较好的较快的发现问题或能总结一定的规律。
问题
有时候JVM还会发生欺骗你的场景, JVM不停的在垃圾回收,可是每次回收完后堆却还是满的,很明显程序内存被使用完了,已经无法正常工作了,但JVM就是不抛出OutOfMemoryError(OOM)这个异常来告诉程序员内部发出了什么,只是不停的做老好人尝试帮我们做垃圾回收,把服务器的资源耗光了,但是此时服务器已经无法响应用户的正常请求了,让我们一起来看看这些情况发生时候的现象,体会一下被欺骗的感觉。
现状:
同事在模拟用户不停的发送请求给某系统,在运行一段时间后,突然,系统上邮件报告测试用例请求失败,登录测试系统的服务器,首先看下JVM的参数设置,如下:
-server –Xms4g –Xmx4g -XX:MaxPermSize=256m -verbose:gc -XX:+PrintGCDetails -Xloggc:$CATALINA_BASE/logs/gc.log -XX:+PrintGCTimeStamp,再使用TOP命令看看服务器发生了什么。
观察一段时间后,CPU一直运行在100%,于是想当然的认为可能是那段程序里面触发了BUG,有可能是正则表达式或者某段代码里面有个死循环的坑跳进去,没有出来。这不是很简单的事吗?直接使用jstack + pid 把堆栈打出来即可,直接操作吧,界面上马上输出操作日志,由于日志过多并且其他的日志类似,帮只截取部分如下:
从上面的堆栈日志可以看出,所有的线程都被BLOCKED住了,然后堆栈里面也找不到任何业务的相关代码,难道直觉出错了,感觉一下子不太好了,但是至少可以排查到不是上面的二种原因了,好吧,那再看看应用的GC的情况,部分日志如下。
1403682.561: [GC [PSYoungGen: 1375104K->11376K(1386176K)] 4145665K->2782002K(4182400K), 0.0174410 secs] [Times: user=0.27 sys=0.00, real=0.02 secs] 1407799.743: [GC [PSYoungGen: 1386160K->11632K(1386432K)] 4156786K->2793538K(4182656K), 0.0285330 secs] [Times: user=0.48 sys=0.00, real=0.03 secs] 1409230.024: [GC [PSYoungGen: 1386416K->10688K(1377984K)] 4168322K->2803822K(4174208K), 0.0265000 secs] [Times: user=0.43 sys=0.00, real=0.02 secs] 1409230.051: [Full GC [PSYoungGen: 10688K->7014K(1377984K)] [PSOldGen: 2793134K->2796224K(2796224K)] 2803822K->2803238K(4174208K) [PSPermGen: 48439K->48439K(262144K)], 7.8892780 secs] [Times: user=7.92 sys=0.00, real=7.89 secs] 1410502.582: [Full GC [PSYoungGen: 1366336K->85344K(1377984K)] [PSOldGen: 2796224K->2796224K(2796224K)] 4162560K->2881568K(4174208K) [PSPermGen: 48577K->48577K(262144K)], 8.2720110 secs] [Times: user=8.29 sys=0.00, real=8.27 secs]
解释一下:
第一行:
1403682.561: [GC [PSYoungGen: 1375104K->11376K(1386176K)] 4145665K->2782002K(4182400K), 0.0174410 secs] [Times: user=0.27 sys=0.00, real=0.02 secs]
发生的时间点,:JVM运行的时间长度,以度为单位,也可以格式化成固定的时间格式
PSYoungGen:发生了何种类型的GC,此处代表发生了年轻代的GC
1375104K:回收前的大小
11376K:回收后的大小
1386176K:YOUNG代的大小
4145665 K:回收前总的占用大小
2782002K:回收后的占用大小
4182400K:总占用大小
0.27和0.00:代表在用户态(user)和系统状(sys)的CPU运行时间
0.02 secs:代表实际的GC的运行时间
注:上面总的运行时间小于用户态和系统态的时间总和,是由于后者仅指CPU的运行时间,包括等待或IO阻塞的时间,而且现在的GC是采用多线程收集的,同时机器也是多个CPU,因此,大部分是二者之和要比前面的值大,如果是采用串形化收集器( serial collector)的话,二者时间几乎相差不多。关于各种收集器的差别,后续有时间再安排详细总结。
接下来的二行,不再重复说明,第四行有Full字样,代表JVM发生了Full GC,不过多了二个分区的收集,PSOldGen:老生代的回收前后空间大小及总空间;PSPermGen:持久代的回收前后空间大小和总空间。从第三行,可以看出老空间的使用率达到饱和,从而触发了FULL GC,但是很遗憾的是第五行后又接着发生了FULL GC,后面的都是一直在持续进行,但是系统一直不抛出OOM异常或者进程退出,导致这台机器服务进程一直存在,但是基本无法正常工作。
GC,无论Young GC还是Full GC,每次都会导致JVM STW(STOP WORLD)暂停用户的业务工作,来处理垃圾回收任务,短时间内无法响应用户请求,特别是大量的Full GC会导致系统响应速度降低,另外还有OOM的巨大风险。Young GC频繁,就算GC采用多线程回收方式,尽管回收的时候非常短,但是如果GC次数和频率很高,因此对应用的影响是不可忽视的。 Full GC 包括整个分区的垃圾回收,包括新生代、旧生代、持久代等。因此其回收成本高,应用也会暂停更长时间,无法及时响应用户的请求,所以需要特别注意这个种情况,一般来讲,排除主动的调用GC操作外,JVM会在以下几种情况发生Full GC。
1. 旧生代内存不足
2. 持久代内存不足
3. 统计新生代 GC晋升到旧生代的平均大小大于旧生代的剩余空间
解决
知道发生的原因后,就可以使用JMAP -heap直接看一下JVM内存的对像值,或者使用JMAP -dump直接JVM的堆栈DUMP出来,使用MAT打开分析就行。如果这种现像发生之后,DUMP出来的文件会较大,有些会达到十多个G,因为一般不直接在工作机器上进行,需要把文件转发到其他的非线上服务并且内存足够的机器上分析,最后可以用MAT把分析后的文件打开即可,操作结果如下:
第四行里面看不出实际的业务相关的,第五行到六行还是可以看出来的,那就先看第四行的对象包括什么具体的实例吧。
打开后,首页会给出可疑的建议对象实例,直接跳转到列表中,打开折叠细节即可看到真面目,里面包括了三十多万个对象,找相关的人员对根据业务需要,直接把不需要的实例在使用完后移除,其他几行的问题类似处理就即可。
总结
从上面GC的发生的情况来看,JVM一次次不停的努力的帮我们进行GC操作,直接把CPU全部占光,但是就是不直接抛出异常直接告诉我们内存不够了,感觉把我们带了到一个巨大的庞氏骗局,也许我们把JVM的内存加大,这个坑还将帮我们隐藏下去,如果程序设置了定时重启之类的操作,这个坑就永远发现不了。一般产品开发人员非常希望应用程序能在用户发觉之前发现这个问题,JVM无法判断出这个问题,也就不能帮我们抛出几乎OOM的异常,不过可以通过调整GCTimeLimit和GCHeapFreeLimit参数来重新定义何时抛出OutOfMemoryError错误。GCTimeLimit 的默认值是98%,也就是说如果98%时间都用花在GC上,则会抛出OutOfMemoryError。GCHeapFreeLimit 是回收后可用堆的大小。默认值是2%。当然最好的办法就是开发工程师开始就很清楚如何使用相关的容器类的正确用法,并且在上线前能经过充分的测试或运行。本文只是引用GC方面的一个具体的安全来说明GC是怎么骗人的,关于GC和JVM内存相关的细节如何及时的发现此类的问题,有机会再通过示例和大家探讨学习。
注:以上资料仅以HOTSPOT VM 1.7.65 版本参考。
参考资料:
JVM http://docs.oracle.com/javase/8/docs/technotes/guides/vm/gc-ergonomics.html
HotSpot JVM就是个庞氏骗局 http://it.deepinmind.com/gc/2014/04/01/hotspot-jvm-ponzi-scheme.html
Java内存泄露分析 http://doc.hz.netease.com/pages/viewpage.action?pageId=36468038
免费体验云安全(易盾)内容安全、验证码等服务
更多网易技术、产品、运营经验分享请点击。
相关文章:
【推荐】 SVN迁移到GIT
转载于:https://www.cnblogs.com/163yun/p/9875928.html
JVM内存GC的骗局相关推荐
- JVM内存GC的骗局——JVM不抛出OOM但内存已经泄露
概述 在日常测试中,我们会去重点观察java的内存使用情况,比如:进程会抛出OOM异常,不再接收新的请求:响应时间在固定时间段内变长,超时或者不响应,CPU使用率时常像过山车一样等.有时候JVM还会发 ...
- jvm对象从新生代到老年代_深入理解jvm内存模型以及gc原理
整体架构 Jvm = 类加载器 + 执行引擎 + 运行时数据区域 类加载器 ● 作用 类加载器是将编译好的class文件加载到内存中,并进行验证.初始化等步骤,形成能被jvm直接使用的类型. ● 加载 ...
- JVM内存管理及GC机制
转载自:http://blog.csdn.net/suifeng3051/article/details/48292193 一.概述 Java GC(Garbage Collection,垃圾收集,垃 ...
- 64位Linux下JVM内存调设遇到GC问题的备忘
问题:jar提交到64位的linux环境中执行,由于文件过大,5G左右,发现数据一致导入不了,于是设置了JVM内存,执行命令如下: java -Xmx10240m -jar vip.jar 结果爆出G ...
- JVM内存结构与GC
JVM内存模型总体架构图 程序计数器 多线程时,当线程数超过CPU数量或CPU内核数量,线程之间就要根据时间片轮询抢夺CPU时间资源.因此每个线程有要有一个独立的程序计数器,记录下一条要运行的指令.线 ...
- 36.JVM内存分哪几个区,每个区的作用是什么、如和判断一个对象是否存活、java垃圾回收机制、垃圾收集的方法有哪些、java类加载过程、类加载机制、双亲委派、Minor GC和Major GC
36.JVM内存分哪几个区,每个区的作用是什么? 37.如和判断一个对象是否存活?(或者GC对象的判定方法) 38.简述java垃圾回收机制? 39.java中垃圾收集的方法有哪些? 40.java类 ...
- JVM内存管理------GC算法精解(五分钟教你终极算法---分代搜集算法)
转载自 JVM内存管理------GC算法精解(五分钟教你终极算法---分代搜集算法) 引言 何为终极算法? 其实就是现在的JVM采用的算法,并非真正的终极.说不定若干年以后,还会有新的终极算法, ...
- JVM内存管理------GC算法精解(五分钟让你彻底明白标记/清除算法)
转载自 JVM内存管理------GC算法精解(五分钟让你彻底明白标记/清除算法) 相信不少猿友看到标题就认为LZ是标题党了,不过既然您已经被LZ忽悠进来了,那就好好的享受一顿算法大餐吧.不过LZ丑 ...
- JVM内存管理------GC算法精解(复制算法与标记/整理算法)
转载自 JVM内存管理------GC算法精解(复制算法与标记/整理算法) 本次LZ和各位分享GC最后两种算法,复制算法以及标记/整理算法.上一章在讲解标记/清除算法时已经提到过,这两种算法都是在此 ...
最新文章
- Android/Java 中线程(Thread)的使用
- 抢鲜!华硕240MIMOWL-566gM
- 如何在TortoiseGit中使用ssh-keygen生成的key
- linux安装x11鼠标主题
- when and where is createContent called
- HDFS常用文件操作命令汇总
- git命令超实用集齐
- 上网爱快?EasyRadius FOR 爱快V2接口测试版正式推出,欢迎广大爱迷们测试噢
- abp api返回自定义结构体
- proxy ip 收集方式总结
- Java NIO 中的非阻塞究竟体现在哪里?
- linux文件夹怎么恢复默认打开方式,怎么还原打开方式_在win7电脑上还原文件默认打开方式的步骤 - 驱动管家...
- 《Linux多线程muduo》读书笔记1——多线程下的析构函数
- linux添加驱动模块,Linux驱动模块添加
- PDF加密如何加密?分享两个方法给你
- AT-GAN: A Generative Attack Model for Adversarial Transferring on Generative Adversarial Nets
- 毕设经典-人事档案管理系统(layer+SSM)-AOP介绍
- html中的keygen元素
- 代理/ssh端口转发
- C语言-快速回忆_float和double的输入输出格式