ThreadLocal出現OOM內存溢出的場景和原理分析

一、案例代碼

1、首先看一下代碼,模擬了一個線程數爲500的線程池,所有線程共享一個ThreadLocal變量,每一個線程執行的時候插入一個大的List集合:
這裏寫圖片描述
這裏寫圖片描述

2、設置JVM參數設置最大內存爲256M,以便模擬出OOM:
這裏寫圖片描述

3、運行代碼,輸出結果:
這裏寫圖片描述

可以看出,單線程池執行到第212的時候,就報了錯誤,出現OOM內存溢出錯誤。
4、在運行代碼的時候,同時打開JDK工具jConsole 監控內存變化:
這裏寫圖片描述

可以看出,上述內存一直遞增到JVM設置的最大值,然後拋出異常,程序退出。
5、這個實例可以很好的演示了:線程池的一個線程使用完ThreadLocal對象之後,再也不用,由於線程池中的線程不會退出,線程池中的線程的存在,同時ThreadLocal變量也會存在,佔用內存!造成OOM溢出!

二、ThreadLocal爲什麼會內存泄漏

在上一篇的時候,已經簡單的介紹了不正當的使用ThreadLocal造成OOM的原因,下邊詳細的介紹一下:
1、首先看一下ThreadLocal的原理圖:
在ThreadLocal的生命週期中,都存在這些引用。看下圖: 實線代表強引用,虛線代表弱引用。
這裏寫圖片描述
2、ThreadLocal的實現是這樣的:每個Thread 維護一個 ThreadLocalMap 映射表,這個映射表的 key 是 ThreadLocal實例本身,value 是真正需要存儲的 Object。

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

4、ThreadLocalMap使用ThreadLocal的弱引用作爲key,如果一個ThreadLocal沒有外部強引用來引用它,那麼系統 GC 的時候,這個ThreadLocal勢必會被回收,這樣一來,ThreadLocalMap中就會出現key爲null的Entry,就沒有辦法訪問這些key爲null的Entry的value,如果當前線程再遲遲不結束的話,這些key爲null的Entry的value就會一直存在一條強引用鏈:Thread Ref -> Thread -> ThreaLocalMap -> Entry -> value永遠無法回收,造成內存泄漏。

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

6、其實,ThreadLocalMap的設計中已經考慮到這種情況,也加上了一些防護措施:在ThreadLocal的get(),set(),remove()的時候都會清除線程ThreadLocalMap裏所有key爲null的value。這一點在上一節中也講到過!

7、但是這些被動的預防措施並不能保證不會內存泄漏:

(1)使用static的ThreadLocal,延長了ThreadLocal的生命週期,可能導致內存泄漏。
(2)分配使用了ThreadLocal又不再調用get(),set(),remove()方法,那麼就會導致內存泄漏,因爲這塊內存一直存在。

三、爲什麼使用弱引用,OOM是否是弱引用的鍋?

1、從表面上看內存泄漏的根源在於使用了弱引用。網上的文章大多着重分析ThreadLocal使用了弱引用會導致內存泄漏,但是另一個問題也同樣值得思考:爲什麼使用弱引用而不是強引用?

我們先來看看官方文檔的說法:
這裏寫圖片描述
下面我們分兩種情況討論:

(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 最佳實踐

1、綜合上面的分析,我們可以理解ThreadLocal內存泄漏的前因後果,那麼怎麼避免內存泄漏呢?

答案就是:每次使用完ThreadLocal,都調用它的remove()方法,清除數據。

在使用線程池的情況下,沒有及時清理ThreadLocal,不僅是內存泄漏的問題,更嚴重的是可能導致業務邏輯出現問題。所以,使用ThreadLocal就跟加鎖完要解鎖一樣,用完就清理。

注意:

並不是所有使用ThreadLocal的地方,都在最後remove(),他們的生命週期可能是需要和項目的生存週期一樣長的,所以要進行恰當的選擇,以免出現業務邏輯錯誤!但首先應該保證的是ThreadLocal中保存的數據大小不是很大!

2、那麼我們修改最開始的代碼爲:

取消註釋:threadLocal.remove(); 結果不會出現OOM,可以看出堆內存的變化呈現鋸齒狀,證明每一次remove()之後,ThreadLocal的內存釋放掉了!線程池中的線程的數量持續增加!
這裏寫圖片描述
取消註釋:threadLocal.remove(); 結果不會出現OOM,可以看出堆內存的變化呈現鋸齒狀,證明每一次remove()之後,ThreadLocal的內存釋放掉了!線程池中的線程的數量持續增加!
這裏寫圖片描述
這裏寫圖片描述

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章