性能文章>关于内存溢出,咱再聊点有意思的?>

关于内存溢出,咱再聊点有意思的?原创

2年前
1098106

概述

上篇文章讲了JVM在GC上的一个设计缺陷,揪出一个导致GC慢慢变长的JVM设计缺陷,可能有不少人还是没怎么看明白的,今天准备讲的大家应该都很容易看明白

本文其实很犹豫写不写,因为感觉没有太多值得探索的东西,不过文末估计会给你点小惊喜

或许大家曾经都碰到过HashMap因为其非线程安全的多线程并发操作导致cpu飙高的问题,不过这个问题在JDK8里已经解决掉了,其根本原因网上也早已遍地开花,所以我这篇文章里就不再熬述了,不了解的可以去网上找找相关文章,本文和大家聊的是看到的另外一个现象—-内存溢出

现象

同事丢了一个链接过来,是内存分析的,我看到一个线程占用的内存非常高,这个问题其实已然非常明显了,展开看了下线程栈
image.png
正在调用一个Map对象的toString方法,直到抛出java.lang.OutOfMemoryError,之所以这个栈顶能看到OutOfMemoryError的逻辑是因为配置了-XX:+HeapDumpOnOutOfMemoryError参数
不过这个参数只会生效一次,不会每次OOM的时候都做内存dump,大家可以想像一下,如果是代码的问题会发生连续的OOM,那连续做dump也没必要,于是JVM里控制这个参数只会在第一次发生OOM的时候做一次内存dump

分析

其实在我看到这个OutOfMemoryError栈之后,还没等同事说多少话,我就立马要同事去看我之前那篇关于OOM的文章了,想表达的是虽然这个线程栈里看到了OOM,但是内存泄露其实不一定是和这个线程有关的,可能只是临门一脚而已,不过后面细看了下这个线程占的内存其实真的挺高了,高达2G多,所以就这个案例来说还是和这个线程有关的,有时候不能太相信自己的经验,具体问题还是得具体分析才好

那为什么这个线程会占用这么大的内存呢?看到整个栈后面都在做字符串的拼接扩容动作,因为都是toString方法触发的,难道真的有个2G的字符串?询问同事他们说绝对不可能存在这么大的字符串,貌似老早之前有同事问过我类似的问题,不过我都一直怀疑他们说的,觉得肯定是存在这么大的字符串的,只是他们不知道而已,原来那个问题我也已经忘记最后情况了。今天又有类似的问题过来,我想也许我想的真的不对?后面同事打我电话说了下场景,他打印一个Map,但是这个Map其实是一个ConcurrentHashMap,是线程安全的,但是这个map里的value是一个HashSet,这个HashSet是非线程安全的,并且存在多个线程修改这个Set的情况,那会不会是因为并发导致的呢,HashSet里其实就是一个HasMap的结构,我觉得是很有可能的,于是要同事自己去模拟下这个场景,看能否重现出来

我继续看他们的内存dump,果然发现了一些猫腻,确实在打印那个HashSet过程中,next字段是循环连起来的,于是基本确定了死循环的存在,没过一会儿,同事也重现出来了,大概逻辑如下:
image.png

注意,这个得在JDK6或者7下跑才会重现,JDK8下不存在这个问题

Demo里就是两个线程同时对HashSet进行修改,可能带来的一个后果是里面的HashMap因为要扩容并且做rehash而出现死循环的情况,当有线程要打印这个HashSet的时候,会调用其toString方法,再看看其父类AbstractCollection的toString的逻辑:
image.png
就是挨个遍历,然后将值塞到StringBuilder里,如果正巧之前因为多线程的并发操作导致了死循环链的产生,那可能会导致这个StringBuilder会非常大,并且还会不断进行扩容,正如上面的堆栈看到的一样,这直接带来的一个后果就是出现内存溢出

内存富余下的OutOfMemory

对于同事线上碰到的那个问题看到的OOM提示是Requested array size exceeds VM limit,这个提示讲真我还是第一次碰到有发生的,假如说你的内存其实非常大,足够的剩余,但是当你要创建一个数组的时候,如果你的数组的长度超过Integer.MAX_VALUE-2的话,那你将会看到一个这个提示的OOM抛出来,其实这也是你能创建的数组的最大长度了,这或许很多人都没有注意到的,就把这个当做本文的一个最有价值的亮点吧

请先登录,感受更多精彩内容
快去登录吧,你将获得
  • 浏览更多精彩评论
  • 和开发者讨论交流,共同进步

为你推荐

不起眼,但是足以让你有收获的JVM内存分析案例
分析 这个问题说白了,就是说有些int[]对象不知道是哪里来的,于是我拿他的例子跑了跑,好像还真有这么回事。点该 dump 文件详情,查看相关的 int[] 数组,点该对象的“被引用对象”,发现所
从一起GC血案谈到反射原理
前言 首先回答一下提问者的问题。这主要是由于存在大量反射而产生的临时类加载器和 ASM 临时生成的类,这些类会被保留在 Metaspace,一旦 Metaspace 即将满的时候,就会触发 Fu
关于内存溢出,咱再聊点有意思的?
概述 上篇文章讲了JVM在GC上的一个设计缺陷,揪出一个导致GC慢慢变长的JVM设计缺陷,可能有不少人还是没怎么看明白的,今天准备讲的大家应该都很容易看明白 本文其实很犹豫写不写,因为感觉没有
协助美团kafka团队定位到的一个JVM Crash问题
概述 有挺长一段时间没写技术文章了,正好这两天美团kafka团队有位小伙伴加了我微信,然后咨询了一个JVM crash的问题,大家对crash的问题都比较无奈,因为没有现场,信息量不多,碰到这类问题我
又发现一个导致JVM物理内存消耗大的Bug(已提交Patch)
概述 最近我们公司在帮一个客户查一个JVM的问题(JDK1.8.0_191-b12),发现一个系统老是被OS Kill掉,是内存泄露导致的。在查的过程中,阴差阳错地发现了JVM另外的一个Bug。这个B
JVM实战:优化我的IDEA GC
IDEA是个好东西,可以说是地球上最好的Java开发工具,但是偶尔也会卡顿,仔细想想IDEA也是Java开发的,会不会和GC有关,于是就有了接下来对IDEA的GC进行调优 IDEA默认JVM参数: -
不起眼,但是足以让你收获的JVM内存案例
今天的这个案例我觉得应该会让你涨姿势吧,不管你对JVM有多熟悉,看到这篇文章,应该还是会有点小惊讶的,不过我觉得这个案例我分享出来,是想表达不管多么奇怪的现象请一定要追究下去,会让你慢慢变得强大起来,
谨防JDK8重复类定义造成的内存泄漏
概述 如今JDK8成了主流,大家都紧锣密鼓地进行着升级,享受着JDK8带来的各种便利,然而有时候升级并没有那么顺利?比如说今天要说的这个问题。我们都知道JDK8在内存模型上最大的改变是,放弃了Perm