原創文章,轉載請務必將下面這段話置於文章開頭處(保留超鏈接)。
本文轉發自技術世界,原文鏈接 http://www.jasongj.com/java/threadlocal/
ThreadLocal解決什么問題
由於 ThreadLocal 支持范型,如 ThreadLocal< StringBuilder >,為表述方便,后文用 變量 代表 ThreadLocal 本身,而用 實例 代表具體類型(如 StringBuidler )的實例。
不恰當的理解
寫這篇文章的一個原因在於,網上很多博客關於 ThreadLocal 的適用場景以及解決的問題,描述的並不清楚,甚至是錯的。下面是常見的對於 ThreadLocal的介紹
ThreadLocal為解決多線程程序的並發問題提供了一種新的思路
ThreadLocal的目的是為了解決多線程訪問資源時的共享問題
還有很多文章在對比 ThreadLocal 與 synchronize 的異同。既然是作比較,那應該是認為這兩者解決相同或類似的問題。
上面的描述,問題在於,ThreadLocal 並不解決多線程 共享 變量的問題。既然變量不共享,那就更談不上同步的問題。
合理的理解
ThreadLoal 變量,它的基本原理是,同一個 ThreadLocal 所包含的對象(對ThreadLocal< String >而言即為 String 類型變量),在不同的 Thread 中有不同的副本(實際是不同的實例,后文會詳細闡述)。這里有幾點需要注意
- 因為每個 Thread 內有自己的實例副本,且該副本只能由當前 Thread 使用。這是也是 ThreadLocal 命名的由來
- 既然每個 Thread 有自己的實例副本,且其它 Thread 不可訪問,那就不存在多線程間共享的問題
- 既無共享,何來同步問題,又何來解決同步問題一說?
那 ThreadLocal 到底解決了什么問題,又適用於什么樣的場景?
This class provides thread-local variables. These variables differ from their normal counterparts in that each thread that accesses one (via its get or set method) has its own, independently initialized copy of the variable. 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).
Each thread holds an implicit reference to its copy of a thread-local variable as long as the thread is alive and the ThreadLocal instance is accessible; after a thread goes away, all of its copies of thread-local instances are subject to garbage collection (unless other references to these copies exist).
核心意思是
ThreadLocal 提供了線程本地的實例。它與普通變量的區別在於,每個使用該變量的線程都會初始化一個完全獨立的實例副本。ThreadLocal 變量通常被
private static
修飾。當一個線程結束時,它所使用的所有 ThreadLocal 相對的實例副本都可被回收。
總的來說,ThreadLocal 適用於每個線程需要自己獨立的實例且該實例需要在多個方法中被使用,也即變量在線程間隔離而在方法或類間共享的場景。后文會通過實例詳細闡述該觀點。另外,該場景下,並非必須使用 ThreadLocal ,其它方式完全可以實現同樣的效果,只是 ThreadLocal 使得實現更簡潔。
ThreadLocal用法
實例代碼
下面通過如下代碼說明 ThreadLocal 的使用方式
1 |
public class ThreadLocalDemo { |
實例分析
ThreadLocal本身支持范型。該例使用了 StringBuilder 類型的 ThreadLocal 變量。可通過 ThreadLocal 的 get() 方法讀取 StringBuidler 實例,也可通過 set(T t) 方法設置 StringBuilder。
上述代碼執行結果如下
1 |
Thread name:thread - 1 , ThreadLocal hashcode:372282300, Instance hashcode:418873098, Value:0 |
從上面的輸出可看出
- 從第1-3行輸出可見,每個線程通過 ThreadLocal 的 get() 方法拿到的是不同的 StringBuilder 實例
- 第1-3行輸出表明,每個線程所訪問到的是同一個 ThreadLocal 變量
- 從7、12、13行輸出以及第30行代碼可見,雖然從代碼上都是對 Counter 類的靜態 counter 字段進行 get() 得到 StringBuilder 實例並追加字符串,但是這並不會將所有線程追加的字符串都放進同一個 StringBuilder 中,而是每個線程將字符串追加進各自的 StringBuidler 實例內
- 對比第1行與第15行輸出並結合第38行代碼可知,使用 set(T t) 方法后,ThreadLocal 變量所指向的 StringBuilder 實例被替換
ThreadLocal原理
ThreadLocal維護線程與實例的映射
既然每個訪問 ThreadLocal 變量的線程都有自己的一個“本地”實例副本。一個可能的方案是 ThreadLocal 維護一個 Map,鍵是 Thread,值是它在該 Thread 內的實例。線程通過該 ThreadLocal 的 get() 方案獲取實例時,只需要以線程為鍵,從 Map 中找出對應的實例即可。該方案如下圖所示
該方案可滿足上文提到的每個線程內一個獨立備份的要求。每個新線程訪問該 ThreadLocal 時,需要向 Map 中添加一個映射,而每個線程結束時,應該清除該映射。這里就有兩個問題:
- 增加線程與減少線程均需要寫 Map,故需保證該 Map 線程安全。雖然從ConcurrentHashMap的演進看Java多線程核心技術一文介紹了幾種實現線程安全 Map 的方式,但它或多或少都需要鎖來保證線程的安全性
- 線程結束時,需要保證它所訪問的所有 ThreadLocal 中對應的映射均刪除,否則可能會引起內存泄漏。(后文會介紹避免內存泄漏的方法)
其中鎖的問題,是 JDK 未采用該方案的一個原因。
Thread維護ThreadLocal與實例的映射
上述方案中,出現鎖的問題,原因在於多線程訪問同一個 Map。如果該 Map 由 Thread 維護,從而使得每個 Thread 只訪問自己的 Map,那就不存在多線程寫的問題,也就不需要鎖。該方案如下圖所示。
該方案雖然沒有鎖的問題,但是由於每個線程訪問某 ThreadLocal 變量后,都會在自己的 Map 內維護該 ThreadLocal 變量與具體實例的映射,如果不刪除這些引用(映射),則這些 ThreadLocal 不能被回收,可能會造成內存泄漏。后文會介紹 JDK 如何解決該問題。
ThreadLocal 在 JDK 8 中的實現
ThreadLocalMap與內存泄漏
該方案中,Map 由 ThreadLocal 類的靜態內部類 ThreadLocalMap 提供。該類的實例維護某個 ThreadLocal 與具體實例的映射。與 HashMap 不同的是,ThreadLocalMap 的每個 Entry 都是一個對 鍵 的弱引用,這一點從super(k)
可看出。另外,每個 Entry 都包含了一個對 值 的強引用。
1 |
static class Entry extends WeakReference<ThreadLocal<?>> { |
使用弱引用的原因在於,當沒有強引用指向 ThreadLocal 變量時,它可被回收,從而避免上文所述 ThreadLocal 不能被回收而造成的內存泄漏的問題。
但是,這里又可能出現另外一種內存泄漏的問題。ThreadLocalMap 維護 ThreadLocal 變量與具體實例的映射,當 ThreadLocal 變量被回收后,該映射的鍵變為 null,該 Entry 無法被移除。從而使得實例被該 Entry 引用而無法被回收造成內存泄漏。
注:Entry雖然是弱引用,但它是 ThreadLocal 類型的弱引用(也即上文所述它是對 鍵 的弱引用),而非具體實例的的弱引用,所以無法避免具體實例相關的內存泄漏。
讀取實例
讀取實例方法如下所示
1 |
public T get() { |
讀取實例時,線程首先通過getMap(t)
方法獲取自身的 ThreadLocalMap。從如下該方法的定義可見,該 ThreadLocalMap 的實例是 Thread 類的一個字段,即由 Thread 維護 ThreadLocal 對象與具體實例的映射,這一點與上文分析一致。
1 |
ThreadLocalMap getMap(Thread t) { |
獲取到 ThreadLocalMap 后,通過map.getEntry(this)
方法獲取該 ThreadLocal 在當前線程的 ThreadLocalMap 中對應的 Entry。該方法中的 this 即當前訪問的 ThreadLocal 對象。
如果獲取到的 Entry 不為 null,從 Entry 中取出值即為所需訪問的本線程對應的實例。如果獲取到的 Entry 為 null,則通過setInitialValue()
方法設置該 ThreadLocal 變量在該線程中對應的具體實例的初始值。
設置初始值
設置初始值方法如下
1 |
private T setInitialValue() { |
該方法為 private 方法,無法被重載。
首先,通過initialValue()
方法獲取初始值。該方法為 public 方法,且默認返回 null。所以典型用法中常常重載該方法。上例中即在內部匿名類中將其重載。
然后拿到該線程對應的 ThreadLocalMap 對象,若該對象不為 null,則直接將該 ThreadLocal 對象與對應實例初始值的映射添加進該線程的 ThreadLocalMap中。若為 null,則先創建該 ThreadLocalMap 對象再將映射添加其中。
這里並不需要考慮 ThreadLocalMap 的線程安全問題。因為每個線程有且只有一個 ThreadLocalMap 對象,並且只有該線程自己可以訪問它,其它線程不會訪問該 ThreadLocalMap,也即該對象不會在多個線程中共享,也就不存在線程安全的問題。
設置實例
除了通過initialValue()
方法設置實例的初始值,還可通過 set 方法設置線程內實例的值,如下所示。
1 |
public void set(T value) { |
該方法先獲取該線程的 ThreadLocalMap 對象,然后直接將 ThreadLocal 對象(即代碼中的 this)與目標實例的映射添加進 ThreadLocalMap 中。當然,如果映射已經存在,就直接覆蓋。另外,如果獲取到的 ThreadLocalMap 為 null,則先創建該 ThreadLocalMap 對象。
防止內存泄漏
對於已經不再被使用且已被回收的 ThreadLocal 對象,它在每個線程內對應的實例由於被線程的 ThreadLocalMap 的 Entry 強引用,無法被回收,可能會造成內存泄漏。
針對該問題,ThreadLocalMap 的 set 方法中,通過 replaceStaleEntry 方法將所有鍵為 null 的 Entry 的值設置為 null,從而使得該值可被回收。另外,會在 rehash 方法中通過 expungeStaleEntry 方法將鍵和值為 null 的 Entry 設置為 null 從而使得該 Entry 可被回收。通過這種方式,ThreadLocal 可防止內存泄漏。
1 |
private void set(ThreadLocal<?> key, Object value) { |
適用場景
如上文所述,ThreadLocal 適用於如下兩種場景
- 每個線程需要有自己單獨的實例
- 實例需要在多個方法中共享,但不希望被多線程共享
對於第一點,每個線程擁有自己實例,實現它的方式很多。例如可以在線程內部構建一個單獨的實例。ThreadLocal 可以以非常方便的形式滿足該需求。
對於第二點,可以在滿足第一點(每個線程有自己的實例)的條件下,通過方法間引用傳遞的形式實現。ThreadLocal 使得代碼耦合度更低,且實現更優雅。
案例
對於 Java Web 應用而言,Session 保存了很多信息。很多時候需要通過 Session 獲取信息,有些時候又需要修改 Session 的信息。一方面,需要保證每個線程有自己單獨的 Session 實例。另一方面,由於很多地方都需要操作 Session,存在多方法共享 Session 的需求。如果不使用 ThreadLocal,可以在每個線程內構建一個 Session實例,並將該實例在多個方法間傳遞,如下所示。
1 |
public class SessionHandler { |
該方法是可以實現需求的。但是每個需要使用 Session 的地方,都需要顯式傳遞 Session 對象,方法間耦合度較高。
這里使用 ThreadLocal 重新實現該功能如下所示。
1 |
public class SessionHandler { |
使用 ThreadLocal 改造后的代碼,不再需要在各個方法間傳遞 Session 對象,並且也非常輕松的保證了每個線程擁有自己獨立的實例。
如果單看其中某一點,替代方法很多。比如可通過在線程內創建局部變量可實現每個線程有自己的實例,使用靜態變量可實現變量在方法間的共享。但如果要同時滿足變量在線程間的隔離與方法間的共享,ThreadLocal再合適不過。
總結
- ThreadLocal 並不解決線程間共享數據的問題
- ThreadLocal 通過隱式的在不同線程內創建獨立實例副本避免了實例線程安全的問題
- 每個線程持有一個 Map 並維護了 ThreadLocal 對象與具體實例的映射,該 Map 由於只被持有它的線程訪問,故不存在線程安全以及鎖的問題
- ThreadLocalMap 的 Entry 對 ThreadLocal 的引用為弱引用,避免了 ThreadLocal 對象無法被回收的問題
- ThreadLocalMap 的 set 方法通過調用 replaceStaleEntry 方法回收鍵為 null 的 Entry 對象的值(即為具體實例)以及 Entry 對象本身從而防止內存泄漏
- ThreadLocal 適用於變量在線程間隔離且在方法間共享的場景