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

阅读更多

遇到一个有意思的业务。
有两个单列文件，一个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里轻轻松松解决了问题。