談談引用和Threadlocal的那些事
1 背景
某一天在某一個群裡面的某個群友突然提出了一個問題:"threadlocal的key是弱引用,那麼在threadlocal.get()的時候,發生GC之後,key是否是null?"螢幕前的你可以好好的想想這個問題,在這裡我先賣個關子,先講講Java中引用和ThreadLocal的那些事。
2 Java中的引用
對於很多Java初學者來說,會把引用和物件給搞混淆。下面有一段程式碼,
User zhangsan = new User("zhangsan", 24);
這裡先提個問題zhangsan到底是引用還是物件呢?很多人會認為zhangsan是個物件,如果你也是這樣認為的話那麼再看一下下面一段程式碼
User zhangsan;
zhangsan = new User("zhangsan", 24);
這段程式碼和開始的程式碼其實執行效果是一致的,這段程式碼的第一行User zhangsan,定義了zhangsan,那你認為zhangsan還是物件嗎?如果你還認為的話,那麼這個物件應該是什麼呢?的確,zhangsan其實只是一個引用,對JVM記憶體劃分熟悉的同學應該熟悉下面的圖片:
其實zhangsan是棧中分配的一個引用,而new User("zhangsan", 24)是在堆中分配的一個物件。而'='的作用是用來將引用指向堆中的物件的。就像你叫張三但張三是個名字而已並不是一個實際的人,他只是指向的你。
我們一般所說的引用其實都是代指的強引用,在JDK1.2之後引用不止這一種,一般來說分為四種:強引用,軟引用,弱引用,虛引用。而接下來我會一一介紹這四種引用。
2.1 強引用
上面我們說過了
User zhangsan = new User("zhangsan", 24);這種就是強引用,有點類似C的指標。對強引用他的特點有下面幾個:
強引用可以直接訪問目標物件。
只要這個物件被強引用所關聯,那麼垃圾回收器都不會回收,那怕是丟擲OOM異常。
容易導致記憶體洩漏。
2.2 軟引用
在Java中使用SoftReference幫助我們定義軟引用。其構造方法有兩個:
public SoftReference(T referent);
public SoftReference(T referent, ReferenceQueue<? super T> q);
兩個構造方法相似,第二個比第一個多了一個引用佇列,在構造方法中的第一個引數就是我們的實際被指向的物件,這裡用新建一個SoftReference來替代我們上面強引用的等號。
下面是構造軟引用的例子:
softZhangsan = new SoftReference(new User("zhangsan", 24));
2.2.1軟引用有什麼用?
如果某個物件他只被軟引用所指向,那麼他將會在記憶體要溢位的時候被回收,也就是當我們要出現OOM的時候,如果回收了一波記憶體還不夠,這才丟擲OOM,弱引用回收的時候如果設定了引用佇列,那麼這個軟引用還會進一次引用佇列,但是引用所指向的物件已經被回收。這裡要和下面的弱引用區分開來,弱引用是隻要有垃圾回收,那麼他所指向的物件就會被回收。下面是一個程式碼例子:
public static void main(String[] args) {
ReferenceQueue<User> referenceQueue = new ReferenceQueue();
SoftReference softReference = new SoftReference(new User("zhangsan",24), referenceQueue);
//手動觸發GC
System.gc();
Thread.sleep(1000);
System.out.println("手動觸發GC:" + softReference.get());
System.out.println("手動觸發的佇列:" + referenceQueue.poll());
//透過堆記憶體不足觸發GC
makeHeapNotEnough();
System.out.println("透過堆記憶體不足觸發GC:" + softReference.get());
System.out.println("透過堆記憶體不足觸發GC:" + referenceQueue.poll());
}
private static void makeHeapNotEnough() {
SoftReference softReference = new SoftReference(new byte[1024*1024*5]);
byte[] bytes = new byte[1024*1024*5];
}
輸出:
手動觸發GC:User{name='zhangsan', age=24}
手動觸發的佇列:null
透過堆記憶體不足觸發GC:null
透過堆記憶體不足觸發GC:java.lang.ref.SoftReference@4b85612c
透過-Xmx10m設定我們堆記憶體大小為10,方便構造堆記憶體不足的情況。可以看見我們輸出的情況我們手動呼叫System.gc並沒有回收我們的軟引用所指向的物件,只有在記憶體不足的情況下才能觸發。
2.2.2軟應用的應用
在SoftReference的doc中有這麼一句話:
Soft references are most often used to implement memory-sensitive caches
也就是說軟引用經常用來實現記憶體敏感的快取記憶體。怎麼理解這句話呢?我們知道軟引用他只會在記憶體不足的時候才觸發,不會像強引用那用容易記憶體溢位,我們可以用其實現快取記憶體,一方面記憶體不足的時候可以回收,一方面也不會頻繁回收。在高速本地快取Caffeine中實現了軟引用的快取,當需要快取淘汰的時候,如果是隻有軟引用指向那麼久會被回收。不熟悉Caffeine的同學可以閱讀深入理解Caffeine
2.3 弱引用
弱引用在Java中使用WeakReference來定義一個弱引用,上面我們說過他比軟引用更加弱,只要發生垃圾回收,若這個物件只被弱引用指向,那麼就會被回收。這裡我們就不多廢話了,直接上例子:
public static void main(String[] args) {
WeakReference weakReference = new WeakReference(new User("zhangsan",24));
System.gc();
System.out.println("手動觸發GC:" + weakReference.get());
}
輸出結果:
手動觸發GC:null
可以看見上面的例子只要垃圾回收一觸發,該物件就被回收了。
2.3.1 弱引用的作用
在WeakReference的註釋中寫到:
Weak references are most often used to implement canonicalizing mappings.
從中可以知道弱引用更多的是用來實現canonicalizing mappings(規範化對映)。在JDK中WeakHashMap很好的體現了這個例子:
public static void main(String[] args) throws Exception {
WeakHashMap<User, String> weakHashMap = new WeakHashMap();
//強引用
User zhangsan = new User("zhangsan", 24);
weakHashMap.put(zhangsan, "zhangsan");
System.out.println("有強引用的時候:map大小" + weakHashMap.size());
//去掉強引用
zhangsan = null;
System.gc();
Thread.sleep(1000);
System.out.println("無強引用的時候:map大小"+weakHashMap.size());
}
輸出結果為:
有強引用的時候:map大小1
無強引用的時候:map大小0
可以看出在GC之後我們在map中的鍵值對就被回收了,在weakHashMap中其實只有Key是弱引用做關聯的,然後透過引用佇列再去對我們的map進行回收處理。
2.4 虛引用
虛引用是最弱的引用,在Java中使用PhantomReference進行定義。弱到什麼地步呢?也就是你定義了虛引用根本無法透過虛引用獲取到這個物件,更別談影響這個物件的生命週期了。在虛引用中唯一的作用就是用佇列接收物件即將死亡的通知。
public static void main(String[] args) throws Exception {
ReferenceQueue referenceQueue = new ReferenceQueue();
PhantomReference phantomReference = new PhantomReference(new User("zhangsan", 24), referenceQueue);
System.out.println("什麼也不做,獲取:" + phantomReference.get());
}
輸出結果:
什麼也不做,獲取:null
在PhantomReference的註釋中寫到:
Phantom references are most often used for scheduling pre-mortem cleanup actions in a more flexible way than is possible with the Java finalization mechanism.
虛引用得最多的就是在物件死前所做的清理操作,這是一個比Java的finalization梗靈活的機制。
在DirectByteBuffer中使用Cleaner用來回收對外記憶體,Cleaner是PhantomReference的子類,當DirectByteBuffer被回收的時候未防止記憶體洩漏所以透過這種方式進行回收,有點類似於下面的程式碼:
public static void main(String[] args) throws Exception {
Cleaner.create(new User("zhangsan", 24), () -> {System.out.println("我被回收了,當前執行緒:{}"+ Thread.currentThread().getName());});
System.gc();
Thread.sleep(1000);
}
輸出:
我被回收了,當前執行緒:Reference Handler
3 ThreadLocal
ThreadLocal是一個本地執行緒副本變數工具類,基本在我們的程式碼中隨處可見。這裡就不過多的介紹他了。
3.1 ThreadLocal和弱引用的那些事
上面說了這麼多關於引用的事,這裡終於回到了主題了我們的ThreadLocal和弱引用有什麼關係呢?
在我們的Thread類中有下面這個變數:
ThreadLocal.ThreadLocalMap threadLocals
ThreadLocalMap本質上也是個Map,其中Key是我們的ThreadLocal這個物件,Value就是我們在ThreadLocal中儲存的值。也就是說我們的ThreadLocal儲存和取物件都是透過Thread中的ThreadLocalMap來操作的,而key就是本身。在ThreadLocalMap中Entry有如下定義:
static class Entry extends WeakReference<ThreadLocal<?>> {
/** The value associated with this ThreadLocal. */
Object value;
Entry(ThreadLocal<?> k, Object v) {
super(k);
value = v;
}
}
可以看見Entry是WeakReference的子類,而這個弱引用所關聯的物件正是我們的ThreadLocal這個物件。我們又回到上面的問題:
"threadlocal的key是弱引用,那麼在threadlocal.get()的時候,發生GC之後,key是否是null?"
這個問題晃眼一看,弱引用嘛,還有垃圾回收那肯定是為null,這其實是不對的,因為題目說的是在做threadlocal.get()操作,證明其實還是有強引用存在的。所以key並不為null。如果我們的強引用不存在的話,那麼Key就會被回收,也就是會出現我們value沒被回收,key被回收,導致value永遠存在,出現記憶體洩漏。這也是ThreadLocal經常會被很多書籍提醒到需要remove()的原因。
你也許會問看到很多原始碼的ThreadLocal並沒有寫remove依然再用得很好呢?那其實是因為很多原始碼經常是作為靜態變數存在的生命週期和Class是一樣的,而remove需要再那些方法或者物件裡面使用ThreadLocal,因為方法棧或者物件的銷燬從而強引用丟失,導致記憶體洩漏。
3.2 FastThreadLocal
FastThreadLocal是Netty中提供的高效能本地執行緒副本變數工具。在Netty的io.netty.util中提供了很多牛逼的工具,後續會一一給大家介紹,這裡就先說下FastThreadLocal。
FastThreadLocal有下面幾個特點:
使用陣列代替ThreadLocalMap儲存資料,從而獲取更快的效能。(快取行和一次定位,不會有hash衝突)
由於使用陣列,不會出現Key回收,value沒被回收的尷尬局面,所以避免了記憶體洩漏。
總結
文章開頭的問題,為什麼會被問出來,其實是對弱引用和ThreadLocal理解不深導致,很多時候只記著一個如果是弱引用,在垃圾回收時就會被回收,就會導致把這個觀念先入為主,沒有做更多的分析思考。所以大家再分析一個問題的時候還是需要更多的站在不同的場景上做更多的思考。
最後這篇文章被我收錄於JGrowing-Java基礎篇,一個全面,優秀,由社群一起共建的Java學習路線,如果您想參與開源專案的維護,可以一起共建,github地址為:
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/31555607/viewspace-2637681/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 談談 Java 中的那些“瑣”事Java
- 談談jQuery中Ajax那些事jQuery
- Android 談談封裝那些事 –BaseActivity 和 BaseFragment(二)Android封裝Fragment
- 談談java入門的那些事兒Java
- 淺談Blazor開發的那些事Blazor
- 淺談synchronized、Lock、ThreadLocal和semaphoresynchronizedthread
- 結合原始碼談談ThreadLocal!原始碼thread
- Java面試題:請談談對ThreadLocal的理解?Java面試題thread
- 通過Wireshark抓包分析談談DNS域名解析的那些事兒DNS
- 談談 React 那些小事React
- 淺談Go型別轉換之間的那些事Go型別
- 淺談 Go 型別轉換之間的那些事Go型別
- 淺談AsyncLocal,我們應該知道的那些事兒
- 談談Java事務Java
- 碼農何苦為難碼農:談談程式設計師面試那些事程式設計師面試
- 大齡碼農那些事——也談996.ICU996
- 淺談使用者研究那些事(上)定性研究
- 談談分散式事務原理分散式
- 談談javascript非同步哪些事JavaScript非同步
- 大齡碼農那些事——淺談技術變現
- 人人都是藝術家!談談那些奇怪的字元(上)字元
- 工作快兩年了!斗膽談談校招社招技術面試那些事面試
- 網際網路求職時薪資談判那些事求職
- 如何實現高效運維?來談談效能優化那些事(含直播回顧 Q&A)運維優化
- 阿里二面:談談ThreadLocal的記憶體洩漏問題?問麻了。。。。阿里thread記憶體
- 談談遊戲資料分析的那點事遊戲
- Java中的引用與ThreadLocalJavathread
- 那些年曾談起的跨域跨域
- 談談MySQL InnoDB儲存引擎事務的ACID特性MySql儲存引擎
- 基礎篇:JAVA引用型別和ThreadLocalJava型別thread
- 談談 JDK 和 SAPMachine 的關係JDKMac
- 談談mysql和redis的區別MySqlRedis
- 談談import和require的區別ImportUI
- 面試完 BAT等數十家公司,我想談談關於 Android 面試那些事面試BATAndroid
- 由事務擴充套件開談一談套件
- 【計算講談社】第十二講|資料中心那些事兒
- 守住髮際線:南大蔣炎巖談讀博那些事兒
- 細談Mysql事務MySql