前言

在分析ThreadLocal導致的內(nèi)存泄露前，需要普及了解一下內(nèi)存泄露、強引用與弱引用以及GC回收機制，這樣才能更好的分析為什么ThreadLocal會導致內(nèi)存泄露呢？更重要的是知道該如何避免這樣情況發(fā)生，增強系統(tǒng)的健壯性。

內(nèi)存泄露

內(nèi)存泄露為程序在申請內(nèi)存后，無法釋放已申請的內(nèi)存空間，一次內(nèi)存泄露危害可以忽略，但內(nèi)存泄露堆積后果很嚴重，無論多少內(nèi)存,遲早會被占光，

廣義并通俗的說，就是：不再會被使用的對象或者變量占用的內(nèi)存不能被回收，就是內(nèi)存泄露。

強引用與弱引用

強引用，使用最普遍的引用，一個對象具有強引用，不會被垃圾回收器回收。當內(nèi)存空間不足，Java虛擬機寧愿拋出OutOfMemoryError錯誤，使程序異常終止，也不回收這種對象。

如果想取消強引用和某個對象之間的關聯(lián)，可以顯式地將引用賦值為null，這樣可以使JVM在合適的時間就會回收該對象。

弱引用，JVM進行垃圾回收時，無論內(nèi)存是否充足，都會回收被弱引用關聯(lián)的對象。在java中，用java.lang.ref.WeakReference類來表示。可以在緩存中使用弱引用。

GC回收機制-如何找到需要回收的對象

JVM如何找到需要回收的對象，方式有兩種：

• 引用計數(shù)法：每個對象有一個引用計數(shù)屬性，新增一個引用時計數(shù)加1，引用釋放時計數(shù)減1，計數(shù)為0時可以回收，
• 可達性分析法：從 GC Roots 開始向下搜索，搜索所走過的路徑稱為引用鏈。當一個對象到 GC Roots 沒有任何引用鏈相連時，則證明此對象是不可用的，那么虛擬機就判斷是可回收對象。

引用計數(shù)法，可能會出現(xiàn)A 引用了 B，B 又引用了 A，這時候就算他們都不再使用了，但因為相互引用 計數(shù)器=1 永遠無法被回收。

ThreadLocal的內(nèi)存泄露分析

先從前言的了解了一些概念（已懂忽略），接下來我們開始正式的來理解ThreadLocal導致的內(nèi)存泄露的解析。

實現(xiàn)原理

static class ThreadLocalMap {static class Entry extends WeakReference<ThreadLocal<?>> {/** The value associated with this ThreadLocal. */Object value;Entry(ThreadLocal<?> k, Object v) {super(k);value = v;}}...}

ThreadLocal的實現(xiàn)原理，每一個Thread維護一個ThreadLocalMap，key為使用弱引用的ThreadLocal實例，value為線程變量的副本。這些對象之間的引用關系如下,

實心箭頭表示強引用，空心箭頭表示弱引用

ThreadLocal 內(nèi)存泄漏的原因

從上圖中可以看出，hreadLocalMap使用ThreadLocal的弱引用作為key，如果一個ThreadLocal不存在外部強引用時，Key(ThreadLocal)勢必會被GC回收，這樣就會導致ThreadLocalMap中key為null， 而value還存在著強引用，只有thead線程退出以后,value的強引用鏈條才會斷掉。

但如果當前線程再遲遲不結束的話，這些key為null的Entry的value就會一直存在一條強引用鏈：

Thread Ref -> Thread -> ThreaLocalMap -> Entry -> value

永遠無法回收，造成內(nèi)存泄漏。

那為什么使用弱引用而不是強引用？？

我們看看Key使用的

key 使用強引用

當hreadLocalMap的key為強引用回收ThreadLocal時，因為ThreadLocalMap還持有ThreadLocal的強引用，如果沒有手動刪除，ThreadLocal不會被回收，導致Entry內(nèi)存泄漏。

key 使用弱引用

當ThreadLocalMap的key為弱引用回收ThreadLocal時，由于ThreadLocalMap持有ThreadLocal的弱引用，即使沒有手動刪除，ThreadLocal也會被回收。當key為null，在下一次ThreadLocalMap調(diào)用set(),get()，remove()方法的時候會被清除value值。

ThreadLocalMap的remove()分析

在這里只分析remove()方式，其他的方法可以查看源碼進行分析：

private void remove(ThreadLocal<?> key) {//使用hash方式，計算當前ThreadLocal變量所在table數(shù)組位置Entry[] tab = table;int len = tab.length;int i = key.threadLocalHashCode & (len-1);//再次循環(huán)判斷是否在為ThreadLocal變量所在table數(shù)組位置for (Entry e = tab[i];e != null;e = tab[i = nextIndex(i, len)]) {if (e.get() == key) {//調(diào)用WeakReference的clear方法清除對ThreadLocal的弱引用e.clear();//清理key為null的元素expungeStaleEntry(i);return;}} }

再看看清理key為null的元素expungeStaleEntry(i):

private int expungeStaleEntry(int staleSlot) {Entry[] tab = table;int len = tab.length;// 根據(jù)強引用的取消強引用關聯(lián)規(guī)則，將value顯式地設置成null，去除引用tab[staleSlot].value = null;tab[staleSlot] = null;size--;// 重新hash，并對table中key為null進行處理Entry e;int i;for (i = nextIndex(staleSlot, len);(e = tab[i]) != null;i = nextIndex(i, len)) {ThreadLocal<?> k = e.get();//對table中key為null進行處理,將value設置為null，清除value的引用if (k == null) {e.value = null;tab[i] = null;size--;} else {int h = k.threadLocalHashCode & (len - 1);if (h != i) {tab[i] = null;while (tab[h] != null)h = nextIndex(h, len);tab[h] = e;}}}return i; }

總結

由于Thread中包含變量ThreadLocalMap，因此ThreadLocalMap與Thread的生命周期是一樣長，如果都沒有手動刪除對應key，都會導致內(nèi)存泄漏。

但是使用弱引用可以多一層保障：弱引用ThreadLocal不會內(nèi)存泄漏，對應的value在下一次ThreadLocalMap調(diào)用set(),get(),remove()的時候會被清除。

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

ThreadLocal正確的使用方法

• 每次使用完ThreadLocal都調(diào)用它的remove()方法清除數(shù)據(jù)
• 將ThreadLocal變量定義成private static，這樣就一直存在ThreadLocal的強引用，也就能保證任何時候都能通過ThreadLocal的弱引用訪問到Entry的value值，進而清除掉 。

作者：Ccww
原文鏈接：https://juejin.im/post/5e184276e51d4557e86e8afd

總結

以上是生活随笔為你收集整理的弱引用什么时候被回收_ThreadLocal的内存泄露？什么原因？如何避免？的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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