服了，一個ThreadLocal被問出了花
一、故事
地鐵上，小帥無力地倚靠著桿子，腦子里盡是剛才面試官的奪命連環問，“用過TheadLocal么？ThreadLocal是如何解決共享變量訪問的安全性的呢？你覺得啥場景下會用到TheadLocal? 我們在日常用ThreadLocal的時候需要注意什么？ThreadLocal在高并發場景下會造成內存泄漏嗎？為什么？如何避免？......”
這些問題，如同陰影一般，在小帥的腦海里揮之不去。
是的，他萬萬沒想到，自詡“多線程小能手”的他栽在了ThreadLocal上。
這是小帥苦投了半個月簡歷之后才拿到的面試機會，然而又喪失了。當下行情實在是卷到了極點。
都兩個月了，面試機會少，居然還每次都被問翻，這樣下去真要回老家另謀出路了，小帥內心五味成雜......
小伙伴們，試問一下，如果是你，面對上述的問題，你能否對答如流呢？
二、概要
既然被問到了，那么作為事后諸葛的老貓就和大家一起來接面試官的招吧。
我們將從以下點來全面剖析一下ThreadLocal。
概覽
三、基本篇
1.什么是ThreadLocal？
ThreadLocal英文翻譯過來就是：線程本地量，它其實是一種線程的隔離機制，保障了多線程環境下對于共享變量訪問的安全性。
看到上面的定義之后，那么問題就來了，ThreadLocal是如何解決共享變量訪問的安全性的呢？
其實ThreadLocal為變量在每個線程中都創建了一個副本，那么每個線程可以訪問自己內部的副本變量。由于副本都歸屬于各自的線程，所以就不存在多線程共享的問題了。
便于理解，我們看一下下圖。
結構圖
至于上述圖中提及的threadLocals(ThreadLocalMap)，我們后文看源代碼的時候再繼續來看。大家心中暫時有個概念。
既然都是保證線程訪問的安全性，那么和Synchronized區別是什么呢？
在上面聊到共享變量訪問安全性的問題上，其實大家還會很容易想起另外一個關鍵字Synchronized。聊聊區別吧，整理了一張圖，看起來可能會更加直觀一些，如下。
對比
通過上圖，我們發現ThreadLocal其實是一種線程隔離機制。Synchronized則是一種基于Happens-Before規則里的監視器鎖規則從而保證同一個時刻只有一個線程能夠對共享變量進行更新。
Synchronized加鎖會帶來性能上的下降。ThreadLocal采用了空間換時間的設計思想，也就是說每個線程里面都有一個專門的容器來存儲共享變量的副本信息，然后每個線程只對自己的變量副本做相對應的更新操作，這樣避免了多線程鎖競爭的開銷。
2.ThreadLocal的使用
上面說了這么多，咱們來使用一下。就拿SimpleDateFormat來做個例子。當然也會有一道這樣的面試題，SimpleDateFormat是否是線程安全的？在阿里Java開發規約中，有強制性地提到SimpleDateFormat 是線程不安全的類。其實主要的原因是由于多線程操作SimpleDateFormat中的Calendar對象引用，然后出現臟讀導致的。
踩坑代碼：
/**
* @author 公眾號：程序員老貓
* @date 2024/2/1 22:58
*/
public class DateFormatTest {
private static final SimpleDateFormat simpleDateFormat =
new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
public static Date parse(String dateString) {
Date date = null;
try {
date = simpleDateFormat.parse(dateString);
} catch (ParseException e) {
e.printStackTrace();
}
return date;
}
public static void main(String[] args) {
ExecutorService executorService = Executors.newFixedThreadPool(20);
for (int i = 0; i < 20; i++) {
executorService.execute(()->{
System.out.println(parse("2024-02-01 23:34:30"));
});
}
executorService.shutdown();
}
}上述咱們通過線程池的方式針對SimpleDateFormat進行了測試。其輸出結果如下。
我們可以看到剛開始好好的，后面就異常了。
我們通過ThreadLocal的方式將其優化一下。代碼如下：
/**
* @author 公眾號：程序員老貓
* @date 2024/2/1 22:58
*/
public class DateFormatTest {
private static final ThreadLocal<SimpleDateFormat> dateFormatThreadLocal =
ThreadLocal.withInitial(() -> new SimpleDateFormat("yyyy-MM-dd HH:mm:ss"));
public static Date parse(String dateString) {
Date date = null;
try {
date = dateFormatThreadLocal.get().parse(dateString);
} catch (ParseException e) {
e.printStackTrace();
}
return date;
}
public static void main(String[] args) {
ExecutorService executorService = Executors.newFixedThreadPool(10);
for (int i = 0; i < 20; i++) {
executorService.execute(()->{
System.out.println(parse("2024-02-01 23:34:30"));
});
}
executorService.shutdown();
}
}運行了一下,完全正常了。
Thu Feb 01 23:34:30 CST 2024
Thu Feb 01 23:34:30 CST 2024
Thu Feb 01 23:34:30 CST 2024
Thu Feb 01 23:34:30 CST 2024
Thu Feb 01 23:34:30 CST 2024
Thu Feb 01 23:34:30 CST 2024
Thu Feb 01 23:34:30 CST 2024
Thu Feb 01 23:34:30 CST 2024
Thu Feb 01 23:34:30 CST 20243.TheadLocal使用場景
那么我們什么時候會用到ThreadLocal呢？
上面針對SimpleDateFormat的封裝也算是一個吧。
- 用來替代參數鏈傳遞：在編寫API接口時，可以將需要傳遞的參數放入ThreadLocal中，從而不需要在每個調用的方法上都顯式地傳遞這些參數。這種方法雖然不如將參數封裝為對象傳遞來得常見，但在某些情況下可以簡化代碼結構。
- 數據庫連接和會話管理：在某些應用中，如Web應用程序，ThreadLocal可以用來保持對數據庫連接或會話的管理，以簡化并發控制并提高性能。例如，可以使用ThreadLocal來維護一個連接池，使得每個請求都能共享相同的連接，而不是每次都需要重新建立連接。
- 全局存儲信息：例如在前后端分離的應用中，ThreadLocal可以用來在服務端維護用戶的上下文信息或者一些配置信息，而不需要通過HTTP請求攜帶大量的用戶信息。這樣做可以在不改變原有架構的情況下，提供更好的用戶體驗。
如果大家還能想到其他使用的場景也歡迎留言。
四、升華篇
1.ThreadLocal原理
上述其實咱們聊得相對而言還是比較淺的。那么接下來，咱們豐富一下之前提到的結構圖，從源代碼側深度剖一下ThreadLocal吧。
深度結構圖
對應上述圖中，解釋一下。
- 圖中有兩個線程Thread1以及Thread2。
- Thread類中有一個叫做threadLocals的成員變量，它是ThreadLocal.ThreadLocalMap類型的。
- ThreadLocalMap內部維護了Entry數組，每個Entry代表一個完整的對象，key是ThreadLocal本身，value是ThreadLocal的泛型對象值。
對應的我們看一下Thread的源代碼，如下：
public class Thread implements Runnable {
...
ThreadLocal.ThreadLocalMap threadLocals = null;
...
}在源碼中threadLocals的初始值為Null。
抽絲剝繭，咱們繼續看一下ThreadLocalMap在調用構造函數進行初始化的源代碼：
static class ThreadLocalMap {
private static final int INITIAL_CAPACITY = 16; //初始化容量
private Entry[] table; //ThreadLocalMap數據真正存儲在table中
private int size = 0; //ThreadLocalMap條數
private int threshold; // 默認為0,達到這個大小，則擴容
//類Entry的實現
static class Entry extends WeakReference<ThreadLocal<?>> {
Object value;
Entry(ThreadLocal<?> k, Object v) {
super(k);
value = v;
}
}
//構造函數
ThreadLocalMap(ThreadLocal<?> firstKey, Object firstValue) {
table = new Entry[INITIAL_CAPACITY]; //初始化table數組，INITIAL_CAPACITY默認值為16
int i = firstKey.threadLocalHashCode & (INITIAL_CAPACITY - 1); //key和16取得哈希值
table[i] = new Entry(firstKey, firstValue);//創建節點，設置key-value
size = 1;
setThreshold(INITIAL_CAPACITY); //設置擴容閾值
}
}在源碼中涉及比較核心的還有set,get以及remove方法。我們依次來看一下：
set方法如下：
public void set(T value) {
Thread t = Thread.currentThread(); //獲取當前線程t
ThreadLocalMap map = getMap(t); //根據當前線程獲取到ThreadLocalMap
if (map != null) //如果獲取的ThreadLocalMap對象不為空
map.set(this, value); //K，V設置到ThreadLocalMap中
else
createMap(t, value); //創建一個新的ThreadLocalMap
}
ThreadLocalMap getMap(Thread t) {
return t.threadLocals; //返回Thread對象的ThreadLocalMap屬性
}
void createMap(Thread t, T firstValue) { //調用ThreadLocalMap的構造函數
t.threadLocals = new ThreadLocalMap(this, firstValue); //this表示當前類ThreadLocal
}get方法如下：
public T get() {
//1、獲取當前線程
Thread t = Thread.currentThread();
//2、獲取當前線程的ThreadLocalMap
ThreadLocalMap map = getMap(t);
//3、如果map數據不為空，
if (map != null) {
//3.1、獲取threalLocalMap中存儲的值
ThreadLocalMap.Entry e = map.getEntry(this);
if (e != null) {
@SuppressWarnings("unchecked")
T result = (T)e.value;
return result;
}
}
//如果是數據為null，則初始化，初始化的結果，TheralLocalMap中存放key值為threadLocal，值為null
return 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;
}remove方法：
public void remove() {
ThreadLocalMap m = getMap(Thread.currentThread());
if (m != null)
m.remove(this);
}那么為什么需要remove方法呢？其實這里會涉及到內存泄漏的問題了。后面咱們細看。
對照著上述的結構圖以及源碼，如果面試官問ThreadLocal原理的時候，相信大家應該可以說出個所以然來。
- Thread線程類有一個類型為ThreadLocal.ThreadLocalMap的變量threadLocals，即每個線程都有一個屬于自己的ThreadLocalMap。
- ThreadLocalMap方法內部維護著Entry數組，其中key是ThreadLocal本身，而value則為其泛型值。
- 并發場景下，每個線程都會存儲當前變量副本到自己的ThreadLocalMap中，后續這個線程對于共享變量的操作，都是從TheadLocalMap里進行變更，不會影響全局共享變量的值。
2.高并發場景下ThreadLocal會造成內存泄漏嗎？什么原因導致？如何避免？
(1) 造成內存泄漏的原因
這個問題其實還是得從ThreadLocal底層源碼的實現去看。高并發場景下，如果對ThreadLocal處理得當的話其實就不會造成內存泄漏。我們看下面這樣一組源代碼片段：
static class ThreadLocalMap {
...
//類Entry的實現
static class Entry extends WeakReference<ThreadLocal<?>> {
Object value;
Entry(ThreadLocal<?> k, Object v) {
super(k);
value = v;
}
}
...
}上文中其實我們已經知道Entry中以key和value的形式存儲，key是ThreadLocal本身，上面代碼中我們看到entry進行key設置的時候用的是super(k)。那就意味著調用的父類的方法去設置了key，我們再看一下父類是什么，父類其實是WeakReference。關于WeakReference底層的實現，大家有興趣可以展開去看看源代碼，老貓在這里直接說結果。
WeakReference 如字面意思，弱引用，當一個對象僅僅被weak reference（弱引用）指向, 而沒有任何其他strong reference（強引用）指向的時候, 如果這時GC運行, 那么這個對象就會被回收，不論當前的內存空間是否足夠，這個對象都會被回收。
關于這些引用的強弱，稍微聊一下，這里其實涉及到jvm的回收機制。在JDK1.2之后，java對引用的概念其實做了擴充的，分為強引用，軟引用，弱引用，虛引用。
- 強引用：其實就是咱們一般用“=”的賦值行為，如 Student s = new Student(),只要強引用還在，對象就不會被回收。
- 軟引用：不是必須存活的對象，jvm在內存不夠的情況下即將內存溢出前會對其進行回收。例如緩存。
- 弱引用：非必須存活的對象，引用關系比軟引用還弱，無論內存夠還是不夠，下次的GC一定會被回收。
- 虛引用：別名幽靈引用或者幻影引用。等同于沒有引用，唯一的目的是對象被回收的時候會受到系統通知。
明白這些概念之后，咱們再看看上面的源代碼，我們就會發現，原來Key其實是弱引用，而里面的value因為是直接賦值行為所以是強引用。
如下圖：
jvm存儲
圖中我們可以看到由于threadLocal對象是弱引用，如果外部沒有強引用指向的話，它就會被GC回收，那么這個時候導致Entry的key就為NULL，如果此時value外部也沒有強引用指向的話，那么這個value就永遠無法訪問了，按道理也該被回收。但是由于entry還在強引用value（看源代碼）。那么此時value就無法被回收，此時內存泄漏就出現了。本質原因是因為value成為了一個永遠無法被訪問也無法被回收的對象。
那肯定有小伙伴會有疑問了，線程本身生命周期不是很短么，如果短時間內被銷毀，就不會內存泄漏了，因為只要線程銷毀，那么value也會被回收。這話是沒錯。但是咱們的線程是計算機珍貴資源，為了避免重復創建線程帶來開銷，系統中我們往往會使用線程池（線程池傳送門）,如果使用線程池的話，那么線程的生命周期就被拉長了，那么就可想而知了。
(2) 如何避免
解法如下：
- 每次使用完畢之后記得調用一下remove()方法清除數據。
- ThreadLocal變量盡量定義成static final類型，避免頻繁創建ThreadLocal實例。這樣可以保證程序中一直存在ThreadLocal強引用，也能保證任何時候都能通過ThreadLocal的弱引用訪問Entry的value值，從而進行清除。
不過話說回來，其實ThreadLocal內部也做了優化的。在set()的時候也會采樣清理，擴容的時候也會檢查（這里希望大家自己深入看一下源代碼），在get（）的時候，如果沒有直接命中或者向后環形查找的時候也會進行清理。但是為了系統的穩健萬無一失，所以大家盡量還是將上面的兩個注意點在寫代碼的時候注意下。
總結
面試的時候大家總會去背一些八股文，但是這種也只是臨時應付面試官而已，真正的懂其中的原理才是硬道理。無論咋問，萬變不離核心原理。當然這些核心原理在我們的日常編碼中也會給我們帶來很大的幫助，用法很簡單，翻車了如何處理，那還不是得知其所以然么，伙伴們，你們覺得呢？
