2. 程式人生 > >JDK 原始碼閱讀 : DirectByteBuffer

JDK 原始碼閱讀 : DirectByteBuffer

阿新 • • 發佈：2018-12-09

在文章JDK原始碼閱讀-ByteBuffer中，我們學習了ByteBuffer的設計。但是他是一個抽象類，真正的實現分為兩類：HeapByteBuffer與DirectByteBuffer。HeapByteBuffer是堆內ByteBuffer，使用byte[]儲存資料，是對陣列的封裝，比較簡單。DirectByteBuffer是堆外ByteBuffer，直接使用堆外記憶體空間儲存資料，是NIO高效能的核心設計之一。本文來分析一下DirectByteBuffer的實現。

如何使用DirectByteBuffer

如果需要例項化一個DirectByteBuffer，可以使用java.nio.ByteBuffer#allocateDirect

這個方法：

public static ByteBuffer allocateDirect(int capacity) {
    return new DirectByteBuffer(capacity);
}

DirectByteBuffer例項化流程

我們來看一下DirectByteBuffer是如何構造，如何申請與釋放記憶體的。先看看DirectByteBuffer的建構函式：

DirectByteBuffer(int cap) {                   // package-private
	// 初始化Buffer的四個核心屬性
    super(-1, 0, cap, cap);
    // 判斷是否需要頁面對齊，通過引數-XX:+PageAlignDirectMemory控制，預設為false
    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 {
        // 呼叫unsafe方法分配記憶體
        base = unsafe.allocateMemory(size);
    } catch (OutOfMemoryError x) {
        // 分配失敗，釋放記憶體
        Bits.unreserveMemory(size, cap);
        throw x;
    }
    // 初始化記憶體空間為0
    unsafe.setMemory(base, size, (byte) 0);
    // 設定記憶體起始地址
    if (pa && (base % ps != 0)) {
        address = base + ps - (base & (ps - 1));
    } else {
        address = base;
    }
    // 使用Cleaner機制註冊記憶體回收處理函式
    cleaner = Cleaner.create(this, new Deallocator(base, size, cap));
    att = null;
}

申請記憶體前會呼叫java.nio.Bits#reserveMemory判斷是否有足夠的空間可供申請：

// 該方法主要用於判斷申請的堆外記憶體是否超過了用例指定的最大值
// 如果還有足夠空間可以申請，則更新對應的變數
// 如果已經沒有空間可以申請，則丟擲OOME
// 引數解釋：
//     size：根據是否按頁對齊，得到的真實需要申請的記憶體大小
//     cap：使用者指定需要的記憶體大小(<=size)
static void reserveMemory(long size, int cap) {
    // 因為涉及到更新多個靜態統計變數，這裡需要Bits類鎖
    synchronized (Bits.class) {
        // 獲取最大可以申請的對外記憶體大小，預設值是64MB
        // 可以通過引數-XX:MaxDirectMemorySize=<size>設定這個大小
        if (!memoryLimitSet && VM.isBooted()) {
            maxMemory = VM.maxDirectMemory();
            memoryLimitSet = true;
        }
        // -XX:MaxDirectMemorySize限制的是使用者申請的大小，而不考慮對齊情況
        // 所以使用兩個變數來統計：
        //     reservedMemory：真實的目前保留的空間
        //     totalCapacity：目前使用者申請的空間
        if (cap <= maxMemory - totalCapacity) {
            reservedMemory += size;
            totalCapacity += cap;
            count++;
            return; // 如果空間足夠，更新統計變數後直接返回
        }
    }

    // 如果已經沒有足夠空間，則嘗試GC
    System.gc();
    try {
        Thread.sleep(100);
    } catch (InterruptedException x) {
        // Restore interrupt status
        Thread.currentThread().interrupt();
    }
    synchronized (Bits.class) {
        // GC後再次判斷，如果還是沒有足夠空間，則丟擲OOME
        if (totalCapacity + cap > maxMemory)
            throw new OutOfMemoryError("Direct buffer memory");
        reservedMemory += size;
        totalCapacity += cap;
        count++;
    }
}

在java.nio.Bits#reserveMemory方法中，如果空間不足，會呼叫System.gc()嘗試釋放記憶體，然後再進行判斷，如果還是沒有足夠的空間，丟擲OOME。

如果分配失敗，則需要把預留的統計變數更新回去：

static synchronized void unreserveMemory(long size, int cap) {
    if (reservedMemory > 0) {
        reservedMemory -= size;
        totalCapacity -= cap;
        count--;
        assert (reservedMemory > -1);
    }
}

從上面幾個函式中我們可以得到資訊：

  1. 可以通過-XX:+PageAlignDirectMemor引數控制堆外記憶體分配是否需要按頁對齊，預設不對齊。
  2. 每次申請和釋放需要呼叫呼叫Bits的reserveMemory或unreserveMemory方法，這兩個方法根據內部維護的統計變數判斷當前是否還有足夠的空間可供申請，如果有足夠的空間，更新統計變數，如果沒有足夠的空間，呼叫System.gc()嘗試進行垃圾回收，回收後再次進行判斷，如果還是沒有足夠的空間，丟擲OOME。
  3. Bits的reserveMemory方法判斷是否有足夠記憶體不是判斷物理機是否有足夠記憶體，而是判斷JVM啟動時，指定的堆外記憶體空間大小是否有剩餘的空間。這個大小由引數-XX:MaxDirectMemorySize=<size>設定。
  4. 確定有足夠的空間後，使用sun.misc.Unsafe#allocateMemory申請記憶體
  5. 申請後的記憶體空間會被清零
  6. DirectByteBuffer使用Cleaner機制進行空間回收

可以看出除了判斷是否有足夠的空間的邏輯外，核心的邏輯是呼叫sun.misc.Unsafe#allocateMemory申請記憶體，我們看一下這個函式是如何申請對外記憶體的：

// 申請一塊本地記憶體。記憶體空間是未初始化的，其內容是無法預期的。
// 使用freeMemory釋放記憶體，使用reallocateMemory修改記憶體大小
public native long allocateMemory(long bytes);
// openjdk8/hotspot/src/share/vm/prims/unsafe.cpp
UNSAFE_ENTRY(jlong, Unsafe_AllocateMemory(JNIEnv *env, jobject unsafe, jlong size))
  UnsafeWrapper("Unsafe_AllocateMemory");
  size_t sz = (size_t)size;
  if (sz != (julong)size || size < 0) {
    THROW_0(vmSymbols::java_lang_IllegalArgumentException());
  }
  if (sz == 0) {
    return 0;
  }
  sz = round_to(sz, HeapWordSize);
  // 呼叫os::malloc申請記憶體，內部使用malloc函式申請記憶體
  void* x = os::malloc(sz, mtInternal);
  if (x == NULL) {
    THROW_0(vmSymbols::java_lang_OutOfMemoryError());
  }
  //Copy::fill_to_words((HeapWord*)x, sz / HeapWordSize);
  return addr_to_java(x);
UNSAFE_END

可以看出sun.misc.Unsafe#allocateMemory使用malloc這個C標準庫的函式來申請記憶體。

DirectByteBuffer回收流程

在DirectByteBuffer的建構函式的最後，我們看到了這樣的語句：

// 使用Cleaner機制註冊記憶體回收處理函式
cleaner = Cleaner.create(this, new Deallocator(base, size, cap));

這是使用Cleaner機制進行記憶體回收。因為DirectByteBuffer申請的記憶體是在堆外，DirectByteBuffer本身支援儲存了記憶體的起始地址而已，所以DirectByteBuffer的記憶體佔用是由堆內的DirectByteBuffer物件與堆外的對應記憶體空間共同構成。堆內的佔用只是很小的一部分，這種物件被稱為冰山物件。

堆內的DirectByteBuffer物件本身會被垃圾回收正常的處理，但是對外的記憶體就不會被GC回收了，所以需要一個機制，在DirectByteBuffer回收時，同時回收其堆外申請的記憶體。

Java中可選的特性有finalize函式，但是finalize機制是Java官方不推薦的，官方推薦的做法是使用虛引用來處理物件被回收時的後續處理工作，可以參考JDK原始碼閱讀-Reference。同時Java提供了Cleaner類來簡化這個實現，Cleaner是PhantomReference的子類，可以在PhantomReference被加入ReferenceQueue時觸發對應的Runnable回撥。

DirectByteBuffer就是使用Cleaner機制來實現本身被GC時，回收堆外記憶體的能力。我們來看一下其回收處理函式是如何實現的：

private static class Deallocator
    implements Runnable
    {

        private static Unsafe unsafe = Unsafe.getUnsafe();

        private long address;
        private long size;
        private int capacity;

        private Deallocator(long address, long size, int capacity) {
            assert (address != 0);
            this.address = address;
            this.size = size;
            this.capacity = capacity;
        }

        public void run() {
            if (address == 0) {
                // Paranoia
                return;
            }
            // 使用unsafe方法釋放記憶體
            unsafe.freeMemory(address);
            address = 0;
            // 更新統計變數
            Bits.unreserveMemory(size, capacity);
        }

    }

sun.misc.Unsafe#freeMemory方法使用C標準庫的free函式釋放記憶體空間。同時更新Bits類中的統計變數。

DirectByteBuffer讀寫邏輯

public ByteBuffer put(int i, byte x) {
    unsafe.putByte(ix(checkIndex(i)), ((x)));
    return this;
}

public byte get(int i) {
    return ((unsafe.getByte(ix(checkIndex(i)))));
}

private long ix(int i) {
    return address + (i << 0);
}

DirectByteBuffer使用sun.misc.Unsafe#getByte(long)和sun.misc.Unsafe#putByte(long, byte)這兩個方法來讀寫堆外記憶體空間的指定位置的位元組資料。不過這兩個方法本地實現比較複雜，這裡就不分析了。

預設可以申請的堆外記憶體大小

上文提到了DirectByteBuffer申請記憶體前會判斷是否有足夠的空間可供申請，這個是在一個指定的堆外大小限制的前提下。使用者可以通過-XX:MaxDirectMemorySize=<size>這個引數來控制可以申請多大的DirectByteBuffer記憶體。但是預設情況下這個大小是多少呢？

DirectByteBuffer通過sun.misc.VM#maxDirectMemory來獲取這個值，可以看一下對應的程式碼：

// A user-settable upper limit on the maximum amount of allocatable direct
// buffer memory.  This value may be changed during VM initialization if
// "java" is launched with "-XX:MaxDirectMemorySize=<size>".
//
// The initial value of this field is arbitrary; during JRE initialization
// it will be reset to the value specified on the command line, if any,
// otherwise to Runtime.getRuntime().maxMemory().
//
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;
}

這裡directMemory預設賦值為64MB，那對外記憶體的預設大小是64MB嗎？不是，仔細看註釋，註釋中說，這個值會在JRE啟動過程中被重新設定為使用者指定的值，如果使用者沒有指定，則會設定為Runtime.getRuntime().maxMemory()。

這個過程發生在sun.misc.VM#saveAndRemoveProperties函式中，這個函式會被java.lang.System#initializeSystemClass呼叫：

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;
        }
    }

    //...
}

所以預設情況下，可以申請的DirectByteBuffer大小為Runtime.getRuntime().maxMemory()，而這個值等於可用的最大Java堆大小，也就是我們-Xmx引數指定的值。

所以最終結論是：預設情況下，可以申請的最大DirectByteBuffer空間為Java最大堆大小的值。

和DirectByteBuffer有關的JVM選項

根據上文的分析，有兩個JVM引數與DirectByteBuffer直接相關：

  • -XX:+PageAlignDirectMemory：指定申請的記憶體是否需要按頁對齊，預設不對其
  • -XX:MaxDirectMemorySize=<size>，可以申請的最大DirectByteBuffer大小，預設與-Xmx相等

參考資料

相關推薦

JDK 原始碼閱讀 : DirectByteBuffer

在文章JDK原始碼閱讀-ByteBuffer中，我們學習了ByteBuffer的設計。但是他是一個抽象類，真正的實現分為兩類：HeapByteBuffer與DirectByteBuffer。HeapByteBuffer是堆內ByteBuffer，使用byte[]儲存資料，是

JDK原始碼閱讀：InterruptibleChannel與可中斷IO，ig牛逼

Java傳統IO是不支援中斷的，所以如果程式碼在read/write等操作阻塞的話，是無法被中斷的。這就無法和Thead的interrupt模型配合使用了。JavaNIO眾多的升級點中就包含了IO操作對中斷的支援。InterruptiableChannel表示支援中斷的Channel。我們常用的FileCha

jdk原始碼閱讀之——arraylist

首先看一下他的建構函式： public ArrayList() { this.elementData = DEFAULTCAPACITY_EMPTY_ELEMENTDATA; } 其實arraylist還有其他的建構函式，可以指定陣列的長度，這裡先從最基本的入

jdk原始碼閱讀——linkedlist

首先還是從建構函式開始 /** * Constructs an empty list. */ public LinkedList() { } 是一個空的 然後我們從add看 public boolean add(E e) {

jdk原始碼閱讀筆記-LinkedHashMap

　　Map是Java collection framework 中重要的組成部分，特別是HashMap是在我們在日常的開發的過程中使用的最多的一個集合。但是遺憾的是，存放在HashMap中元素都是無序的，原因是我們在put或get資料的時候都是根據key的hash值來確定元素的位置。在具體的業務場景中，我們更

jdk原始碼閱讀(ⅠSet介面相關類）

HashSet原始碼閱讀筆記 1、是建立在HashMap的基礎之上的，通過HashMap的各個方法進行實現的。 2、內部擁有一個HashMap,這個map就是儲存HashSet所有元素的。 3、內部還有一個假的Object物件。這個物件就是在向map中放入key的時候對應的value。無實際意義

jdk原始碼閱讀筆記-ArrayList

一、ArrayList概述 首先我們來說一下ArrayList是什麼？它解決了什麼問題？ArrayList其實是一個數組，但是有區別於一般的陣列，它是一個可以動態改變大小的動態陣列。ArrayList的關鍵特性也是這個動態的特性了，ArrayList的設計初衷就是為了解決Java陣列長度不可變的

JDK 原始碼閱讀 Reference

Java最初只有普通的強引用，只有物件存在引用，則物件就不會被回收，即使記憶體不足，也是如此，JVM會爆出OOME，也不會去回收存在引用的物件。 如果只提供強引用，我們就很難寫出“這個物件不是很重要，如果記憶體不足GC回收掉也是可以的”這種語義的程式碼。Java

jdk原始碼閱讀之Object類

Object的作用 Object是java所有類的基類，定義了所有類的基礎方法 。這個類所定義的方法也不多，大部分是native方法。 什麼是native方法 native關鍵字標識的java方法為本地方法，底層是有c/c++編寫的程式編譯後dll檔案，jav

JDK原始碼閱讀之ArrayList

ArrayList簡介 List 介面的大小可變陣列的實現。實現了所有可選列表操作，並允許包括 null 在內的所有元素。除了實現 List 介面外，此類還提供一些方法來操作內部用來儲存列表的陣列的大小。（此類大致上等同於 Vector 類，除了此類是不同步

JDK原始碼閱讀之HashMap

HashMap簡介 基於雜湊表的 Map 介面的實現。此實現提供所有可選的對映操作，並允許使用 null 值和 null 鍵。（除了非同步和允許使用 null 之外，HashMap 類與 Hashtable 大致相同。）此類不保證對映的順序，特別是它不保證該

JDK原始碼閱讀順序

版權宣告：本文為博主原創文章，未經博主允許不得轉載。    https://blog.csdn.net/qq_21033663/article/details/79571506 很多java開發的小夥伴都會閱讀jdk原始碼，然而確不知道應該從哪讀起。以下為小編整理的通常所需閱

JDK原始碼閱讀02---------String

版本：JDK1.8 1.String類簡述 String類表示字串。所有Java程式中的字串文字，如"abc"，都是該類的例項。 String類是不可變(final)的,對String類的任何改變,都是返回一個新的String類物件. 2.原始碼閱讀 1.St

JDK原始碼閱讀：ByteBuffer

Buffer是Java NIO中對於緩衝區的封裝。在Java BIO中，所有的讀寫API，都是直接使用byte陣列作為緩衝區的，簡單直接。但是在Java NIO中，緩衝區這一概念變得複雜，可能是對應Java堆中的一塊記憶體，也可能是對應本地記憶體中的一塊記憶體。

jdk原始碼閱讀筆記-LinkedList

　　一、LinkedList概述 　　LinkedList的底層資料結構為雙向連結串列結構，與ArrayList相同的是LinkedList也可以儲存相同或null的元素。相對於ArrayList來說，LinkedList的插入與刪除的速度更快，時間複雜度為O(1),查詢的速度就相對比較慢了，因為每次遍歷的時

JDK原始碼閱讀—ArrayList的實現

1 繼承結構圖 ArrayList繼承AbstractList，實現了List介面 2 建構函式 transient Object[] elementData; // 陣列儲存元素 private int size; // 記錄長度 size記錄

JDK原始碼閱讀——LinkedList實現

1 繼承結構圖   LinkedList是List的另一種實現。繼承自AbstractSequentialList 2 資料結構 LinkedList與ArrayList不同的是LinkedList底層使用雙向連結串列進行儲存，其主要資料結構如下 　　// 記錄List長度 　　tr

JDK原始碼閱讀——Vector實現

1 繼承結構圖 Vector同樣繼承自AbstractList，與ArrayList、LinedList一樣，是List的一種實現 2 資料結構 // 與ArrayList一樣，也是使用物件陣列儲存元素 protected Object[] elementData;

jdk原始碼閱讀之HashMap（二）

HashMap的遍歷 HashMap對應有三種遍歷方式，分別是條目遍歷（可理解為節點遍歷）、鍵遍歷、值遍歷. //遍歷鍵的迭代器 final class KeyIterator extends HashIterator implements Iterator<K

jdk原始碼閱讀之HashMap（一）

HashMap是一個散列表，這個散列表包含的雜湊桶的格式為2^n個，而且必須滿足這個條件，原因在getNode(int hash, Object key)這個方法的分析中給出。HashMap允許null的鍵值對，null的鍵值對總會被對映到第一個雜湊桶中。HashMap裡面的鍵值對並沒有順序