并發(fā)編程系列寫到這一篇前面的內容基本都在圍繞一個詞打轉共享。鎖、原子類、并發(fā)容器本質上都是想讓多個線程更安全、更高效地協作同一份數據。而ThreadLocal的思路是反著來的——既然共享這么容易出問題那干脆每個線程各存一份誰也別碰誰的。這個思路聽著簡單但背后牽扯到弱引用、內存泄漏、線程池上下文傳遞一系列坑值得用一整篇來拆。ThreadLocal解決的是線程隔離問題不是并發(fā)原子性問題搞清楚這一點后面所有原理和實戰(zhàn)姿勢才立得住。這一篇我打算從最經典的SimpleDateFormat翻車現場切入先讓你明白ThreadLocal到底解決了什么問題然后進源碼拆一遍set/get/remove的完整鏈路重點講ThreadLocalMap的哈希設計和弱引用機制接著把內存泄漏的形成鏈路徹底還原說清楚為什么線程池是重災區(qū)再給出實戰(zhàn)層面的使用規(guī)范包括remove的幾種姿勢和上下文封裝思路最后記錄一次線上OOM排查實錄手把手走一遍jmap加MAT的定位流程。適合剛學并發(fā)編程的同學建立正確認知也適合被ThreadLocal泄漏或臟數據坑過的人對照著排查。1. 從SimpleDateFormat翻車現場切入ThreadLocal到底解決了什么問題1.1 SimpleDateFormat在多線程下的崩潰如果你在Java后端寫過日期格式化大概率見過這個經典事故一個SimpleDateFormat實例被多個線程同時調用parse()或format()結果日期串錯位、數字亂掉甚至直接拋NumberFormatException。private static final SimpleDateFormat SDF new SimpleDateFormat(yyyy-MM-dd HH:mm:ss); public String formatDate(Date date) { return SDF.format(date); // 并發(fā)調用時偶發(fā)錯亂 }根因不復雜SimpleDateFormat內部維護了一個Calendar對象format()和parse()過程中要反復讀寫這個共享的Calendar。多個線程同時操作同一份可變狀態(tài)又沒有同步數據被互相覆蓋自然就亂了。你單獨跑單測永遠復現不出來一壓測就現原形。1.2 加鎖、每次新建和ThreadLocal三條路的取舍解決這個線程安全問題通常有三條路。第一條是給format()加synchronized或使用ReentrantLock。這能保證正確性但等于把并發(fā)的日期格式化全部串行化。想象一個支付系統每秒鐘幾千筆訂單都要格式化時間所有請求擠在同一把鎖上性能損耗肉眼可見。第二條是每次調用都new SimpleDateFormat()。這條路避免了共享可變狀態(tài)但頻繁創(chuàng)建對象會增加GC壓力。雖然JIT的逃逸分析在部分場景能把對象優(yōu)化到棧上但依賴編譯器優(yōu)化本身不可靠尤其在對象構造較重、調用頻繁時效果并不穩(wěn)定。第三條就是用ThreadLocal給每個線程緩存一個SimpleDateFormat實例private static final ThreadLocalSimpleDateFormat DATE_FORMAT ThreadLocal.withInitial(() - new SimpleDateFormat(yyyy-MM-dd HH:mm:ss)); public String formatDate(Date date) { return DATE_FORMAT.get().format(date); }每個線程第一次get()時通過withInitial創(chuàng)建自己的實例之后一直復用。線程之間互不干擾不需要加鎖也不存在頻繁創(chuàng)建對象的開銷。這也直接點出了ThreadLocal的核心定位給每個線程一份獨立的私有副本把共享問題轉化成隔離問題。方案是否線程安全并發(fā)度對象創(chuàng)建開銷代碼侵入synchronized加鎖安全低串行無額外對象低每次new實例安全高高依賴GC兜底低ThreadLocal緩存安全高每個線程僅一次中需注意清理1.3 ThreadLocal解決的是線程隔離不是并發(fā)修改不少初學者把ThreadLocal當成線程安全的Map來用這是個危險的誤解。ThreadLocal并不保證你對某個對象內部狀態(tài)的修改是原子的它只是讓每個線程看到不同的對象實例。你往ThreadLocal里放一個共享的ArrayList再讓100個線程同時往這個List里add那該出事還是出事因為List本身還是同一個。所以在實踐中ThreadLocal的典型場景是那種每個線程天然該有一份但又不方便作為參數層層傳遞的東西事務連接、用戶登錄上下文、traceId、請求級別的緩存、框架層面的上下文對象。Spring的RequestContextHolder、MyBatis的SqlSessionTemplate在底層都用ThreadLocal綁定當前線程的資源。理解這點你才不會被后續(xù)的內存泄漏問題帶偏思路——它存儲的本質是線程級上下文而不是并發(fā)安全容器。2. ThreadLocal的源碼級拆解線程本地變量是怎么存進去、取出來的2.1 每個線程都自帶了兩個Map字段很多人以為ThreadLocal是把數據存在ThreadLocal對象里這是錯的。真正存儲數據的地方是Thread類內部的兩個字段threadLocals和inheritableThreadLocals?？碕DK源碼里Thread.java的字段定義一目了然ThreadLocal.ThreadLocalMap threadLocals null; ThreadLocal.ThreadLocalMap inheritableThreadLocals null;每個線程對象自帶一個ThreadLocalMap。當你調用ThreadLocal.set(value)的時候本質是把當前線程的threadLocals這個Map取出來往里面塞了一條記錄key是ThreadLocal對象自身value是你傳入的數據。不同ThreadLocal實例就是同一個線程Map里不同的key。所以線程隔離的準確含義是數據分散存儲在各個線程自己的Map里而不是存在ThreadLocal對象上。inheritableThreadLocals則是給子線程用的后面講子線程傳遞時再細說。這里先記住getMap(t)方法本身沒做什么高深的事它就是返回t.threadLocals這個字段。很多人在看源碼時卡在這個方法上其實它就是個訪問器熱詞里那句threadlocal getmap指的就是這一步。ThreadLocalMap getMap(Thread t) { return t.threadLocals; }2.2 set、get、remove的完整調用鏈先看set()在JDK 8里的實現public void set(T value) { Thread t Thread.currentThread(); ThreadLocalMap map getMap(t); if (map ! null) map.set(this, value); else createMap(t, value); }流程很直白拿到當前線程取出它的threadLocals如果Map已經存在就直接往里放不存在就創(chuàng)建一個新Map并塞入第一條記錄。createMap內部會new一個初始容量16的ThreadLocalMap并把當前ThreadLocal和value作為第一個Entry放進去。再看get()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(); }線程的Map存在并且能找到以當前ThreadLocal為key的Entry就返回里面的value找不到就調用setInitialValue()——它會執(zhí)行initialValue()方法默認返回nullwithInitial就是重寫這個方法把初始值塞進Map再返回。remove()更直接public void remove() { ThreadLocalMap m getMap(Thread.currentThread()); if (m ! null) m.remove(this); }看到這里你應該已經發(fā)現一個關鍵點ThreadLocal的線程隔離能力完全建立在每個Thread對象內部的Map之上。這意味著只要線程還活著它Map里所有的value都不會被自動釋放。這條結論是理解內存泄漏的起點。2.3 哈希散列為什么ThreadLocal敢用線性探測硬扛沖突ThreadLocalMap底層是個Entry數組初始容量16負載因子是2/3。每個ThreadLocal實例在創(chuàng)建時都會通過一個全局的AtomicInteger累加得到一個threadLocalHashCode增量是那個著名的魔數0x61c88647源碼里叫HASH_INCREMENT。private final int threadLocalHashCode nextHashCode(); private static int nextHashCode() { return nextHashCode.getAndAdd(HASH_INCREMENT); }為什么要定這個增量它和黃金分割比例有關對應的是斐波那契散列。簡單說0x61c88647能保證ThreadLocal的哈希值在數組長度是2的冪時均勻地散布在槽位上最大程度避免多個ThreadLocal擠在同一條探測序列上。你不需要深挖數學推導只要記住結論ThreadLocalMap的鑰匙分布是經過精心設計的所以在ThreadLocal數量不多的前提下用開放地址法線性探測解決沖突就夠了不需要像HashMap那樣掛鏈表、轉紅黑樹。定位槽位的語句是這樣的int i key.threadLocalHashCode (table.length - 1);table.length永遠是2的冪所以按位與等價于取模而且比取?？?。如果槽位被占就往后找空位找的時候如果遇到key為null的過期Entry還會順手做清理。這套機制讓ThreadLocalMap在低沖突場景下性能非常好代價是它不適合存儲大量key——如果你在一個線程里new了幾百個ThreadLocal線性探測的性能就會明顯劣化。這也是為什么實戰(zhàn)規(guī)范里強調能復用的ThreadLocal盡量復用。3. 弱引用不等于安全ThreadLocal內存泄漏的完整鏈路分析3.1 Entry的引用鏈key是弱引用value是強引用先看ThreadLocalMap.Entry的定義static class Entry extends WeakReferenceThreadLocal? { Object value; Entry(ThreadLocal? k, Object v) { super(k); value v; } }注意Entry繼承自WeakReference也就是說Entry本身是個弱引用引用的是key也就是ThreadLocal對象。而value字段是一個普通強引用。整條引用鏈畫出來是這樣Thread 對象 └─ ThreadLocalMap └─ Entry[] └─ Entry (弱引用 - ThreadLocal key) └─ value (強引用 - 你塞進去的數據)弱引用的語義是當GC發(fā)生時如果一個對象只被弱引用指向沒有任何強引用它就會被回收。也就是說ThreadLocal對象一旦在業(yè)務代碼里失去外部強引用比如方法局部變量用完了GC就有資格回收它Entry的key就變成null。這看起來是個保護機制框架不知道業(yè)務什么時候不再需要ThreadLocal所以用弱引用保證ThreadLocal實例本身可以被回收。但value沒有這層保護。value是強引用只要Entry還在value就一直在。而Entry被線程的ThreadLocalMap持有ThreadLocalMap又被線程對象持有。只要線程還活著這條鏈就斷不開。3.2 泄漏的完整形成條件我見過很多人把ThreadLocal內存泄漏簡單歸結為用了弱引用這其實是誤解。弱引用恰恰是為了避免ThreadLocal對象本身泄漏真正的問題出在value的強引用鏈上。一個完整的泄漏需要同時滿足三個條件ThreadLocal對象失去外部強引用。最常見的是在方法內部直接new ThreadLocal()使用方法執(zhí)行完局部變量沒了ThreadLocal實例只剩Entry里的弱引用GC一發(fā)生就被回收。線程是長生命周期的。線程池里的worker線程、Tomcat的請求處理線程都是長期存活的只要線程不死它的ThreadLocalMap就一直在。沒有后續(xù)操作觸發(fā)清理。如果后面再也不碰這個ThreadLocalMap底層的expungeStaleEntry()清理邏輯永遠不會執(zhí)行value就變成永遠無法訪問但一直被強引用的垃圾。典型的業(yè)務場景長這樣public void handleRequest(Request req) { ThreadLocalbyte[] holder new ThreadLocal(); holder.set(new byte[1024 * 1024]); // 1MB // 業(yè)務處理... // 忘記remove方法結束后holder失去外部引用 }如果這個handleRequest被丟進一個線程池執(zhí)行每個請求都new一個ThreadLocal并set入大對象那么每次請求都會在線程的Map里留下一個key為null、value為1MB數組的過期Entry。線程池線程不死這些Entry就永遠躺在那里。QPS稍微高一點內存漲起來非?？?。3.3 線程池既是泄漏放大器也是臟數據制造機線程池把線程長生命周期這個條件放大了。普通線程執(zhí)行完一個任務就結束整個ThreadLocalMap隨著線程銷毀被回收根本談不上泄漏。但線程池的worker線程是復用的它們一直在等新任務threadLocals這個Map也跟著一直存活。線程池還會帶來第二個問題臟數據串線。假設你寫了一個登錄用戶信息上下文private static ThreadLocalUser currentUser new ThreadLocal();任務A里執(zhí)行了currentUser.set(userA)但忘了remove任務A跑完worker線程回到池子里待命。任務B被分配到同一個worker線程如果任務B的代碼路徑在某個分支沒有主動set用戶信息它currentUser.get()讀到的就是用戶A的信息。輕則業(yè)務數據錯亂重則出現越權訪問。這類問題在代碼Review里很難發(fā)現因為它不是必現的完全取決于線程池把哪個任務分配給哪個worker。所以在線程池場景下ThreadLocal的正確用法不是用完等GC而是用后必須remove甚至要在任務最外層做防御性清理。3.4 ThreadLocalMap的兜底清理機制能救命但不能依賴JDK的設計者當然知道這個坑所以ThreadLocalMap在幾個關鍵操作里內置了清理邏輯set()時如果發(fā)現相同key的Entry會用新值覆蓋并對探測路徑上的過期Entry做清理get()未直接命中時會在getEntryAfterMiss()里線性向后找遇到key為null的Entry會調用expungeStaleEntry()把value置null、槽位置空rehash()時也會先全面清理再擴容。這套機制確實能在很多情況下兜底比如你反復set同一個ThreadLocal舊的過期Entry大概率會被順帶清掉。它的問題是一切清理都必須由后續(xù)的set/get/remove操作觸發(fā)。如果線程執(zhí)行完任務后長時間閑置沒有任何關于這個Map的操作過期Entry就一直靜止在內存里。你指望GC救你但GC根本碰不到value——它有一條完整的強引用鏈。結論很明確底層清理是優(yōu)化不是保障業(yè)務側的remove()才是唯一靠得住的釋放手段。4. 實戰(zhàn)守則如何正確使用ThreadLocal而不埋雷4.1 remove是底線三種清理姿勢先說最基礎的姿勢也是我要求團隊必須遵守的用完之后在finally里remove無論正常返回還是拋出異常都必須執(zhí)行。private static final ThreadLocalString TRACE_ID new ThreadLocal(); public void process() { try { TRACE_ID.set(generateTraceId()); doSomething(); } finally { TRACE_ID.remove(); } }為什么必須在finally而不是在方法末尾因為方法中間拋了異常末尾的remove根本執(zhí)行不到然后殘留值就留在線程里了。線上拋異常是常態(tài)不是意外。很多泄漏就是在某個異常分支里漏掉了清理。第二種姿勢是在框架的攔截器或過濾器中統一清理。以Spring Web應用為例如果你需要請求級的上下文更推薦用HandlerInterceptor的afterCompletion方法public class TraceIdInterceptor implements HandlerInterceptor { Override public void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex) { TraceContext.clear(); // 內部調用ThreadLocal.remove() } }Filter或者Interceptor的好處是入口和出口都在框架層面業(yè)務代碼不需要在每個方法里try-finally漏清理的概率大大降低。第三種姿勢是封裝成AutoCloseable配合try-with-resources使用public class AutoThreadLocalT extends ThreadLocalT implements AutoCloseable { Override public void close() { remove(); } }這種寫法適合那種只在單個方法里臨時用的場景代碼會更緊湊但我個人更推薦前兩種——因為try-with-resources要求每個用到的代碼塊都正確寫語法而Filter/Interceptor是集中式治理對團隊更友好。4.2 static修飾符到底該不該加這是一個經常被問到的點。結論分兩種情況。如果ThreadLocal是Spring單例Bean的成員變量那實例只有一份ThreadLocal對象長期存活相當于static。這種情況下用不用static修飾影響不大但為了語義清晰統一用private static final。真正危險的是在短生命周期對象里持有ThreadLocal。比如一個每次請求都new的Helper類里面定義了一個實例字段ThreadLocalString holder。Helper對象在請求結束時失去引用ThreadLocal對象也失去強引用GC把這key回收后Map里就剩一個value還在。如果這個請求跑在線程池里下次任務又new一個新的Helper、新的ThreadLocalMap里的過期Entry持續(xù)累積。這種寫法是我在代碼Review里看到最多的隱性雷。所以我的建議是ThreadLocal實例能定義為static final就優(yōu)先static final。它不會讓你少寫remove但能避免ThreadLocal對象本身被GC回收導致value失聯這條更隱蔽的泄漏路徑。4.3 統一封裝上下文工具類把ThreadLocal關進籠子業(yè)務代碼里散落使用ThreadLocal最大的問題不是語法錯誤而是管理混亂。今天你在A服務里set了個用戶ID明天B服務也想用又不好意思改A的代碼于是自己又new了一個ThreadLocal。線程Map里的key越來越多清理也越來越不徹底。我建議每個項目針對線程級上下文做統一封裝。比如這樣一個TraceContextpublic final class TraceContext { private static final ThreadLocalString TRACE_ID new ThreadLocal(); private TraceContext() { } public static void setTraceId(String traceId) { TRACE_ID.set(traceId); } public static String getTraceId() { return TRACE_ID.get(); } public static void clear() { TRACE_ID.remove(); } }然后在整個調用鏈的最外層——Filter、Interceptor、或者異步任務的入口——統一調用setTraceId統一在finally里調用clear。業(yè)務代碼只通過靜態(tài)方法讀寫不需要知道底層的ThreadLocal長什么樣。這樣做還有一個好處以后想換成TransmittableThreadLocal只需要改這一個類不用滿項目找散落的ThreadLocal.set/get。4.4 子線程與線程池的變量傳遞InheritableThreadLocal的局限和TTL的解法很多場景需要把父線程的上下文傳到子線程比如異步任務里記錄traceId。JDK提供的原生方案是InheritableThreadLocal。它的實現原理是父線程創(chuàng)建子線程時把父線程的inheritableThreadLocals里的Entry復制一份給子線程。注意是創(chuàng)建線程那一刻的快照而且這個復制是淺拷貝——如果value是可變對象父子線程持有的是同一個引用并發(fā)修改照樣有競爭問題。InheritableThreadLocal最大的局限在于線程池。線程池的worker線程不是每次任務都新建的它早在提交任務之前就創(chuàng)建好了。父線程想傳值給worker線程根本不觸發(fā)線程創(chuàng)建過程InheritableThreadLocal完全無效。而且即使你第一次提交任務時值傳過去了下次提交新值也不會更新因為worker線程不會再走創(chuàng)建線程復制這條路徑。這個場景下業(yè)界更常用的方案是阿里開源的TransmittableThreadLocal簡稱TTL。它的思路是在任務提交時捕獲當前線程TTL值的快照任務真正執(zhí)行前把快照回放到執(zhí)行線程上執(zhí)行結束后恢復執(zhí)行線程原有的值。使用方式很簡單ExecutorService executor TtlExecutors.getTtlExecutorService(executorService); executor.submit(() - { // 這里能正確讀到提交任務時的上下文 });不引入依賴包的情況下你也可以自己包裝Runnable在run()前后手動set/remove實現思路和TTL一致提交時快照執(zhí)行前回放執(zhí)行后清理。只不過TTL把這個邏輯封裝好了還支持Java Agent方式自動透傳。如果項目里大量使用線程池且需要傳遞traceId、用戶身份這類上下文建議直接把TTL納入基礎設施。5. 一次線上OOM排查實錄如何定位到ThreadLocal泄漏5.1 現象老年代持續(xù)上漲但GC后回不去之前接手過一個異步處理服務現象很典型JVM老年代使用率從啟動后一路爬升Full GC之后也只是從95%降到80%很快又漲回去。接口響應時間越來越長最后每天固定OOM一次只能靠重啟續(xù)命。第一反應肯定是先看GC日志和內存曲線。用jstat看一眼jstat -gcutil pid 1000輸出里重點觀察FGCFull GC次數和O老年代使用率。如果YGC很頻繁、FGC也在持續(xù)增長但老年代使用率始終處于高位說明堆里有大量對象無法被回收。這時候就要考慮是不是有對象被長生命周期對象比如線程、類加載器、緩存持有形成了事實上的泄漏。值得提醒的是不要一看內存高就無腦調-Xmx。調大堆只會推遲OOM時間不會解決問題。正確步驟是把堆dump下來看對象構成。5.2 用jmap導出堆快照再用MAT定位可疑對象低峰期用jmap導出堆快照jmap -dump:live,formatb,fileheap.bin pid注意live參數會先觸發(fā)一次Full GC生產環(huán)境盡量在業(yè)務低谷操作或者改用jcmd pid GC.heap_dump heap.bin。dump文件通常很大本地用MATMemory Analyzer打開。打開后先看Histogram直方圖按retained heap排序。在這個服務里我很快就看到了一個熟悉的自定義類RequestContext有幾萬個實例retained heap占了差不多1GB。這個類為什么會單例持有那么多實例肯定是被某個容器類緩存了。接下來右鍵這個類選擇List objects - with incoming references看看引用它的是什么。你會看到大量引用來自java.lang.ThreadLocal$ThreadLocalMap$Entry這就基本鎖定方向了這些對象都被ThreadLocalMap里的Entry強引用著。5.3 順著GC Roots路徑確認是ThreadLocal鏈確認這一步需要右鍵對象選Path to GC Roots - exclude weak references。如果之前看過一遍ThreadLocal的引用鏈此刻再看這條路徑會非常清晰Thread (worker線程) └─ ThreadLocalMap └─ Entry[ ] └─ Entry └─ value (RequestContext實例)路徑里能看到Thread對象是GC Roots因為線程池里的worker線程都活著正等著新任務。順著路徑往下還會發(fā)現一個關鍵細節(jié)很多Entry的key已經是null了。這說明ThreadLocal對象本身已經被GC回收但value還躺在Entry里。這就是典型的key弱引用被回收、value強引用殘留的泄漏形態(tài)。如果只看Entry數量還不足以定位到代碼就再切到線程棧視圖把目標Thread的線程棧打出來看看這個線程最近在執(zhí)行什么業(yè)務然后回代碼里找這個業(yè)務鏈路上的set()調用。我當時就是從worker線程綁定的任務名一路追到一個公共的異步切面發(fā)現在切面里為了記錄traceId每次請求都new ThreadLocal()set完之后沒有remove方法結束ThreadLocal失去強引用剩下的value就全留在線程池線程的Map里了。5.4 修復與驗證一行remove解決幾百MB內存修復方案很簡單把那個切面里的new ThreadLocal改成靜態(tài)常量并在finally塊里調用remove()。public class AsyncTraceAspect { private static final ThreadLocalString TRACE_ID new ThreadLocal(); public Object around(ProceedingJoinPoint point) throws Throwable { try { TRACE_ID.set(buildTraceId()); return point.proceed(); } finally { TRACE_ID.remove(); } } }改完之后再用jmap導一次堆用MAT對比修復前后的對象數量。最直觀的驗證指標有兩個一是RequestContext的實例數從幾萬降到了和線程數同一量級二是老年代使用率在幾次Full GC后穩(wěn)定在30%左右不再持續(xù)爬坡。這個效果不是靠調參數調出來的是真正把引用鏈斷了。排查過程中還有一個容易忽略的點如果你在MAT里用exclude weak references查不到GC Roots路徑不要慌。key為null的Entry本身已經斷開了對ThreadLocal的引用MAT的弱引用排除規(guī)則可能導致路徑不顯示。這時候換include all references再查或者直接在Dominator Tree里找ThreadLocalMap通常能看到完整的引用鏈。這次排查給我留下的最深印象是ThreadLocal泄漏很少是單個大對象的問題更多是業(yè)務對象被線程池線程長期持有的組合問題。你單看每個對象都不算大但線程池有幾百個線程每個線程攢幾百個過期Entry就是幾百MB甚至上GB的垃圾。它在代碼Review階段極難發(fā)現因為所有set/remove分散在各個方法里沒有一個集中的審視點。這也是為什么我會在前面的實戰(zhàn)部分反復強調統一封裝和攔截器清理——線上少踩一個坑比事后排查輕松太多。最后分享一個我個人的習慣線上服務里如果需要排查ThreadLocal相關的問題除了jmap和MAT也可以用Arthas的watch命令觀察某個上下文類的set和remove調用次數。如果發(fā)現set被瘋狂觸發(fā)但remove幾乎不觸發(fā)那基本不用dump堆也能判斷問題出在哪了。這套組合拳下來ThreadLocal這個線程私有的小籠子在你手里就不再是黑盒了。