ThreadLocal奪命4問(wèn)
本文轉(zhuǎn)載自微信公眾號(hào)「小姐姐味道」，作者小姐姐養(yǎng)的狗 。轉(zhuǎn)載本文請(qǐng)聯(lián)系小姐姐味道公眾號(hào)。
閱讀本文需要首先大體了解ThreadLocal。不啰嗦，直接進(jìn)入正題。
標(biāo)簽：【各種級(jí)別】【Java】【源碼】
1. 問(wèn)
連環(huán)四問(wèn)：
- ThreadLocal的原理?
- 內(nèi)存泄漏的原因?
- InheritableThreadLocal用過(guò)嗎?
- Netty的FastThreadLocal是什么?
2. 分析
ThreadLocal作為實(shí)現(xiàn)“線程封閉”的最主要的編程手段，經(jīng)常被使用。比如，比如，傳統(tǒng)的SimpleDateFormat，不是線程安全的。如果你聲明成全局變量，在并發(fā)環(huán)境下就會(huì)產(chǎn)生時(shí)間錯(cuò)亂。一種好的解決方式，就是使用ThreadLocal。
ThreadLocal使用非常廣泛。比如，Spring的事務(wù)管理，就是通過(guò)它實(shí)現(xiàn)的。但它的弱點(diǎn)也是有的，不能透?jìng)?不能被子線程獲取)，所以催生了InheritableThreadLocal，甚至更高級(jí)的封裝庫(kù)。
3. 答
3.1 ThreadLocal的原理?
看過(guò)源碼就不難回答。如下圖(這張圖最易懂)，ThreadLocal的get和remove方法，只不過(guò)是一個(gè)使用的快捷方式。它的真正數(shù)據(jù)，是存在于線程中的一個(gè)叫做ThreadLocalMap的結(jié)構(gòu)里。
一個(gè)ThreadLocal的值，會(huì)根據(jù)線程的不同，分散在N個(gè)線程中。所以獲取ThreadLocal的Value，有兩個(gè)步驟。
- 第一步，根據(jù)線程獲取Map
- 第二部，根據(jù)自身從Map中獲取值，所以它的this就是Map的Key
這沒什么原理。這就是一個(gè)為了照顧編碼習(xí)慣的數(shù)據(jù)結(jié)構(gòu)。
3.2 內(nèi)存泄漏的原因?
嚴(yán)格來(lái)說(shuō)，ThreadLocal沒有內(nèi)存泄漏問(wèn)題。有的話，那就是你忘記執(zhí)行remove方法。這是不正確使用引起的。
這和其他一些內(nèi)存泄漏的問(wèn)題是一致的，比如：
- 流沒有關(guān)閉
- 連接沒有斷開
- 濫用static map
為什么會(huì)有泄漏問(wèn)題?
如果你不調(diào)用remove方法的話，ThreadLocal所對(duì)應(yīng)的值，就會(huì)存在，一直到當(dāng)前線程的銷毀。
眾所周知，線程的生命周期都比較長(zhǎng)，加上現(xiàn)在普遍使用的線程池，會(huì)讓線程的生命更加長(zhǎng)。不remove，當(dāng)然不會(huì)釋放。這和Key，到底是不是弱引用，關(guān)系不大。
那這種情況，屬不屬于泄漏問(wèn)題，是一個(gè)咬字眼的問(wèn)題。面試的過(guò)程是探討，并不一定要標(biāo)準(zhǔn)的答案。
比起內(nèi)存泄漏問(wèn)題，線程池所引起的數(shù)據(jù)錯(cuò)亂問(wèn)題，更加應(yīng)該引起關(guān)心。因?yàn)榉旁赥hreadLocal的數(shù)據(jù)，肯定不會(huì)很大，泄漏頂多占用一點(diǎn)內(nèi)存而已;而數(shù)據(jù)錯(cuò)亂，可是會(huì)引起業(yè)務(wù)Bug的。
3.3 InheritableThreadLocal用過(guò)嗎?
InheritableThreadLocal在父子線程傳遞值的時(shí)候用到過(guò)，解決了threadlocal不能在父子線程間傳值的問(wèn)題。
這個(gè)在本質(zhì)上，還是通過(guò)Thread來(lái)實(shí)現(xiàn)的。通過(guò)兩個(gè)Map來(lái)進(jìn)行屬性拷貝。
- /* ThreadLocal values pertaining to this thread. This map is maintained
- * by the ThreadLocal class. */
- ThreadLocal.ThreadLocalMap threadLocals = null;
- /*
- * InheritableThreadLocal values pertaining to this thread. This map is
- * maintained by the InheritableThreadLocal class.
- */
- ThreadLocal.ThreadLocalMap inheritableThreadLocals = null;
不要高興太早，對(duì)于使用線程池的情況，由于會(huì)緩存線程，線程是緩存起來(lái)反復(fù)使用的。這時(shí)父子線程關(guān)系的上下文傳遞，已經(jīng)沒有意義。
附加問(wèn)：你如何解決的?
阿里這里有個(gè)庫(kù)，https://github.com/alibaba/transmittable-thread-local 專門解決變量跨線程共享。如果你面的阿里，不妨順便舔一把。
3.4 Netty的FastThreadLocal是什么
既然Java中有了ThreadLocal類了，為什么Netty還自己創(chuàng)建了一個(gè)叫做FastThreadLocal的結(jié)構(gòu)?
我們首先來(lái)看一下ThreadLocal的實(shí)現(xiàn)。
Thread類中，有一個(gè)成員變量threadLocals，存放了與本線程相關(guān)的所有自定義信息。對(duì)這個(gè)變量的定義在Thread類，而操作卻在ThreadLocal類中。
問(wèn)題就出在ThreadLocalMap類上，它雖然叫Map，但卻沒有實(shí)現(xiàn)Map的接口。如圖，ThreadLocalMap在rehash的時(shí)候，并沒有采用類似HashMap的數(shù)組+鏈表+紅黑樹的做法，它只使用了一個(gè)數(shù)組，使用開放尋址(遇到?jīng)_突，依次查找，直到空閑位置)的方法，這種方式是非常低效的。
由于Netty對(duì)ThreadLocal的使用非常頻繁，Netty對(duì)它進(jìn)行了專項(xiàng)的優(yōu)化。它之所以快，是因?yàn)樵诘讓訑?shù)據(jù)結(jié)構(gòu)上做了文章，使用常量下標(biāo)對(duì)元素進(jìn)行定位，而不是使用JDK默認(rèn)的探測(cè)性算法。
底層的InternalThreadLocalMap對(duì)cacheline也做了相應(yīng)的優(yōu)化。
作者簡(jiǎn)介：小姐姐味道 (xjjdog)，一個(gè)不允許程序員走彎路的公眾號(hào)。聚焦基礎(chǔ)架構(gòu)和Linux。十年架構(gòu)，日百億流量，與你探討高并發(fā)世界，給你不一樣的味道。我的個(gè)人微信xjjdog0，歡迎添加好友，進(jìn)一步交流。
