前言
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。
但是這些被動的預防措施並不能保證不會內存泄漏：
- 使用線程池的時候，這個線程執行任務結束，
ThreadLocal對象被回收了，線程放回線程池中不銷毀，這個線程一直不被使用，導致內存泄漏。 - 分配使用了
ThreadLocal又不再調用get(),set(),remove()方法，那么這個期間就會發生內存泄漏。
為什么使用弱引用
從表面上看內存泄漏的根源在於使用了弱引用。網上的文章大多着重分析為什么會內存泄漏，但是另一個問題也同樣值得思考：為什么使用弱引用？為什么不用強引用？
我們先來看看官方文檔的說法：
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的時候會被清除。
比較兩種情況，我們可以發現：由於ThreadLocalMap的生命周期跟Thread一樣長，如果都沒有手動刪除對應key，都會導致內存泄漏，但是使用弱引用可以多一層保障：弱引用ThreadLocal不會內存泄漏，對應的value在下一次ThreadLocalMap調用set,get,remove的時候會被清除。
因此，ThreadLocal內存泄漏的根源是：由於ThreadLocalMap的生命周期跟Thread一樣長，如果沒有手動刪除對應key就會導致內存泄漏，而不是因為弱引用。
ThreadLocal 最佳實踐
綜合上面的分析，我們可以理解ThreadLocal內存泄漏的前因后果，那么怎么避免內存泄漏呢？
- 每次使用完
ThreadLocal，都調用它的remove()方法，清除數據。
在使用線程池的情況下，沒有及時清理ThreadLocal，不僅是內存泄漏的問題，更嚴重的是可能導致業務邏輯出現問題。所以，使用ThreadLocal就跟加鎖完要解鎖一樣，用完就清理。
為什么會導致業務邏輯出錯：
當ThreadLocal用於線程池、web應用或者線程被多次重復使用的時候，特別要注意，以web應用為例：
我們都知道web應用很多類都是單例模式，如spring默認注入方式所創建的類就是一個單例，當不同的http請求到達服務器的時候，實際上都是使用了同一個實例，假如該實例使用了全局變量，當請求A修改了這個變量，后面到來的其它請求（此時不管A請求是否結束），如請求B再使用該變量的時候，實際上是被請求A修改過的，這會導致業務邏輯出錯，而且很難被發現，這種情況，通常是使用ThreadLocal來解決，因為不同的請求雖然使用了同一個實例，但所使用的線程卻不同，但有一點需要特別注意，那就是web容器的線程是重復使用的，web容器使用了線程池，當一個請求使用完某個線程，該線程會放回線程池被其它請求使用，這就導致一個問題，不同的請求還是有可能會使用到同一個線程（只要請求數量大於線程數量），而ThreadLocal是屬於線程的，如果我們使用完ThreadLocal對象而沒有手動刪掉，那么后面的請求就有機會使用到被使用過的ThreadLocal對象，如果一個請求在使用ThreadLocal的時候，是先get()來判斷然后再set()，那就會有問題，因為get到的是別的請求set的內容，如果一個請求每次使用ThreadLocal，都是先set再get，那就不會有問題，因為一個線程同一時刻只被一個請求使用，只要我們每次使用之前，都設置成自己想要的內容，那就不會在使用的過程中被覆蓋。使用ThreadLocal最好是每次使用完就調用remove方法，將其刪掉，避免先get后set的情況導致業務的錯誤。