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

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

3年前
1143906

概述

上篇文章讲了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抛出来,其实这也是你能创建的数组的最大长度了,这或许很多人都没有注意到的,就把这个当做本文的一个最有价值的亮点吧

点赞收藏
你假笨

通过创新的技术肯定可以让这个世界变得更美好,让我们为技术而狂吧

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

为你推荐

怒啃 24 小时,终于搞懂上下文切换!

怒啃 24 小时,终于搞懂上下文切换!

【译】一次Docker 中的 Java 内存消耗问题的排查之旅

【译】一次Docker 中的 Java 内存消耗问题的排查之旅

JVM 常见线上问题:CPU100%、内存泄露的问题排查

JVM 常见线上问题:CPU100%、内存泄露的问题排查

FullGC没及时处理,差点造成P0事故

FullGC没及时处理,差点造成P0事故

使用JDK中自带的JVM分析工具解决内存溢出问题

使用JDK中自带的JVM分析工具解决内存溢出问题

【全网首发】一次想不到的 Bootstrap 类加载器带来的 Native 内存泄露分析

【全网首发】一次想不到的 Bootstrap 类加载器带来的 Native 内存泄露分析

6
0