加载中…
正文 字体大小:

java nio 和 jvm 虚拟机参数的 XX:+DisableExplicitGC 的潜规则

(2013-12-03 17:22:00)
标签:

it

分类: java

原文:http://blog.csdn.net/phj88/article/details/8011830

有段时间应用总是出现jvm所管理的内存没有发生溢出的情况,而是使用的直接内存区域发生溢出的行为。后来经过分析情况如下:

是由于应用中使用netty,netty 使用的nio 和 jvm 中的 XX:+DisableExplicitGC配置的冲突导致的,

具体经过:nio 使用直接内存区域  Direct Memory内存回收和其他内存回收有点区别。Java堆内放置的是direct memory 引用,正常情况下当在young gc 的时候会把这个已死的引用回收,进而也回收了native memory 区域 , 但是有些移动到old gen区中的,在没有发生full gc时候这个对象一直没有被回收,然后direct memory 应该会累积。

另外当在为DirectByteBuffer分配空间过程中发现直接内存不足时会显式调用System.gc(),以期 通过full GC来强迫已经无用的DirectByteBuffer对象释放掉它们关联的native memory , 这个可以从java.nio的源码中可以分析到(DirectByteBuffer .class Bits.class):



但是导致OOM 的最终原因是jvm调优时配置了参数:

-XX:+DisableExplicitGC这个将会忽略手动调用GC的代码使得 System.gc()的调用就会变成一个空调用,完全不会触发任何GC。

所以实际上在old gen未达到full gc的要求jvm内存回收正常时,而native memory (reservedMemory + size > maxMemory)已经满了。这样就导致了Direct Memory 的OOM

XX:+DisableExplicitGC去掉配置

另外 对于-XX:MaxDirectMemorySize参数的配置,这个参数的设置需要调整,因为这个参数的配置直接会导致full gc的频率,影响web的整体响应情况。

当初查这个问题时一直忽略了jvm的参数被调整过的情况,导致排查过程一直反复。所以这次也算是一次深刻的总结分享吧

0

阅读 评论 收藏 转载 喜欢 打印举报
前一篇:junit4介绍
  • 评论加载中,请稍候...
发评论

    发评论

    以上网友发言只代表其个人观点,不代表新浪网的观点或立场。

    < 前一篇junit4介绍
      

    新浪BLOG意见反馈留言板 电话:4006900000 提示音后按1键(按当地市话标准计费) 欢迎批评指正

    新浪简介 | About Sina | 广告服务 | 联系我们 | 招聘信息 | 网站律师 | SINA English | 会员注册 | 产品答疑

    新浪公司 版权所有