java編程Reference核心原理示例源碼分析
帶著問題,看源碼針對性會更強一點、印象會更深刻、并且效果也會更好。所以我先賣個關(guān)子,提兩個問題(沒準下次跳槽時就被問到)。
- 我們可以用ByteBuffer的allocateDirect方法,申請一塊堆外內(nèi)存創(chuàng)建一個DirectByteBuffer對象,然后利用它去操作堆外內(nèi)存。這些申請完的堆外內(nèi)存,我們可以回收嗎?可以的話是通過什么樣的機制回收的?
- 大家應(yīng)該都知道WeakHashMap可以用來實現(xiàn)內(nèi)存相對敏感的本地緩存,為什么WeakHashMap合適這種業(yè)務(wù)場景,其內(nèi)部實現(xiàn)會做什么特殊處理呢?
GC可到達性與JDK中Reference類型
上面提到的兩個問題,其答案都在JDK的Reference里面。JDK早期版本中并沒有Reference相關(guān)的類,這導致對象被GC回收后如果想做一些額外的清理工作(比如socket、堆外內(nèi)存等)是無法實現(xiàn)的,同樣如果想要根據(jù)堆內(nèi)存的實際使用情況決定要不要去清理一些內(nèi)存敏感的對象也是法實現(xiàn)的。
為此JDK1.2中引入的Reference相關(guān)的類,即今天要介紹的Reference、SoftReference、WeakReference、PhantomReference,還有與之相關(guān)的Cleaner、ReferenceQueue、ReferenceHandler等。與Reference相關(guān)核心類基本都在java.lang.ref包下面。其類關(guān)系如下:
其中,SoftReference代表軟引用對象,垃圾回收器會根據(jù)內(nèi)存需求酌情回收軟引用指向的對象。普通的GC并不會回收軟引用,只有在即將OOM的時候(也就是最后一次Full GC)如果被引用的對象只有SoftReference指向的引用,才會回收。WeakReference代表弱引用對象,當發(fā)生GC時,如果被引用的對象只有WeakReference指向的引用,就會被回收。PhantomReference代表虛引用對象(也有叫幻象引用的,個人認為還是虛引用更加貼切),其是一種特殊的引用類型,不能通過虛引用獲取到其關(guān)聯(lián)的對象,但當GC時如果其引用的對象被回收,這個事件程序可以感知,這樣我們可以做相應(yīng)的處理。最后就是最常見強引用對象,也就是通常我們new出來的對象。在繼續(xù)介紹Reference相關(guān)類的源碼前,先來簡單的看一下GC如何決定一個對象是否可被回收。其基本思路是從GC Root開始向下搜索,如果對象與GC Root之間存在引用鏈,則對象是可達的,GC會根據(jù)是否可到達與可到達性決定對象是否可以被回收。而對象的可達性與引用類型密切相關(guān),對象的可到達性可分為5種。
- 強可到達,如果從GC Root搜索后,發(fā)現(xiàn)對象與GC Root之間存在強引用鏈則為強可到達。強引用鏈即有強引用對象,引用了該對象。
- 軟可到達,如果從GC Root搜索后,發(fā)現(xiàn)對象與GC Root之間不存在強引用鏈,但存在軟引用鏈,則為軟可到達。軟引用鏈即有軟引用對象,引用了該對象。
- 弱可到達,如果從GC Root搜索后,發(fā)現(xiàn)對象與GC Root之間不存在強引用鏈與軟引用鏈,但有弱引用鏈,則為弱可到達。弱引用鏈即有弱引用對象,引用了該對象。
- 虛可到達,如果從GC Root搜索后,發(fā)現(xiàn)對象與GC Root之間只存在虛引用鏈則為虛可到達。虛引用鏈即有虛引用對象,引用了該對象。
- 不可達,如果從GC Root搜索后,找不到對象與GC Root之間的引用鏈,則為不可到達。
看一個簡單的列子:
ObjectA為強可到達,ObjectB也為強可到達,雖然ObjectB對象被SoftReference ObjcetE 引用但由于其還被ObjectA引用所以為強可到達;而ObjectC和ObjectD為弱引用達到,雖然ObjectD對象被PhantomReference ObjcetG引用但由于其還被ObjectC引用,而ObjectC又為弱引用達到,所以O(shè)bjectD為弱引用達到;而ObjectH與ObjectI是不可到達。引用鏈的強弱有關(guān)系依次是 強引用 > 軟引用 > 弱引用 > 虛引用,如果有更強的引用關(guān)系存在,那么引用鏈到達性,將由更強的引用有關(guān)系決定。
Reference核心處理流程
JVM在GC時如果當前對象只被Reference對象引用,JVM會根據(jù)Reference具體類型與堆內(nèi)存的使用情況決定是否把對應(yīng)的Reference對象加入到一個由Reference構(gòu)成的pending鏈表上,如果能加入pending鏈表JVM同時會通知ReferenceHandler線程進行處理。ReferenceHandler線程是在Reference類被初始化時調(diào)用的,其是一個守護進程并且擁有最高的優(yōu)先級。Reference類靜態(tài)初始化塊代碼如下:
static { //省略部分代碼... Thread handler = new ReferenceHandler(tg, "Reference Handler"); handler.setPriority(Thread.MAX_PRIORITY); handler.setDaemon(true); handler.start(); //省略部分代碼... }
而ReferenceHandler線程內(nèi)部的run方法會不斷地從Reference構(gòu)成的pending鏈表上獲取Reference對象,如果能獲取則根據(jù)Reference的具體類型進行不同的處理,不能則調(diào)用wait方法等待GC回收對象處理pending鏈表的通知。ReferenceHandler線程run方法源碼:
public void run() { //死循環(huán),線程啟動后會一直運行 while (true) { tryHandlePending(true); } }
run內(nèi)部調(diào)用的tryHandlePending源碼:
static boolean tryHandlePending(boolean waitForNotify) { Reference<Object> r; Cleaner c; try { synchronized (lock) { if (pending != null) { r = pending; //instanceof 可能會拋出OOME,所以在將r從pending鏈上斷開前,做這個處理 c = r instanceof Cleaner ? (Cleaner) r : null; //將將r從pending鏈上斷開 pending = r.discovered; r.discovered = null; } else { //等待CG后的通知 if (waitForNotify) { lock.wait(); } //重試 return waitForNotify; } } } catch (OutOfMemoryError x) { //當拋出OOME時,放棄CPU的運行時間,這樣有希望收回一些存活的引用并且GC能回收部分空間。同時能避免頻繁地自旋重試,導致連續(xù)的OOME異常 Thread.yield(); //重試 return true; } catch (InterruptedException x) { //重試 return true; } //如果是Cleaner類型的Reference調(diào)用其clean方法并退出 if (c != null) { c.clean(); return true; } ReferenceQueue<? super Object> q = r.queue; //如果Reference有注冊ReferenceQueue,則處理pending指向的Reference結(jié)點將其加入ReferenceQueue中 if (q != ReferenceQueue.NULL) q.enqueue(r); return true; }
上面tryHandlePending方法中比較重要的點是c.clean()與q.enqueue®,這個是文章最開始提到的兩個問題答案的入口。Cleaner的clean方法用于完成清理工作,而ReferenceQueue是將被回收對象加入到對應(yīng)的Reference列隊中,等待其他線程的后繼處理。更具體地關(guān)于Cleaner與ReferenceQueue后面會再詳細說明。Reference的核心處理流程可總結(jié)如下:
對Reference的核心處理流程有整體了解后,再來回過頭細看一下Reference類的源碼。
/* Reference實例有四種內(nèi)部的狀態(tài) * Active: 新創(chuàng)建Reference的實例其狀態(tài)為Active。當GC檢測到Reference引用的referent可達到狀態(tài)發(fā)生改變時, * 為改變Reference的狀態(tài)為Pending或Inactive。這個取決于創(chuàng)建Reference實例時是否注冊過ReferenceQueue。 * 注冊過其狀態(tài)會轉(zhuǎn)換為Pending,同時GC會將其加入pending-Reference鏈表中,否則為轉(zhuǎn)換為Inactive狀態(tài)。 * Pending: 代表Reference是pending-Reference鏈表的成員,等待ReferenceHandler線程調(diào)用Cleaner#clean * 或ReferenceQueue#enqueue操作。未注冊過ReferenceQueue的實例不會達到這個狀態(tài) * Enqueued: Reference實例成為其被創(chuàng)建時注冊過的ReferenceQueue的成員,代表已入隊列。當其從ReferenceQueue * 中移除后,其狀態(tài)會變?yōu)镮nactive。 * Inactive: 什么也不會做,一旦處理該狀態(tài),就不可再轉(zhuǎn)換。 * 不同狀態(tài)時,Reference對應(yīng)的queue與成員next變量值(next可理解為ReferenceQueue中的下個結(jié)點的引用)如下: * Active: queue為Reference實例被創(chuàng)建時注冊的ReferenceQueue,如果沒注冊為Null。此時,next為null, * Reference實例與queue真正產(chǎn)生關(guān)系。 * Pending: queue為Reference實例被創(chuàng)建時注冊的ReferenceQueue。next為當前實例本身。 * Enqueued: queue為ReferenceQueue.ENQUEUED代表當前實例已入隊列。next為queue中的下一實列結(jié)點, * 如果是queue尾部則為當前實例本身 * Inactive: queue為ReferenceQueue.NULL,當前實例已從queue中移除與queue無關(guān)聯(lián)。next為當前實例本身。 */ public abstract class Reference<T> { // Reference 引用的對象 private T referent; /* Reference注冊的queue用于ReferenceHandler線程入隊列處理與用戶線程取Reference處理。 * 其取值會根據(jù)Reference不同狀態(tài)發(fā)生改變,具體取值見上面的分析 */ volatile ReferenceQueue<? super T> queue; // 可理解為注冊的queue中的下一個結(jié)點的引用。其取值會根據(jù)Reference不同狀態(tài)發(fā)生改變,具體取值見上面的分析 volatile Reference next; /* 其由VM維護,取值會根據(jù)Reference不同狀態(tài)發(fā)生改變, * 狀態(tài)為active時,代表由GC維護的discovered-Reference鏈表的下個節(jié)點,如果是尾部則為當前實例本身 * 狀態(tài)為pending時,代表pending-Reference的下個節(jié)點的引用。否則為null */ transient private Reference<T> discovered; /* pending-Reference 鏈表頭指針,GC回收referent后會將Reference加pending-Reference鏈表。 * 同時ReferenceHandler線程會獲取pending指針,不為空時Cleaner.clean()或入列queue。 * pending-Reference會采用discovered引用接鏈表的下個節(jié)點。 */ private static Reference<Object> pending = null; // 可理解為注冊的queue中的下一個結(jié)點的引用。其取值會根據(jù)Reference不同狀態(tài)發(fā)生改變,具體取值見上面的分析 volatile Reference next; //用于CG同步Reference成員變量值的對象。 static private class Lock { } private static Lock lock = new Lock(); //省略部分代碼... }
上面解釋了Reference中的主要成員的作用,其中比較重要是Reference內(nèi)部維護的不同狀態(tài),其狀態(tài)不同成員變量queue、pending、discovered、next的取值都會發(fā)生變化。Reference的主要方法如下:
//構(gòu)造函數(shù),指定引用的對象referent Reference(T referent) { this(referent, null); } //構(gòu)造函數(shù),指定引用的對象referent與注冊的queue Reference(T referent, ReferenceQueue<? super T> queue) { this.referent = referent; this.queue = (queue == null) ? ReferenceQueue.NULL : queue; } //獲取引用的對象referent public T get() { return this.referent; } //將當前對象加入創(chuàng)建時注冊的queue中 public boolean enqueue() { return this.queue.enqueue(this); }
ReferenecQueue與Cleaner源碼分析
先來看下ReferenceQueue的主要成員變量的含義。
//代表Reference的queue為null。Null為ReferenceQueue子類 static ReferenceQueue<Object> NULL = new Null<>(); //代表Reference已加入當前ReferenceQueue中。 static ReferenceQueue<Object> ENQUEUED = new Null<>(); //用于同步的對象 private Lock lock = new Lock(); //當前ReferenceQueue中的頭節(jié)點 private volatile Reference<? extends T> head = null; //ReferenceQueue的長度 private long queueLength = 0;
ReferenceQueue中比較重要的方法為enqueue、poll、remove方法。
//入列隊enqueue方法,只被Reference類調(diào)用,也就是上面分析中ReferenceHandler線程為調(diào)用 boolean enqueue(Reference<? extends T> r) { //獲取同步對象lock對應(yīng)的監(jiān)視器對象 synchronized (lock) { //獲取r關(guān)聯(lián)的ReferenceQueue,如果創(chuàng)建r時未注冊ReferenceQueue則為NULL,同樣如果r已從ReferenceQueue中移除其也為null ReferenceQueue<?> queue = r.queue; //判斷queue是否為NULL 或者 r已加入ReferenceQueue中,是的話則入隊列失敗 if ((queue == NULL) || (queue == ENQUEUED)) { return false; } assert queue == this; //設(shè)置r的queue為已入隊列 r.queue = ENQUEUED; //如果ReferenceQueue頭節(jié)點為null則r的next節(jié)點指向當前節(jié)點,否則指向頭節(jié)點 r.next = (head == null) ? r : head; //更新ReferenceQueue頭節(jié)點 head = r; //列隊長度加1 queueLength++; //為FinalReference類型引用增加FinalRefCount數(shù)量 if (r instanceof FinalReference) { sun.misc.VM.addFinalRefCount(1); } //通知remove操作隊列有節(jié)點 lock.notifyAll(); return true; } }
poll方法源碼相對簡單,其就是從ReferenceQueue的頭節(jié)點獲取Reference。
public Reference<? extends T> poll() { //頭結(jié)點為null直接返回,代表Reference還沒有加入ReferenceQueue中 if (head == null) return null; //獲取同步對象lock對應(yīng)的監(jiān)視器對象 synchronized (lock) { return reallyPoll(); } } //從隊列中真正poll元素的方法 private Reference<? extends T> reallyPoll() { Reference<? extends T> r = head; //double check 頭節(jié)點不為null if (r != null) { //保存頭節(jié)點的下個節(jié)點引用 Reference<? extends T> rn = r.next; //更新queue頭節(jié)點引用 head = (rn == r) ? null : rn; //更新Reference的queue值,代表r已從隊列中移除 r.queue = NULL; //更新Reference的next為其本身 r.next = r; queueLength--; //為FinalReference節(jié)點FinalRefCount數(shù)量減1 if (r instanceof FinalReference) { sun.misc.VM.addFinalRefCount(-1); } //返回獲取的節(jié)點 return r; } return null; }
remove方法的源碼如下:
public Reference<? extends T> remove(long timeout) throws IllegalArgumentException, InterruptedException { if (timeout < 0) { throw new IllegalArgumentException("Negative timeout value"); } //獲取同步對象lock對應(yīng)的監(jiān)視器對象 synchronized (lock) { //獲取隊列頭節(jié)點指向的Reference Reference<? extends T> r = reallyPoll(); //獲取到返回 if (r != null) return r; long start = (timeout == 0) ? 0 : System.nanoTime(); //在timeout時間內(nèi)嘗試重試獲取 for (;;) { //等待隊列上有結(jié)點通知 lock.wait(timeout); //獲取隊列中的頭節(jié)點指向的Reference r = reallyPoll(); //獲取到返回 if (r != null) return r; if (timeout != 0) { long end = System.nanoTime(); timeout -= (end - start) / 1000_000; //已超時但還沒有獲取到隊列中的頭節(jié)點指向的Reference返回null if (timeout <= 0) return null; start = end; } } } }
簡單的分析完ReferenceQueue的源碼后,再來整體回顧一下Reference的核心處理流程。JVM在GC時如果當前對象只被Reference對象引用,JVM會根據(jù)Reference具體類型與堆內(nèi)存的使用情況決定是否把對應(yīng)的Reference對象加入到一個由Reference構(gòu)成的pending鏈表上,如果能加入pending鏈表JVM同時會通知ReferenceHandler線程進行處理。ReferenceHandler線程收到通知后會調(diào)用Cleaner#clean或ReferenceQueue#enqueue方法進行處理。如果引用當前對象的Reference類型為WeakReference且堆內(nèi)存不足,那么JMV就會把WeakReference加入到pending-Reference鏈表上,然后ReferenceHandler線程收到通知后會異步地做入隊列操作。而我們的應(yīng)用程序中的線程便可以不斷地去拉取ReferenceQueue中的元素來感知JMV的堆內(nèi)存是否出現(xiàn)了不足的情況,最終達到根據(jù)堆內(nèi)存的情況來做一些處理的操作。實際上WeakHashMap低層便是過通上述過程實現(xiàn)的,只不過實現(xiàn)細節(jié)上有所偏差,這個后面再分析。再來看看ReferenceHandler線程收到通知后可能會調(diào)用的另外一個類Cleaner的實現(xiàn)。
同樣先看一下Cleaner的成員變量,再看主要的方法實現(xiàn)。
//繼承了PhantomReference類也就是虛引用,PhantomReference源碼很簡單只是重寫了get方法返回null public class Cleaner extends PhantomReference<Object> { /* 虛隊列,命名很到位。之前說CG把ReferenceQueue加入pending-Reference鏈中后,ReferenceHandler線程在處理時 * 是不會將對應(yīng)的Reference加入列隊的,而是調(diào)用Cleaner.clean方法。但如果Reference不注冊ReferenceQueue,GC處理時 * 又無法把他加入到pending-Reference鏈中,所以Cleaner里面有了一個dummyQueue成員變量。 */ private static final ReferenceQueue<Object> dummyQueue = new ReferenceQueue(); //Cleaner鏈表的頭結(jié)點 private static Cleaner first = null; //當前Cleaner節(jié)點的后續(xù)節(jié)點 private Cleaner next = null; //當前Cleaner節(jié)點的前續(xù)節(jié)點 private Cleaner prev = null; //真正執(zhí)行清理工作的Runnable對象,實際clean內(nèi)部調(diào)用thunk.run()方法 private final Runnable thunk; //省略部分代碼... }
從上面的成變量分析知道Cleaner實現(xiàn)了雙向鏈表的結(jié)構(gòu)。先看構(gòu)造函數(shù)與clean方法。
//私有方法,不能直接new private Cleaner(Object var1, Runnable var2) { super(var1, dummyQueue); this.thunk = var2; } //創(chuàng)建Cleaner對象,同時加入Cleaner鏈中。 public static Cleaner create(Object var0, Runnable var1) { return var1 == null ? null : add(new Cleaner(var0, var1)); } //頭插法將新創(chuàng)意的Cleaner對象加入雙向鏈表,synchronized保證同步 private static synchronized Cleaner add(Cleaner var0) { if (first != null) { var0.next = first; first.prev = var0; } //更新頭節(jié)點引用 first = var0; return var0; } public void clean() { //從Cleaner鏈表中先移除當前節(jié)點 if (remove(this)) { try { //調(diào)用thunk.run()方法執(zhí)行對應(yīng)清理邏輯 this.thunk.run(); } catch (final Throwable var2) { //省略部分代碼.. } } }
可以看到Cleaner的實現(xiàn)還是比較簡單,Cleaner實現(xiàn)為PhantomReference類型的引用。當JVM GC時如果發(fā)現(xiàn)當前處理的對象只被PhantomReference類型對象引用,同之前說的一樣其會將該Reference加pending-Reference鏈中上,只是ReferenceHandler線程在處理時如果PhantomReference類型實際類型又是Cleaner的話。其就是調(diào)用Cleaner.clean方法做清理邏輯處理。Cleaner實際是DirectByteBuffer分配的堆外內(nèi)存收回的實現(xiàn),具體見下面的分析。
DirectByteBuffer堆外內(nèi)存回收與WeakHashMap敏感內(nèi)存回收
繞開了一大圈終于回到了文章最開始提到的兩個問題,先來看一下分配給DirectByteBuffer堆外內(nèi)存是如何回收的。在創(chuàng)建DirectByteBuffer時我們實際是調(diào)用ByteBuffer#allocateDirect方法,而其實現(xiàn)如下:
public static ByteBuffer allocateDirect(int capacity) { return new DirectByteBuffer(capacity); } DirectByteBuffer(int cap) { //省略部分代碼... try { //調(diào)用unsafe分配內(nèi)存 base = unsafe.allocateMemory(size); } catch (OutOfMemoryError x) { //省略部分代碼... } //省略部分代碼... //前面分析中的Cleaner對象創(chuàng)建,持有當前DirectByteBuffer的引用 cleaner = Cleaner.create(this, new Deallocator(base, size, cap)); att = null; }
里面和DirectByteBuffer堆外內(nèi)存回收相關(guān)的代碼便是Cleaner.create(this, new Deallocator(base, size, cap))這部分。還記得之前說實際的清理邏輯是里面和DirectByteBuffer堆外內(nèi)存回收相關(guān)的代碼便是Cleaner里面的Runnable#run方法嗎?直接看Deallocator.run方法源碼:
public void run() { if (address == 0) { // Paranoia return; } //通過unsafe.freeMemory釋放創(chuàng)建的堆外內(nèi)存 unsafe.freeMemory(address); address = 0; Bits.unreserveMemory(size, capacity); }
終于找到了分配給DirectByteBuffer堆外內(nèi)存是如何回收的的答案。再總結(jié)一下,創(chuàng)建DirectByteBuffer對象時會創(chuàng)建一個Cleaner對象,Cleaner對象持有了DirectByteBuffer對象的引用。當JVM在GC時,如果發(fā)現(xiàn)DirectByteBuffer被地方法沒被引用啦,JVM會將其對應(yīng)的Cleaner加入到pending-reference鏈表中,同時通知ReferenceHandler線程處理,ReferenceHandler收到通知后,會調(diào)用Cleaner#clean方法,而對于DirectByteBuffer創(chuàng)建的Cleaner對象其clean方法內(nèi)部會調(diào)用unsafe.freeMemory釋放堆外內(nèi)存。最終達到了DirectByteBuffer對象被GC回收其對應(yīng)的堆外內(nèi)存也被回收的目的。
再來看一下文章開始提到的另外一個問題WeakHashMap如何實現(xiàn)敏感內(nèi)存的回收。實際WeakHashMap實現(xiàn)上其Entry繼承了WeakReference。
//Entry繼承了WeakReference, WeakReference引用的是Map的key private static class Entry<K,V> extends WeakReference<Object> implements Map.Entry<K,V> { V value; final int hash; Entry<K,V> next; /** * 創(chuàng)建Entry對象,上面分析過的ReferenceQueue,這個queue實際是WeakHashMap的成員變量, * 創(chuàng)建WeakHashMap時其便被初始化 final ReferenceQueue<Object> queue = new ReferenceQueue<>() */ Entry(Object key, V value, ReferenceQueue<Object> queue, int hash, Entry<K,V> next) { super(key, queue); this.value = value; this.hash = hash; this.next = next; } //省略部分原碼... }
往WeakHashMap添加元素時,實際都會調(diào)用Entry的構(gòu)造方法,也就是會創(chuàng)建一個WeakReference對象,這個對象的引用的是WeakHashMap剛加入的Key,而所有的WeakReference對象關(guān)聯(lián)在同一個ReferenceQueue上。我們上面說過JVM在GC時,如果發(fā)現(xiàn)當前對象只有被WeakReference對象引用,那么會把其對應(yīng)的WeakReference對象加入到pending-reference鏈表上,并通知ReferenceHandler線程處理。而ReferenceHandler線程收到通知后,對于WeakReference對象會調(diào)用ReferenceQueue#enqueue方法把他加入隊列里面?,F(xiàn)在我們只要關(guān)注queue里面的元素在WeakHashMap里面是在哪里被拿出去啦做了什么樣的操作,就能找到文章開始問題的答案啦。最終能定位到WeakHashMap的expungeStaleEntries方法。
private void expungeStaleEntries() { //不斷地從ReferenceQueue中取出,那些只有被WeakReference對象引用的對象的Reference for (Object x; (x = queue.poll()) != null; ) { synchronized (queue) { //轉(zhuǎn)為 entry Entry<K,V> e = (Entry<K,V>) x; //計算其對應(yīng)的桶的下標 int i = indexFor(e.hash, table.length); //取出桶中元素 Entry<K,V> prev = table[i]; Entry<K,V> p = prev; //桶中對應(yīng)位置有元素,遍歷桶鏈表所有元素 while (p != null) { Entry<K,V> next = p.next; //如果當前元素(也就是entry)與queue取出的一致,將entry從鏈表中去除 if (p == e) { if (prev == e) table[i] = next; else prev.next = next; // Must not null out e.next; //清空entry對應(yīng)的value e.value = null; size--; break; } prev = p; p = next; } } } }
現(xiàn)在只看一下WeakHashMap哪些地方會調(diào)用expungeStaleEntries方法就知道什么時候WeakHashMap里面的Key變得軟可達時我們就可以將其對應(yīng)的Entry從WeakHashMap里面移除。直接調(diào)用有三個地方分別是getTable方法、size方法、resize方法。 getTable方法又被很多地方調(diào)用如get、containsKey、put、remove、containsValue、replaceAll。最終看下來,只要對WeakHashMap進行操作就行調(diào)用expungeStaleEntries方法。所有只要操作了WeakHashMap,沒WeakHashMap里面被再用到的Key對應(yīng)的Entry就會被清除。再來總結(jié)一下,為什么WeakHashMap適合作為內(nèi)存敏感緩存的實現(xiàn)。當JVM 在GC時,如果發(fā)現(xiàn)WeakHashMap里面某些Key沒地方在被引用啦(WeakReference除外),JVM會將其對應(yīng)的WeakReference對象加入到pending-reference鏈表上,并通知ReferenceHandler線程處理。而ReferenceHandler線程收到通知后將對應(yīng)引用Key的WeakReference對象加入到 WeakHashMap內(nèi)部的ReferenceQueue中,下次再對WeakHashMap做操作時,WeakHashMap內(nèi)部會清除那些沒有被引用的Key對應(yīng)的Entry。這樣就達到了每操作WeakHashMap時,自動的檢索并清量沒有被引用的Key對應(yīng)的Entry的目地。
總結(jié)
本文通過兩個問題引出了JDK中Reference相關(guān)類的源碼分析,最終給出了問題的答案。但實際上一般開發(fā)規(guī)范中都會建議禁止重寫Object#finalize方法同樣與Reference類關(guān)系密切(具體而言是Finalizer類)。受篇幅的限制本文并未給出分析,有待各位自己看源碼啦。半年沒有寫文章啦,有點對不住關(guān)注的小伙伴。希望看完本文各位或多或少能有所收獲。如果覺得本文不錯就幫忙轉(zhuǎn)發(fā)記得標一下出處,謝謝。后面我還會繼續(xù)分享一些自己覺得比較重要的東西給大家。由于個人能力有限,文中不足與錯誤還望指正。
以上就是java編程Reference核心原理示例源碼分析的詳細內(nèi)容,更多關(guān)于Reference核心原理的資料請關(guān)注腳本之家其它相關(guān)文章!
相關(guān)文章
java調(diào)用WebService服務(wù)的四種方法總結(jié)
WebService是一種跨編程語言、跨操作系統(tǒng)平臺的遠程調(diào)用技術(shù),已存在很多年了,很多接口也都是通過WebService方式來發(fā)布的,下面這篇文章主要給大家介紹了關(guān)于java調(diào)用WebService服務(wù)的四種方法,需要的朋友可以參考下2021-11-11詳解用JWT對SpringCloud進行認證和鑒權(quán)
這篇文章主要介紹了詳解用JWT對SpringCloud進行認證和鑒權(quán),文中通過示例代碼介紹的非常詳細,對大家的學習或者工作具有一定的參考學習價值,需要的朋友們下面隨著小編來一起學習學習吧2019-03-03談?wù)凧ava中Volatile關(guān)鍵字的理解
volatile這個關(guān)鍵字可能很多朋友都聽說過,或許也都用過。在Java 5之前,它是一個備受爭議的關(guān)鍵字,因為在程序中使用它往往會導致出人意料的結(jié)果,本文給大家介紹java中volatile關(guān)鍵字,需要的朋友參考下2016-03-03spring cloud中啟動Eureka Server的方法
本篇文章主要介紹了spring cloud中啟動Eureka Server的方法,小編覺得挺不錯的,現(xiàn)在分享給大家,也給大家做個參考。一起跟隨小編過來看看吧2018-01-01spring cloud 使用Zuul 實現(xiàn)API網(wǎng)關(guān)服務(wù)問題
這篇文章主要介紹了spring cloud 使用Zuul 實現(xiàn)API網(wǎng)關(guān)服務(wù)問題,非常不錯,具有一定的參考借鑒價值,需要的朋友可以參考下2018-05-05