[[421387]]

本文轉(zhuǎn)載自微信公眾號「yes的練級攻略」，作者是Yes呀。轉(zhuǎn)載本文請聯(lián)系yes的練級攻略公眾號。

你好，我是yes。

繼上一篇之后我把 ThreadLocal 能問的，都寫了，咱們再來盤一盤 FastThreadLocal ，這個算是 ThreadLocal 的進(jìn)階版，是 Netty 針對 ThreadLocal 自己造的輪子，所以對 ThreadLocal 沒有完全理解的話，建議先看上一篇文章，打個基礎(chǔ)。

那了解 FastThreadLocal 之后呢，對平日的一些優(yōu)化可能可以提供一些思路，或者面試就能裝個x。

面試官：ThreadLocal 竟然有xxx這個缺點，那怎么優(yōu)化啊?

你就把 FastThreadLocal 的實現(xiàn) BB 一遍，這不就穩(wěn)妥了嘛!

所以，今天我們就來看看 Netty 是如何實現(xiàn) FastThreadLocal 的，話不多說，本文大綱如下：

• 數(shù)數(shù) ThreadLocal 的缺點。
• 應(yīng)該如何針對 ThreadLocal 缺點改進(jìn)?
• FastThreadLocal 的原理。
• FastThreadLocal VS ThreadLocal 的實操。

這篇下來，進(jìn)階版 ThreadLocal 基本拿下，下篇我會基于這篇做一個延伸，一個比較底層的延伸，屬于絕對裝x的那種，等下看文章你就知道了，我會埋坑的，哈哈。

預(yù)告一下，這篇是個長文，源碼也有點多，但是耐心看完肯定會有收獲的。

發(fā)車發(fā)車!

數(shù)數(shù) ThreadLocal 的缺點

看完上篇文章的同學(xué)，應(yīng)該都很清楚了 ThreadLocal 的一個缺點：hash 沖突用的是線性探測法，效率低。

可以看到，圖上顯示的是經(jīng)過兩個遍歷找到了空位，假設(shè)沖突多了，需要遍歷的次數(shù)就多了。并且下次 get 的時候，hash 直接命中的位置發(fā)現(xiàn)不是要找的 Entry ，于是就接著遍歷向后找，所以說這個效率低。

而像 HashMap 是通過鏈表法來解決沖突，并且為了防止鏈表過長遍歷的開銷變大，在一定條件之后又會轉(zhuǎn)變成紅黑樹來查找，這樣的解決方案在頻繁沖突的條件下，肯定是優(yōu)于線性探測法，所以這是一個優(yōu)化方向。

不過 FastThreadLocal 不是這樣優(yōu)化的，我們下面再說。

還有一個缺點是 ThreadLocal 使用了 WeakReference 以保證資源可以被釋放，但是這可能會產(chǎn)生一些 Etnry 的 key 為 null，即無用的 Entry 存在。

所以調(diào)用 ThreadLocal 的 get 或 set 方法時，會主動清理無用的 Entry，減輕內(nèi)存泄漏的發(fā)生。

這其實等于把清理的開銷弄到了 get 和 set 上，萬一 get 的時候清理的無用 Entry 特別多，那這次 get 相對而言就比較慢了。

還有一個就是內(nèi)存泄漏的問題了，當(dāng)然這個問題只存在于用線程池使用的時候，并且上面也提到了 get 和 set 的時候也能清理一些無用的 Key，所以沒有那么的夸張，只要記得用完后調(diào)用 ThreadLocal#remove 就不會有內(nèi)存泄漏的問題了。

大致就這么幾點。

應(yīng)該如何針對 ThreadLocal 缺點改進(jìn)

所以怎么改呢?

前面提到 ThreadLocal hash 沖突的線性探測法不好，還有 Entry 的弱引用可能會發(fā)生內(nèi)存泄漏，這些都和 ThreadLocalMap 有關(guān)，所以需要搞個新的 map 來替換 ThreadLocalMap。

而這個 ThreadLocalMap 又是 Thread 里面的一個成員變量，這么一看 Thread 也得動一動，但是我們又無法修改 Thread 的代碼，所以配套的還得弄個新的 Thread。

所以我們不僅得弄個新的 ThreadLocal、ThreadLocalMap 還得弄個配套的 Thread 來用上新的 ThreadLocalMap 。

所以如果想改進(jìn) ThreadLocal ，就需要動這三個類。

對應(yīng)到 Netty 的實現(xiàn)就是 FastThreadLocal、InternalThreadLocalMap、FastThreadLocalThread

然后發(fā)散一下思維，既然 Hash 沖突的想線性探測效果不好，你可能比較容易想到的就是上面提到的鏈表法，然后再基于鏈表法說個改成紅黑樹，這個確實是一方面，但是可以再想想。

比如，讓 Hash 不沖突，所以設(shè)計一個不會沖突的 hash 算法?不存在的!

所以怎么樣才不會產(chǎn)生沖突呢?

各自取號入座

什么意思?就是每往 InternalThreadLocalMap 中塞入一個新的 FastThreadLocal 對象，就給這個對象發(fā)個唯一的下標(biāo)，然后讓這個對象記住這個下標(biāo)，到時候去 InternalThreadLocalMap 找 value 的時候，直接通過下標(biāo)去取對應(yīng)的 value 。

這樣不就不會沖突了?

這就是 FastThreadLocal 給出的方案，具體下面分析。

還有個內(nèi)存泄漏的問題，這個其實只要規(guī)范的使用即用完后 remove 就好了，其實也沒太好的解決方案，不過 FastThreadLocal 曲線救國了一下，這個也且看下面的分析!

FastThreadLocal 的原理

以下 Netty 基于 4.1 版本分析

先來看下 FastThreadLocal 的定義：

可以看到有個叫 variablesToRemoveIndex 的類成員，并且用 final 修飾的，所以等于每個 FastThreadLocal 都有個共同的不可變 int 值，值為多少等下分析。

然后看到這個 index 沒，在 FastThreadLocal 構(gòu)造的時候就被賦值了，且也被 final 修飾，所以也不可變，這個 index 就是我上面說的給每個新 FastThreadLocal 都發(fā)個唯一的下標(biāo)，這樣每個 index 就都知道自己的位置了。

上面兩個 index 都是通過 InternalThreadLocalMap.nextVariableIndex() 賦值的，盲猜一下，這個肯定是用原子類遞增實現(xiàn)的。

我們來看一下實現(xiàn)：

確實，在 InternalThreadLocalMap 也定義了一個靜態(tài)原子類，每次調(diào)用 nextVariableIndex 就返回且遞增，沒有什么別的賦值操作，從這里也可以得知 variablesToRemoveIndex 的值為 0，因為它屬于常量賦值，第一次調(diào)用時 nextIndex 的值為 0 。

看到這，不知道大家是否已經(jīng)感覺到一絲不對勁了。好像有點浪費空間的意思，我們繼續(xù)往下看。

InternalThreadLocalMap 對標(biāo)的就是之前的 ThreadLocalMap 也就是 ThreadLocal 缺點集中的類，需要重點看下。

我們再來回顧一下 ThreadLocalMap 的定義。

它是個 Entry 數(shù)組，然后 Entry 里面弱引用了 ThreadLocal 作為 Key。

而 InternalThreadLocalMap 有點不太一樣：

可以看到， InternalThreadLocalMap 好像放棄了 map 的形式，沒用定義 key 和 value，而是一個 Object 數(shù)組?

那它是如何通過 Object 來存儲 FastThreadLocal 和對應(yīng)的 value 的呢?我們從 FastThreadLocal#set 開始分析：

因為我們已經(jīng)熟悉 ThreadLocal 的套路，所以我們知道 InternalThreadLocalMap 肯定是 FastThreadLocalThread 里面的一個變量。

然后我們從對應(yīng)的 FastThreadLocalThread 里面拿到了 map 之后，就要執(zhí)行塞入操作即 setKnownNotUnset。

我們先看一下塞入操作里面的 setIndexedVariable 方法：

可以看到，根據(jù)傳入構(gòu)造 FastThreadLocal 生成的唯一 index 可以直接從 Object 數(shù)組里面找到下標(biāo)并且進(jìn)行替換，這樣一來壓根就不會產(chǎn)生沖突，邏輯很簡單，完美。

那如果塞入的 value 不是 UNSET(默認(rèn)值)，則執(zhí)行 addToVariablesToRemove 方法，這個方法又有什么用呢?

是不是看著有點奇怪?這是啥操作?別急，看我畫個圖來解釋解釋：

這就是 Object 數(shù)組的核心關(guān)系圖了，第一個位置放了一個 set ，set 里面存儲了所有使用的 FastThreadLocal 對象，然后數(shù)組后面的位置都放 value。

那為什么要放一個 set 保存所有使用的 FastThreadLocal 對象?

用于刪除，你想想看，假設(shè)現(xiàn)在要清空線程里面的所有 FastThreadLocal ，那必然得有一個地方來存放這些 FastThreadLocal 對象，這樣才能找到這些家伙，然后干掉。

所以剛好就把數(shù)組的第一個位置騰出來放一個 set 來保存這些 FastThreadLocal 對象，如果要刪除全部 FastThreadLocal 對象的時候，只需要遍歷這個 set ，得到 FastThreadLocal 的 index 找到數(shù)組對應(yīng)的 位置將 value 置空，然后把 FastThreadLocal 從 set 中移除即可。

剛好 FastThreadLocal 里面實現(xiàn)了這個方法，我們來看下：

圖片內(nèi)容可能有點多了，我們做下小結(jié)，理一理上面說的：

首先 InternalThreadLocalMap 沒有采用 ThreadLocalMap k-v形式的存儲方式，而是用 Object 數(shù)組來存儲 FastThreadLocal 對象和其 value，具體是在第一個位置存放了一個包含所使用的 FastThreadLocal 對象的 set，然后后面存儲所有的 value。

之所以需要個 set 是為了存儲所有使用的 FastThreadLocal 對象，這樣就能找到這些對象，便于后面的刪除工作。

之所以數(shù)組其他位置可以直接存儲 value ，是因為每個 FastThreadLocal 構(gòu)造的時候已經(jīng)被分配了一個唯一的下標(biāo)，這個下標(biāo)對應(yīng)的就是 value 所處的下標(biāo)。

看到這里，不知道大家是否有感受到空間的浪費?

我舉個例子。

假設(shè)系統(tǒng)里面一個 new 了 100 個 FastThreadLocal ，那第 100 個 FastThreadLocal 的下標(biāo)就是 100 ，這個應(yīng)該沒有疑義。

從上面的 set 方法可以得知，只有調(diào)用 set 的時候，才會從當(dāng)前線程中拿出 InternalThreadLocalMap ，然后往這個 map 的數(shù)組里面塞入 value，這里我們再回顧一下 set 的方法。

那這里是什么意思呢?

如果我這個線程之前都沒塞過 FastThreadLocal ，此時要塞入第一個 FastThreadLocal ，構(gòu)造出來的數(shù)組長度是32，但是這個 FastThreadLocal 的下標(biāo)已經(jīng)漲到了 100 了，所以這個線程第一次塞值，也僅僅只有這么一個值，數(shù)組就需要擴容。

看到?jīng)]，這就是我所說的浪費，空間被浪費了。

Netty 相關(guān)實現(xiàn)者知道這樣會浪費空間，所以數(shù)組的擴容是基于 index 而不是原先數(shù)組的大小，你看看如果是基于原先數(shù)組的擴容，那么第一次擴容 2 倍，32 變成 64，還是塞不下下標(biāo) 100 的數(shù)據(jù)，所以還得擴容一次，這就不美了。

所以可以看到擴容傳進(jìn)去的參數(shù)是 index 。

可以看到，直接基于 index 的向上 2 次冪取整。然后就是擴容的拷貝，這里是直接進(jìn)行數(shù)組拷貝，不需要進(jìn)行 rehash，而 ThreadLocalMap 的擴容需要進(jìn)行rehash，也就是重新基于 key 的 hash 值進(jìn)行位置的分配，所以這個也是 FastThreadLocal 優(yōu)于ThreadLocal 的一個點。

對了，上面那個向上 2 次冪取整的操作，不知道你們熟悉不熟悉，這個和 HashMap 的實現(xiàn)是一致的。

咳咳，但是我沒有證據(jù)，只能說優(yōu)秀的代碼，就是源遠(yuǎn)流長。

所以從上面的實現(xiàn)可以得知 Netty 就是特意這樣設(shè)計的，用多余的空間去換取不會沖突的 set 和 get ，這樣寫入和獲取的速度就更快了，這就是典型的空間換時間。

好了，想必此時你已經(jīng)弄懂了 FastThreadLocal 的核心原理了，我們再來看看 get 方法的實現(xiàn)，我想你應(yīng)該能腦補這個實現(xiàn)了。

是吧，沒啥難度，index 就是 FastThreadLocal 構(gòu)造時候預(yù)先分配好的那個下標(biāo)，然后直接進(jìn)行一個數(shù)組下標(biāo)查找，如果沒找到就調(diào)用 init 方法進(jìn)行初始化。

我們這里再繼續(xù)探究一下InternalThreadLocalMap.get()，這里面做了一個兼容。不過我要先介紹一下 FastThreadLocalThread ，就是這玩意替代了 Thread。

可以看到它繼承了 Thread ，并且弄了一個成員變量就是我們前面說的 InternalThreadLocalMap。

然后我們再來看一下 get 方法，我截了好幾個，不過邏輯很簡單。

這里之所以分了 fastGet 和 slowGet 是為了做一個兼容，假設(shè)有個不熟悉的人，他用了 FastThreadLocal 但是沒有配套使用 FastThreadLocalThread ，然后調(diào)用 FastThreadLocal#get 的時候去 Thread 里面找 InternalThreadLocalMap 那不就傻了嗎，會報錯的。

所以就再弄了個 slowThreadLocalMap ，它是個 ThreadLocal ，里面保存 InternalThreadLocalMap 來兼容一下這個情況。

從這里我們也能得知，F(xiàn)astThreadLocal 最好和 FastThreadLocalThread 配套使用，不然就隔了一層了。

FastThreadLocal<String> threadLocal = new FastThreadLocal<String>(); 
Thread t = new FastThreadLocalThread(new Runnable() { //記得要 new FastThreadLocalThread 
     public void run() { 
      threadLocal.get()； 
      .... 
     } 
 }); 

好了，get 和 set 這兩個核心操作都分析完了，我們最后再來看一下 remove 操作吧。

很簡單對吧，把數(shù)組里的 value 給覆蓋了，然后再到 set 里把對應(yīng)的 FastThreadLocal 對象給刪了。

不過看到這里，可能有人會發(fā)出疑惑，內(nèi)存泄漏相關(guān)的點呢?

其實吧，可以看到 FastThreadLocal 就沒用弱引用，所以它把無用 FastThreadLocal 的清理就寄托到規(guī)范使用上，即沒用了就主動調(diào)用 remove 方法。

但是它曲線救國了一下，我們來看一下 FastThreadLocalRunnable 這個類：

我已經(jīng)把重點畫出來了，可以看到這個 Runnable 執(zhí)行完畢之后，會主動調(diào)用 FastThreadLocal.removeAll() 來清理所有的 FastThreadLocal，這就是我說的曲線救國，怕你完了調(diào)用 remove ，沒事我?guī)湍惴庋b一下，就是這么貼心。

當(dāng)然，這個前提是你不能用 Runnable 而是用 FastThreadLocalRunnable。不過這里 Netty 也是做了封裝的。

Netty 實現(xiàn)了一個 DefaultThreadFactory 工廠類來創(chuàng)建線程。

你看，你傳入 Runnable 是吧，沒事，我把它包成 FastThreadLocalRunnable，并且我 new 回去的線程是 FastThreadLocalThread 類型，這樣就能在很大程度上避免使用的錯誤，也減少了使用的難度。

這也是工廠方法這個設(shè)計模式的好處之一啦。所以工程上如果怕對方?jīng)]用對，我們就封裝了再給別人使用，這樣也屏蔽了一些細(xì)節(jié)，他好你也好。

所以說多看看開源框架的源碼，有很多可以學(xué)習(xí)的地方!好了，F(xiàn)astThreadLocal 原理大致就說到這里。

FastThreadLocal VS ThreadLocal

到此，我們已經(jīng)充分了解了兩者之間的不同，但是 Fast 到底有多 Fast 呢?

我們用實驗說話，Netty 源碼里面已經(jīng)有 benchmark 了，我們直接跑就行了

里面有兩個實驗：

FastPath 對應(yīng)的是使用 FastThreadLocalThread 線程對象。

SlowPath 對應(yīng)的是使用 Thread 線程對象。

兩個實驗都是分別定義了 ThreadLocal 和 FastThreadLocal ：

我們來看一下執(zhí)行的結(jié)果：

FastPath:

SlowPath:

可以看到搭配 FastThreadLocalThread 來使用 FastThreadLocal 吞吐確實比使用 ThreadLocal 大，但是好像也沒大太多?

不過，我在網(wǎng)上有看別比人的 benchmark 對比，同樣的代碼，他的結(jié)果是大了三倍。

我反正又跑了幾遍，每次都比原生的 ThreadLocal 吞吐好，但是也沒好那么多...有點奇怪。

至于 FastThreadLocal 搭配 Thread 則吞吐比 ThreadLocal 都少，說明 FastThreadLocal 的使用必須得搭配 FastThreadLocalThread ，不然就是反向優(yōu)化了。

代碼在 netty 的 microbench 這個項目里，有興趣的可以自己 down 下來跑一跑看看。

最后

我們再來總結(jié)一下：

• FastThreadLocal 通過分配下標(biāo)直接定位 value ，不會有 hash 沖突，效率較高。
• FastThreadLocal 采用空間換時間的方式來提高效率。
• FastThreadLocal 需要配套 FastThreadLocalThread 使用，不然還不如原生 ThreadLocal。
• FastThreadLocal 使用最好配套 FastThreadLocalRunnable，這樣執(zhí)行完任務(wù)后會主動調(diào)用 removeAll 來移除所有 FastThreadLocal ，防止內(nèi)存泄漏。
• FastThreadLocal 的使用也是推薦用完之后，主動調(diào)用 remove。

這就是 Netty 實現(xiàn)的加強版 ThreadLocal，如果你看過 Netty 源碼，你會發(fā)現(xiàn)內(nèi)部是有挺多使用 ThreadLocal 的場景，所以這個優(yōu)化還是有必要的。

并且 Netty work 線程池默認(rèn)線程數(shù)是兩倍 CPU 核心數(shù)，所以線程不會太多，那么空間的浪費其實也不會很多，所以這波空間換時間影響不大。

好了，文章就到這了。挖個坑，我在 InternalThreadLocalMap 這個類里面發(fā)現(xiàn)了一些奇怪的 long 變量。

懂行的同學(xué)看著可能知道，這是為了填充 Cache Line，避免偽共享問題的產(chǎn)生。

ok ，那為什么被標(biāo)記了@deprecated?并且說將來的版本要被移除?

且聽下回分解。