深入分析 ThreadLocal 記憶體洩漏問題
前言
ThreadLocal 的作用是提供執行緒內的區域性變數，這種變數線上程的生命週期內起作用，減少同一個執行緒內多個函式或者元件之間一些公共變數的傳遞的複雜度。但是如果濫用ThreadLocal，就可能會導致記憶體洩漏。下面，我們將圍繞三個方面來分析ThreadLocal 記憶體洩漏的問題
ThreadLocal實現原理ThreadLocal為什麼會記憶體洩漏ThreadLocal最佳實踐
ThreadLocal 實現原理
ThreadLocal
ThreadLocal的實現是這樣的：每個Thread 維護一個 ThreadLocalMap 對映表，這個對映表的 key
ThreadLocal例項本身，value 是真正需要儲存的 Object。
也就是說 ThreadLocal 本身並不儲存值，它只是作為一個 key 來讓執行緒從 ThreadLocalMap 獲取 value。值得注意的是圖中的虛線，表示 ThreadLocalMap 是使用 ThreadLocal 的弱引用作為 Key 的，弱引用的物件在 GC 時會被回收。
ThreadLocal為什麼會記憶體洩漏
ThreadLocalMap使用ThreadLocal的弱引用作為key，如果一個ThreadLocal沒有外部強引用來引用它，那麼系統 GC 的時候，這個ThreadLocal
ThreadLocalMap中就會出現key為null的Entry，就沒有辦法訪問這些key為null的Entry的value，如果當前執行緒再遲遲不結束的話，這些key為null的Entry的value就會一直存在一條強引用鏈：Thread Ref -> Thread -> ThreaLocalMap -> Entry -> value永遠無法回收，造成記憶體洩漏。
其實，ThreadLocalMap的設計中已經考慮到這種情況，也加上了一些防護措施：在ThreadLocal的get(),set(),remove()的時候都會清除執行緒ThreadLocalMap
key為null的value。
但是這些被動的預防措施並不能保證不會記憶體洩漏：
- 使用
static的ThreadLocal，延長了ThreadLocal的生命週期，可能導致的記憶體洩漏（參考ThreadLocal 記憶體洩露的例項分析）。 - 分配使用了
ThreadLocal又不再呼叫get(),set(),remove()方法，那麼就會導致記憶體洩漏。
為什麼使用弱引用
從表面上看記憶體洩漏的根源在於使用了弱引用。網上的文章大多著重分析ThreadLocal使用了弱引用會導致記憶體洩漏，但是另一個問題也同樣值得思考：為什麼使用弱引用而不是強引用？
我們先來看看官方文件的說法：
To help deal with very large and long-lived usages, the hash table entries use WeakReferences for keys.
為了應對非常大和長時間的用途，雜湊表使用弱引用的 key。
下面我們分兩種情況討論：
- key 使用強引用：引用的
ThreadLocal的物件被回收了，但是ThreadLocalMap還持有ThreadLocal的強引用，如果沒有手動刪除，ThreadLocal不會被回收，導致Entry記憶體洩漏。 - key 使用弱引用：引用的
ThreadLocal的物件被回收了，由於ThreadLocalMap持有ThreadLocal的弱引用，即使沒有手動刪除，ThreadLocal也會被回收。value在下一次ThreadLocalMap呼叫set,get，remove的時候會被清除。
比較兩種情況，我們可以發現：由於ThreadLocalMap的生命週期跟Thread一樣長，如果都沒有手動刪除對應key，都會導致記憶體洩漏，但是使用弱引用可以多一層保障：弱引用ThreadLocal不會記憶體洩漏，對應的value在下一次ThreadLocalMap呼叫set,get,remove的時候會被清除。
因此，ThreadLocal記憶體洩漏的根源是：由於ThreadLocalMap的生命週期跟Thread一樣長，如果沒有手動刪除對應key就會導致記憶體洩漏，而不是因為弱引用。
ThreadLocal 最佳實踐
綜合上面的分析，我們可以理解ThreadLocal記憶體洩漏的前因後果，那麼怎麼避免記憶體洩漏呢？
- 每次使用完
ThreadLocal，都呼叫它的remove()方法，清除資料。
在使用執行緒池的情況下，沒有及時清理ThreadLocal，不僅是記憶體洩漏的問題，更嚴重的是可能導致業務邏輯出現問題。所以，使用ThreadLocal就跟加鎖完要解鎖一樣，用完就清理。