深入分析ThreadLocal內存泄漏問題

魏可源

ThreadLocal的作用是提供線程內的局部變量，這種變量在線程的生命周期內起作用，減少同一個線程內多個函數或者組件之間一些公共變量傳遞的復雜度。但是如果濫用ThreadLocal，就可能會導致內存泄漏。

下面，我們將圍繞三個方面來分析ThreadLocal內存泄漏的問題：

1. ThreadLocal實現原理

2. ThreadLocal為什么會內存泄漏

3. 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。

但是這些被動的預防措施并不能保證不會內存泄漏：

1.使用static的ThreadLocal，延長了ThreadLocal的生命周期，可能導致的內存泄漏。

2.分配使用了ThreadLocal又不再調用get（），set（），remove（）方法，那么就會導致內存泄漏。

為什么使用弱引用

從表面上看內存泄漏的根源在于使用了弱引用，但是另一個問題也同樣值得思考：為什么使用弱引用而不是強引用？

我們先來看看官方文檔的說法：

為了應對非常大和長時間的用途，哈希表使用弱引用的

key。（To help deal with verylarge and long-lived usages， the hash table entries use WeakReferences for keys.）

下面分兩種情況討論：

1. key使用強引用：引用的ThreadLocal的對象被回收了，但是ThreadLocalMap還持有ThreadLocal的強引用，如果沒有手動刪除，ThreadLocal不會被回收，導致Entry內存泄漏。

2. 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就跟加鎖完要解鎖一樣，所以用完就一定要清理。