淺談Java引用和Threadlocal的那些事

1 背景

海陵網(wǎng)站建設(shè)公司創(chuàng)新互聯(lián)建站,海陵網(wǎng)站設(shè)計(jì)制作，有大型網(wǎng)站制作公司豐富經(jīng)驗(yàn)。已為海陵上千提供企業(yè)網(wǎng)站建設(shè)服務(wù)。企業(yè)網(wǎng)站搭建\外貿(mào)網(wǎng)站建設(shè)要多少錢，請找那個(gè)售后服務(wù)好的海陵做網(wǎng)站的公司定做！

某一天在某一個(gè)群里面的某個(gè)群友突然提出了一個(gè)問題:"threadlocal的key是虛引用，那么在threadlocal.get()的時(shí)候,發(fā)生GC之后，key是否是null？"屏幕前的你可以好好的想想這個(gè)問題，在這里我先賣個(gè)關(guān)子，先講講Java中引用和ThreadLocal的那些事。

2 Java中的引用

對(duì)于很多Java初學(xué)者來說，會(huì)把引用和對(duì)象給搞混淆。下面有一段代碼，

User zhangsan = new User("zhangsan", 24);

這里先提個(gè)問題zhangsan到底是引用還是對(duì)象呢？很多人會(huì)認(rèn)為zhangsan是個(gè)對(duì)象，如果你也是這樣認(rèn)為的話那么再看一下下面一段代碼

User zhangsan;
zhangsan = new User("zhangsan", 24);

這段代碼和開始的代碼其實(shí)執(zhí)行效果是一致的，這段代碼的第一行User zhangsan，定義了zhangsan，那你認(rèn)為zhangsan還是對(duì)象嗎？如果你還認(rèn)為的話，那么這個(gè)對(duì)象應(yīng)該是什么呢？的確,zhangsan其實(shí)只是一個(gè)引用，對(duì)JVM內(nèi)存劃分熟悉的同學(xué)應(yīng)該熟悉下面的圖片:

 其實(shí)zhangsan是棧中分配的一個(gè)引用，而new User("zhangsan", 24)是在堆中分配的一個(gè)對(duì)象。而'='的作用是用來將引用指向堆中的對(duì)象的。就像你叫張三但張三是個(gè)名字而已并不是一個(gè)實(shí)際的人，他只是指向的你。

我們一般所說的引用其實(shí)都是代指的強(qiáng)引用，在JDK1.2之后引用不止這一種，一般來說分為四種:強(qiáng)引用，軟引用，弱引用，虛引用。而接下來我會(huì)一一介紹這四種引用。

2.1 強(qiáng)引用

上面我們說過了 User zhangsan = new User("zhangsan", 24);這種就是強(qiáng)引用，有點(diǎn)類似C的指針。對(duì)強(qiáng)引用他的特點(diǎn)有下面幾個(gè):

強(qiáng)引用可以直接訪問目標(biāo)對(duì)象。

只要這個(gè)對(duì)象被強(qiáng)引用所關(guān)聯(lián)，那么垃圾回收器都不會(huì)回收，那怕是拋出OOM異常。

容易導(dǎo)致內(nèi)存泄漏。

2.2 軟引用

在Java中使用SoftReference幫助我們定義軟引用。其構(gòu)造方法有兩個(gè):

public SoftReference(T referent);
public SoftReference(T referent, ReferenceQueue<? super T> q);

兩個(gè)構(gòu)造方法相似，第二個(gè)比第一個(gè)多了一個(gè)引用隊(duì)列，在構(gòu)造方法中的第一個(gè)參數(shù)就是我們的實(shí)際被指向的對(duì)象，這里用新建一個(gè)SoftReference來替代我們上面強(qiáng)引用的等號(hào)。 下面是構(gòu)造軟引用的例子:

 softZhangsan = new SoftReference(new User("zhangsan", 24));

2.2.1軟引用有什么用？

如果某個(gè)對(duì)象他只被軟引用所指向，那么他將會(huì)在內(nèi)存要溢出的時(shí)候被回收，也就是當(dāng)我們要出現(xiàn)OOM的時(shí)候，如果回收了一波內(nèi)存還不夠，這才拋出OOM,弱引用回收的時(shí)候如果設(shè)置了引用隊(duì)列，那么這個(gè)軟引用還會(huì)進(jìn)一次引用隊(duì)列，但是引用所指向的對(duì)象已經(jīng)被回收。這里要和下面的弱引用區(qū)分開來，弱引用是只要有垃圾回收，那么他所指向的對(duì)象就會(huì)被回收。下面是一個(gè)代碼例子:

public static void main(String[] args) {
 ReferenceQueue<User> referenceQueue = new ReferenceQueue();
 SoftReference softReference = new SoftReference(new User("zhangsan",24), referenceQueue);
 //手動(dòng)觸發(fā)GC
 System.gc();
 Thread.sleep(1000);
 System.out.println("手動(dòng)觸發(fā)GC:" + softReference.get());
 System.out.println("手動(dòng)觸發(fā)的隊(duì)列:" + referenceQueue.poll());
 //通過堆內(nèi)存不足觸發(fā)GC
 makeHeapNotEnough();
 System.out.println("通過堆內(nèi)存不足觸發(fā)GC:" + softReference.get());
 System.out.println("通過堆內(nèi)存不足觸發(fā)GC:" + referenceQueue.poll());
 }

 private static void makeHeapNotEnough() {
 SoftReference softReference = new SoftReference(new byte[1024*1024*5]);
 byte[] bytes = new byte[1024*1024*5];
 }
 輸出:
 手動(dòng)觸發(fā)GC:User{name='zhangsan', age=24}
 手動(dòng)觸發(fā)的隊(duì)列:null
 通過堆內(nèi)存不足觸發(fā)GC:null
 通過堆內(nèi)存不足觸發(fā)GC:java.lang.ref.SoftReference@4b85612c

通過-Xmx10m設(shè)置我們堆內(nèi)存大小為10，方便構(gòu)造堆內(nèi)存不足的情況?？梢钥匆娢覀冚敵龅那闆r我們手動(dòng)調(diào)用System.gc并沒有回收我們的軟引用所指向的對(duì)象，只有在內(nèi)存不足的情況下才能觸發(fā)。

2.2.2軟應(yīng)用的應(yīng)用

在SoftReference的doc中有這么一句話:

Soft references are most often used to implement memory-sensitive caches

也就是說軟引用經(jīng)常用來實(shí)現(xiàn)內(nèi)存敏感的高速緩存。怎么理解這句話呢？我們知道軟引用他只會(huì)在內(nèi)存不足的時(shí)候才觸發(fā)，不會(huì)像強(qiáng)引用那用容易內(nèi)存溢出，我們可以用其實(shí)現(xiàn)高速緩存，一方面內(nèi)存不足的時(shí)候可以回收，一方面也不會(huì)頻繁回收。在高速本地緩存Caffeine中實(shí)現(xiàn)了軟引用的緩存，當(dāng)需要緩存淘汰的時(shí)候，如果是只有軟引用指向那么久會(huì)被回收。不熟悉Caffeine的同學(xué)可以閱讀深入理解Caffeine

2.3 弱引用

弱引用在Java中使用WeakReference來定義一個(gè)弱引用，上面我們說過他比軟引用更加弱，只要發(fā)生垃圾回收，若這個(gè)對(duì)象只被弱引用指向，那么就會(huì)被回收。這里我們就不多廢話了，直接上例子:

public static void main(String[] args) {
 WeakReference weakReference = new WeakReference(new User("zhangsan",24));
 System.gc();
 System.out.println("手動(dòng)觸發(fā)GC:" + weakReference.get());
 }
輸出結(jié)果:
手動(dòng)觸發(fā)GC:null

可以看見上面的例子只要垃圾回收一觸發(fā)，該對(duì)象就被回收了。

2.3.1 弱引用的作用

在WeakReference的注釋中寫到:

Weak references are most often used to implement canonicalizing mappings.

從中可以知道虛引用更多的是用來實(shí)現(xiàn)canonicalizing mappings(規(guī)范化映射)。在JDK中WeakHashMap很好的體現(xiàn)了這個(gè)例子:

public static void main(String[] args) throws Exception {
 WeakHashMap<User, String> weakHashMap = new WeakHashMap();
 //強(qiáng)引用
 User zhangsan = new User("zhangsan", 24);
 weakHashMap.put(zhangsan, "zhangsan");
 System.out.println("有強(qiáng)引用的時(shí)候:map大小" + weakHashMap.size());
 //去掉強(qiáng)引用
 zhangsan = null;
 System.gc();
 Thread.sleep(1000);
 System.out.println("無強(qiáng)引用的時(shí)候:map大小"+weakHashMap.size());
 }
輸出結(jié)果為:
有強(qiáng)引用的時(shí)候:map大小1
無強(qiáng)引用的時(shí)候:map大小0

可以看出在GC之后我們在map中的鍵值對(duì)就被回收了，在weakHashMap中其實(shí)只有Key是虛引用做關(guān)聯(lián)的，然后通過引用隊(duì)列再去對(duì)我們的map進(jìn)行回收處理。

2.4 虛引用

虛引用是最弱的引用，在Java中使用PhantomReference進(jìn)行定義。弱到什么地步呢？也就是你定義了虛引用根本無法通過虛引用獲取到這個(gè)對(duì)象，更別談?dòng)绊戇@個(gè)對(duì)象的生命周期了。在虛引用中唯一的作用就是用隊(duì)列接收對(duì)象即將死亡的通知。

 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());
 }
輸出結(jié)果:
什么也不做，獲取: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.

虛引用得最多的就是在對(duì)象死前所做的清理操作，這是一個(gè)比Java的finalization梗靈活的機(jī)制。 在DirectByteBuffer中使用Cleaner用來回收對(duì)外內(nèi)存，Cleaner是PhantomReference的子類，當(dāng)DirectByteBuffer被回收的時(shí)候未防止內(nèi)存泄漏所以通過這種方式進(jìn)行回收，有點(diǎn)類似于下面的代碼:

public static void main(String[] args) throws Exception {
 Cleaner.create(new User("zhangsan", 24), () -> {System.out.println("我被回收了，當(dāng)前線程:{}"+ Thread.currentThread().getName());});
 System.gc();
 Thread.sleep(1000);
 }
輸出:
我被回收了，當(dāng)前線程:Reference Handler

3 ThreadLocal

ThreadLocal是一個(gè)本地線程副本變量工具類,基本在我們的代碼中隨處可見。這里就不過多的介紹他了。

3.1 ThreadLocal和弱引用的那些事

上面說了這么多關(guān)于引用的事，這里終于回到了主題了我們的ThreadLocal和弱引用有什么關(guān)系呢？

在我們的Thread類中有下面這個(gè)變量:

ThreadLocal.ThreadLocalMap threadLocals

ThreadLocalMap本質(zhì)上也是個(gè)Map,其中Key是我們的ThreadLocal這個(gè)對(duì)象，Value就是我們在ThreadLocal中保存的值。也就是說我們的ThreadLocal保存和取對(duì)象都是通過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的子類，而這個(gè)虛引用所關(guān)聯(lián)的對(duì)象正是我們的ThreadLocal這個(gè)對(duì)象。我們又回到上面的問題:

"threadlocal的key是虛引用，那么在threadlocal.get()的時(shí)候,發(fā)生GC之后，key是否是null？"
這個(gè)問題晃眼一看，虛引用嘛，還有垃圾回收那肯定是為null，這其實(shí)是不對(duì)的，因?yàn)轭}目說的是在做threadlocal.get()操作，證明其實(shí)還是有強(qiáng)引用存在的。所以key并不為null。如果我們的強(qiáng)引用不存在的話，那么Key就會(huì)被回收，也就是會(huì)出現(xiàn)我們value沒被回收，key被回收，導(dǎo)致value永遠(yuǎn)存在，出現(xiàn)內(nèi)存泄漏。這也是ThreadLocal經(jīng)常會(huì)被很多書籍提醒到需要remove()的原因。

你也許會(huì)問看到很多源碼的ThreadLocal并沒有寫remove依然再用得很好呢？那其實(shí)是因?yàn)楹芏嘣创a經(jīng)常是作為靜態(tài)變量存在的生命周期和Class是一樣的，而remove需要再那些方法或者對(duì)象里面使用ThreadLocal，因?yàn)榉椒；蛘邔?duì)象的銷毀從而強(qiáng)引用丟失，導(dǎo)致內(nèi)存泄漏。

3.2 FastThreadLocal

FastThreadLocal是Netty中提供的高性能本地線程副本變量工具。在Netty的io.netty.util中提供了很多牛逼的工具，后續(xù)會(huì)一一給大家介紹，這里就先說下FastThreadLocal。

FastThreadLocal有下面幾個(gè)特點(diǎn):

使用數(shù)組代替ThreadLocalMap存儲(chǔ)數(shù)據(jù)，從而獲取更快的性能。(緩存行和一次定位，不會(huì)有hash沖突)
由于使用數(shù)組，不會(huì)出現(xiàn)Key回收，value沒被回收的尷尬局面，所以避免了內(nèi)存泄漏。

總結(jié)

文章開頭的問題，為什么會(huì)被問出來，其實(shí)是對(duì)虛引用和ThreadLocal理解不深導(dǎo)致，很多時(shí)候只記著一個(gè)如果是虛引用，在垃圾回收時(shí)就會(huì)被回收，就會(huì)導(dǎo)致把這個(gè)觀念先入為主，沒有做更多的分析思考。所以大家再分析一個(gè)問題的時(shí)候還是需要更多的站在不同的場景上做更多的思考。

以上所述是小編給大家介紹的Java引用和Threadlocal的那些事，希望對(duì)大家有所幫助，如果大家有任何疑問請給我留言，小編會(huì)及時(shí)回復(fù)大家的。在此也非常感謝大家對(duì)創(chuàng)新互聯(lián)網(wǎng)站的支持！

名稱欄目：淺談Java引用和Threadlocal的那些事
URL標(biāo)題：http://muchs.cn/article46/isjjhg.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)頁設(shè)計(jì)公司、網(wǎng)站制作、響應(yīng)式網(wǎng)站、ChatGPT、移動(dòng)網(wǎng)站建設(shè)、虛擬主機(jī)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來源： 創(chuàng)新互聯(lián)