文章目錄

• 概述
• Why 內存泄露 ？
• 在線程池中使用ThreadLocal導致的內存泄漏

---

概述

ThreadLocal的基本使用我們就不贅述了，可以參考

每日一博 - ThreadLocal VS InheritableThreadLocal VS TransmittableThreadLocal

直接進入主題。 我們今天要聊的是使用ThreadLocal會導致內存泄漏的原因，并給出使用ThreadLocal導致內存泄漏的案例及源碼分析。

Why 內存泄露 ？

我們知道 ThreadLocal只是一個工具類，具體存放變量的是線程的threadLocals變量。threadLocals是一個ThreadLocalMap類型的變量

ThreadLocalMap內部是一個Entry數組，Entry繼承自WeakReference，Entry內部的value用來存放通過ThreadLocal的set方法傳遞的值，那么ThreadLocal對象本身存放到哪里了呢？

下面看看Entry的構造函數

/*** The entries in this hash map extend WeakReference, using* its main ref field as the key (which is always a* ThreadLocal object). Note that null keys (i.e. entry.get()* == null) mean that the key is no longer referenced, so the* entry can be expunged from table. Such entries are referred to* as "stale entries" in the code that follows.*/static class Entry extends WeakReference<ThreadLocal<?>> {/** The value associated with this ThreadLocal. */Object value;Entry(ThreadLocal<?> k, Object v) {super(k);value = v;}}

繼續跟進 super(k);

/*** Creates a new weak reference that refers to the given object. The new* reference is not registered with any queue.** @param referent object the new weak reference will refer to*/public WeakReference(T referent) {super(referent);}

繼續 super(referent);

Reference(T referent) {this(referent, null);}Reference(T referent, ReferenceQueue<? super T> queue) {this.referent = referent;this.queue = (queue == null) ? ReferenceQueue.NULL : queue;}

k被傳遞給WeakReference的構造函數，也就是說ThreadLocalMap里面的key為ThreadLocal對象的弱引用，具體就是referent變量引用了ThreadLocal對象，value為具體調用ThreadLocal的set方法時傳遞的值。

• 當一個線程調用ThreadLocal的set方法設置變量時，當前線程的ThreadLocalMap里就會存放一個記錄，這個記錄的key為ThreadLocal的弱引用，value則為設置的值。

• 如果當前線程一直存在且沒有調用ThreadLocal的remove方法，并且這時候在其他地方還有對ThreadLocal的引用，則當前線程的ThreadLocalMap變量里面會存在對ThreadLocal變量的引用和對value對象的引用，它們是不會被釋放的，這就會造成內存泄漏。

• 考慮這個ThreadLocal變量沒有其他強依賴，而當前線程還存在的情況，由于線程的ThreadLocalMap里面的key是弱依賴，所以當前線程的ThreadLocalMap里面的ThreadLocal變量的弱引用會在gc的時候被回收，但是對應的value還是會造成內存泄漏，因為這時候ThreadLocalMap里面就會存在key為null但是value不為null的entry項。

• 其實在ThreadLocal的set、get和remove方法里面可以找一些時機對這些key為null的entry進行清理，但是這些清理不是必須發生的。

下面分析下ThreadLocalMap的remove方法中的清理過程。

/*** Removes the current thread's value for this thread-local* variable. If this thread-local variable is subsequently* {@linkplain #get read} by the current thread, its value will be* reinitialized by invoking its {@link #initialValue} method,* unless its value is {@linkplain #set set} by the current thread* in the interim. This may result in multiple invocations of the* {@code initialValue} method in the current thread.** @since 1.5*/public void remove() {ThreadLocalMap m = getMap(Thread.currentThread());if (m != null)m.remove(this);}

繼續

/*** Remove the entry for key.*/private void remove(ThreadLocal<?> key) {// 1 計算當前ThreadLocal變量所在的table數組位置，嘗試使用快速定位方法Entry[] tab = table;int len = tab.length;int i = key.threadLocalHashCode & (len-1);// 2 這里使用循環是為了防止快速定位失敗后，遍歷table數組for (Entry e = tab[i];e != null;e = tab[i = nextIndex(i, len)]) {// 3 找到if (e.get() == key) {// 4 找到調用WeakReference的clear方法清除對ThreadLocal的弱引用e.clear();// 5 清理key為null的元素expungeStaleEntry(i);return;}}}

代碼（4）調用了Entry的clear方法，實際調用的是父類WeakReference的clear方法，作用是去掉對ThreadLocal的弱引用。

/*** Clears this reference object. Invoking this method will not cause this* object to be enqueued.** <p> This method is invoked only by Java code; when the garbage collector* clears references it does so directly, without invoking this method.*/public void clear() {this.referent = null;}

如下代碼（6）去掉對value的引用，到這里當前線程里面的當前ThreadLocal對象的信息被清理完畢了。

/*** Expunge a stale entry by rehashing any possibly colliding entries* lying between staleSlot and the next null slot. This also expunges* any other stale entries encountered before the trailing null. See* Knuth, Section 6.4** @param staleSlot index of slot known to have null key* @return the index of the next null slot after staleSlot* (all between staleSlot and this slot will have been checked* for expunging).*/private int expungeStaleEntry(int staleSlot) {Entry[] tab = table;int len = tab.length;// expunge entry at staleSlot // 6 去掉對value的引用tab[staleSlot].value = null;tab[staleSlot] = null;size--;// Rehash until we encounter nullEntry e;int i;for (i = nextIndex(staleSlot, len);(e = tab[i]) != null;i = nextIndex(i, len)) {ThreadLocal<?> k = e.get();// 如果key為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;// Unlike Knuth 6.4 Algorithm R, we must scan until// null because multiple entries could have been stale.while (tab[h] != null)h = nextIndex(h, len);tab[h] = e;}}}return i;}

代碼（7）從當前元素的下標開始查看table數組里面是否有key為null的其他元素，有則清理。循環退出的條件是遇到table里面有null的元素。所以這里知道null元素后面的Entry里面key 為null的元素不會被清理。

總結一下：

• ThreadLocalMap的Entry中的key使用的是對ThreadLocal對象的弱引用，這在避免內存泄漏方面是一個進步，因為如果是強引用，即使其他地方沒有對ThreadLocal對象的引用，ThreadLocalMap中的ThreadLocal對象還是不會被回收，而如果是弱引用則ThreadLocal引用是會被回收掉的。

• 但是對應的value還是不能被回收，這時候ThreadLocalMap里面就會存在key為null但是value不為null的entry項，雖然ThreadLocalMap提供了set、get和remove方法，可以在一些時機下對這些Entry項進行清理，但是這是不及時的，也不是每次都會執行，所以在一些情況下還是會發生內存漏，因此在使用完畢后及時調用remove方法才是解決內存泄漏問題的王道。

---

在線程池中使用ThreadLocal導致的內存泄漏

import java.util.concurrent.*;/*** @author 小工匠* @version 1.0* @description: TODO* @date 2021/11/21 8:55* @mark: show me the code , change the world*/ public class ThreadLocalTest {static class LocalVariable {// 模擬大對象private Long[] variable = new Long[1024 * 1024];// byte[] bytes = new byte[1024 * 1024 * 10];}// 1final static ThreadPoolExecutor tpe = new ThreadPoolExecutor(5, 5, 1, TimeUnit.MINUTES,new LinkedBlockingDeque<>());// 2final static ThreadLocal<LocalVariable> tl = new ThreadLocal<LocalVariable>();public static void main(String[] args) throws InterruptedException {// 3for (int i = 0; i < 100; i++) {tpe.submit(()->{// 4tl.set(new LocalVariable());// 5System.out.println("ThreadLocal set完畢");// tl.remove();});Thread.sleep(1000);}// 6System.out.println("線程池執行完畢");} }

• 代碼（1）創建了一個核心線程數和最大線程數都為5的線程池。

-代碼（2）創建了一個ThreadLocal的變量，泛型參數為LocalVariable，LocalVariable內部是一個Long數組。

-代碼（3）向線程池里面放入100個任務。

-代碼（4）設置當前線程的tl變量，也就是把new的LocalVariable變量放入當前線程的threadLocals變量中。

由于沒有調用線程池的shutdown或者shutdownNow方法，所以線程池里面的用戶線程不會退出，進而JVM進程也不會退出。

通過jconsle來看一下內存的狀態

然后去掉localVariable.remove()注釋，

再運行，觀察堆內存變化

從運行結果一 可知，當主線程處于休眠時，

進程占用了大概128.5MB內存，

運行結果二 顯示占用了大概35.1Mb內存，

由此可知運行代碼一時發生了內存泄漏，

下面分析泄露的原因

• 第一次運行代碼時，在設置線程的tl變量后沒有調用tl.remove()方法，這導致線程池里面5個核心線程的threadLocals變量里面的new LocalVariable()實例沒有被釋放。

• 雖然線程池里面的任務執行完了，但是線程池里面的5個線程會一直存在直到JVM進程被殺死。這里需要注意的是，由于tl被聲明為了static變量，雖然在線程的ThreadLocalMap里面對tl進行了弱引用，但是tl不會被回收。

• 第二次運行代碼時，由于線程在設置tl變量后及時調用了tl.remove()方法進行了清理，所以不會存在內存泄漏問題。

總結：如果在線程池里面設置了ThreadLocal變量，則一定要記得及時清理，因為線程池里面的核心線程是一直存在的，如果不清理，線程池的核心線程的threadLocals變量會一直持有ThreadLocal變量。

總結

以上是生活随笔為你收集整理的Java Review - 线程池中使用ThreadLocal不当导致的内存泄漏案例源码分析的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。