頭條二面：你確定ThreadLocal真的會(huì)造成內(nèi)存泄露？

ThreadLocal，java面試過程中的“釘子戶”，在網(wǎng)上也充斥著各種有關(guān)ThreadLocal內(nèi)存泄露的問題，本文換個(gè)角度，先思考ThreadLocal體系中的ThreadLocalMap為什么要設(shè)計(jì)成弱引用。

1、ThreadLocal知識(shí)體系

本文還是不能免俗，在回答這個(gè)問題之前需要先和大家介紹一下ThreadLocal的知識(shí)，使大家對(duì)ThreadLocal有一個(gè)相對(duì)全面的認(rèn)識(shí)。

ThreadLocal本地線程變量，主要用于解決數(shù)據(jù)訪問的競(jìng)爭(zhēng)，通常用于多租戶、全鏈路壓測(cè)、鏈路跟蹤中保存線程上下文環(huán)境，在一個(gè)請(qǐng)求流轉(zhuǎn)中非常方便的獲取一些關(guān)鍵信息，例如當(dāng)前的租戶信息、壓測(cè)標(biāo)記。

ThreadLocal正如其名，本地線程變量，即數(shù)據(jù)存儲(chǔ)在線程自己的局部變量中。

其整體架構(gòu)如下圖所示：

• 每一個(gè)線程對(duì)象會(huì)維護(hù)一個(gè)私有屬性:ThreadLocal.ThreadLocalMap threadLocals。

• ThreadLocalMap內(nèi)部結(jié)構(gòu)為Key-Value鍵值對(duì)，其Key為ThreadLocal對(duì)象，Value為調(diào)用ThreadLocal的set方法設(shè)置的值。

一言以蔽之：ThreadLocal是將線程需要訪問的數(shù)據(jù)存儲(chǔ)在線程對(duì)象自身中，從而避免多線程的競(jìng)爭(zhēng)。

2、為什么會(huì)被設(shè)計(jì)為弱引用呢？

接下來我們來看一下ThreadLocalMap的聲明：

思考這個(gè)問題之前先和大家普及一下Java的4種引用類型，主要是在垃圾回收時(shí)java虛擬機(jī)會(huì)根據(jù)不同的引用類型采取不同的措施。

• 強(qiáng)引用：java默認(rèn)的引用類型，例如 Object a = new Object();其中 a 為強(qiáng)引用，new Object()為一個(gè)具體的對(duì)象。一個(gè)對(duì)象從根路徑能找到強(qiáng)引用指向它，jvm虛擬機(jī)就不會(huì)回收。

• 軟引用(SoftReference)：進(jìn)行年輕代的垃圾回收不會(huì)觸發(fā)SoftReference所指向?qū)ο蟮幕厥?；但如果觸發(fā)Full GC，那SoftReference所指向的對(duì)象將被回收。備注：是除了軟引用之外沒有其他強(qiáng)引用引用的情況下。

• 弱引用(WeakReference) :如果對(duì)象除了有弱引用指向它后沒有其他強(qiáng)引用關(guān)聯(lián)它，當(dāng)進(jìn)行年輕代垃圾回收時(shí)，該引用指向的對(duì)象就會(huì)被垃圾回收器回收。

• 虛引用(PhantomeReference) 該引用指向的對(duì)象，無法對(duì)垃圾收集器收集對(duì)象時(shí)產(chǎn)生任何影響，但在執(zhí)行垃圾回收后垃圾收集器會(huì)通過注冊(cè)在PhantomeReference上的隊(duì)列來通知應(yīng)用程序?qū)ο蟊换厥铡?/span>

從四種弱引用的實(shí)際作用來說，主要是與垃圾回收器配合，決策什么時(shí)候可以將被引用的對(duì)象回收。

理論看起來有點(diǎn)晦澀難懂，接下來筆者將以圖解的方式，爭(zhēng)取將該問題闡述清楚。

ThreadLocal的設(shè)計(jì)比較晦澀難懂，究其原因是我們通過threadLocal對(duì)象的set方法進(jìn)行存儲(chǔ)值，但數(shù)據(jù)并不是存儲(chǔ)在ThreadLocal對(duì)象中，而是存儲(chǔ)在當(dāng)前調(diào)用該方法的線程對(duì)象中。但從應(yīng)用者的角度來看，我們操作的對(duì)象是ThreadLocal，從設(shè)計(jì)上來說就應(yīng)該為它考慮。

試問一個(gè)問題：如果應(yīng)用程序覺得ThreadLocal對(duì)象的使命完成，將threadLocal ref 設(shè)置為null，如果Entry中引用ThreadLocald對(duì)象的引用類型設(shè)置為強(qiáng)引用的話，會(huì)發(fā)生什么問題？

答案是：ThreadLocal對(duì)象會(huì)無法被垃圾回收器回收，因?yàn)閺膖hread對(duì)象出發(fā)，有強(qiáng)引用指向threadlocal obj。此時(shí)會(huì)違背用戶的初衷，造成所謂的內(nèi)存泄露。

由于ThreadLocalMap中的key是指向ThreadLocal，故從設(shè)計(jì)角度來看，設(shè)計(jì)為弱引用，將不會(huì)干擾用戶的釋放ThreadLocal意圖。

3、大量Entry造成的內(nèi)存溢出問題探討

亮出了自己的觀點(diǎn)，接下來我們?cè)傺由煲幌?，想再來談?wù)劸W(wǎng)絡(luò)上關(guān)于ThreadLocalMap中存儲(chǔ)大量Entry對(duì)象導(dǎo)致的內(nèi)存“泄露”問題。

溫馨提示：本節(jié)僅代表我當(dāng)前的觀點(diǎn)，希望各位讀者朋友們帶著批判與辨證的思維來一起看待問題，而不是人云亦云。

網(wǎng)絡(luò)觀點(diǎn)：在使用ThreadLocal中set方法與remove方法需要成對(duì)執(zhí)行，需要沒有執(zhí)行remove方法會(huì)造成內(nèi)存泄露？甚至造成內(nèi)存溢出？

我的觀點(diǎn)：當(dāng)然能成對(duì)使用當(dāng)然更好，但在實(shí)際情況中，其實(shí)不調(diào)用remove方法也不太容易造成內(nèi)存溢出，因?yàn)閺拇鎯?chǔ)結(jié)構(gòu)來看，除非創(chuàng)建海量線程，并且這些線程都不釋放，導(dǎo)致大量線程內(nèi)部持有的ThreadLocalMap中對(duì)象一直不會(huì)釋放，但一個(gè)線程所持有的Entry對(duì)象個(gè)數(shù)不多，取決于關(guān)聯(lián)的ThreadLocal對(duì)象個(gè)數(shù)，故我們需要的關(guān)注點(diǎn)而不是remove方法，而是防止線程資源泄露。

好了，本文就介紹到這里了，一鍵三連(關(guān)注、點(diǎn)贊、留言)是對(duì)我最大的鼓勵(lì)。

這篇文章來自于我的好基友的公眾號(hào) 「中間件興趣圈」。

他一個(gè)雙非背景，通過中間件技術(shù)分享，輸出12個(gè)源碼分析專欄，出版《RocketMQ技術(shù)內(nèi)幕》一書，榮獲RocketMQ官方社區(qū)優(yōu)秀布道師、CSDN博客之星TOP，在MQ領(lǐng)域有著較大的影響力，他將他日均千億級(jí)消息的MQ運(yùn)維經(jīng)驗(yàn)整理成力電子書：