1 背景
某一天在某一個(gè)群里面的某個(gè)群友突然提出了一個(gè)問(wèn)題:"threadlocal的key是虛引用,那么在threadlocal.get()的時(shí)候,發(fā)生gc之后,key是否是null?"屏幕前的你可以好好的想想這個(gè)問(wèn)題,在這里我先賣個(gè)關(guān)子,先講講java中引用和threadlocal的那些事。
2 java中的引用
對(duì)于很多java初學(xué)者來(lái)說(shuō),會(huì)把引用和對(duì)象給搞混淆。下面有一段代碼,
1
|
user zhangsan = new user( "zhangsan" , 24 ); |
這里先提個(gè)問(wèn)題zhangsan到底是引用還是對(duì)象呢?很多人會(huì)認(rèn)為zhangsan是個(gè)對(duì)象,如果你也是這樣認(rèn)為的話那么再看一下下面一段代碼
1
2
|
user zhangsan; zhangsan = new user( "zhangsan" , 24 ); |
這段代碼和開(kāi)始的代碼其實(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ì)象。而'='的作用是用來(lái)將引用指向堆中的對(duì)象的。就像你叫張三但張三是個(gè)名字而已并不是一個(gè)實(shí)際的人,他只是指向的你。
我們一般所說(shuō)的引用其實(shí)都是代指的強(qiáng)引用,在jdk1.2之后引用不止這一種,一般來(lái)說(shuō)分為四種:強(qiáng)引用,軟引用,弱引用,虛引用。而接下來(lái)我會(huì)一一介紹這四種引用。
2.1 強(qiáng)引用
上面我們說(shuō)過(guò)了 user zhangsan = new user("zhangsan", 24);這種就是強(qiáng)引用,有點(diǎn)類似c的指針。對(duì)強(qiáng)引用他的特點(diǎn)有下面幾個(gè):
強(qiáng)引用可以直接訪問(wèn)目標(biāo)對(duì)象。
只要這個(gè)對(duì)象被強(qiáng)引用所關(guān)聯(lián),那么垃圾回收器都不會(huì)回收,那怕是拋出oom異常。
容易導(dǎo)致內(nèi)存泄漏。
2.2 軟引用
在java中使用softreference幫助我們定義軟引用。其構(gòu)造方法有兩個(gè):
1
2
|
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來(lái)替代我們上面強(qiáng)引用的等號(hào)。 下面是構(gòu)造軟引用的例子:
1
|
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ū)分開(kāi)來(lái),弱引用是只要有垃圾回收,那么他所指向的對(duì)象就會(huì)被回收。下面是一個(gè)代碼例子:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
|
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()); //通過(guò)堆內(nèi)存不足觸發(fā)gc makeheapnotenough(); system.out.println( "通過(guò)堆內(nèi)存不足觸發(fā)gc:" + softreference.get()); system.out.println( "通過(guò)堆內(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 通過(guò)堆內(nèi)存不足觸發(fā)gc: null 通過(guò)堆內(nèi)存不足觸發(fā)gc:java.lang.ref.softreference @4b85612c |
通過(guò)-xmx10m設(shè)置我們堆內(nèi)存大小為10,方便構(gòu)造堆內(nèi)存不足的情況。可以看見(jiàn)我們輸出的情況我們手動(dòng)調(diào)用system.gc并沒(méi)有回收我們的軟引用所指向的對(duì)象,只有在內(nèi)存不足的情況下才能觸發(fā)。
2.2.2軟應(yīng)用的應(yīng)用
在softreference的doc中有這么一句話:
soft references are most often used to implement memory-sensitive caches
也就是說(shuō)軟引用經(jīng)常用來(lái)實(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來(lái)定義一個(gè)弱引用,上面我們說(shuō)過(guò)他比軟引用更加弱,只要發(fā)生垃圾回收,若這個(gè)對(duì)象只被弱引用指向,那么就會(huì)被回收。這里我們就不多廢話了,直接上例子:
1
2
3
4
5
6
7
|
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 |
可以看見(jiàn)上面的例子只要垃圾回收一觸發(fā),該對(duì)象就被回收了。
2.3.1 弱引用的作用
在weakreference的注釋中寫到:
weak references are most often used to implement canonicalizing mappings.
從中可以知道虛引用更多的是用來(lái)實(shí)現(xiàn)canonicalizing mappings(規(guī)范化映射)。在jdk中weakhashmap很好的體現(xiàn)了這個(gè)例子:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
|
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( "無(wú)強(qiáng)引用的時(shí)候:map大小" +weakhashmap.size()); } 輸出結(jié)果為: 有強(qiáng)引用的時(shí)候:map大小 1 無(wú)強(qiáng)引用的時(shí)候:map大小 0 |
可以看出在gc之后我們?cè)趍ap中的鍵值對(duì)就被回收了,在weakhashmap中其實(shí)只有key是虛引用做關(guān)聯(lián)的,然后通過(guò)引用隊(duì)列再去對(duì)我們的map進(jìn)行回收處理。
2.4 虛引用
虛引用是最弱的引用,在java中使用phantomreference進(jìn)行定義。弱到什么地步呢?也就是你定義了虛引用根本無(wú)法通過(guò)虛引用獲取到這個(gè)對(duì)象,更別談?dòng)绊戇@個(gè)對(duì)象的生命周期了。在虛引用中唯一的作用就是用隊(duì)列接收對(duì)象即將死亡的通知。
1
2
3
4
5
6
7
|
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用來(lái)回收對(duì)外內(nèi)存,cleaner是phantomreference的子類,當(dāng)directbytebuffer被回收的時(shí)候未防止內(nèi)存泄漏所以通過(guò)這種方式進(jìn)行回收,有點(diǎn)類似于下面的代碼:
1
2
3
4
5
6
7
|
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è)本地線程副本變量工具類,基本在我們的代碼中隨處可見(jiàn)。這里就不過(guò)多的介紹他了。
3.1 threadlocal和弱引用的那些事
上面說(shuō)了這么多關(guān)于引用的事,這里終于回到了主題了我們的threadlocal和弱引用有什么關(guān)系呢?
在我們的thread類中有下面這個(gè)變量:
threadlocal.threadlocalmap threadlocals
threadlocalmap本質(zhì)上也是個(gè)map,其中key是我們的threadlocal這個(gè)對(duì)象,value就是我們?cè)趖hreadlocal中保存的值。也就是說(shuō)我們的threadlocal保存和取對(duì)象都是通過(guò)thread中的threadlocalmap來(lái)操作的,而key就是本身。在threadlocalmap中entry有如下定義:
1
2
3
4
5
6
7
8
9
|
static class entry extends weakreference<threadlocal<?>> { /** the value associated with this threadlocal. */ object value; entry(threadlocal<?> k, object v) { super (k); value = v; } } |
可以看見(jiàn)entry是weakreference的子類,而這個(gè)虛引用所關(guān)聯(lián)的對(duì)象正是我們的threadlocal這個(gè)對(duì)象。我們又回到上面的問(wèn)題:
"threadlocal的key是虛引用,那么在threadlocal.get()的時(shí)候,發(fā)生gc之后,key是否是null?"
這個(gè)問(wèn)題晃眼一看,虛引用嘛,還有垃圾回收那肯定是為null,這其實(shí)是不對(duì)的,因?yàn)轭}目說(shuō)的是在做threadlocal.get()操作,證明其實(shí)還是有強(qiáng)引用存在的。所以key并不為null。如果我們的強(qiáng)引用不存在的話,那么key就會(huì)被回收,也就是會(huì)出現(xiàn)我們value沒(méi)被回收,key被回收,導(dǎo)致value永遠(yuǎn)存在,出現(xiàn)內(nèi)存泄漏。這也是threadlocal經(jīng)常會(huì)被很多書籍提醒到需要remove()的原因。
你也許會(huì)問(wèn)看到很多源碼的threadlocal并沒(méi)有寫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ì)一一給大家介紹,這里就先說(shuō)下fastthreadlocal。
fastthreadlocal有下面幾個(gè)特點(diǎn):
使用數(shù)組代替threadlocalmap存儲(chǔ)數(shù)據(jù),從而獲取更快的性能。(緩存行和一次定位,不會(huì)有hash沖突)
由于使用數(shù)組,不會(huì)出現(xiàn)key回收,value沒(méi)被回收的尷尬局面,所以避免了內(nèi)存泄漏。
總結(jié)
文章開(kāi)頭的問(wèn)題,為什么會(huì)被問(wèn)出來(lái),其實(shí)是對(duì)虛引用和threadlocal理解不深導(dǎo)致,很多時(shí)候只記著一個(gè)如果是虛引用,在垃圾回收時(shí)就會(huì)被回收,就會(huì)導(dǎo)致把這個(gè)觀念先入為主,沒(méi)有做更多的分析思考。所以大家再分析一個(gè)問(wèn)題的時(shí)候還是需要更多的站在不同的場(chǎng)景上做更多的思考。
以上所述是小編給大家介紹的java引用和threadlocal的那些事,希望對(duì)大家有所幫助,如果大家有任何疑問(wèn)請(qǐng)給我留言,小編會(huì)及時(shí)回復(fù)大家的。在此也非常感謝大家對(duì)服務(wù)器之家網(wǎng)站的支持!
原文鏈接:https://my.oschina.net/u/4072299/blog/3017914