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