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

946 阅读4分钟

概述

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

欢迎关注 PerfMa 社区,推荐阅读:
JVM Code Cache空间不足,导致服务性能变慢
海量连接服务端CMS调优记