[Java併發包學習七]解密ThreadLocal

轉自：

http://qifuguang.me/2015/09/02/[Java%E5%B9%B6%E5%8F%91%E5%8C%85%E5%AD%A6%E4%B9%A0%E4%B8%

概述

相信讀者在網上也看了很多關於ThreadLocal的資料，很多博客都這樣說：ThreadLocal爲解決多線程程序的併發問題提供了一種新的思路；ThreadLocal的目的是爲了解決多線程訪問資源時的共享問題。如果你也這樣認爲的，那現在給你10秒鐘，清空之前對ThreadLocal的錯誤的認知！

看看JDK中的源碼是怎麼寫的：

This class provides thread-local variables. These variables differ from
their normal counterparts in that each thread that accesses one (via its
{@code get} or {@code set} method) has its own, independently initialized
copy of the variable. {@code ThreadLocal} instances are typically private
static fields in classes that wish to associate state with a thread (e.g.,
a user ID or Transaction ID).

翻譯過來大概是這樣的(英文不好，如有更好的翻譯，請留言說明)：

ThreadLocal類用來提供線程內部的局部變量。這種變量在多線程環境下訪問(通過get或set方法訪問)時能保證各個線程裏的變量相對獨立於其他線程內的變量。ThreadLocal實例通常來說都是private static類型的，用於關聯線程和線程的上下文。

可以總結爲一句話：ThreadLocal的作用是提供線程內的局部變量，這種變量在線程的生命週期內起作用，減少同一個線程內多個函數或者組件之間一些公共變量的傳遞的複雜度。
舉個例子，我出門需要先坐公交再做地鐵，這裏的坐公交和坐地鐵就好比是同一個線程內的兩個函數，我就是一個線程，我要完成這兩個函數都需要同一個東西：公交卡（北京公交和地鐵都使用公交卡），那麼我爲了不向這兩個函數都傳遞公交卡這個變量（相當於不是一直帶着公交卡上路），我可以這麼做：將公交卡事先交給一個機構，當我需要刷卡的時候再向這個機構要公交卡（當然每次拿的都是同一張公交卡）。這樣就能達到只要是我(同一個線程)需要公交卡，何時何地都能向這個機構要的目的。

有人要說了：你可以將公交卡設置爲全局變量啊，這樣不是也能何時何地都能取公交卡嗎？但是如果有很多個人（很多個線程）呢？大家可不能都使用同一張公交卡吧(我們假設公交卡是實名認證的)，這樣不就亂套了嘛。現在明白了吧？這就是ThreadLocal設計的初衷：提供線程內部的局部變量，在本線程內隨時隨地可取，隔離其他線程。

ThreadLocal基本操作

構造函數

ThreadLocal的構造函數簽名是這樣的：

1 2 3 4 5 6

/** * Creates a thread local variable. * @see #withInitial(java.util.function.Supplier) */ public ThreadLocal() { }

內部啥也沒做。

initialValue函數

initialValue函數用來設置ThreadLocal的初始值，函數簽名如下：

1 2 3

protected T initialValue() { return null; }

該函數在調用get函數的時候會第一次調用，但是如果一開始就調用了set函數，則該函數不會被調用。通常該函數只會被調用一次，除非手動調用了remove函數之後又調用get函數，這種情況下，get函數中還是會調用initialValue函數。該函數是protected類型的，很顯然是建議在子類重載該函數的，所以通常該函數都會以匿名內部類的形式被重載，以指定初始值，比如：

1 2 3 4 5 6 7 8 9 10 11 12 13 14

package com.winwill.test; /** * @author qifuguang * @date 15/9/2 00:05 */ public class TestThreadLocal { private static final ThreadLocal<Integer> value = new ThreadLocal<Integer>() { @Override protected Integer initialValue() { return Integer.valueOf(1); } }; }

get函數

該函數用來獲取與當前線程關聯的ThreadLocal的值，函數簽名如下：

1	public T get()

如果當前線程沒有該ThreadLocal的值，則調用initialValue函數獲取初始值返回。

set函數

set函數用來設置當前線程的該ThreadLocal的值，函數簽名如下：

1	public void set(T value)

設置當前線程的ThreadLocal的值爲value。

remove函數

remove函數用來將當前線程的ThreadLocal綁定的值刪除，函數簽名如下：

1	public void remove()

在某些情況下需要手動調用該函數，防止內存泄露。

代碼演示

學習了最基本的操作之後，我們用一段代碼來演示ThreadLocal的用法，該例子實現下面這個場景：

有5個線程，這5個線程都有一個值value，初始值爲0，線程運行時用一個循環往value值相加數字。

代碼實現：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36

package com.winwill.test; /** * @author qifuguang * @date 15/9/2 00:05 */ public class TestThreadLocal { private static final ThreadLocal<Integer> value = new ThreadLocal<Integer>() { @Override protected Integer initialValue() { return 0; } }; public static void main(String[] args) { for (int i = 0; i < 5; i++) { new Thread(new MyThread(i)).start(); } } static class MyThread implements Runnable { private int index; public MyThread(int index) { this.index = index; } public void run() { System.out.println("線程" + index + "的初始value:" + value.get()); for (int i = 0; i < 10; i++) { value.set(value.get() + i); } System.out.println("線程" + index + "的累加value:" + value.get()); } } }

執行結果爲：

線程0的初始value:0
線程3的初始value:0
線程2的初始value:0
線程2的累加value:45
線程1的初始value:0
線程3的累加value:45
線程0的累加value:45
線程1的累加value:45
線程4的初始value:0
線程4的累加value:45

可以看到，各個線程的value值是相互獨立的，本線程的累加操作不會影響到其他線程的值，真正達到了線程內部隔離的效果。

如何實現的

看了基本介紹，也看了最簡單的效果演示之後，我們更應該好好研究下ThreadLocal內部的實現原理。如果給你設計，你會怎麼設計？相信大部分人會有這樣的想法：

每個ThreadLocal類創建一個Map，然後用線程的ID作爲Map的key，實例對象作爲Map的value，這樣就能達到各個線程的值隔離的效果。

沒錯，這是最簡單的設計方案，JDK最早期的ThreadLocal就是這樣設計的。JDK1.3（不確定是否是1.3）之後ThreadLocal的設計換了一種方式。

我們先看看JDK8的ThreadLocal的get方法的源碼:

1 2 3 4 5 6 7 8 9 10 11 12 13

public T get() { Thread t = Thread.currentThread(); ThreadLocalMap map = getMap(t); if (map != null) { ThreadLocalMap.Entry e = map.getEntry(this); if (e != null) { @SuppressWarnings("unchecked") T result = (T)e.value; return result; } } return setInitialValue(); }

其中getMap的源碼：

1 2 3

ThreadLocalMap getMap(Thread t) { return t.threadLocals; }

setInitialValue函數的源碼：

1 2 3 4 5 6 7 8 9 10

private T setInitialValue() { T value = initialValue(); Thread t = Thread.currentThread(); ThreadLocalMap map = getMap(t); if (map != null) map.set(this, value); else createMap(t, value); return value; }

createMap函數的源碼：

1 2 3

void createMap(Thread t, T firstValue) { t.threadLocals = new ThreadLocalMap(this, firstValue); }

簡單解析一下，get方法的流程是這樣的：

1. 首先獲取當前線程
2. 根據當前線程獲取一個Map
3. 如果獲取的Map不爲空，則在Map中以ThreadLocal的引用作爲key來在Map中獲取對應的value e，否則轉到5
4. 如果e不爲null，則返回e.value，否則轉到5
5. Map爲空或者e爲空，則通過initialValue函數獲取初始值value，然後用ThreadLocal的引用和value作爲firstKey和firstValue創建一個新的Map

然後需要注意的是Thread類中包含一個成員變量：

1	ThreadLocal.ThreadLocalMap threadLocals = null;

所以，可以總結一下ThreadLocal的設計思路：
每個Thread維護一個ThreadLocalMap映射表，這個映射表的key是ThreadLocal實例本身，value是真正需要存儲的Object。
這個方案剛好與我們開始說的簡單的設計方案相反。查閱了一下資料，這樣設計的主要有以下幾點優勢：

• 這樣設計之後每個Map的Entry數量變小了：之前是Thread的數量，現在是ThreadLocal的數量，能提高性能，據說性能的提升不是一點兩點(沒有親測)
• 當Thread銷燬之後對應的ThreadLocalMap也就隨之銷燬了，能減少內存使用量。

再深入一點

先交代一個事實：ThreadLocalMap是使用ThreadLocal的弱引用作爲Key的：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

static class ThreadLocalMap { /** * 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; } } ... ... }

下圖是本文介紹到的一些對象之間的引用關係圖，實線表示強引用，虛線表示弱引用：

然後網上就傳言，ThreadLocal會引發內存泄露，他們的理由是這樣的：

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

我們來看看到底會不會出現這種情況。
其實，在JDK的ThreadLocalMap的設計中已經考慮到這種情況，也加上了一些防護措施，下面是ThreadLocalMap的getEntry方法的源碼：

1 2 3 4 5 6 7 8

private Entry getEntry(ThreadLocal<?> key) { int i = key.threadLocalHashCode & (table.length - 1); Entry e = table[i]; if (e != null && e.get() == key) return e; else return getEntryAfterMiss(key, i, e); }

getEntryAfterMiss函數的源碼：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

private Entry getEntryAfterMiss(ThreadLocal<?> key, int i, Entry e) { Entry[] tab = table; int len = tab.length; while (e != null) { ThreadLocal<?> k = e.get(); if (k == key) return e; if (k == null) expungeStaleEntry(i); else i = nextIndex(i, len); e = tab[i]; } return null; }

expungeStaleEntry函數的源碼：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35

private int expungeStaleEntry(int staleSlot) { Entry[] tab = table; int len = tab.length; // expunge entry at staleSlot tab[staleSlot].value = null; tab[staleSlot] = null; size--; // Rehash until we encounter null Entry e; int i; for (i = nextIndex(staleSlot, len); (e = tab[i]) != null; i = nextIndex(i, len)) { ThreadLocal<?> k = e.get(); 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; }

整理一下ThreadLocalMap的getEntry函數的流程：

1. 首先從ThreadLocal的直接索引位置(通過ThreadLocal.threadLocalHashCode & (len-1)運算得到)獲取Entry e，如果e不爲null並且key相同則返回e；
2. 如果e爲null或者key不一致則向下一個位置查詢，如果下一個位置的key和當前需要查詢的key相等，則返回對應的Entry，否則，如果key值爲null，則擦除該位置的Entry，否則繼續向下一個位置查詢

在這個過程中遇到的key爲null的Entry都會被擦除，那麼Entry內的value也就沒有強引用鏈，自然會被回收。仔細研究代碼可以發現，set操作也有類似的思想，將key爲null的這些Entry都刪除，防止內存泄露。
但是光這樣還是不夠的，上面的設計思路依賴一個前提條件：要調用ThreadLocalMap的genEntry函數或者set函數。這當然是不可能任何情況都成立的，所以很多情況下需要使用者手動調用ThreadLocal的remove函數，手動刪除不再需要的ThreadLocal，防止內存泄露。所以JDK建議將ThreadLocal變量定義成private static的，這樣的話ThreadLocal的生命週期就更長，由於一直存在ThreadLocal的強引用，所以ThreadLocal也就不會被回收，也就能保證任何時候都能根據ThreadLocal的弱引用訪問到Entry的value值，然後remove它，防止內存泄露。