【Java】 DirectByteBuffer堆外記憶體回收
PhantomReference虛參照
在分析堆外記憶體回收之前，先了解下PhantomReference虛參照。
PhantomReference需要與ReferenceQueue參照佇列結合使用，在GC進行垃圾回收的時候，如果發現一個物件只有虛參照在參照它，則認為該物件需要被回收，會將參照該物件的虛參照加入到與其關聯的ReferenceQueue佇列中，開發者可以通過ReferenceQueue獲取需要被回收的物件，然後做一些清理操作，從佇列中獲取過的元素會從佇列中清除，之後GC就可以對該物件進行回收。
虛參照提供了一種追蹤物件垃圾回收狀態的機制，讓開發者知道哪些物件準備進行回收，在回收之前開發者可以進行一些清理工作，之後GC就可以將物件進行真正的回收。
來看一個虛參照的使用例子：
- 建立一個
ReferenceQueue佇列queue，用於跟蹤物件的回收； - 建立一個obj物件，通過new建立的是強參照，只要強參照存在，物件就不會被回收；
- 建立一個虛參照
PhantomReference，將obj物件和ReferenceQueue佇列傳入，此時phantomReference裡面參照了obj物件，並關聯著參照佇列queue； - 同樣的方式建立另一個obj1物件和虛參照物件phantomReference1；
- 將obj置為NULL，此時強參照關係失效；
- 呼叫
System.gc()進行垃圾回收； - 由於obj的強參照關係失效，所以GC認為該物件需要被回收，會將參照該物件的虛參照phantomReference物件放入到與其關聯的參照佇列queue中；
- 通過
poll從參照佇列queue中獲取物件，可以發現會獲取到phantomReference物件，poll獲取之後會將物件從參照佇列中刪除，之後會被垃圾回收器回收； - obj1的強參照關係還在，所以從queue中並不會獲取到；
public static void main(String[] args) {
// 建立參照佇列
ReferenceQueue<Object> queue = new ReferenceQueue<Object>();
// 建立obj物件
Object obj = new Object();
// 建立虛參照，虛參照參照了obj物件，並與queue進行關聯
PhantomReference<Object> phantomReference = new PhantomReference<Object>(obj, queue);
// 建立obj1物件
Object obj1 = new Object();
PhantomReference<Object> phantomReference1 = new PhantomReference<Object>(obj1, queue);
// 將obj置為NULL，強參照關係失效
obj = null;
// 垃圾回收
System.gc();
// 從參照佇列獲取物件
Object o = queue.poll();
if (null != o) {
System.out.println(o.toString());
}
}
輸出結果：
java.lang.ref.PhantomReference@277c0f21
Reference範例的幾種狀態
Active：初始狀態，建立一個Reference型別的範例之後處於Active狀態，以上面虛參照為例，通過new建立一個PhantomReference虛參照物件之後，虛參照物件就處於Active狀態。
Pending：當GC檢測到物件的可達性發生變化時，會根據是否關聯了參照佇列來決定是否將狀態更改為Pending或者Inactive，虛參照必須與參照佇列結合使用，所以對於虛參照來說，如果它實際參照的物件需要被回收，垃圾回收器會將這個虛參照物件加入到一個Pending列表中，此時處於Pending狀態。
同樣以上面的的虛參照為例，因為obj的強參照關係失效，GC就會把參照它的虛參照物件放入到pending列表中。
Enqueued：表示參照物件被加入到了參照佇列，Reference有一個後臺執行緒去檢測是否有處於Pending狀態的參照物件，如果有會將參照物件加入到與其關聯的參照佇列中，此時由Pending轉為Enqueued狀態表示物件已加入到參照佇列中。
Inactive：通過參照佇列的poll方法可以從參照佇列中獲取參照物件，同時參照物件會從佇列中移除，此時參照物件處於Inactive狀態，之後會被GC回收。
DirectByteBuffer堆外記憶體回收
在DirectByteBuffer的建構函式中，在申請記憶體之前，先呼叫了Bits的reserveMemory方法回收記憶體，申請記憶體之後，呼叫Cleaner的create方法建立了一個Cleaner物件，並傳入了當前物件（DirectByteBuffer）和一個Deallocator型別的物件：
class DirectByteBuffer extends MappedByteBuffer implements DirectBuffer {
private final Cleaner cleaner;
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;
}
// 建立Cleader，傳入了當前物件和Deallocator
cleaner = Cleaner.create(this, new Deallocator(base, size, cap));
att = null;
}
}
Cleaner從名字上可以看出與清理有關，Bits的reserveMemory方法底層也是通過Cleaner來進行清理，所以Cleaner是重點關注的類。
Deallocator是DirectByteBuffer的一個內部類，並且實現了Runnable介面，在run方法中可以看到對記憶體進行了釋放，接下來就去看下在哪裡觸發Deallocator任務的執行：
class DirectByteBuffer extends MappedByteBuffer implements DirectBuffer {
private static class Deallocator implements Runnable {
// ...
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.freeMemory(address);
address = 0;
Bits.unreserveMemory(size, capacity);
}
}
}
Cleaner
Cleaner繼承了PhantomReference，PhantomReference是Reference的子類，所以Cleaner是一個虛參照物件。
建立Cleaner
虛參照需要與參照佇列結合使用，所以在Cleaner中可以看到有一個ReferenceQueue，它是一個靜態的變數，所以建立的所有Cleaner物件都會共同使用這個參照佇列。
在建立Cleaner的create方法中，處理邏輯如下：
- 通過建構函式建立了一個Cleaner物件，建構函式中的referent引數為
DirectByteBuffer，thunk引數為Deallocator物件，在建構函式中又呼叫了父類別的建構函式完成範例化； - 呼叫add方法將建立的Cleaner物件加入到連結串列中，新增到連結串列的時候使用的是頭插法，新加入的節點放在連結串列的頭部，first成員變數是一個靜態變數，它指向連結串列的頭結點，建立的Cleaner都會加入到這個連結串列中；
建立後的Cleaner物件處於Active狀態。
public class Cleaner extends PhantomReference<Object>{
// ReferenceQueue佇列
private static final ReferenceQueue<Object> dummyQueue = new ReferenceQueue<>();
// 靜態變數，連結串列的頭結點，建立的Cleaner都會加入到這個連結串列中
static private Cleaner first = null;
// thunk
private final Runnable thunk;
public static Cleaner create(Object ob, Runnable thunk) {
if (thunk == null)
return null;
// 建立一個Cleaner並加入連結串列
return add(new Cleaner(ob, thunk));
}
private Cleaner(Object referent, Runnable thunk) {
super(referent, dummyQueue); // 呼叫父類別建構函式，傳入參照物件和參照佇列
this.thunk = thunk; // thunk指向傳入的Deallocator
}
private static synchronized Cleaner add(Cleaner cl) {
// 如果頭結點不為空
if (first != null) {
// 將新加入的節點作為頭結點
cl.next = first;
first.prev = cl;
}
first = cl;
return cl;
}
}
Cleaner呼叫父類別建構函式時，最終會進入到父類別Reference中的建構函式中：
referent：指向實際的參照物件，上面建立的是DirectByteBuffer，所以這裡指向的是DirectByteBuffer。
queue：參照佇列，指向Cleaner中的參照佇列dummyQueue。
public class PhantomReference<T> extends Reference<T> {
// ...
public PhantomReference(T referent, ReferenceQueue<? super T> q) {
super(referent, q); // 呼叫父類別建構函式
}
}
public abstract class Reference<T> {
/* 參照物件 */
private T referent;
// 參照佇列
volatile ReferenceQueue<? super T> queue;
Reference(T referent, ReferenceQueue<? super T> queue) {
this.referent = referent;
// 設定參照佇列
this.queue = (queue == null) ? ReferenceQueue.NULL : queue;
}
}
啟動ReferenceHandler執行緒
Reference中有一個靜態方法，裡面建立了一個ReferenceHandler並設定為守護執行緒，然後啟動了該執行緒，並建立了JavaLangRefAccess物件設定到SharedSecrets中：
public abstract class Reference<T> {
static {
ThreadGroup tg = Thread.currentThread().getThreadGroup();
for (ThreadGroup tgn = tg;
tgn != null;
tg = tgn, tgn = tg.getParent());
// 建立ReferenceHandler
Thread handler = new ReferenceHandler(tg, "Reference Handler");
// 設定優先順序為最高
handler.setPriority(Thread.MAX_PRIORITY);
handler.setDaemon(true);
handler.start();
// 這裡設定了JavaLangRefAccess
SharedSecrets.setJavaLangRefAccess(new JavaLangRefAccess() {
@Override
public boolean tryHandlePendingReference() {
// 呼叫了tryHandlePending
return tryHandlePending(false);
}
});
}
}
ReferenceHandler是Reference的內部類，繼承了Thread，在run方法中開啟了一個迴圈，不斷的執行tryHandlePending方法，處理Reference中的pending列表：
public abstract class Reference<T> {
private static class ReferenceHandler extends Thread {
// ...
ReferenceHandler(ThreadGroup g, String name) {
super(g, name);
}
public void run() {
while (true) {
// 處理pending列表
tryHandlePending(true);
}
}
}
}
Cleaner會啟動一個優先順序最高的守護執行緒，不斷呼叫tryHandlePending來檢測是否有需要回收的參照物件(還未進行真正的回收)，然後進行處理。
處理pending列表
垃圾回收器會將要回收的參照物件放在Reference的pending變數中，從資料型別上可以看出pending只是一個Reference型別的物件，並不是一個list，如果有多個需要回收的物件，如何將它們全部放入pending物件中？
可以把pengding看做是一個連結串列的頭結點，假如有參照物件被判定需要回收，如果pengding為空直接放入即可，如果不為空，將使用頭插法將新的物件加入到連結串列中，也就是將新物件的discovered指向pending物件，然後將pending指向當前要回收的這個物件，這樣就形成了一個連結串列，pending指向連結串列的頭結點。
在pending連結串列中的參照物件處於pending狀態。
接下來看tryHandlePending方法的處理邏輯：
-
如果pending不為空，表示有需要回收的物件，此時將pengding指向的物件放在臨時變數
r中，並判斷是否是Cleaner型別，如果是將其強制轉為Cleaner，記錄在臨時變數c中，接著更新pending的值為r的discovered，因為discovered中記錄了下一個需要被回收的物件，pengding需要指向下一個需要被回收的物件；pending如果為NULL，會進入到else的處理邏輯，返回值為引數傳入的waitForNotify的值。
-
判斷
Cleaner物件是否為空，如果不為空，呼叫Cleaner的clean方法進行清理； -
獲取參照物件關聯的參照佇列，然後呼叫
enqueue方法將參照物件加入到參照佇列中； -
返回true；
public abstract class Reference<T> {
// 指向pending列表中的下一個節點
transient private Reference<T> discovered;
// 靜態變數pending列表，可以看做是一個連結串列，pending指向連結串列的頭結點
private static Reference<Object> pending = null;
static boolean tryHandlePending(boolean waitForNotify) {
Reference<Object> r;
Cleaner c;
try {
synchronized (lock) {
// 如果pending不為空
if (pending != null) {
// 獲取pending執行的物件
r = pending;
// 如果是Cleaner型別
c = r instanceof Cleaner ? (Cleaner) r : null;
// 將pending指向下一個節點
pending = r.discovered;
// 將discovered置為空
r.discovered = null;
} else {
// 等待
if (waitForNotify) {
lock.wait();
}
return waitForNotify;
}
}
} catch (OutOfMemoryError x) {
Thread.yield();
// retry
return true;
} catch (InterruptedException x) {
// retry
return true;
}
if (c != null) {
// 呼叫clean方法進行清理
c.clean();
return true;
}
// 獲取參照佇列
ReferenceQueue<? super Object> q = r.queue;
// 如果佇列不為空，將物件加入到參照佇列中
if (q != ReferenceQueue.NULL) q.enqueue(r);
// 返回true
return true;
}
}
釋放記憶體
在Cleaner的clean方法中，可以看到，呼叫了thunk的run方法，前面內容可知，thunk指向的是Deallocator物件，所以會執行Deallocator的run方法，Deallocator的run方法前面也已經看過，裡面會對DirectByteBuffer的堆外記憶體進行釋放：
public class Cleaner extends PhantomReference<Object> {
public void clean() {
if (!remove(this))
return;
try {
// 呼叫run方法
thunk.run();
} catch (final Throwable x) {
AccessController.doPrivileged(new PrivilegedAction<Void>() {
public Void run() {
if (System.err != null)
new Error("Cleaner terminated abnormally", x)
.printStackTrace();
System.exit(1);
return null;
}});
}
}
}
總結
Cleaner是一個虛參照，它實際參照的物件DirectByteBuffer如果被GC判定為需要回收，會將參照該物件的Cleaner加入到pending列表，ReferenceHandler執行緒會不斷檢測pending是否為空，如果不為空，就對其進行處理：
- 如果物件型別為Cleaner，就呼叫Cleaner的clean方法進行清理，Cleaner的clean方法又會呼叫Deallocator的run方法，裡面呼叫了freeMemory方法對DirectByteBuffer分配的堆外記憶體進行釋放；
- 將Cleaner物件加入到與其關聯的參照佇列中；
參照佇列
ReferenceQueue名字聽起來是一個佇列，實際使用了一個連結串列，使用頭插法將加入的節點串起來，ReferenceQueue中的head變數指向連結串列的頭節點，每個節點是一個Reference型別的物件：
public class ReferenceQueue<T> {
// head為連結串列頭節點
private volatile Reference<? extends T> head = null;
}
Reference中除了discovered變數之外，還有一個next變數，discovered指向的是處於pending狀態時pending列表中的下一個元素，next變數指向的是處於Enqueued狀態時，參照佇列中的下一個元素：
public abstract class Reference<T> {
/* When active: 處於active狀態時為NULL
* pending: this
* Enqueued: Enqueued狀態時，指向參照佇列中的下一個元素
* Inactive: this
*/
@SuppressWarnings("rawtypes")
Reference next;
/* When active: active狀態時，指向GC維護的一個discovered連結串列中的下一個元素
* pending: pending狀態時，指向pending列表中的下一個元素
* otherwise: 其他情況為NULL
*/
transient private Reference<T> discovered; /* used by VM */
}
enqueue入隊
進入參照佇列中的參照物件處於enqueue狀態。
enqueue的處理邏輯如下：
- 判斷要加入的物件關聯的參照佇列，對佇列進行判斷，如果佇列為空或者佇列等於
ReferenceQueue中的空佇列ENQUEUED，表示該物件之前已經加入過佇列，不能重複操作，返回false，如果未加入過繼續下一步； - 將物件所關聯的參照佇列置為
ENQUEUED，它是一個空佇列，表示節點已經加入到佇列中； - 判斷頭節點是否為空，如果為空，表示連結串列還沒有節點，將當前物件的next指向自己，如果頭結點不為空，將當前物件的next指向頭結點，然後更新頭結點的值為當前物件（頭插法插入連結串列）；
- 增加佇列的長度，也就是連結串列的長度；
public class ReferenceQueue<T> {
// 空佇列
static ReferenceQueue<Object> ENQUEUED = new Null<>();
// 入隊，將節點加入參照佇列，佇列實際上是一個連結串列
boolean enqueue(Reference<? extends T> r) {
synchronized (lock) {
// 獲取關聯的參照佇列
ReferenceQueue<?> queue = r.queue;
// 如果為空或者已經新增到過佇列
if ((queue == NULL) || (queue == ENQUEUED)) {
return false;
}
assert queue == this;
// 將參照佇列置為一個空佇列，表示該節點已經入隊
r.queue = ENQUEUED;
// 如果頭結點為空將下一個節點置為自己，否則將next置為連結串列的頭結點，可以看出同樣使用的是頭插法將節點插入連結串列
r.next = (head == null) ? r : head;
// 更新頭結點為當前節點
head = r;
// 增加長度
queueLength++;
if (r instanceof FinalReference) {
sun.misc.VM.addFinalRefCount(1);
}
lock.notifyAll();
return true;
}
}
}
poll出隊
在呼叫poll方法從參照佇列中獲取一個元素並出隊的時候，首先對head頭結點進行判空，如果為空表示參照佇列中沒有資料，返回NULL，否則呼叫reallyPoll從參照佇列中獲取元素。
出隊的處理邏輯如下：
-
獲取連結串列中的第一個節點也就是頭結點，如果不為空進行下一步；
-
如果頭節點的下一個節點是自己，表示連結串列只有一個節點，頭結點出隊之後連結串列為空，所以將頭結點的值更新為NULL；
如果頭節點的下一個節點不是自己，表示連結串列中還有其他節點，更新head頭節點的值為下一個節點，也就是next指向的物件；
-
將需要出隊的節點的參照佇列置為NULL，next節點置為自己，表示節點已從佇列中刪除；
-
參照佇列的長度減一；
-
返回要出隊的節點；
從出隊的邏輯中可以看出，參照佇列中的物件是後進先出的，poll出隊之後的參照物件處於Inactive狀態，表示可以被GC回收掉。
public class ReferenceQueue<T> {
/**
* 從參照佇列中獲取一個節點，進行出隊操作
*/
public Reference<? extends T> poll() {
// 如果頭結點為空，表示沒有資料
if (head == null)
return null;
synchronized (lock) {
return reallyPoll();
}
}
@SuppressWarnings("unchecked")
private Reference<? extends T> reallyPoll() { 、 /* Must hold lock */
// 獲取頭結點
Reference<? extends T> r = head;
if (r != null) {
// 如果頭結點的下一個節點是自己，表示連結串列只有一個節點，head置為null，否則head值為r的下一個節點，也就是next指向的物件
head = (r.next == r) ?
null :
r.next;
// 將參照佇列置為NULL
r.queue = NULL;
// 下一個節點置為自己
r.next = r;
// 長度減一
queueLength--;
if (r instanceof FinalReference) {
sun.misc.VM.addFinalRefCount(-1);
}
// 返回連結串列中的第一個節點
return r;
}
return null;
}
}
reserveMemory記憶體清理
最開始在DirectByteBuffer的建構函式中看到申請記憶體之前會呼叫Bits的reserveMemory方法，如果沒有足夠的記憶體，它會從SharedSecrets獲取JavaLangRefAccess物件進行一些處理，由前面的內容可知，Reference中的靜態方法啟動ReferenceHandler之後，建立了JavaLangRefAccess並設定到SharedSecrets中，所以這裡呼叫JavaLangRefAccess的tryHandlePendingReference實際上依舊呼叫的是Reference中的tryHandlePending方法。
在呼叫Reference中的tryHandlePending方法處理需要回收的物件之後，呼叫tryReserveMemory方法判斷是否有足夠的記憶體，如果記憶體依舊不夠，會呼叫` System.gc()觸發垃圾回收，然後開啟一個迴圈，處理邏輯如下：
-
判斷記憶體是否充足，如果充足直接返回；
-
判斷睡眠次數是否小於限定的最大值，如果小於繼續下一步，否則終止迴圈；
-
呼叫tryHandlePendingReference處理penging列表中的參照物件，前面在處理pending列表的邏輯中可以知道，如果pending列表不為空，會返回true，tryHandlePendingReference也會返回true，此時意味著清理了一部分物件，所以重新進入到第1步進行檢查；
如果pending列表為空，會返回引數中傳入的waitForNotify的值，從JavaLangRefAccess的tryHandlePendingReference中可以看出這裡傳入的是false，所以會進行如下處理：
- 通過
Thread.sleep(sleepTime)讓當前執行緒睡眠一段時間，這樣可以避免reserveMemory方法一直在佔用資源; - 對睡眠次數加1;
- 通過
-
如果以上步驟處理之後還沒有足夠的空間會丟擲丟擲OutOfMemoryError異常；
reserveMemory方法的作用是保證在申請記憶體之前有足夠的記憶體，如果沒有足夠的記憶體會進行清理，達到指定清理次數之後依舊沒有足夠的記憶體空間，將丟擲OutOfMemoryError異常。
class Bits {
static void reserveMemory(long size, int cap) {
if (!memoryLimitSet && VM.isBooted()) {
maxMemory = VM.maxDirectMemory();
memoryLimitSet = true;
}
// 是否有足夠記憶體
if (tryReserveMemory(size, cap)) {
return;
}
// 獲取JavaLangRefAccess
final JavaLangRefAccess jlra = SharedSecrets.getJavaLangRefAccess();
// 呼叫tryHandlePendingReference
while (jlra.tryHandlePendingReference()) {
// 判斷是否有足夠的記憶體
if (tryReserveMemory(size, cap)) {
return;
}
}
// 呼叫gc進行垃圾回收
System.gc();
boolean interrupted = false;
try {
long sleepTime = 1;
int sleeps = 0;
// 開啟迴圈
while (true) {
// 是否有足夠記憶體
if (tryReserveMemory(size, cap)) {
return;
}
// 如果次數小於最大限定次數，終止
if (sleeps >= MAX_SLEEPS) {
break;
}
// 再次處理penging列表中的物件
if (!jlra.tryHandlePendingReference()) {
try {
// 睡眠一段時間
Thread.sleep(sleepTime);
sleepTime <<= 1;
sleeps++; // 睡眠次數增加1
} catch (InterruptedException e) {
interrupted = true;
}
}
}
// 丟擲OutOfMemoryError異常
throw new OutOfMemoryError("Direct buffer memory");
} finally {
if (interrupted) {
// don't swallow interrupts
Thread.currentThread().interrupt();
}
}
}
}
public abstract class Reference<T> {
static {
// ...
// 這裡設定了JavaLangRefAccess
SharedSecrets.setJavaLangRefAccess(new JavaLangRefAccess() {
@Override
public boolean tryHandlePendingReference() {
// 呼叫tryHandlePending,這裡waitForNotify引數傳入的是false
return tryHandlePending(false);
}
});
}
}
參考
Java 原始碼剖析——徹底搞懂 Reference 和 ReferenceQueue