深入理解ThreadLocal
學習JDK中的類，首先看下JDK API對此類的描述，描述如下：
該類提供了線程局部 (thread-local) 變量。這些變量不同于它們的普通對應物，因為訪問某個變量（通過其 get 或 set 方法）的每個線程都有自己的局部變量，它獨立于變量的初始化副本。ThreadLocal其實就是一個工具類，用來操作線程局部變量，ThreadLocal 實例通常是類中的 private static 字段。它們希望將狀態與某一個線程（例如，用戶 ID 或事務 ID）相關聯。 例如，以下類生成對每個線程唯一的局部標識符。線程 ID 是在第一次調用UniqueThreadIdGenerator.getCurrentThreadId()時分配的，在后續調用中不會更改。
其實ThreadLocal并非是一個線程的本地實現版本，它并不是一個Thread，而是threadlocalvariable(線程局部變量)。也許把它命名為ThreadLocalVar更加合適。線程局部變量(ThreadLocal)其實的功用非常簡單，就是為每一個使用該變量的線程都提供一個變量值的副本，是Java中一種較為特殊的線程綁定機制，是每一個線程都可以獨立地改變自己的副本，而不會和其它線程的副本沖突。
import java.util.concurrent.atomic.AtomicInteger;
public class UniqueThreadIdGenerator {
private static final AtomicInteger uniqueId = new AtomicInteger(0);
private static final ThreadLocal < Integer > uniqueNum =
new ThreadLocal < Integer > () {
@Override protected Integer initialValue() {
return uniqueId.getAndIncrement();
}
};
public static int getCurrentThreadId() {
return uniqueId.get();
}
}
從線程的角度看，每個線程都保持對其線程局部變量副本的隱式引用，只要線程是活動的并且 ThreadLocal 實例是可訪問的；在線程消失之后，其線程局部實例的所有副本都會被垃圾回收（除非存在對這些副本的其他引用）。
API表達了下面幾種觀點：
既然定義為類變量，為何為每個線程維護一個副本（姑且成為‘拷貝’容易理解），讓每個線程獨立訪問？多線程編程的經驗告訴我們，對于線程共享資源（你可以理解為屬性），資源是否被所有線程共享，也就是說這個資源被一個線程修改是否影響另一個線程的運行，如果影響我們需要使用synchronized同步，讓線程順序訪問。
ThreadLocal適用于資源共享但不需要維護狀態的情況，也就是一個線程對資源的修改，不影響另一個線程的運行；這種設計是空間換時間，synchronized順序執行是時間換取空間。
ThreadLocal介紹
從字面上來理解ThreadLocal，感覺就是相當于線程本地的。我們都知道，每個線程在jvm的虛擬機里都分配有自己獨立的空間，線程之間對于本地的空間是相互隔離的。那么ThreadLocal就應該是該線程空間里本地可以訪問的數據了。ThreadLocal變量高效地為每個使用它的線程提供單獨的線程局部變量值的副本。每個線程只能看到與自己相聯系的值，而不知道別的線程可能正在使用或修改它們自己的副本。
很多人看到這里會容易產生一種錯誤的印象，感覺是不是這個ThreadLocal對象建立了一個類似于全局的map，然后每個線程作為map的key來存取對應線程本地的value。你看，每個線程不一樣，所以他們映射到map中的key應該也不一樣。實際上，如果我們后面詳細分析ThreadLocal的代碼時，會發現不是這樣的。它具體是怎么實現的呢？
ThreadLocal源碼
ThreadLocal類本身定義了有get(), set()和initialValue()三個方法。前面兩個方法是public的，initialValue()是protected的，主要用于我們在定義ThreadLocal對象的時候根據需要來重寫。這樣我們初始化這么一個對象在里面設置它的初始值時就用到這個方法。ThreadLocal變量因為本身定位為要被多個線程來訪問，它通常被定義為static變量。
ThreadLocal有一個ThreadLocalMap靜態內部類，你可以簡單理解為一個MAP，這個Map為每個線程復制一個變量的‘拷貝’存儲其中。
當線程調用ThreadLocal.get()方法獲取變量時,首先獲取當前線程引用，以此為key去獲取響應的ThreadLocalMap，如果此‘Map’不存在則初始化一個，否則返回其中的變量，代碼如下：
?public T get() {
Thread t = Thread.currentThread();
ThreadLocalMap map = getMap(t);
if (map != null) {
ThreadLocalMap.Entry e = map.getEntry(this);
if (e != null)
return (T)e.value;
}
return setInitialValue();
}
調用get方法如果此Map不存在首先初始化，創建此map，將線程為key，初始化的vlaue存入其中，注意此處的initialValue，我們可以覆蓋此方法，在首次調用時初始化一個適當的值。setInitialValue代碼如下：
?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;
}
set方法相對比較簡單如果理解以上倆個方法，獲取當前線程的引用，從map中獲取該線程對應的map，如果map存在更新緩存值，否則創建并存儲，代碼如下：
?public void set(T value) {
Thread t = Thread.currentThread();
ThreadLocalMap map = getMap(t);
if (map != null)
map.set(this, value);
else
createMap(t, value);
}
對于ThreadLocal在何處存儲變量副本，我們看getMap方法：獲取的是當前線程的ThreadLocal類型的threadLocals屬性。顯然變量副本存儲在每一個線程中。
?/**
* 獲取線程的ThreadLocalMap 屬性實例
*/
ThreadLocalMap getMap(Thread t) {
return t.threadLocals;
}
上面我們知道變量副本存放于何處，這里我們簡單說下如何被java的垃圾收集機制收集，當我們不在使用時調用set(null)，此時不在將引用指向該‘map’，而線程退出時會執行資源回收操作，將申請的資源進行回收，其實就是將屬性的引用設置為null。這時已經不在有任何引用指向該map，故而會被垃圾收集。
注意：如果ThreadLocal.set()進去的東西本來就是多個線程共享的同一個對象，那么多個線程的ThreadLocal.get()取得的還是這個共享對象本身，還是有并發訪問問題。
看到ThreadLocal類中的變量只有這3個int型：
?/**
* ThreadLocals rely on per-thread linear-probe hash maps attached
* to each thread (Thread.threadLocals and
* inheritableThreadLocals). The ThreadLocal objects act as keys,
* searched via threadLocalHashCode. This is a custom hash code
* (useful only within ThreadLocalMaps) that eliminates collisions
* in the common case where consecutively constructed ThreadLocals
* are used by the same threads, while remaining well-behaved in
* less common cases.
*/
private final int threadLocalHashCode = nextHashCode();
/**
* The next hash code to be given out. Updated atomically. Starts at
* zero.
*/
private static AtomicInteger nextHashCode = new AtomicInteger();
/**
* The difference between successively generated hash codes - turns
* implicit sequential thread-local IDs into near-optimally spread
* multiplicative hash values for power-of-two-sized tables.
*/
private static final int HASH_INCREMENT = 0x61c88647;
而作為ThreadLocal實例的變量只有 threadLocalHashCode 這一個，nextHashCode 和HASH_INCREMENT 是ThreadLocal類的靜態變量，實際上HASH_INCREMENT是一個常量，表示了連續分配的兩個ThreadLocal實例的threadLocalHashCode值的增量，而nextHashCode 的表示了即將分配的下一個ThreadLocal實例的threadLocalHashCode 的值。
現在來看看它的哈希策略。所有ThreadLocal對象共享一個AtomicInteger對象nextHashCode用于計算hashcode，一個新對象產生時它的hashcode就確定了，算法是從0開始，以HASH_INCREMENT = 0x61c88647為間隔遞增，這是ThreadLocal唯一需要同步的地方。根據hashcode定位桶的算法是將其與數組長度-1進行與操作：key.threadLocalHashCode & (table.length - 1)。
0x61c88647這個魔數是怎么確定的呢？
ThreadLocalMap的初始長度為16，每次擴容都增長為原來的2倍，即它的長度始終是2的n次方，上述算法中使用0x61c88647可以讓hash的結果在2的n次方內盡可能均勻分布，減少沖突的概率。
可以來看一下創建一個ThreadLocal實例即new ThreadLocal()時做了哪些操作，從上面看到構造函數ThreadLocal()里什么操作都沒有，唯一的操作是這句：
private final int threadLocalHashCode = nextHashCode();那么nextHashCode()做了什么呢：
?private static synchronized int nextHashCode() {
int h = nextHashCode;
nextHashCode = h + HASH_INCREMENT;
return h;
}
就是將ThreadLocal類的下一個hashCode值即nextHashCode的值賦給實例的threadLocalHashCode，然后nextHashCode的值增加HASH_INCREMENT這個值。
因此ThreadLocal實例的變量只有這個threadLocalHashCode，而且是final的，用來區分不同的ThreadLocal實例，ThreadLocal類主要是作為工具類來使用，那么ThreadLocal.set()進去的對象是放在哪兒的呢？
看一下上面的set()方法，兩句合并一下成為：
ThreadLocalMap map = Thread.currentThread().threadLocals;這個ThreadLocalMap 類是ThreadLocal中定義的內部類，但是它的實例卻用在Thread類中：
?public class Thread implements Runnable {
......
/* ThreadLocal values pertaining to this thread. This map is maintained
* by the ThreadLocal class. */
ThreadLocal.ThreadLocalMap threadLocals = null;
/*
* InheritableThreadLocal values pertaining to this thread. This map is
* maintained by the InheritableThreadLocal class.
*/
ThreadLocal.ThreadLocalMap inheritableThreadLocals = null;
......
}
這就說明了其實每個Thread本身就包含了兩個ThreadLocalMap對象的引用。這一點非常重要。以后每個thread要訪問他們的local對象時，就是訪問存在這個ThreadLocalMap里的value。
ThreadLocalMap是定義在ThreadLocal類內部的私有類，它是采用“開放定址法”解決沖突的hashmap。key是ThreadLocal對象。當調用某個ThreadLocal對象的get或put方法時，首先會從當前線程中取出ThreadLocalMap，然后查找對應的value：
?public T get() {
Thread t = Thread.currentThread();
ThreadLocalMap map = getMap(t); //拿到當前線程的ThreadLocalMap
if (map != null) {
ThreadLocalMap.Entry e = map.getEntry(this); // 以該ThreadLocal對象為key取value
if (e != null)
return (T)e.value;
}
return setInitialValue();
}
ThreadLocalMap getMap(Thread t) {
return t.threadLocals;
}
再看這句：
?if (map != null)
map.set(this, value);
也就是將該ThreadLocal實例作為key，要保持的對象作為值，設置到當前線程的ThreadLocalMap 中，get()方法同樣大家看了代碼也就明白了，ThreadLocalMap 類的代碼太多了，我就不帖了，自己去看源碼吧。
自然想法實現
一個非常自然想法是用一個線程安全的Map<Thread,Object>實現：
?class ThreadLocal {
private Map values = Collections.synchronizedMap(new HashMap());
public Object get() {
Thread curThread = Thread.currentThread();
Object o = values.get(curThread);
if (o == null && !values.containsKey(curThread)) {
o = initialValue();
values.put(curThread, o);
}
return o;
}
public void set(Object newValue) {
values.put(Thread.currentThread(), newValue);
}
}
但這是非常naive的：
JDK 的實現剛好是反過來的：
碰撞解決與神奇的0x61c88647
既然ThreadLocal用map就避免不了沖突的產生。
碰撞避免和解決
這里碰撞其實有兩種類型：
（1）只有一個ThreadLocal實例的時候(上面推薦的做法)，當向thread-local變量中設置多個值的時產生的碰撞，碰撞解決是通過開放定址法， 且是線性探測(linear-probe)。
（2）多個ThreadLocal實例的時候，最極端的是每個線程都new一個ThreadLocal實例，此時利用特殊的哈希碼0x61c88647大大降低碰撞的幾率， 同時利用開放定址法處理碰撞。
神奇的0x61c88647
注意 0x61c88647 的利用主要是為了多個ThreadLocal實例的情況下用的。從ThreadLocal源碼中找出這個哈希碼所在的地方：
?/**
* ThreadLocals rely on per-thread linear-probe hash maps attached
* to each thread (Thread.threadLocals and inheritableThreadLocals).
* The ThreadLocal objects act as keys, searched via threadLocalHashCode.
* This is a custom hash code (useful only within ThreadLocalMaps) that
* eliminates collisions in the common case where consecutively
* constructed ThreadLocals are used by the same threads,
* while remaining well-behaved in less common cases.
*/
private final int threadLocalHashCode = nextHashCode();
/**
* The next hash code to be given out. Updated atomically.
* Starts at zero.
*/
private static AtomicInteger nextHashCode = new AtomicInteger();
/**
* The difference between successively generated hash codes - turns
* implicit sequential thread-local IDs into near-optimally spread
* multiplicative hash values for power-of-two-sized tables.
*/
private static final int HASH_INCREMENT = 0x61c88647;
/**
* Returns the next hash code.
*/
private static int nextHashCode() {
return nextHashCode.getAndAdd(HASH_INCREMENT);
}
注意實例變量threadLocalHashCode, 每當創建ThreadLocal實例時這個值都會累加 0x61c88647, 目的在上面的注釋中已經寫的很清楚了：為了讓哈希碼能均勻的分布在2的N次方的數組里, 即Entry[] table。
下面來看一下ThreadLocal怎么使用的這個threadLocalHashCode哈希碼的，下面是ThreadLocalMap靜態內部類中的set方法的部分代碼：
?// Set the value associated with key.
private void set(ThreadLocal key, Object value) {
Entry[] tab = table;
int len = tab.length;
int i = key.threadLocalHashCode & (len-1);
for (Entry e = tab[i]; e != null;
e = tab[i = nextIndex(i, len)]) {...}
...
key.threadLocalHashCode & (len-1)這么用是什么意思? 先看一下table數組的長度吧：
?/**
* The table, resized as necessary.
* table.length MUST always be a power of two.
*/
private Entry[] table;
哇，ThreadLocalMap 中 Entry[] table 的大小必須是2的N次方呀(len = 2^N)，那 len-1 的二進制表示就是低位連續的N個1， 那 key.threadLocalHashCode & (len-1) 的值就是 threadLocalHashCode 的低N位, 這樣就能均勻的產生均勻的分布? 我用python做個實驗吧：
?>>> HASH_INCREMENT = 0x61c88647
>>> def magic_hash(n):
... for i in range(n):
... nextHashCode = i * HASH_INCREMENT + HASH_INCREMENT
... print nextHashCode & (n - 1),
...
>>> magic_hash(16)
7 14 5 12 3 10 1 8 15 6 13 4 11 2 9 0
>>> magic_hash(32)
7 14 21 28 3 10 17 24 31 6 13 20 27 2 9 16 23 30 5 12 19 26 1 8 15 22 29 4 11 18 25 0
產生的哈希碼分布真的是很均勻，而且沒有任何沖突啊, 太神奇了。
ThreadLocal內存泄漏
很多人認為：threadlocal里面使用了一個存在弱引用的map,當釋放掉threadlocal的強引用以后,map里面的value卻沒有被回收.而這塊value永遠不會被訪問到了. 所以存在著內存泄露. 最好的做法是將調用threadlocal的remove方法。
說的也比較正確,當value不再使用的時候,調用remove的確是很好的做法.但內存泄露一說卻不正確. 這是threadlocal的設計的不得已而為之的問題. 首先,讓我們看看在threadlocal的生命周期中,都存在哪些引用吧. 看下圖: 實線代表強引用,虛線代表弱引用。
每個thread中都存在一個map, map的類型是ThreadLocal.ThreadLocalMap. Map中的key為一個threadlocal實例. 這個Map的確使用了弱引用,不過弱引用只是針對key. 每個key都弱引用指向threadlocal. 當把threadlocal實例tl置為null以后,沒有任何強引用指向threadlocal實例,所以threadlocal將會被gc回收. 但是,我們的value卻不能回收,因為存在一條從current thread連接過來的強引用. 只有當前thread結束以后, current thread就不會存在棧中,強引用斷開, Current Thread, Map, value將全部被GC回收。通過源碼看下此處的實現，如下：
?public void set(T value) {
Thread t = Thread.currentThread();
ThreadLocalMap map = getMap(t);
if (map != null)
map.set(this, value); // 將當前threadLocal實例作為key
else
createMap(t, value);
}
private void set(ThreadLocal key, Object value) {
// We don't use a fast path as with get() because it is at
// least as common to use set() to create new entries as
// it is to replace existing ones, in which case, a fast
// path would fail more often than not.
Entry[] tab = table;
int len = tab.length;
int i = key.threadLocalHashCode & (len-1);
for (Entry e = tab[i];
e != null;
e = tab[i = nextIndex(i, len)]) {
ThreadLocal k = e.get();
if (k == key) {
e.value = value;
return;
}
if (k == null) {
replaceStaleEntry(key, value, i);
return;
}
}
tab[i] = new Entry(key, value); // 構造key-value實例
int sz = ++size;
if (!cleanSomeSlots(i, sz) && sz >= threshold)
rehash();
}
static class Entry extends WeakReference<ThreadLocal> {
/** The value associated with this ThreadLocal. */
Object value;
Entry(ThreadLocal k, Object v) {
super(k); // 構造key弱引用
value = v;
}
}
public T get() {
Thread t = Thread.currentThread();
ThreadLocalMap map = getMap(t);
if (map != null) {
ThreadLocalMap.Entry e = map.getEntry(this);
if (e != null)
return (T)e.value;
}
return setInitialValue();
}
ThreadLocalMap getMap(Thread t) {
return t.threadLocals;
}
從中可以看出,弱引用只存在于key上,所以key會被回收. 而value還存在著強引用.只有thead退出以后,value的強引用鏈條才會斷掉。一旦某個ThreadLocal對象沒有強引用了，它在所有線程內部的ThreadLocalMap中的key都將被GC掉（此時value還未回收），在map后續的get/set中會探測到key被回收的entry，將其 value 設置為 null 以幫助GC，因此 value 在 key 被 GC 后可能還會存活一段時間，但最終也會被回收。這個過程和java.util.WeakHashMap的實現幾乎是一樣的。
因此ThreadLocal本身是沒有內存泄露問題的，通常由它引發的內存泄露問題都是線程只 put 而忘了 remove 導致的，從上面分析可知，即使線程退出了，只要 ThreadLocal 還有強引用，該線程曾經 put 過的東西是不會被回收掉的。
ThreadLocal有何用
很多時候我們會創建一些靜態域來保存全局對象，那么這個對象就可能被任意線程訪問到，如果它是線程安全的，這當然沒什么說的。然而大部分情況下它不是線程安全的（或者無法保證它是線程安全的），尤其是當這個對象的類是由我們自己（或身邊的同事）創建的（很多開發人員對線程的知識都是一知半解，更何況線程安全）。
這時候我們就需要為每個線程都創建一個對象的副本。我們當然可以用ConcurrentMap 來保存這些對象，但問題是當一個線程結束的時候我們如何刪除這個線程的對象副本呢？
ThreadLocal為我們做了一切。首先我們聲明一個全局的ThreadLocal對象（final static，沒錯，我很喜歡final），當我們創建一個新線程并調用threadLocal.get時，threadLocal會調用initialValue方法初始化一個對象并返回，以后無論何時我們在這個線程中調用get方法，都將得到同一個對象（除非期間set過）。而如果我們在另一個線程中調用get，將的到另一個對象，而且始終會得到這個對象。
當一個線程結束了，ThreadLocal就會釋放跟這個線程關聯的對象，這不需要我們關心，反正一切都悄悄地發生了。
（以上敘述只關乎線程，而不關乎get和set是在哪個方法中調用的。以前有很多不理解線程的同學總是問我這個方法是哪個線程，那個方法是哪個線程，我不知如何回答。）
所以，保存”線程局部變量”的map并非是ThreadLocal的成員變量， 而是java.lang.Thread的成員變量。也就是說，線程結束的時候，該map的資源也同時被回收。通過如下代碼：
ThreadLocal的set,get方法中均通過如下方式獲取Map：
ThreadLocalMap map = getMap(t);而getMap方法的代碼如下：
?ThreadLocalMap getMap(Thread t) {
return t.threadLocals;
}
可見：ThreadLocalMap實例是作為java.lang.Thread的成員變量存儲的，每個線程有唯一的一個threadLocalMap。這個map以ThreadLocal對象為key，”線程局部變量”為值，所以一個線程下可以保存多個”線程局部變量”。對ThreadLocal的操作，實際委托給當前Thread，每個Thread都會有自己獨立的ThreadLocalMap實例，存儲的倉庫是Entry[] table；Entry的key為ThreadLocal，value為存儲內容；因此在并發環境下，對ThreadLocal的set或get，不會有任何問題。以下為”線程局部變量”的存儲圖：
由于treadLocalMap是java.util.Thread的成員變量，threadLocal作為threadLocalMap中的key值，在一個線程中只能保存一個”線程局部變量”。將ThreadLocalMap作為Thread類的成員變量的好處是：
- 當線程死亡時，threadLocalMap被回收的同時，保存的”線程局部變量”如果不存在其它引用也可以同時被回收。
- 同一個線程下，可以有多個treadLocal實例，保存多個”線程局部變量”。
- 同一個threadLocal實例，可以有多個線程使用，保存多個線程的“線程局部變量”。
ThreadLocal的應用
我們在多線程的開發中，經常會考慮到的策略是對一些需要公開訪問的屬性通過設置同步的方式來訪問。這樣每次能保證只有一個線程訪問它，不會有沖突。但是這樣做的結果會使得性能和對高并發的支持不夠。在某些情況下，如果我們不一定非要對一個變量共享不可，而是給每個線程一個這樣的資源副本，讓他們可以獨立都各自跑各自的，這樣不是可以大幅度的提高并行度和性能了嗎？
還有的情況是有的數據本身不是線程安全的，或者說它只能被一個線程使用，不能被其他線程同時使用。如果等一個線程使用完了再給另外一個線程使用就根本不現實。這樣的情況下，我們也可以考慮用ThreadLocal。一個典型的情況就是我們連接數據庫的時候通常會用到連接池。而對數據庫的連接不能有多個線程共享訪問。這個時候就需要使用ThreadLocal了。在比較熟悉的兩個框架中，Struts2和Hibernate均有采用ThreadLocal變量，而且對整個框架來說是非常核心的一部分。
Struts2和Struts1的一個重要升級就是對request,response兩個對象的解耦，Struts2的Action方法中不再需要傳遞request,response參數。但是Struts2不通過方法直接傳入request,response對象，那么這兩個值是如何傳遞的呢？
Struts2采用的正是ThreadLocal變量。在每次接收到請求時，Struts2在調用攔截器和action前，通過將request，response對象放入ActionContext實例中，而ActionContext實例是作為”線程局部變量”存入ThreadLocal actionContext中。
?public class ActionContext implements Serializable {
static ThreadLocal actionContext = new ThreadLocal();
. . .
由于actionContext是”線程局部變量”，這樣我們通過ServletActionContext.getRequest()即可獲得本線程的request對象，而且在本地線程的任意類中，均可通過該方法獲取”線程局部變量”，而無需值傳遞，這樣Action類既可以成為一個simple類，無需繼承struts2的任意父類。
在利用Hibernate開發DAO模塊時，我們和Session打的交道最多，所以如何合理的管理Session，避免Session的頻繁創建和銷毀，對于提高系統的性能來說是非常重要的。一般常用的Hibernate工廠類，都會通過ThreadLocal來保存線程的session，這樣我們在同一個線程中的處理，工廠類的getSession()方法，即可以多次獲取同一個Session進行操作，closeSession方法可在不傳入參數的情況下，正確關閉session。
Hiberante的Session 工具類HibernateUtil，這個類是Hibernate官方文檔中HibernateUtil類，用于session管理。如下：
?public class HibernateUtil {
private static Log log = LogFactory.getLog(HibernateUtil.class);
private static final SessionFactory sessionFactory; //定義SessionFactory
static {
try {
// 通過默認配置文件hibernate.cfg.xml創建SessionFactory
sessionFactory = new Configuration().configure().buildSessionFactory();
} catch (Throwable ex) {
log.error("初始化SessionFactory失敗！", ex);
throw new ExceptionInInitializerError(ex);
}
}
//創建線程局部變量session，用來保存Hibernate的Session
public static final ThreadLocal session = new ThreadLocal();
/**
* 獲取當前線程中的Session
* @return Session
* @throws HibernateException
*/
public static Session currentSession() throws HibernateException {
Session s = (Session) session.get();
// 如果Session還沒有打開，則新開一個Session
if (s == null) {
s = sessionFactory.openSession();
session.set(s); //將新開的Session保存到線程局部變量中
}
return s;
}
public static void closeSession() throws HibernateException {
//獲取線程局部變量，并強制轉換為Session類型
Session s = (Session) session.get();
session.set(null);
if (s != null)
s.close();
}
}
在這個類中，由于沒有重寫ThreadLocal的initialValue()方法，則首次創建線程局部變量session其初始值為null，第一次調用currentSession()的時候，線程局部變量的get()方法也為null。因此，對session做了判斷，如果為null，則新開一個Session，并保存到線程局部變量session中，這一步非常的關鍵，這也是“public static final ThreadLocal session = new ThreadLocal()”所創建對象session能強制轉換為Hibernate Session對象的原因。
可以看到在getSession()方法中，首先判斷當前線程中有沒有放進去session，如果還沒有，那么通過sessionFactory().openSession()來創建一個session，再將session set到線程中，實際是放到當前線程的ThreadLocalMap這個map中，這時，對于這個session的唯一引用就是當前線程中的那個ThreadLocalMap，而threadSession作為這個值的key，要取得這個session可以通過threadSession.get()來得到，里面執行的操作實際是先取得當前線程中的ThreadLocalMap，然后將threadSession作為key將對應的值取出。這個session相當于線程的私有變量，而不是public的。
顯然，其他線程中是取不到這個session的，他們也只能取到自己的ThreadLocalMap中的東西。要是session是多個線程共享使用的，那還不亂套了。
試想如果不用ThreadLocal怎么來實現呢？可能就要在action中創建session，然后把session一個個傳到service和dao中，這可夠麻煩的。或者可以自己定義一個靜態的map，將當前thread作為key，創建的session作為值，put到map中，應該也行，這也是一般人的想法，但事實上，ThreadLocal的實現剛好相反，它是在每個線程中有一個map，而將ThreadLocal實例作為key，這樣每個map中的項數很少，而且當線程銷毀時相應的東西也一起銷毀了，不知道除了這些還有什么其他的好處。
典型使用方式
?// 摘自 j.u.c.ThreadLocalRandom
private static final ThreadLocal<ThreadLocalRandom> localRandom = // ThreadLocal對象都是static的，全局共享
new ThreadLocal<ThreadLocalRandom>() { // 初始值
protected ThreadLocalRandom initialValue() {
return new ThreadLocalRandom();
}
};
localRandom.get(); // 拿當前線程對應的對象
localRandom.put(...); // put
ThreadLocal產生的問題
在WEB服務器環境下，由于Tomcat，weblogic等服務器有一個線程池的概念，即接收到一個請求后，直接從線程池中取得線程處理請求；請求響應完成后，這個線程本身是不會結束，而是進入線程池，這樣可以減少創建線程、啟動線程的系統開銷。
由于Tomcat線程池的原因，我最初使用的”線程局部變量”保存的值，在下一次請求依然存在（同一個線程處理），這樣每次請求都是在本線程中取值而不是去memCache中取值，如果memCache中的數據發生變化，也無法及時更新。
解決方案：處理完成后主動調用該業務treadLocal的remove()方法，將”線程局部變量”清空，避免本線程下次處理的時候依然存在舊數據。
Sturts2是如何解決線程池的問題呢？由于web服務器的線程是多次使用的，很顯然Struts2在響應完成后，會主動的清除“線程局部變量”中的ActionContext值，在struts2的org.apache.struts2.dispatcher.ng.filter.StrutsPrepareAndExecuteFilter類中，有這樣的代碼片段：
?finally {
prepare.cleanupRequest(request);
}
而cleanupRequest方法中有如下代碼：
?public void cleanupRequest(HttpServletRequest request) {
……//省略部分代碼
ActionContext.setContext(null);
Dispatcher.setInstance(null);
}
由此可見，Sturts2在處理完成后，會主動清空”線程局部變量”ActionContext，來達到釋放系統資源的目的。
ThreadLocal總結
ThreadLocal使用場合主要解決多線程中數據數據因并發產生不一致問題。ThreadLocal為每個線程的中并發訪問的數據提供一個副本，通過訪問副本來運行業務，這樣的結果是耗費了內存，單大大減少了線程同步所帶來性能消耗，也減少了線程并發控制的復雜度。
ThreadLocal不能使用原子類型，只能使用Object類型。ThreadLocal的使用比synchronized要簡單得多。
ThreadLocal和Synchonized都用于解決多線程并發訪問。但是ThreadLocal與synchronized有本質的區別。synchronized是利用鎖的機制，使變量或代碼塊在某一時該只能被一個線程訪問。而ThreadLocal為每一個線程都提供了變量的副本，使得每個線程在某一時間訪問到的并不是同一個對象，這樣就隔離了多個線程對數據的數據共享。而Synchronized卻正好相反，它用于在多個線程間通信時能夠獲得數據共享。
Synchronized用于線程間的數據共享，而ThreadLocal則用于線程間的數據隔離。
當然ThreadLocal并不能替代synchronized,它們處理不同的問題域。Synchronized用于實現同步機制，比ThreadLocal更加復雜。
總之，ThreadLocal不是用來解決對象共享訪問問題的，而主要是提供了保持對象的方法和避免參數傳遞的方便的對象訪問方式。歸納了兩點：
ThreadLocal建議
本文引用自：http://www.kuqin.com/shuoit/20160421/351682.html
總結
以上是生活随笔為你收集整理的深入理解ThreadLocal的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Spark算子
- 下一篇： 七种常用特征工程技术