如果你在項(xiàng)目里用過(guò)線程池并且拿ThreadLocal做過(guò)上下文透?jìng)鞔蟾怕首惨?jiàn)過(guò)一個(gè)讓人撓頭的現(xiàn)象一次請(qǐng)求進(jìn)來(lái)方法里new了一個(gè)ThreadLocal存數(shù)據(jù)請(qǐng)求結(jié)束線程回池子下一次請(qǐng)求隨機(jī)分配到了同一個(gè)線程代碼里同樣new了一個(gè)ThreadLocal去get()結(jié)果返回了null。第一次存進(jìn)去的東西像是被誰(shuí)悄悄摸走了一樣。反過(guò)來(lái)的坑也常見(jiàn)——線程池里的ThreadLocal值明明已經(jīng)沒(méi)人用了卻一直占著內(nèi)存不釋放最后把堆頂滿。這兩個(gè)現(xiàn)象看起來(lái)矛盾其實(shí)指向同一個(gè)設(shè)計(jì)ThreadLocalMap.Entry對(duì) key 用的是弱引用。很多人面試時(shí)能背出“弱引用是為了防止內(nèi)存泄漏”但追問(wèn)下去就卡殼了防的到底是哪種泄漏換成強(qiáng)引用行不行軟引用行不行為什么偏偏是弱引用這篇文章我把這條線完整拆一遍從源碼到引用類型權(quán)衡再到日常編碼和線上排障一次性講透。1. 一個(gè)看似詭異的現(xiàn)象線程還在ThreadLocal 卻“失憶”了1.1 線程池中復(fù)現(xiàn)“第二次 get 返回 null”先看一個(gè)最小復(fù)現(xiàn)場(chǎng)景。假設(shè)有一個(gè)單線程的線程池兩個(gè)任務(wù)先后交給它執(zhí)行ExecutorService pool Executors.newFixedThreadPool(1); pool.execute(() - { ThreadLocalString local new ThreadLocal(); local.set(第一次請(qǐng)求的數(shù)據(jù)); // 方法結(jié)束local 變量離開(kāi)作用域外部強(qiáng)引用消失 }); // 給 GC 留點(diǎn)時(shí)間比如 Thread.sleep(100); // 這里或者手動(dòng)調(diào)用 System.gc() 幫助復(fù)現(xiàn) pool.execute(() - { ThreadLocalString local new ThreadLocal(); String value local.get(); // null System.out.println(value); // 打印 null });注意兩個(gè)任務(wù)中的local是兩個(gè)不同的 ThreadLocal 實(shí)例。第一次任務(wù)里那個(gè)對(duì)象在任務(wù)結(jié)束后已經(jīng)沒(méi)有外部強(qiáng)引用了第二次任務(wù)創(chuàng)建的是全新實(shí)例。有人會(huì)問(wèn)ThreadLocalMap不是存在線程里嗎線程明明還活著為什么第二次get()拿不到關(guān)鍵在于線程里的ThreadLocalMap保存的可不是ThreadLocal對(duì)象的強(qiáng)引用。當(dāng)?shù)谝淮稳蝿?wù)結(jié)束、外部對(duì)local的強(qiáng)引用消失之后下一次 GC 就會(huì)把這個(gè) ThreadLocal 對(duì)象回收掉因?yàn)榫€程里只握著它的一根弱引用。第二次任務(wù)里的local是一個(gè)全新實(shí)例和原來(lái)那個(gè)對(duì)象沒(méi)有任何關(guān)系get()順著自己的哈希值找一圈找不到舊 entry只能走setInitialValue()返回初始值null。當(dāng)然如果你的ThreadLocal是static的外部強(qiáng)引用一直在這個(gè)現(xiàn)象就不會(huì)出現(xiàn)——這也解釋了為什么后面要專門強(qiáng)調(diào)ThreadLocal定義為static。這兩個(gè)細(xì)節(jié)要關(guān)聯(lián)起來(lái)理解很多人就是栽在這里。1.2 真正回收的是什么一條完整的引用鏈路要把這個(gè)問(wèn)題看懂得先把一條引用鏈畫出來(lái)。每個(gè)線程都持有一個(gè)ThreadLocalMap對(duì)象它內(nèi)部是一個(gè)Entry[] table數(shù)組數(shù)組中每個(gè)Entry保存一個(gè) ThreadLocal 的引用和一個(gè) value 值。鏈路是這樣的Thread 對(duì)象 └── threadLocalsThreadLocalMap 實(shí)例 └── tableEntry[] 數(shù)組 └── Entry ├── key弱引用 - ThreadLocal 對(duì)象 └── value強(qiáng)引用 - 業(yè)務(wù)數(shù)據(jù)對(duì)象這里的核心點(diǎn)來(lái)了Thread對(duì)象到ThreadLocal對(duì)象的這條路徑不是一條強(qiáng)引用鏈。Entry對(duì) key 的引用是WeakReference而引用類型決定了 GC 回收對(duì)象的規(guī)則。弱引用的特點(diǎn)是只要被引用的對(duì)象沒(méi)有其他強(qiáng)引用鏈GC 在下一次回收時(shí)就可以把它清掉不管內(nèi)存夠不夠也不管“使用它的人”是否還活著。所以這條鏈路里真正決定ThreadLocal對(duì)象命運(yùn)的不是線程而是外部代碼有沒(méi)有繼續(xù)持有這個(gè) ThreadLocal 的強(qiáng)引用。線程只是提供了存儲(chǔ)容器但這個(gè)容器不會(huì)強(qiáng)行延續(xù) ThreadLocal 的生命周期。拿公告欄來(lái)類比線程池的線程像一面常駐的公告欄ThreadLocal像貼上去的便利貼但貼上去的膠水是弱性的——只要沒(méi)人手里還拿著同一張便利貼的強(qiáng)引用保潔員GC一來(lái)就把便利貼收走了公告欄本身怎么換人都管不著。理解了這條鏈路再看“弱引用為什么存在”就有了一半答案它設(shè)計(jì)出來(lái)的目的就是讓 ThreadLocal 對(duì)象的生命周期可以由外部引用控制而不是被線程鎖死。至于為什么必須這樣做下一章從源碼角度往下挖。2. 源碼層面的事實(shí)ThreadLocalMap.Entry 為什么繼承 WeakReference2.1 Entry 的定義和 ThreadLocalMap 的存儲(chǔ)模型直接看 JDK 源碼。ThreadLocalMap是ThreadLocal的靜態(tài)內(nèi)部類真正的存儲(chǔ)結(jié)構(gòu)是這樣的public class ThreadLocalT { static class ThreadLocalMap { static class Entry extends WeakReferenceThreadLocal? { Object value; Entry(ThreadLocal? k, Object v) { super(k); // key 以弱引用形式傳給 Reference 構(gòu)造器 value v; // value 是普通強(qiáng)引用 } } private static final int INITIAL_CAPACITY 16; private Entry[] table; private int size 0; private int threshold; } }Entry繼承WeakReferenceThreadLocal?天生就是一個(gè)弱引用對(duì)象。Entry本身繼承的父類里存著referent也就是 key——ThreadLocal對(duì)象而value字段就是普通的強(qiáng)引用存業(yè)務(wù)數(shù)據(jù)。這種結(jié)構(gòu)的技術(shù)術(shù)語(yǔ)叫“弱 key 強(qiáng) value”是整篇所有問(wèn)題的最根本出發(fā)點(diǎn)。ThreadLocalMap的存儲(chǔ)模型和HashMap有相似之處但差異更值得注意底層是Entry[]數(shù)組初始容量 16擴(kuò)容時(shí)翻倍保持 2 的冪線程內(nèi)每個(gè)ThreadLocal實(shí)例都有唯一的threadLocalHashCode這個(gè)哈希值通過(guò)AtomicInteger每次累加0x61c88647生成——黃金分割數(shù)保證不同 ThreadLocal 的 hash 分布均勻減少?zèng)_突。和HashMap不同ThreadLocalMap處理哈希沖突用的是線性探測(cè)法也就是向后逐個(gè)找空槽而不是鏈表。找到null位置后放入新 Entry。這個(gè)差異在get()和set()里都能看到尤其是get()時(shí)遇到“key 已被 GC 回收”的空槽要怎么處理后處理。2.2 這個(gè)結(jié)構(gòu)把“誰(shuí)引用誰(shuí)”的關(guān)系反過(guò)來(lái)了平時(shí)我們寫代碼習(xí)慣是“我持有一個(gè)對(duì)象”。但ThreadLocalMap.Entry把這種關(guān)系倒過(guò)來(lái)了ThreadLocal對(duì)象不是擁有者而是被存儲(chǔ)方。線程里的threadLocals字段指向ThreadLocalMapThreadLocalMap又通過(guò)Entry持有ThreadLocal的弱引用。這段關(guān)系意味著什么看兩條生命周期線線程的生命周期可能很長(zhǎng)。線程池里的線程往往和進(jìn)程同生共死存活幾年都不稀奇。ThreadLocal 對(duì)象的生命周期通常很短。大多數(shù)業(yè)務(wù)場(chǎng)景下它只是一個(gè)局部變量方法執(zhí)行完、請(qǐng)求處理完職責(zé)就結(jié)束了。設(shè)計(jì)者面臨的矛盾是一個(gè)生命周期很長(zhǎng)的容器線程保存了一個(gè)生命周期很短的對(duì)象ThreadLocal。如果采用強(qiáng)引用ThreadLocal 對(duì)象的存活時(shí)間就會(huì)被線程拉長(zhǎng)到“線程死亡”的那一刻短生命周期對(duì)象被長(zhǎng)生命周期容器“綁架”內(nèi)存泄漏的根源就埋下了。弱引用在這里起的作用是解除綁定外部引用沒(méi)了GC 就能把 ThreadLocal 對(duì)象收掉線程的生命周期和 ThreadLocal 的生命周期不再互相拖累。一句話總結(jié)這段源碼設(shè)計(jì)意圖讓 ThreadLocal 對(duì)象“能用多久由外部決定”而不是“能活多久由線程決定”。2.3 hash 與探測(cè)弱引用也參與散列沖突處理弱引用不是簡(jiǎn)單給Entry套一層殼就完事它還影響了ThreadLocalMap的內(nèi)部操作細(xì)節(jié)?？匆幌耮etEntry相關(guān)代碼private Entry getEntry(ThreadLocal? key) { int i key.threadLocalHashCode (table.length - 1); Entry e table[i]; if (e ! null e.get() key) { return e; } else { return getEntryAfterMiss(key, i, e); } } private Entry getEntryAfterMiss(ThreadLocal? key, int i, Entry e) { Entry[] tab table; int len tab.length; while (e ! null) { ThreadLocal? k e.get(); if (k key) { return e; } if (k null) { // 遇到了 key 已被回收的“臟 Entry”順手清理 expungeStaleEntry(i); } else { i nextIndex(i, len); } e tab[i]; } return null; }注意e.get()這個(gè)方法。WeakReference的get()返回的是被引用對(duì)象如果對(duì)象已經(jīng)被 GC 回收get()返回null。ThreadLocalMap在遍歷探測(cè)時(shí)就是用e.get() key判斷當(dāng)前槽位存的是不是同一個(gè) ThreadLocal一旦遇到e.get() null說(shuō)明這個(gè) Entry 的 key 已經(jīng)被回收了也就是“臟 Entry”此時(shí)會(huì)調(diào)用expungeStaleEntry(i)清理掉。這段代碼直接決定了弱引用設(shè)計(jì)的實(shí)際表現(xiàn)key 被回收后Entry 不會(huì)立刻消失只會(huì)在后續(xù)get/set操作時(shí)被“順路清理”。如果一直沒(méi)有人訪問(wèn)這個(gè)槽位殘留的 value 就會(huì)一直躺在table里。這個(gè)特性我們后面還會(huì)展開(kāi)。3. 換成強(qiáng)引用或軟引用行不行三種方案推演3.1 強(qiáng)引用的反例線程池存活十年ThreadLocal 泄漏十年假設(shè)設(shè)計(jì)者當(dāng)初拍板Entry里直接放一個(gè)強(qiáng)引用 key。那會(huì)出現(xiàn)什么// 假如 Entry 是這樣 static class Entry { ThreadLocal? key; // 強(qiáng)引用 Object value; }此時(shí)只要線程活著ThreadLocalMap里的Entry就對(duì)ThreadLocal對(duì)象保持強(qiáng)引用。線程池的線程通常不會(huì)被銷毀業(yè)務(wù)代碼每次執(zhí)行都會(huì)new一個(gè)新的ThreadLocal塞進(jìn)去于是線程的table數(shù)組里積累了一堆外部已經(jīng)無(wú)人使用、但線程還強(qiáng)行引用著的 ThreadLocal 對(duì)象。它們既不能被業(yè)務(wù)代碼再利用GC 又收不掉這就是典型的 key 泄漏。更嚴(yán)重的是很多ThreadLocal是通過(guò)匿名內(nèi)部類或 lambda 創(chuàng)建的這些對(duì)象內(nèi)部會(huì)隱含引用外部類實(shí)例甚至通過(guò).class字段間接引用ClassLoader。一旦 ThreadLocal 實(shí)例被線程強(qiáng)引用它背后掛著的整個(gè)引用鏈都會(huì)被“?；睢薄Ｔ?Web 容器、應(yīng)用服務(wù)器里這可能導(dǎo)致整個(gè)應(yīng)用/Web 模塊的ClassLoader無(wú)法被回收熱部署幾次后直接PermGen/Metaspace溢出。這類故障在早期的 Tomcat、Spring 框架里發(fā)生過(guò)很多次根本原因就只有一句話key 被長(zhǎng)生命周期線程強(qiáng)引用了。3.2 軟引用的反例回收時(shí)機(jī)和“失去外部引用”不同步那改成SoftReference呢軟引用的回收規(guī)則是內(nèi)存充足時(shí)不回收內(nèi)存不足時(shí)才回收。聽(tīng)起來(lái)好像也能兜底但仔細(xì)推演就知道不合適。ThreadLocal對(duì)象在業(yè)務(wù)代碼結(jié)束之后本質(zhì)上已經(jīng)“死亡”了我們希望它盡快被回收。但軟引用只在 JVM 內(nèi)存緊張時(shí)才會(huì)清理。假設(shè)你的應(yīng)用運(yùn)行得好好的堆內(nèi)存還非常寬裕那這些失去外部引用的 ThreadLocal 對(duì)象就會(huì)一直“詐尸”在堆里線程池越活躍堆積越多直到內(nèi)存真的吃緊才被清一波——但那時(shí)候可能已經(jīng)快 OOM 了清理壓力也大。更重要的是軟引用回收時(shí)機(jī)不可控。你沒(méi)法預(yù)測(cè)哪個(gè) GC 周期會(huì)清掉它也沒(méi)法保證它在“外部引用消失后”及時(shí)讓get()返回null。這會(huì)造成一類更難排查的間歇性問(wèn)題同樣的代碼這次能拿到值下次拿不到和內(nèi)存占用水平強(qiáng)相關(guān)。作為語(yǔ)言內(nèi)部的數(shù)據(jù)結(jié)構(gòu)這種不確定性是不可接受的。弱引用完全不同——它不關(guān)心內(nèi)存狀態(tài)只要外部強(qiáng)引用消失下一次 GC 到來(lái)時(shí)就回收行為確定、可預(yù)期。3.3 兩害相權(quán)取其輕弱引用選型邏輯把三種方案放在一起對(duì)比引用類型key 的回收時(shí)機(jī)后果分析強(qiáng)引用幾乎不回收除非線程銷毀ThreadLocal 對(duì)象隨線程存活key 泄漏可能連帶 ClassLoader 泄漏軟引用內(nèi)存不足時(shí)才回收回收時(shí)機(jī)和業(yè)務(wù)語(yǔ)義不同步無(wú)法保證及時(shí)清理弱引用外部強(qiáng)引用消失后下一次 GC 即回收ThreadLocal 對(duì)象本身不泄漏value 可能殘留但可以配合 remove 解決這個(gè)對(duì)比能看出設(shè)計(jì)者的權(quán)衡保證 ThreadLocal 對(duì)象本身一定不泄漏是首要目標(biāo)value 殘留是次要問(wèn)題可以通過(guò)編碼規(guī)范兜住。弱引用恰好讓“ThreadLocal 對(duì)象的生命周期”回歸到“外部引用的生命周期”這正是它被選中的根本原因。很多資料把這段講成“弱引用能防止內(nèi)存泄漏”其實(shí)不嚴(yán)謹(jǐn)。準(zhǔn)確的說(shuō)法是弱引用防止的是 ThreadLocal 對(duì)象key的泄漏它同時(shí)留下了 value 泄漏的隱患。這兩種“泄漏”在外面被混為一談但只要從三種方案對(duì)比的角度看誰(shuí)防什么、誰(shuí)擋不住什么一目了然。4. 弱引用引發(fā)的“次生災(zāi)害”value 殘留和臟 Entry為什么還要 remove4.1 key 沒(méi)了 value 還在臟 Entry 從哪里來(lái)弱引用解決了 key 的泄漏卻帶來(lái)一個(gè)新的不對(duì)稱Entry 對(duì)象和 value 字段仍然是強(qiáng)引用。當(dāng) GC 把ThreadLocal對(duì)象回收后table數(shù)組里的那個(gè) Entry 并不會(huì)自動(dòng)消失它只是變成了“key 為 null”的狀態(tài)也就是臟 Entry。此時(shí) value 對(duì)象仍然被 Entry 強(qiáng)引用著無(wú)法回收。假設(shè)有一個(gè)線程池線程 A 執(zhí)行任務(wù)時(shí)往某個(gè)static ThreadLocal里塞了一個(gè) 10MB 的緩存對(duì)象。代碼忘了remove()任務(wù)結(jié)束。ThreadLocal 對(duì)象因?yàn)槭?static 的外部強(qiáng)引用還在不會(huì)被回收但 value 所在的 Entry 在 A 線程的ThreadLocalMap里永久存在。線程池線程如果一直復(fù)用這個(gè) 10MB 對(duì)象就會(huì)被“釘”在堆里一輩子。線程池有 50 個(gè)線程每個(gè)線程各殘留一份500MB 就沒(méi)了。臟 Entry 的產(chǎn)生過(guò)程和 static 與否沒(méi)有絕對(duì)關(guān)系但有一個(gè)共同前提存了值之后沒(méi)有 remove且后續(xù)又沒(méi)有別的get/set操作碰到這個(gè)槽位。只要滿足這個(gè)條件value 殘留就是必然事件只是時(shí)間早晚和內(nèi)存大小的問(wèn)題。4.2 ThreadLocalMap 的清理機(jī)制被動(dòng)、局部、不保證你可能想問(wèn)既然 key 都空了Java 為什么不自己把這些臟 Entry 全清掉答案在源碼里——它不是不想清而是只做了“被動(dòng)清理”而且觸發(fā)條件有限。ThreadLocalMap里有一套清理機(jī)制主要包括三個(gè)方法expungeStaleEntry(int staleSlot)清理指定槽位的臟 Entry同時(shí)把后續(xù)因沖突而錯(cuò)位的 Entry 重新哈希放入正確位置。cleanSomeSlots(int i, int n)從指定位置向后掃描找到臟 Entry 就調(diào)用expungeStaleEntry清理掃描次數(shù)是log2(n)有上限。replaceStaleEntry(key, value, staleSlot)set()過(guò)程中發(fā)現(xiàn)臟 Entry 時(shí)不新開(kāi)槽位直接用新值替換掉舊槽位并完成清理操作。這些方法在get()、set()、擴(kuò)容rehash()的過(guò)程中會(huì)被觸發(fā)。比如set()方法遍歷探測(cè)時(shí)遇到k null就會(huì)調(diào)用replaceStaleEntrygetEntryAfterMiss遇到臟 Entry 也會(huì)觸發(fā)expungeStaleEntry。但注意這些清理都是被動(dòng)觸發(fā)的只有當(dāng)某個(gè)操作恰好經(jīng)過(guò)臟 Entry 所在的槽位時(shí)清理才會(huì)發(fā)生。如果線程后續(xù)一直沒(méi)有訪問(wèn)這個(gè) ThreadLocal對(duì)應(yīng)的臟 Entry 就永遠(yuǎn)躺在數(shù)組里。ThreadLocalMap不會(huì)在后臺(tái)掃描也沒(méi)有專門的線程去清理。這個(gè)設(shè)計(jì)取舍可以理解——為了性能把清理動(dòng)作合并到常規(guī)操作里避免每次get都全表掃描。但代價(jià)就是你不主動(dòng)清理就沒(méi)有人替你清理。4.3 remove 的底層實(shí)現(xiàn)為什么它能真正斷根既然被動(dòng)清理靠不住主動(dòng)權(quán)就得回到使用者手里。ThreadLocal.remove()的線程內(nèi)調(diào)用鏈public void remove() { ThreadLocalMap m getMap(Thread.currentThread()); if (m ! null) { m.remove(this); } }ThreadLocalMap.remove的源碼private void remove(ThreadLocal? key) { 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)]) { if (e.get() key) { e.clear(); // 斷開(kāi) ThreadLocal 的引用讓 key 變 null expungeStaleEntry(i); // 清理 value并重新哈希后續(xù) entry return; } } }e.clear()是Reference類提供的方法直接把referent置為 null緊接著的expungeStaleEntry會(huì)把 value 也置空。所以remove()之后key 和 value 都不再被線程持有整個(gè)槽位恢復(fù)為 nullGC 可以正?；厥諛I(yè)務(wù)對(duì)象。這就是為什么所有規(guī)范都強(qiáng)調(diào)“用完必須 remove”——它是唯一能同時(shí)清理 key 和 value 的手段。我見(jiàn)過(guò)很多代碼只在finally塊里寫threadLocal.remove()就覺(jué)得很安心了但忘了如果 value 是一個(gè)巨大的對(duì)象集合不 remove 的直接后果就是線程池線程越多殘留越大。經(jīng)典的 OOM 報(bào)告里堆內(nèi)存分析顯示大量的byte[]或自定義業(yè)務(wù)對(duì)象被ThreadLocalMap引用基本就是這個(gè)原因。提示在 JDK 8 及以后的版本中ThreadLocalMap的被動(dòng)清理邏輯已經(jīng)比較完善但你永遠(yuǎn)不應(yīng)該依賴它“恰好幫你清掉”。它只是兜底不是保證。5. 這個(gè)“為什么”直接決定了使用姿勢(shì)從設(shè)計(jì)反推編碼規(guī)范5.1 凡是線程池環(huán)境try-finally 里必須 remove這段規(guī)范應(yīng)該是每個(gè) Java 工程師的肌肉記憶但背后的理由和弱引用設(shè)計(jì)是直接關(guān)聯(lián)的。線程池線程的生命周期極長(zhǎng)如果不在finally里清理ThreadLocalMap 中的 Entry 就會(huì)長(zhǎng)期殘留ThreadLocalUserContext context new ThreadLocal(); try { context.set(userInfo); // 業(yè)務(wù)邏輯... } finally { context.remove(); }為什么強(qiáng)調(diào)finally因?yàn)闃I(yè)務(wù)代碼中途拋異常、提前 return都會(huì)跳過(guò)remove()只有finally能保證“無(wú)論走那條路都執(zhí)行清理”。尤其在異步框架、消息處理器、定時(shí)任務(wù)調(diào)度器里線程復(fù)用非常頻繁一次殘留可能影響后續(xù)幾十次任務(wù)的數(shù)據(jù)隔離。這個(gè)寫法不是“規(guī)范好看”而是直接對(duì)應(yīng)源碼里那個(gè)被動(dòng)清理機(jī)制——你不動(dòng)手沒(méi)人動(dòng)手。還有一個(gè)容易被忽略的細(xì)節(jié)remove()之后再get()會(huì)返回初始值不會(huì)拋異常但如果你只是把ThreadLocal對(duì)象設(shè)為 null而不是調(diào)用remove()那 entry 還在value 殘留問(wèn)題依然存在。清理對(duì)象和清理 ThreadLocalMap 的 entry是兩個(gè)層面的事。5.2 ThreadLocal 建議定義成 static 的底層原因“ThreadLocal 要定義為 static”這條最佳實(shí)踐很多人只當(dāng)作教條背其實(shí)和弱引用也有關(guān)系。如果不是 static每個(gè)實(shí)例化的類對(duì)象都會(huì)創(chuàng)建自己的ThreadLocal實(shí)例線程里保存的 entry key 是各類實(shí)例特有的 ThreadLocal 對(duì)象。如果這個(gè)宿主對(duì)象被回收而線程還在弱引用 key 就會(huì)被回收——雖然不會(huì)造成 ThreadLocal 泄漏但會(huì)帶來(lái)一個(gè)更隱蔽的問(wèn)題同一個(gè)線程里相同的語(yǔ)義字段可能對(duì)應(yīng)多個(gè)不同的 ThreadLocal 實(shí)例容易傳錯(cuò)或拿不到。而 static 的 ThreadLocal 由類的強(qiáng)引用持有ThreadLocal 對(duì)象本身永遠(yuǎn)不會(huì)被 GC 回收key 始終有效同時(shí)全局只有一個(gè)實(shí)例語(yǔ)義唯一線程的get()才能穩(wěn)定命中。這是代碼層面最穩(wěn)妥的使用姿勢(shì)。注意static 并不能免掉remove()。static 只保證 key 不丟value 的殘留完全不受影響。很多人以為把ThreadLocal定義成 static 就安全了結(jié)果線上一跑內(nèi)存就漲——因?yàn)?value 仍然由線程強(qiáng)引用和 key 弱不弱沒(méi)有關(guān)系。5.3 如何用工具確認(rèn) ThreadLocal 相關(guān)的內(nèi)存殘留遇到內(nèi)存異常上漲時(shí)如果懷疑 ThreadLocal可以按這幾步排查用jmap -histo:live pid查看存活實(shí)例重點(diǎn)看java.lang.ThreadLocal和java.lang.ThreadLocal$ThreadLocalMap$Entry的數(shù)量。正常應(yīng)用里 ThreadLocal 實(shí)例數(shù)應(yīng)該和業(yè)務(wù)類數(shù)量一個(gè)量級(jí)如果數(shù)量上千上萬(wàn)說(shuō)明有大量 ThreadLocal 對(duì)象沒(méi)被回收。用jmap -dump:formatb,fileheap.hprof pid抓堆快照再用 MATMemory Analyzer Tool打開(kāi)。在 MAT 的Dominator Tree里搜索ThreadLocalMap$Entry可以看到每個(gè) Entry 的 value 是什么對(duì)象、被哪條引用鏈?；?。對(duì)比活躍線程數(shù)。如果Entry數(shù)量遠(yuǎn)超活躍線程數(shù)幾乎可以斷定有大量臟 Entry 在數(shù)組中堆積。此時(shí)再定位每個(gè) Entry 的 value 來(lái)自哪段業(yè)務(wù)代碼基本就能找到?jīng)]有執(zhí)行remove()的地方。這套排查流程我實(shí)際跑過(guò)不止一次。最典型的結(jié)果是某個(gè)攔截器、過(guò)濾器里往 ThreadLocal 塞了用戶信息或請(qǐng)求體然后忘了清理。內(nèi)存畫像非常清晰——大量Entry的 value 指向同一個(gè)業(yè)務(wù)對(duì)象類型數(shù)量等于歷史請(qǐng)求峰值線程數(shù)。6. 面試與實(shí)戰(zhàn)怎么把這個(gè)問(wèn)題講清楚、用明白6.1 一套直接可用的面試回答框架如果面試官問(wèn)“為什么 ThreadLocal 的 key 要用弱引用”不要只回一句“防止內(nèi)存泄漏”。按照下面這個(gè)順序答基本能覆蓋考點(diǎn)結(jié)構(gòu)層ThreadLocalMap.Entry繼承WeakReferenceThreadLocal?key 是弱引用value 是強(qiáng)引用Entry 數(shù)組存放在線程對(duì)象的threadLocals字段里。生命周期層線程池線程存活時(shí)間長(zhǎng)ThreadLocal 對(duì)象生命周期通常很短。如果 key 是強(qiáng)引用ThreadLocal 對(duì)象就會(huì)跟著線程一直活到線程銷毀短生命周期對(duì)象被長(zhǎng)生命周期容器鎖死形成 key 泄漏。反證強(qiáng)引用尤其在線程池場(chǎng)景里線程不銷毀ThreadLocal 對(duì)象不回收。如果 ThreadLocal 是被匿名內(nèi)部類創(chuàng)建的還會(huì)連帶引用外部類和 ClassLoader導(dǎo)致類加載器泄漏、熱部署內(nèi)存溢出。軟引用不可行軟引用只在內(nèi)存不足時(shí)回收回收時(shí)機(jī)和“外部引用消失”不同步無(wú)法保證及時(shí)清理。副作用與補(bǔ)償弱引用讓 key 可以及時(shí)回收但 value 是強(qiáng)引用所以線程里可能殘留臟 Entry。被動(dòng)清理機(jī)制只在 get/set 時(shí)觸發(fā)不可靠工程上必須用remove()在 finally 中顯式清理。實(shí)踐結(jié)論ThreadLocal 定義成 static 保證 key 穩(wěn)定線程池環(huán)境必須 try-finally remove不要依賴隱式清理。這套答法從源碼走向設(shè)計(jì)權(quán)衡再落到工程實(shí)踐每一個(gè)追問(wèn)都有內(nèi)容接得住。關(guān)鍵是第 5 點(diǎn)它能區(qū)分“背過(guò)結(jié)論”和“真正理解設(shè)計(jì)”。6.2 我在線上排查時(shí)遇到的一個(gè)真實(shí)場(chǎng)景最后分享一次實(shí)際排查經(jīng)歷。當(dāng)時(shí)的現(xiàn)象是一個(gè)網(wǎng)關(guān)服務(wù)運(yùn)行幾天后堆內(nèi)存持續(xù)上漲最終 OOM。抓了 heap dump 后看到大量ThreadLocalMap$Entry的 value 指向一個(gè)自定義的UserPermission對(duì)象數(shù)量在幾千左右。順著引用鏈往回追發(fā)現(xiàn)是一個(gè)權(quán)限校驗(yàn)攔截器把所有請(qǐng)求的用戶權(quán)限信息塞進(jìn)了 ThreadLocal但攔截器是在preHandle里存入在afterCompletion里忘記刪除。網(wǎng)關(guān)的線程池線程處理完請(qǐng)求后回池下個(gè)請(qǐng)求復(fù)用了同一個(gè)線程——雖然中間也會(huì)調(diào)用權(quán)限校驗(yàn)但并不是每個(gè)請(qǐng)求都會(huì)走到同一段代碼路徑臟 Entry 越來(lái)越多最終把堆頂爆。修復(fù)很簡(jiǎn)單在攔截器的afterCompletion里補(bǔ)上remove()。但這個(gè)問(wèn)題背后真正值得記住的是ThreadLocal的弱引用設(shè)計(jì)防住了 key 泄漏卻把“是不是會(huì)泄漏”的決定權(quán)交到了每個(gè)開(kāi)發(fā)者手里。設(shè)計(jì)者無(wú)法替你寫remove()只能通過(guò)引用類型的選擇把最危險(xiǎn)的那部分風(fēng)險(xiǎn)——ThreadLocal 對(duì)象和 ClassLoader 被長(zhǎng)周期線程釘死——從語(yǔ)言層面排除掉。剩下的價(jià)值管理是使用者的責(zé)任。所以“為什么用弱引用”這個(gè)問(wèn)題的完整答案其實(shí)是一份設(shè)計(jì)說(shuō)明書它告訴我們這個(gè)數(shù)據(jù)結(jié)構(gòu)會(huì)在什么時(shí)候幫你兜底又會(huì)在什么時(shí)候需要你親自出手?？炊@一層面試時(shí)你能侃侃而談排障時(shí)你能一眼定位問(wèn)題。這個(gè)知識(shí)點(diǎn)值得好好吃透。