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