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