廣義的堆外記憶體

說到堆外記憶體，那大家肯定想到堆內記憶體，這也是我們大家接觸最多的，我們在jvm引數裡通常設定-Xmx來指定我們的堆的最大值，不過這還不是我們理解的Java堆，-Xmx的值是新生代和老生代的和的最大值，我們在jvm引數裡通常還會加一個引數-XX:MaxPermSize來指定持久代的最大值，那麼我們認識的Java堆的最大值其實是-Xmx和-XX:MaxPermSize的總和，在分代演算法下，新生代，老生代和持久代是連續的虛擬地址，因為它們是一起分配的，那麼剩下的都可以認為是堆外記憶體(廣義的)了，這些包括了jvm本身在執行過程中分配的記憶體，codecache，jni裡分配的記憶體，DirectByteBuffer分配的記憶體等等

狹義的堆外記憶體

而作為java開發者，我們常說的堆外記憶體溢位了，其實是狹義的堆外記憶體，這個主要是指java.nio.DirectByteBuffer在建立的時候分配記憶體，我們這篇文章裡也主要是講狹義的堆外記憶體，因為它和我們平時碰到的問題比較密切

JDK/JVM裡DirectByteBuffer的實現

DirectByteBuffer通常用在通訊過程中做緩衝池，在mina，netty等nio框架中屢見不鮮，先來看看JDK裡的實現：

DirectByteBuffer(int cap) {                   // package-private

    super(-1, 0, cap, cap);
    boolean pa = VM.isDirectMemoryPageAligned();
    int ps = Bits.pageSize();
    long size = Math.max(1L, (long)cap + (pa ? ps : 0));
    Bits.reserveMemory(size, cap);

    long base = 0;
    try {
        base = unsafe.allocateMemory(size);
    } catch (OutOfMemoryError x) {
        Bits.unreserveMemory(size, cap);
        throw x;
    }
    unsafe.setMemory(base, size, (byte) 0);
    if (pa && (base % ps != 0)) {
        // Round up to page boundary
        address = base + ps - (base & (ps - 1));
    } else {
        address = base;
    }
    cleaner = Cleaner.create(this, new Deallocator(base, size, cap));
    att = null;
}

 通過上面的建構函式我們知道，真正的記憶體分配是使用的Bits.reserveMemory方法

     static void reserveMemory(long size, int cap) {
        synchronized (Bits.class) {
            if (!memoryLimitSet && VM.isBooted()) {
                maxMemory = VM.maxDirectMemory();
                memoryLimitSet = true;
            }
            // -XX:MaxDirectMemorySize limits the total capacity rather than the
            // actual memory usage, which will differ when buffers are page
            // aligned.
            if (cap <= maxMemory - totalCapacity) {
                reservedMemory += size;
                totalCapacity += cap;
                count++;
                return;
            }
        }

        System.gc();
        try {
            Thread.sleep(100);
        } catch (InterruptedException x) {
            // Restore interrupt status
            Thread.currentThread().interrupt();
        }
        synchronized (Bits.class) {
            if (totalCapacity + cap > maxMemory)
                throw new OutOfMemoryError("Direct buffer memory");
            reservedMemory += size;
            totalCapacity += cap;
            count++;
        }

    }

通過上面的程式碼我們知道可以通過-XX:MaxDirectMemorySize來指定最大的堆外記憶體，那麼我們首先引入兩個問題

• 堆外記憶體預設是多大
• 為什麼要主動呼叫System.gc()

堆外記憶體預設是多大

如果我們沒有通過-XX:MaxDirectMemorySize來指定最大的堆外記憶體，那麼預設的最大堆外記憶體是多少呢，我們還是通過程式碼來分析

上面的程式碼裡我們看到呼叫了sun.misc.VM.maxDirectMemory()

 private static long directMemory = 64 * 1024 * 1024;

    // Returns the maximum amount of allocatable direct buffer memory.
    // The directMemory variable is initialized during system initialization
    // in the saveAndRemoveProperties method.
    //
    public static long maxDirectMemory() {
        return directMemory;
    }

看到上面的程式碼之後是不是誤以為預設的最大值是64M？其實不是的，說到這個值得從java.lang.System這個類的初始化說起

 /**
     * Initialize the system class.  Called after thread initialization.
     */
    private static void initializeSystemClass() {

        // VM might invoke JNU_NewStringPlatform() to set those encoding
        // sensitive properties (user.home, user.name, boot.class.path, etc.)
        // during "props" initialization, in which it may need access, via
        // System.getProperty(), to the related system encoding property that
        // have been initialized (put into "props") at early stage of the
        // initialization. So make sure the "props" is available at the
        // very beginning of the initialization and all system properties to
        // be put into it directly.
        props = new Properties();
        initProperties(props);  // initialized by the VM

        // There are certain system configurations that may be controlled by
        // VM options such as the maximum amount of direct memory and
        // Integer cache size used to support the object identity semantics
        // of autoboxing.  Typically, the library will obtain these values
        // from the properties set by the VM.  If the properties are for
        // internal implementation use only, these properties should be
        // removed from the system properties.
        //
        // See java.lang.Integer.IntegerCache and the
        // sun.misc.VM.saveAndRemoveProperties method for example.
        //
        // Save a private copy of the system properties object that
        // can only be accessed by the internal implementation.  Remove
        // certain system properties that are not intended for public access.
        sun.misc.VM.saveAndRemoveProperties(props);

       ......
       
        sun.misc.VM.booted();
    }

上面這個方法在jvm啟動的時候對System這個類做初始化的時候執行的，因此執行時間非常早，我們看到裡面呼叫了sun.misc.VM.saveAndRemoveProperties(props):

     public static void saveAndRemoveProperties(Properties props) {
        if (booted)
            throw new IllegalStateException("System initialization has completed");

        savedProps.putAll(props);

        // Set the maximum amount of direct memory.  This value is controlled
        // by the vm option -XX:MaxDirectMemorySize=<size>.
        // The maximum amount of allocatable direct buffer memory (in bytes)
        // from the system property sun.nio.MaxDirectMemorySize set by the VM.
        // The system property will be removed.
        String s = (String)props.remove("sun.nio.MaxDirectMemorySize");
        if (s != null) {
            if (s.equals("-1")) {
                // -XX:MaxDirectMemorySize not given, take default
                directMemory = Runtime.getRuntime().maxMemory();
            } else {
                long l = Long.parseLong(s);
                if (l > -1)
                    directMemory = l;
            }
        }

        // Check if direct buffers should be page aligned
        s = (String)props.remove("sun.nio.PageAlignDirectMemory");
        if ("true".equals(s))
            pageAlignDirectMemory = true;

        // Set a boolean to determine whether ClassLoader.loadClass accepts
        // array syntax.  This value is controlled by the system property
        // "sun.lang.ClassLoader.allowArraySyntax".
        s = props.getProperty("sun.lang.ClassLoader.allowArraySyntax");
        allowArraySyntax = (s == null
                               ? defaultAllowArraySyntax
                               : Boolean.parseBoolean(s));

        // Remove other private system properties
        // used by java.lang.Integer.IntegerCache
        props.remove("java.lang.Integer.IntegerCache.high");

        // used by java.util.zip.ZipFile
        props.remove("sun.zip.disableMemoryMapping");

        // used by sun.launcher.LauncherHelper
        props.remove("sun.java.launcher.diag");
    }

如果我們通過-Dsun.nio.MaxDirectMemorySize指定了這個屬性，只要它不等於-1，那效果和加了-XX:MaxDirectMemorySize一樣的，如果兩個引數都沒指定，那麼最大堆外記憶體的值來自於directMemory = Runtime.getRuntime().maxMemory()，這是一個native方法

JNIEXPORT jlong JNICALL
Java_java_lang_Runtime_maxMemory(JNIEnv *env, jobject this)
{
    return JVM_MaxMemory();
}

JVM_ENTRY_NO_ENV(jlong, JVM_MaxMemory(void))
  JVMWrapper("JVM_MaxMemory");
  size_t n = Universe::heap()->max_capacity();
  return convert_size_t_to_jlong(n);
JVM_END

其中在我們使用CMS GC的情況下的實現如下，其實是新生代的最大值-一個survivor的大小+老生代的最大值，也就是我們設定的-Xmx的值裡除去一個survivor的大小就是預設的堆外記憶體的大小了

size_t GenCollectedHeap::max_capacity() const {
  size_t res = 0;
  for (int i = 0; i < _n_gens; i++) {
    res += _gens[i]->max_capacity();
  }
  return res;
}

size_t DefNewGeneration::max_capacity() const {
  const size_t alignment = GenCollectedHeap::heap()->collector_policy()->min_alignment();
  const size_t reserved_bytes = reserved().byte_size();
  return reserved_bytes - compute_survivor_size(reserved_bytes, alignment);
}

size_t Generation::max_capacity() const {
  return reserved().byte_size();
}

為什麼要主動呼叫System.gc

既然要呼叫System.gc，那肯定是想通過觸發一次gc操作來回收堆外記憶體，不過我想先說的是堆外記憶體不會對gc造成什麼影響(這裡的System.gc除外)，但是堆外記憶體的回收其實依賴於我們的gc機制，首先我們要知道在java層面和我們在堆外分配的這塊記憶體關聯的只有與之關聯的DirectByteBuffer物件了，它記錄了這塊記憶體的基地址以及大小，那麼既然和gc也有關，那就是gc能通過操作DirectByteBuffer物件來間接操作對應的堆外記憶體了。DirectByteBuffer物件在建立的時候關聯了一個PhantomReference，說到PhantomReference它其實主要是用來跟蹤物件何時被回收的，它不能影響gc決策，但是gc過程中如果發現某個物件除了只有PhantomReference引用它之外，並沒有其他的地方引用它了，那將會把這個引用放到java.lang.ref.Reference.pending佇列裡，在gc完畢的時候通知ReferenceHandler這個守護執行緒去執行一些後置處理，而DirectByteBuffer關聯的PhantomReference是PhantomReference的一個子類，在最終的處理裡會通過Unsafe的free介面來釋放DirectByteBuffer對應的堆外記憶體塊

JDK裡ReferenceHandler的實現：

 private static class ReferenceHandler extends Thread {

        ReferenceHandler(ThreadGroup g, String name) {
            super(g, name);
        }

        public void run() {
            for (;;) {

                Reference r;
                synchronized (lock) {
                    if (pending != null) {
                        r = pending;
                        Reference rn = r.next;
                        pending = (rn == r) ? null : rn;
                        r.next = r;
                    } else {
                        try {
                            lock.wait();
                        } catch (InterruptedException x) { }
                        continue;
                    }
                }

                // Fast path for cleaners
                if (r instanceof Cleaner) {
                    ((Cleaner)r).clean();
                    continue;
                }

                ReferenceQueue q = r.queue;
                if (q != ReferenceQueue.NULL) q.enqueue(r);
            }
        }
    }

可見如果pending為空的時候，會通過lock.wait()一直等在那裡，其中喚醒的動作是在jvm裡做的，當gc完成之後會呼叫如下的方法VM_GC_Operation::doit_epilogue()，在方法末尾會呼叫lock的notify操作，至於pending佇列什麼時候將引用放進去的，其實是在gc的引用處理邏輯中放進去的，針對引用的處理後面可以專門寫篇文章來介紹

void VM_GC_Operation::doit_epilogue() {
  assert(Thread::current()->is_Java_thread(), "just checking");
  // Release the Heap_lock first.
  SharedHeap* sh = SharedHeap::heap();
  if (sh != NULL) sh->_thread_holds_heap_lock_for_gc = false;
  Heap_lock->unlock();
  release_and_notify_pending_list_lock();
}

void VM_GC_Operation::release_and_notify_pending_list_lock() {
instanceRefKlass::release_and_notify_pending_list_lock(&_pending_list_basic_lock);
}

對於System.gc的實現，之前寫了一篇文章來重點介紹，JVM原始碼分析之SystemGC完全解讀，它會對新生代的老生代都會進行記憶體回收，這樣會比較徹底地回收DirectByteBuffer物件以及他們關聯的堆外記憶體，我們dump記憶體發現DirectByteBuffer物件本身其實是很小的，但是它後面可能關聯了一個非常大的堆外記憶體，因此我們通常稱之為『冰山物件』，我們做ygc的時候會將新生代裡的不可達的DirectByteBuffer物件及其堆外記憶體回收了，但是無法對old裡的DirectByteBuffer物件及其堆外記憶體進行回收，這也是我們通常碰到的最大的問題，如果有大量的DirectByteBuffer物件移到了old，但是又一直沒有做cms gc或者full gc，而只進行ygc，那麼我們的實體記憶體可能被慢慢耗光，但是我們還不知道發生了什麼，因為heap明明剩餘的記憶體還很多(前提是我們禁用了System.gc)。

為什麼要使用堆外記憶體

DirectByteBuffer在建立的時候會通過Unsafe的native方法來直接使用malloc分配一塊記憶體，這塊記憶體是heap之外的，那麼自然也不會對gc造成什麼影響(System.gc除外)，因為gc耗時的操作主要是操作heap之內的物件，對這塊記憶體的操作也是直接通過Unsafe的native方法來操作的，相當於DirectByteBuffer僅僅是一個殼，還有我們通訊過程中如果資料是在Heap裡的，最終也還是會copy一份到堆外，然後再進行傳送，所以為什麼不直接使用堆外記憶體呢。對於需要頻繁操作的記憶體，並且僅僅是臨時存在一會的，都建議使用堆外記憶體，並且做成緩衝池，不斷迴圈利用這塊記憶體。

為什麼不能大面積使用堆外記憶體

如果我們大面積使用堆外記憶體並且沒有限制，那遲早會導致記憶體溢位，畢竟程式是跑在一臺資源受限的機器上，因為這塊記憶體的回收不是你直接能控制的，當然你可以通過別的一些途徑，比如反射，直接使用Unsafe介面等，但是這些務必給你帶來了一些煩惱，Java與生俱來的優勢被你完全拋棄了—開發不需要關注記憶體的回收，由gc演算法自動去實現。另外上面的gc機制與堆外記憶體的關係也說了，如果一直觸發不了cms gc或者full gc，那麼後果可能很嚴重。