在一個下雨的夜晚，我在思考Java中記憶體管理的問題，以及Java集合對記憶體使用的效率情況。我做了一個簡單的實驗，測試在16G記憶體條件下，Java的Map可以插入多少物件。

這個試驗的目的是為了得出集合的內部上限。所以，我決定使用很小的key和value。所有的測試，都是在64w位linux環境下進行的，作業系統是ubuntu12.04。JVM版本為Oracle Java 1.7.0_09-bo5 (HotSpot 23.5-b02)。在這個JVM中，壓縮指標(compressed pointers(-XX:+UseCompressedOops))的選項是預設開啟的。

首先是簡單的針對java.util.TreeMap的測試。不停向其中插入數字，直到其丟擲記憶體溢位異常。JVM的設定是-xmx15G

import java.util.*; 
Map m = new TreeMap();
for(long counter=0;;counter++){
  m.put(counter,"");
  if(counter%1000000==0) System.out.println(""+counter);
}

這個用例插入了1 7200 0000條資料。在接近結束的時候，由於高負荷的GC插入效率開始降低。第二次，我用HashMap代替TreeMap，這次插入了182 000 000條資料。

Java預設的集合並不是最高效利用記憶體的。所以，這回我們嘗試最後化記憶體的測試。我選擇了MapDB中的LongHashMap，其使用原始的long key並且對封裝的記憶體佔用進行了優化。JVM的設定仍然是-Xmx15G

import org.mapdb.*
LongMap m = new LongHashMap();    
for(long counter=0;;counter++){
  m.put(counter,"");
  if(counter%1000000==0) System.out.println(""+counter);
}

這次，計數器停止在了276 000 000。同樣，在插入接近結束的時候，速度開始減慢。看起來這是基於堆的結合的限制所在。垃圾回收帶來了瓶頸 。

現在是時候祭出殺手鐗了:-)。我們可以採用非基於堆的方式儲存，這樣GC就不會發現我們的資料。我來介紹一下MapDB，它提供了基於資料庫引擎的併發同步的TreeMap和HashMap。它提供了多樣化的儲存方式，其中一個就是非堆記憶體的方式。(宣告：我是MapDB的作者)。

現在，讓我們再跑一下之前的用例，這次採用的是非堆的Map。首先是配置並開啟資料庫，它開啟的直接基於記憶體儲存並且關閉事物的模式。接下來的程式碼是在這個db中建立一個新的map。

import org.mapdb.*

DB db = DBMaker
   .newDirectMemoryDB()
   .transactionDisable()
   .make();

Map m = db.getTreeMap("test");
for(long counter=0;;counter++){
  m.put(counter,"");
  if(counter%1000000==0) System.out.println(""+counter);
}

這是非堆的Map，所以我們需要不同的JVM配置： -XX:MaxDirectMemorySize=15G -Xmx128M。這次測試在達到980 000 000條記錄的時候出現記憶體溢位。

但是，MapDB還可以優化。之前樣例的問題在於記錄的破碎分散，b-tree的節點每次插入都要調整它的容量。變通的方案是，將b-tree的節點在其插入前短暫的快取起來。這使得記錄的分散降到最低。所以，我們來改變一下DB的配置：

DB db = DBMaker
     .newDirectMemoryDB()
     .transactionDisable()
     .asyncFlushDelay(100)
     .make();

Map m = db.getTreeMap("test");   

這次記錄數達到了 1 738 000 000。速度也是達到了驚人的31分鐘完成了17億資料的插入。

MapDB還能繼續優化。我們把b-tree的節點容量從32提升到120並且開啟透明(OneCoder理解為對使用者不可見的)壓縮：

DB db = DBMaker
            .newDirectMemoryDB()
            .transactionDisable()
            .asyncFlushDelay(100)
            .compressionEnable()
            .make();

   Map m = db.createTreeMap("test",120, false, null, null, null);

這個用例在大約3 315 000 000條記錄時出現記憶體溢位。由於壓縮，他的速度 有所降低，不過還是在幾個小時內完成。我還可以進行一些優化(自定義序列化等等) ，使得資料量達到大約40億。

也許你好奇所有這些記錄是怎麼儲存的。答案就是，delta-key壓縮。(OneCoder注：不知如何翻譯)。當然，向B-Tree插入已經排好序的遞增key是最佳的使用場景，並且MapDB也對此進行了一些小小的 優化。最差的情形就是key是隨機的.

後續更新：很多朋友對壓縮有一些困惑。在這些用例中，Delta-key 壓縮預設都是啟用的。在下面的用例中，我又額外開啟了zlib方式的壓縮：

DB db = DBMaker
            .newDirectMemoryDB()
            .transactionDisable()
            .asyncFlushDelay(100)
            .make();

    Map m = db.getTreeMap("test");

    Random r = new Random();
    for(long counter=0;;counter++){
        m.put(r.nextLong(),"");
        if(counter%1000000==0) System.out.println(""+counter);
    }

即使在隨機序列情況下，MapDB也可以儲存652 000 000條記錄，大概4倍於基於堆的集合。

這個簡單的試驗沒有太多的目的。這僅僅是我對MapDB的一種優化。也許，更多的驚喜在於插入效率確實不錯並且MapDB可以抗衡基於記憶體的集合。

OneCoder注：OneCoder僅做翻譯，順便了解一下知識，關於本文，下面的評論中也存在一定的爭議，大家可以自行關注。此文，權當開闊視野，不是也很好麼。