`
须等待
  • 浏览: 210493 次
  • 性别: Icon_minigender_1
  • 来自: 深圳
社区版块
存档分类
最新评论

java 对象内存膨胀与Set内存占用问题研究

    博客分类:
  • Java
阅读更多
遇到一个有意思的业务。
有两个单列文件,一个500M一个700M,共1.2G,2E个数据,要将这两个单列文件中的数据提取出来去重。

最简单的思路,理论大小为1.2G的数据塞进Set里直接去重,发现程序跑着跑着就跑不动了,用jstat查看,发现原来没有赋予初始化参数,默认的初始化堆内存太小,导致程序跑不动。

于是在启动的时候加上了-Xms3000m -Xmx3000m

再次启动,用jstat观察发现老年代占用一直在上涨,一段时间之后老年代被占满,Full GC也GC不掉老年代的对象,于是程序再次卡住不动,检查程序没有内存泄露/死循环之后,分析,理论大小1.2G的数据,为何会在内存中占用超过3G的堆内存。

首先检查了Set的内部实现,JDK中Set的实现是用HashMap实现的,而HashMap底层则是两个数组,这里关注到了Map中数组的自动扩容算法:当不停的向Map中put数据的过程中,如果数据量超过了Map中设置的阀值threshold,那么Map就会自动扩容,将原来数组中的数据复制到一个2倍于原来容量的新数组中。
void resize(int newCapacity) {
        Entry[] oldTable = table;
        int oldCapacity = oldTable.length;
        if (oldCapacity == MAXIMUM_CAPACITY) {
            threshold = Integer.MAX_VALUE;
            return;
        }

        Entry[] newTable = new Entry[newCapacity];
        transfer(newTable);
        table = newTable;
        threshold = (int)(newCapacity * loadFactor);
    }

这里可以清楚的看到,Map在移动数据的过程中,需要新建一个数组,而当newCapacity大到一定数量级的时候,就会占用非常多的内存。通过跟踪检查,发现3G内存在数组扩容到5000w大小的时候就抗不住了,于是单独做了一个实验,单独的构造一个5000w大小的数组,观察其内存占用情况,发现确实需要非常多的内存。此为原因之一。

然后,又观察到,虽然构建大数组,需要很多的内存空间,但是这部分空间并没有大到内存无法承受。跟踪检查到,老年代被占满的时候,构造的Set里容纳了2700w个对象,粗略的估算3G被2700w个对象所占据,每个对象大约需要100个字节的大小(由于无法精确的减除掉数组和其他因素占用的内存,所以实际值肯定比100字节要小),但是文件数据为16位的字符串,换句话说,每个16位的字符串对象,在内存里占据了大约100个字节的空间,这比文件编码后的字符大小要大很多。结论:转化为对象的时候,数据会膨胀,并且体积膨胀的大小比我们想象的要更大得多。

最后,丢到hive里轻轻松松解决了问题。
0
3
分享到:
评论
1 楼 须等待 2014-01-24  
麻烦各路神仙,如果我的帖子或者论证的过程有任何错误,欢迎探讨。来我帖子里找自信的麻烦右上角点X出门右转不送,不要来留一些无聊的言论,谢谢。

相关推荐

Global site tag (gtag.js) - Google Analytics