一、案例代碼

1、首先看一下代碼，模擬了一個線程數(shù)為500的線程池，所有線程共享一個ThreadLocal變量，每一個線程執(zhí)行的時候插入一個大的List集合：

2、設(shè)置JVM參數(shù)設(shè)置最大內(nèi)存為256M，以便模擬出OOM：

3、運行代碼，輸出結(jié)果：

可以看出，單線程池執(zhí)行到第212的時候，就報了錯誤，出現(xiàn)OOM內(nèi)存溢出錯誤。
4、在運行代碼的時候，同時打開JDK工具jConsole 監(jiān)控內(nèi)存變化：

可以看出，上述內(nèi)存一直遞增到JVM設(shè)置的最大值，然后拋出異常，程序退出。
5、這個實例可以很好的演示了：線程池的一個線程使用完ThreadLocal對象之后，再也不用，由于線程池中的線程不會退出，線程池中的線程的存在，同時ThreadLocal變量也會存在，占用內(nèi)存！造成OOM溢出！

二、ThreadLocal為什么會內(nèi)存泄漏

在上一篇的時候，已經(jīng)簡單的介紹了不正當(dāng)?shù)氖褂肨hreadLocal造成OOM的原因，下邊詳細的介紹一下：
1、首先看一下ThreadLocal的原理圖：
在ThreadLocal的生命周期中，都存在這些引用。看下圖: 實線代表強引用，虛線代表弱引用。

2、ThreadLocal的實現(xiàn)是這樣的：每個Thread 維護一個 ThreadLocalMap 映射表，這個映射表的 key 是 ThreadLocal實例本身，value 是真正需要存儲的 Object。

3、也就是說 ThreadLocal 本身并不存儲值，它只是作為一個 key 來讓線程從 ThreadLocalMap 獲取 value。值得注意的是圖中的虛線，表示 ThreadLocalMap 是使用 ThreadLocal 的弱引用作為 Key 的，弱引用的對象在 GC 時會被回收。

4、ThreadLocalMap使用ThreadLocal的弱引用作為key，如果一個ThreadLocal沒有外部強引用來引用它，那么系統(tǒng) GC 的時候，這個ThreadLocal勢必會被回收，這樣一來，ThreadLocalMap中就會出現(xiàn)key為null的Entry，就沒有辦法訪問這些key為null的Entry的value，如果當(dāng)前線程再遲遲不結(jié)束的話，這些key為null的Entry的value就會一直存在一條強引用鏈：Thread Ref -> Thread -> ThreaLocalMap -> Entry -> value永遠無法回收，造成內(nèi)存泄漏。

5、總的來說就是，ThreadLocal里面使用了一個存在弱引用的map, map的類型是ThreadLocal.ThreadLocalMap. Map中的key為一個threadlocal實例。這個Map的確使用了弱引用，不過弱引用只是針對key。每個key都弱引用指向threadlocal。 當(dāng)把threadlocal實例置為null以后，沒有任何強引用指向threadlocal實例，所以threadlocal將會被gc回收。
但是，我們的value卻不能回收，而這塊value永遠不會被訪問到了，所以存在著內(nèi)存泄露。因為存在一條從current thread連接過來的強引用。只有當(dāng)前thread結(jié)束以后，current thread就不會存在棧中，強引用斷開，Current Thread、Map value將全部被GC回收。最好的做法是將調(diào)用threadlocal的remove方法，這也是等會后邊要說的。

6、其實，ThreadLocalMap的設(shè)計中已經(jīng)考慮到這種情況，也加上了一些防護措施：在ThreadLocal的get(),set(),remove()的時候都會清除線程ThreadLocalMap里所有key為null的value。這一點在上一節(jié)中也講到過！

7、但是這些被動的預(yù)防措施并不能保證不會內(nèi)存泄漏：

（1）使用static的ThreadLocal，延長了ThreadLocal的生命周期，可能導(dǎo)致內(nèi)存泄漏。
（2）分配使用了ThreadLocal又不再調(diào)用get(),set(),remove()方法，那么就會導(dǎo)致內(nèi)存泄漏，因為這塊內(nèi)存一直存在。

三、為什么使用弱引用，OOM是否是弱引用的鍋？

1、從表面上看內(nèi)存泄漏的根源在于使用了弱引用。網(wǎng)上的文章大多著重分析ThreadLocal使用了弱引用會導(dǎo)致內(nèi)存泄漏，但是另一個問題也同樣值得思考：為什么使用弱引用而不是強引用？

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

下面我們分兩種情況討論：

（1）key 使用強引用：引用的ThreadLocal的對象被回收了，但是ThreadLocalMap還持有ThreadLocal的強引用，如果沒有手動刪除，ThreadLocal不會被回收，導(dǎo)致Entry內(nèi)存泄漏。

（2）key 使用弱引用：引用的ThreadLocal的對象被回收了，由于ThreadLocalMap持有ThreadLocal的弱引用，即使沒有手動刪除，ThreadLocal也會被回收。value在下一次ThreadLocalMap調(diào)用set、get、remove的時候會被清除。

比較兩種情況，我們可以發(fā)現(xiàn)：由于ThreadLocalMap的生命周期跟Thread一樣長，如果都沒有手動刪除對應(yīng)key，都會導(dǎo)致內(nèi)存泄漏，但是使用弱引用可以多一層保障：弱引用ThreadLocal不會內(nèi)存泄漏，對應(yīng)的value在下一次ThreadLocalMap調(diào)用set、get、remove的時候會被清除。

因此，ThreadLocal內(nèi)存泄漏的根源是：由于ThreadLocalMap的生命周期跟Thread一樣長，如果沒有手動刪除對應(yīng)key就會導(dǎo)致內(nèi)存泄漏，而不是因為弱引用。

四、ThreadLocal 最佳實踐

1、綜合上面的分析，我們可以理解ThreadLocal內(nèi)存泄漏的前因后果，那么怎么避免內(nèi)存泄漏呢？

答案就是：每次使用完ThreadLocal，都調(diào)用它的remove()方法，清除數(shù)據(jù)。

在使用線程池的情況下，沒有及時清理ThreadLocal，不僅是內(nèi)存泄漏的問題，更嚴重的是可能導(dǎo)致業(yè)務(wù)邏輯出現(xiàn)問題。所以，使用ThreadLocal就跟加鎖完要解鎖一樣，用完就清理。

注意：

并不是所有使用ThreadLocal的地方，都在最后remove（），他們的生命周期可能是需要和項目的生存周期一樣長的，所以要進行恰當(dāng)?shù)倪x擇，以免出現(xiàn)業(yè)務(wù)邏輯錯誤！但首先應(yīng)該保證的是ThreadLocal中保存的數(shù)據(jù)大小不是很大！

2、那么我們修改最開始的代碼為：

取消注釋：threadLocal.remove(); 結(jié)果不會出現(xiàn)OOM，可以看出堆內(nèi)存的變化呈現(xiàn)鋸齒狀，證明每一次remove()之后，ThreadLocal的內(nèi)存釋放掉了！線程池中的線程的數(shù)量持續(xù)增加！

取消注釋：threadLocal.remove(); 結(jié)果不會出現(xiàn)OOM，可以看出堆內(nèi)存的變化呈現(xiàn)鋸齒狀，證明每一次remove()之后，ThreadLocal的內(nèi)存釋放掉了！線程池中的線程的數(shù)量持續(xù)增加！

總結(jié)

以上是生活随笔為你收集整理的ThreadLocal为什么会内存泄漏（java高级面试）的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。