組索引方案設(shè)計(jì)與實(shí)踐)
1. 先說結(jié)論ThreadLocal 沒那么神真正快的是數(shù)組索引方案最近我把網(wǎng)關(guān)里一組高頻讀寫的 ThreadLocal 變量換成了數(shù)組索引型本地線程變量單線程內(nèi) set/get 混合壓測(cè)下來大概快了 2 到 3 倍接口整體延時(shí)也降了一截。這不是什么黑魔法原理很簡(jiǎn)單ThreadLocal 內(nèi)部靠“散列 線性探測(cè)”找變量而數(shù)組索引方案直接靠下標(biāo)定位變量。這篇文章我會(huì)拆開 ThreadLocal 的查詢鏈路然后給出一個(gè)可以運(yùn)行的最小實(shí)現(xiàn)最后聊聊哪些場(chǎng)景適合替換哪些場(chǎng)景別亂動(dòng)。如果你正在用 ThreadLocal 存用戶上下文、鏈路信息或者你在寫中間件建議看完再?zèng)Q定要不要上這套優(yōu)化。1.1 我為什么動(dòng)了換掉它的念頭ThreadLocal 用起來確實(shí)舒服每個(gè)線程只需 get/set不用傳參。但我們的網(wǎng)關(guān)里每個(gè)請(qǐng)求要讀五六個(gè)上下文變量比如請(qǐng)求 ID、用戶 ID、環(huán)境標(biāo)識(shí)、租戶信息每個(gè)組件各定義各的 ThreadLocal。最近壓測(cè)時(shí)用性能分析工具看熱點(diǎn)發(fā)現(xiàn) ThreadLocal.get 相關(guān)方法在調(diào)用棧上出現(xiàn)得很頻繁單看每個(gè)方法不大但累加起來量很可觀。進(jìn)一步看實(shí)現(xiàn)才發(fā)現(xiàn)它取一個(gè)變量不是“拿一下”那么簡(jiǎn)單中間要經(jīng)過 ThreadLocalMap 的散列定位、沖突探測(cè)甚至可能觸發(fā)擴(kuò)容。對(duì)于高吞吐、方法調(diào)用密集的鏈路這就是不必要的開銷。同時(shí)我們也遇到過一個(gè)內(nèi)存問題某業(yè)務(wù)線程池里的線程長(zhǎng)期存活業(yè)務(wù)代碼只 set 不 remove導(dǎo)致一批上下文對(duì)象遲遲釋放不掉最后只能靠重啟緩解。ThreadLocal 的便利背后是有代價(jià)的它把隔離性做到了但把查找成本和生命周期成本都留給了使用者。后來我決定把核心鏈路上幾個(gè)最常見的 ThreadLocal 換掉才有了這篇文章的實(shí)踐。1.2 ThreadLocalMap 的查找策略開放地址法越用越慢ThreadLocal 的數(shù)據(jù)結(jié)構(gòu)常被忽略。每個(gè) Thread 內(nèi)部有一個(gè) ThreadLocalMap它是一個(gè)自定義的哈希表用 Entry 數(shù)組存儲(chǔ)。Entry 的 key 是 ThreadLocal 實(shí)例本身value 是你塞進(jìn)去的對(duì)象。插入和查找時(shí)會(huì)對(duì) key 的 threadLocalHashCode 做一次與運(yùn)算得到桶位index key.threadLocalHashCode (table.length - 1)。如果這個(gè)位置已經(jīng)被別的 Entry 占住它不會(huì)像 HashMap 那樣用鏈表而是繼續(xù)往下探測(cè)下一個(gè)位置也就是線性探測(cè)。一旦變量數(shù)量接近容量閾值沖突概率上升set 和 get 都可能在探測(cè)循環(huán)里多跑幾步。雖然 JDK 給 ThreadLocal 設(shè)計(jì)了一個(gè)很特別的哈希增量 0x61c88647能盡量把不同實(shí)例的桶位分散開但“分散”不等于“無沖突”尤其當(dāng)項(xiàng)目里 ThreadLocal 實(shí)例特別多時(shí)查找開銷會(huì)逐漸上漲。另一個(gè)問題ThreadLocalMap 在 set 時(shí)會(huì)檢測(cè)并清理探測(cè)路徑上那些 key 已被回收的 Entry但這只在調(diào)用 set 的時(shí)候發(fā)生而且清理也只是某一段路徑。如果你的業(yè)務(wù)線程很少調(diào)用 set獲取值以 get 為主一些廢棄 Entry 就會(huì)長(zhǎng)期存留。還有擴(kuò)容當(dāng) Entry 數(shù)量超過閾值ThreadLocalMap 會(huì)重建數(shù)組并重新 rehash這是偶發(fā)但代價(jià)很高的操作。所以說 ThreadLocal 每次 get 都是“散列 探測(cè) 類型檢查”和直接訪問普通字段完全不是一個(gè)量級(jí)。1.3 弱引用 key 也救不了 value 泄漏ThreadLocalMap 的 Entry 繼承自 WeakReference這在設(shè)計(jì)上是想解決“ThreadLocal 對(duì)象被回收”的問題。假設(shè)你在一個(gè)方法里 new 了一個(gè) ThreadLocal用完之后局部變量消失此時(shí) Entry 的 key 因?yàn)槿跻每梢员换厥盏?value 仍然被 Entry 強(qiáng)引用著。只要這個(gè)線程還活著value 就清理不掉。為什么說它是泄漏因?yàn)樗加枚褍?nèi)存且無法通過 GC 自動(dòng)清理除非之后有其他 set 或 get 操作恰好清理到該槽位。在池化的線程中線程生命周期很長(zhǎng)如果業(yè)務(wù)不斷創(chuàng)建 ThreadLocal 對(duì)象并設(shè)置 value 而忘記 remove這就是一個(gè)長(zhǎng)期累積的坑。網(wǎng)上很多資料把問題全賴在弱引用上其實(shí)弱引用已經(jīng)把 key 的問題解決了大半真正的風(fēng)險(xiǎn)是 value 強(qiáng)引用。JDK 也提供了 remove 方法來幫助處理這個(gè)問題。但業(yè)務(wù)代碼很少會(huì)記得在 finally 里 remove。這一點(diǎn)是所有“線程綁定的變量”的共同難題不是換成數(shù)組索引方案就能自動(dòng)消失的。下面要講的優(yōu)化方案解決的是“更快”的問題而“及時(shí)清理”依然要靠代碼紀(jì)律。2. 拆解“吊打”背后的設(shè)計(jì)數(shù)組下標(biāo)直取2.1 從“搜抽屜”到“按號(hào)取件”在單線程內(nèi)每個(gè)變量如果能夠有一個(gè)固定編號(hào)線程又有一個(gè)“抽屜數(shù)組”那么 set 和 get 就變成Object[] variables threadVariables; variables[index] value; // set Object value variables[index]; // get這個(gè)操作沒有任何散列計(jì)算也沒有循環(huán)探測(cè)。數(shù)組只需要一次內(nèi)存訪問甚至 JIT 會(huì)優(yōu)化邊界檢查再加一次強(qiáng)轉(zhuǎn)就夠了。這個(gè)數(shù)組相當(dāng)于一個(gè)“按號(hào)取件”的柜子而 ThreadLocal 則是一個(gè)需要自己根據(jù)號(hào)碼找位置的倉(cāng)庫(kù)。柜子取件肯定更快但前提是你要提前分好號(hào)碼。這種思路其實(shí)不算新鮮很多高性能框架的本地線程變量就是按這個(gè)思路實(shí)現(xiàn)的。它通常叫 FastThreadLocal 之類的名字實(shí)現(xiàn)細(xì)節(jié)各有差異。我這里不點(diǎn)名具體某個(gè)框架我們按最樸素的思路自己做一個(gè)原理完全一樣。了解了原理看什么開源實(shí)現(xiàn)都不再是黑盒。2.2 下標(biāo)分配每個(gè)變量都有唯一索引關(guān)鍵問題是“固定編號(hào)”從哪來。最簡(jiǎn)單可靠的辦法是用一個(gè)靜態(tài)的 AtomicInteger 作為全局發(fā)號(hào)器。每個(gè) FastThreadLocal 實(shí)例在初始化時(shí)做一次 int index NEXT_INDEX.getAndIncrement()這個(gè)實(shí)例就永久占用該編號(hào)。所有線程里這個(gè)實(shí)例都放在數(shù)組的同一位置。比如第一個(gè)變量拿到 0第二個(gè)拿到 1以此類推。因?yàn)?FastThreadLocal 通常作為類的靜態(tài)字段使用數(shù)量級(jí)也就幾十個(gè)所以發(fā)號(hào)器遞增不會(huì)太大。每個(gè)線程的數(shù)組按需擴(kuò)容數(shù)組長(zhǎng)度取 2 的冪可以簡(jiǎn)單實(shí)現(xiàn)為訪問時(shí)如果 index 超出容量就擴(kuò)容到比 index1 大的下一個(gè) 2 的冪。為什么不直接復(fù)用 ThreadLocal 里的 threadLocalHashCode因?yàn)槟莻€(gè)值是用來做散列的不適合當(dāng)數(shù)組下標(biāo)。散列值可能很大也不唯一無法直接使用。而發(fā)號(hào)器保證連續(xù)且唯一剛好可以映射到數(shù)組下標(biāo)。這個(gè)設(shè)計(jì)犧牲了一點(diǎn)啟動(dòng)時(shí)分配成本換來了每次讀寫時(shí) O(1) 的確定性消耗。2.3 它解決的只是“單線程內(nèi)訪問”不是所有 ThreadLocal 問題雖然這套方案在讀寫速度上優(yōu)于 ThreadLocalMap但存在前提你得先從某個(gè)地方拿到“這個(gè)線程對(duì)應(yīng)的數(shù)組”。為了做到這一點(diǎn)最簡(jiǎn)單的辦法是給線程加一個(gè)字段。但 JDK 的 Thread 類字段是私有的普通線程并不開放所以一般做法是提供自定義 Thread 子類或者用一個(gè)包裝接口讓線程池創(chuàng)建線程時(shí)使用這種線程。如果線程本身不支持還得兜底退化成 ThreadLocal 或拋異常。另外它無法解決跨線程傳遞。ThreadLocal 的子類 InheritableThreadLocal 能在創(chuàng)建子線程時(shí)繼承值而數(shù)組索引方案的數(shù)組是全新的天然不會(huì)有父線程的數(shù)據(jù)。至于線程池中任務(wù)切換到另一線程兩者都無能為力需要額外的上下文傳遞組件去處理。所以“吊打”是有邊界的針對(duì)的是“同一個(gè)線程內(nèi)反復(fù)讀寫有限的幾個(gè)變量”這個(gè)場(chǎng)景而不是所有并發(fā)場(chǎng)景。3. 手寫一個(gè)可跑的極簡(jiǎn)高性能本地線程變量3.1 先給線程增加變量槽數(shù)組要零散列訪問先要有承載數(shù)組的線程。先定義接口 FastThreadLocalAccesspublic interface FastThreadLocalAccess { Object[] getIndexedVariables(); void setIndexedVariables(Object[] indexedVariables); }接著寫一個(gè)默認(rèn)線程子類 MyFastThread extends Thread implements FastThreadLocalAccess內(nèi)部用 Object[] 保存變量提供兩個(gè)方法實(shí)現(xiàn)。注意覆蓋 run 方法時(shí)這些字段自然成為當(dāng)前執(zhí)行的線程字段。自定義線程工廠創(chuàng)建線程時(shí)只需要 new MyFastThread(runnable) 即可。public class MyFastThread extends Thread implements FastThreadLocalAccess { private Object[] indexedVariables; public MyFastThread(Runnable target) { super(target); } Override public Object[] getIndexedVariables() { return indexedVariables; } Override public void setIndexedVariables(Object[] indexedVariables) { this.indexedVariables indexedVariables; } }生產(chǎn)上你還要考慮線程名、守護(hù)線程、異常處理器等這里只關(guān)注核心字段。3.2 FastThreadLocal 核心類get/set/remove現(xiàn)在實(shí)現(xiàn)主類import java.util.Arrays; import java.util.concurrent.atomic.AtomicInteger; public class FastThreadLocalV { private static final AtomicInteger NEXT_INDEX new AtomicInteger(0); private static final int INITIAL_SIZE 16; private final int index NEXT_INDEX.getAndIncrement(); public V get() { Object[] variables threadVariables(); if (variables ! null index variables.length) { Object value variables[index]; if (value ! null) { return (V) value; } } return initialize(); } public void set(V value) { Object[] variables threadVariables(); if (variables null) { variables new Object[Math.max(INITIAL_SIZE, expandedSize(index))]; } else if (index variables.length) { variables Arrays.copyOf(variables, expandedSize(index)); } ((FastThreadLocalAccess) Thread.currentThread()).setIndexedVariables(variables); variables[index] value; } public void remove() { Object[] variables threadVariables(); if (variables ! null index variables.length) { variables[index] null; } } protected V initialValue() { return null; } private V initialize() { Object[] variables threadVariables(); if (variables null) { variables new Object[Math.max(INITIAL_SIZE, expandedSize(index))]; } else if (index variables.length) { variables Arrays.copyOf(variables, expandedSize(index)); } ((FastThreadLocalAccess) Thread.currentThread()).setIndexedVariables(variables); V value initialValue(); variables[index] value; return value; } private static Object[] threadVariables() { Thread thread Thread.currentThread(); if (thread instanceof FastThreadLocalAccess) { return ((FastThreadLocalAccess) thread).getIndexedVariables(); } throw new IllegalStateException(當(dāng)前線程不支持 FastThreadLocalAccess請(qǐng)使用 MyFastThread 或自定義線程工廠); } private static int expandedSize(int targetIndex) { int cap INITIAL_SIZE; while (cap targetIndex) { cap 1; } return cap; } }這個(gè)類基本能跑了。get 方法有一個(gè)語義需要注意如果槽位里的值是 null會(huì)被當(dāng)成“未初始化”再次調(diào)用 initialValue。這和 ThreadLocal 的行為一致所以設(shè)計(jì)上要么讓 initialValue 返回非 null要么避免向變量寫入 null。set 傳 null 同樣會(huì)導(dǎo)致后續(xù) get 重新初始化。還要提醒這段代碼為了演示而縮略生產(chǎn)環(huán)境需要考慮 FastThreadLocal 對(duì)象本身的垃圾回收。上面代碼中靜態(tài) NEXT_INDEX 只發(fā)號(hào)但每個(gè) FastThreadLocal 實(shí)例并不會(huì)被自動(dòng)回收因?yàn)樗?index 綁定在一個(gè)數(shù)組槽位上如果類加載器被卸載這些槽位仍然需要清理。如果你的項(xiàng)目用熱部署動(dòng)態(tài)創(chuàng)建了大量 FastThreadLocal 實(shí)例建議用專門的清理機(jī)制或升級(jí)版方案不要直接套這個(gè)極簡(jiǎn)版。3.3 初始化時(shí)機(jī)與數(shù)組擴(kuò)容ThreadLocal 的 initialValue 在第一次 get 時(shí)調(diào)用。我們的 initialValue 同樣在 get 且槽位為空時(shí)調(diào)用。這里有個(gè)細(xì)節(jié)如果 get 首次調(diào)用時(shí)線程的數(shù)組還沒創(chuàng)建要先建數(shù)組再檢查是否需要擴(kuò)容然后調(diào)用 initialValue 并放入數(shù)組。如果 set 先調(diào)用也類似只是調(diào)用方傳入 value 而不調(diào) initialValue。擴(kuò)容處理需要注意因?yàn)閿?shù)組是每線程各自持有的擴(kuò)容只影響當(dāng)前線程。第二次擴(kuò)容后底層數(shù)組換了一個(gè)新數(shù)組引用會(huì)通過 setIndexedVariables 回寫。其他線程不受影響這個(gè)設(shè)計(jì)下不存在并發(fā)修改同一個(gè)數(shù)組的問題所以不需要加鎖。數(shù)組初始容量為什么選 16 而不是更小考慮到每個(gè)線程通常會(huì)有多個(gè) FastThreadLocal 變量16 可以容納大多數(shù)場(chǎng)景避免頻繁擴(kuò)容。如果你們的變量數(shù)少于 8可以改成 8。老實(shí)說擴(kuò)容成本不高就是一次數(shù)組拷貝但出現(xiàn)得越少越好。3.4 寫個(gè)簡(jiǎn)單壓測(cè)對(duì)比一下不依賴第三方環(huán)境直接用 nanoTime 循環(huán)測(cè)。注意必須用 MyFastThread 線程來跑否則 FastThreadLocal 會(huì)拋異常。測(cè)試代碼如下public class BenchmarkRun extends MyFastThread { Override public void run() { int warmup 1_000_000; int loop 10_000_000; ThreadLocalInteger tl new ThreadLocal(); FastThreadLocalInteger ftl new FastThreadLocal(); for (int i 0; i warmup; i) { tl.set(i); int v tl.get(); ftl.set(i); int w ftl.get(); } long start System.nanoTime(); for (int i 0; i loop; i) { tl.set(i); int v tl.get(); } long threadLocalTime System.nanoTime() - start; start System.nanoTime(); for (int i 0; i loop; i) { ftl.set(i); int v ftl.get(); } long fastThreadLocalTime System.nanoTime() - start; System.out.println(ThreadLocal: threadLocalTime / 1_000_000 ms); System.out.println(FastThreadLocal: fastThreadLocalTime / 1_000_000 ms); } public static void main(String[] args) throws Exception { new BenchmarkRun().start(); } }實(shí)際跑的時(shí)候不同機(jī)器差異很大但單變量 set/get 混合FastThreadLocal 通常比 ThreadLocal 快 2 到 5 倍。注意壓測(cè)有個(gè)陷阱如果只測(cè)讀取已存在的變量JIT 可能把整個(gè)循環(huán)優(yōu)化掉。我一般把 int value 累加到一個(gè)外部容器或者在每次循環(huán)里故意消費(fèi)掉結(jié)果避免死代碼消除。上面代碼里的 int v 和 int w 雖然沒用到理論上 JIT 也可能消除更嚴(yán)謹(jǐn)?shù)淖龇ㄊ抢奂雍蟠蛴?。自己跑的時(shí)候要加一個(gè)黑盒比如把 v 累加到 volatile 字段或者直接累計(jì)到一個(gè)對(duì)象。4. 實(shí)際替換的收益、邊界和踩坑4.1 我實(shí)測(cè)過的收益快是快但別被“吊打”帶偏我在網(wǎng)關(guān)的某個(gè)核心鏈路上把六個(gè)上下文變量從 ThreadLocal 換成數(shù)組索引方案后壓測(cè) QPS 提升了差不多 20% 到 30%。注意這個(gè)提升來自“高頻訪問 多變量”場(chǎng)景。如果業(yè)務(wù)接口一次請(qǐng)求只讀取一個(gè) ThreadLocal那么優(yōu)化幾乎感知不到。你需要訪問的變量數(shù)越多、頻率越高收益就越明顯。另外收益也要考慮現(xiàn)有線程是否支持。如果項(xiàng)目里所有線程都是普通 Thread 對(duì)象無法直接加字段你得先改線程工廠。很多框架內(nèi)部線程池是私有的不方便替換。這種情況下你可以退而求其次用 ThreadLocalObject[] 當(dāng)作線程數(shù)組的 holder首次獲取數(shù)組時(shí)仍走一次 ThreadLocalMap但后續(xù)在這個(gè)線程里訪問多個(gè) FastThreadLocal 變量時(shí)都復(fù)用同一個(gè)數(shù)組引用省掉了多次散列探測(cè)。這種半替代方案雖然不如自定義線程干凈但兼容性更好侵入性也更小。我建議從這種半替代方案開始評(píng)估收益再?zèng)Q定要不要?jiǎng)泳€程工廠。4.2 替換時(shí)最容易翻車的三個(gè)場(chǎng)景第一個(gè)是線程池。數(shù)組索引方案要求每個(gè)訪問線程都能拿出數(shù)組。線程池里的線程如果還是普通 Thread那么 get 會(huì)拋“不支持”異常。不要用 try-catch 掩蓋應(yīng)該從根源上統(tǒng)一線程工廠。你可以包裝一層創(chuàng)建線程時(shí)使用 MyFastThread或者在線程真正執(zhí)行目標(biāo)任務(wù)前把 Thread 換成支持接口的包裝類。第二個(gè)是繼承和傳遞。InheritableThreadLocal 的父子傳遞能力在數(shù)組索引方案里完全沒有。如果某個(gè)請(qǐng)求先在這個(gè)線程設(shè)置了一個(gè)變量然后交給另一個(gè)線程處理新線程中數(shù)組是空的讀出來必然是 null。解決思路很簡(jiǎn)單在執(zhí)行子任務(wù)前把上下文值作為參數(shù)顯式傳遞或者用包裝 Runnable 做變量遷移。如果你不想全鏈路改傳參建議保留 ThreadLocal 或引入專門上下文傳遞工具不要強(qiáng)行替換全部。第三個(gè)是動(dòng)態(tài)類加載。因?yàn)?index 是靜態(tài)發(fā)號(hào)器分配的每 new 一個(gè) FastThreadLocal 實(shí)例全局編號(hào)就加一。如果你在熱部署環(huán)境里反復(fù)加載類會(huì)不斷產(chǎn)生新的 FastThreadLocal 實(shí)例和新的 index舊實(shí)例又不回收每個(gè)線程數(shù)組里都占著一個(gè)槽位。時(shí)間久了數(shù)組會(huì)越來越大相當(dāng)于慢性的內(nèi)存泄漏。所以這類變量應(yīng)該做成類級(jí)別的靜態(tài)字段而不是每實(shí)例都 new。4.3 remove 的時(shí)機(jī)數(shù)組索引方案同樣需要 finally數(shù)組索引方案在 get 和 set 上很快但它不負(fù)責(zé)自動(dòng)回收值。線程數(shù)組是一個(gè)強(qiáng)引用容器只要數(shù)組槽位非空對(duì)象就不會(huì)被 GC 回收。在線程池場(chǎng)景里任務(wù)執(zhí)行完如果不 remove后續(xù)線程復(fù)用時(shí)會(huì)一直帶著上一個(gè)任務(wù)的變量既泄漏內(nèi)存又可能在下一次任務(wù)里讀到臟數(shù)據(jù)。安全寫法是在 try-finally 里釋放且只釋放每個(gè)任務(wù)開始時(shí)實(shí)際寫入的變量。不要無條件 remove 一堆變量那樣會(huì)把別的板塊設(shè)好的數(shù)據(jù)也清掉。比如FastThreadLocalString context ...; context.set(requestId); try { // do work } finally { context.remove(); }如果你同時(shí)用了多個(gè) FastThreadLocal可以封裝成一個(gè)上下文對(duì)象統(tǒng)一清理減少遺漏。這個(gè)習(xí)慣和 ThreadLocal 完全一致只是 ThreadLocal 的問題往往因?yàn)榈皖l訪問而被忽視高頻替換后如果不養(yǎng)成 remove 習(xí)慣問題會(huì)被放大。4.4 常見問題速查表問題可能原因解決辦法調(diào)用 get 拋 IllegalStateException當(dāng)前線程不是 FastThreadLocalAccess 子類線程工廠中統(tǒng)一使用自定義線程子線程或異步任務(wù)讀不到值數(shù)組索引方案沒有父子繼承顯式傳參或使用包裝 Runnable 遷移數(shù)據(jù)池化線程再次執(zhí)行任務(wù)時(shí)讀到舊值任務(wù)結(jié)束后沒有 removefinally 中調(diào)用 remove只清本任務(wù)設(shè)置過的變量熱部署后數(shù)組越來越大動(dòng)態(tài) new FastThreadLocal 實(shí)例占用新的 index用靜態(tài)字段持有變量杜絕每請(qǐng)求創(chuàng)建value 為 null 時(shí) get 行為異常槽位 null 被當(dāng)成未初始化initialValue 返回非 null或避免存儲(chǔ) nullset 后又 get 仍為空線程數(shù)組被替換或 remove 掉了檢查是否有其他代碼調(diào)用 remove 或持有錯(cuò)誤數(shù)組4.5 虛擬線程出現(xiàn)后還需要 ThreadLocal 嗎如果你已經(jīng)開始用虛擬線程會(huì)發(fā)現(xiàn)大量虛擬線程意味著大量線程對(duì)象ThreadLocal 的內(nèi)存占用和生命周期問題會(huì)被進(jìn)一步放大。Java 社區(qū)這幾年也在推動(dòng)更輕量的上下文傳遞方式比如把值作為參數(shù)顯式下傳或者使用不可變局部綁定。數(shù)組索引方案依賴線程對(duì)象字段虛擬線程如果支持這種訪問方式性能優(yōu)勢(shì)仍在但不同實(shí)現(xiàn)環(huán)境對(duì)線程字段的處理不一樣不能指望所有地方都按同一套來。我的建議是如果你的主要場(chǎng)景是虛擬線程優(yōu)先考慮上下文的顯式傳遞而不是繼續(xù)堆 ThreadLocal 或類 ThreadLocal 工具。等真正需要線程本地變量再按具體實(shí)現(xiàn)框架的特點(diǎn)選擇。最后分享一個(gè)我個(gè)人的習(xí)慣我不會(huì)把項(xiàng)目里所有 ThreadLocal 都換掉因?yàn)樘鎿Q本身有侵入成本而且大部分業(yè)務(wù)接口對(duì) ThreadLocal 的訪問頻率遠(yuǎn)沒有到瓶頸。只有在明確的熱點(diǎn)鏈路上并且能控制線程創(chuàng)建和變量清理的前提下我才會(huì)用數(shù)組索引方案。改動(dòng)時(shí)也從一兩個(gè)變量開始?jí)簻y(cè)、觀察內(nèi)存再逐步鋪開。真正常用的不是“吊打”這個(gè)詞而是對(duì)每次讀寫成本的敏感度。你下次寫并發(fā)代碼前不妨先問自己這個(gè)變量真的需要綁定線程嗎如果只是在一個(gè)請(qǐng)求里傳遞狀態(tài)傳參也許才是最便宜的方式。 拆解ThreadLocal性能困境：數(shù)組索引方案設(shè)計(jì)與實(shí)踐
1. 先說結(jié)論ThreadLocal 沒那么神真正快的是數(shù)組索引方案最近我把網(wǎng)關(guān)里一組高頻讀寫的 ThreadLocal 變量換成了數(shù)組索引型本地線程變量單線程內(nèi) set/get 混合壓測(cè)下來大概快了 2 到 3 倍接口整體延時(shí)也降了一截。這不是什么黑魔法原理很簡(jiǎn)單ThreadLocal 內(nèi)部靠“散列 線性探測(cè)”找變量而數(shù)組索引方案直接靠下標(biāo)定位變量。這篇文章我會(huì)拆開 ThreadLocal 的查詢鏈路然后給出一個(gè)可以運(yùn)行的最小實(shí)現(xiàn)最后聊聊哪些場(chǎng)景適合替換哪些場(chǎng)景別亂動(dòng)。如果你正在用 ThreadLocal 存用戶上下文、鏈路信息或者你在寫中間件建議看完再?zèng)Q定要不要上這套優(yōu)化。1.1 我為什么動(dòng)了換掉它的念頭ThreadLocal 用起來確實(shí)舒服每個(gè)線程只需 get/set不用傳參。但我們的網(wǎng)關(guān)里每個(gè)請(qǐng)求要讀五六個(gè)上下文變量比如請(qǐng)求 ID、用戶 ID、環(huán)境標(biāo)識(shí)、租戶信息每個(gè)組件各定義各的 ThreadLocal。最近壓測(cè)時(shí)用性能分析工具看熱點(diǎn)發(fā)現(xiàn) ThreadLocal.get 相關(guān)方法在調(diào)用棧上出現(xiàn)得很頻繁單看每個(gè)方法不大但累加起來量很可觀。進(jìn)一步看實(shí)現(xiàn)才發(fā)現(xiàn)它取一個(gè)變量不是“拿一下”那么簡(jiǎn)單中間要經(jīng)過 ThreadLocalMap 的散列定位、沖突探測(cè)甚至可能觸發(fā)擴(kuò)容。對(duì)于高吞吐、方法調(diào)用密集的鏈路這就是不必要的開銷。同時(shí)我們也遇到過一個(gè)內(nèi)存問題某業(yè)務(wù)線程池里的線程長(zhǎng)期存活業(yè)務(wù)代碼只 set 不 remove導(dǎo)致一批上下文對(duì)象遲遲釋放不掉最后只能靠重啟緩解。ThreadLocal 的便利背后是有代價(jià)的它把隔離性做到了但把查找成本和生命周期成本都留給了使用者。后來我決定把核心鏈路上幾個(gè)最常見的 ThreadLocal 換掉才有了這篇文章的實(shí)踐。1.2 ThreadLocalMap 的查找策略開放地址法越用越慢ThreadLocal 的數(shù)據(jù)結(jié)構(gòu)常被忽略。每個(gè) Thread 內(nèi)部有一個(gè) ThreadLocalMap它是一個(gè)自定義的哈希表用 Entry 數(shù)組存儲(chǔ)。Entry 的 key 是 ThreadLocal 實(shí)例本身value 是你塞進(jìn)去的對(duì)象。插入和查找時(shí)會(huì)對(duì) key 的 threadLocalHashCode 做一次與運(yùn)算得到桶位index key.threadLocalHashCode (table.length - 1)。如果這個(gè)位置已經(jīng)被別的 Entry 占住它不會(huì)像 HashMap 那樣用鏈表而是繼續(xù)往下探測(cè)下一個(gè)位置也就是線性探測(cè)。一旦變量數(shù)量接近容量閾值沖突概率上升set 和 get 都可能在探測(cè)循環(huán)里多跑幾步。雖然 JDK 給 ThreadLocal 設(shè)計(jì)了一個(gè)很特別的哈希增量 0x61c88647能盡量把不同實(shí)例的桶位分散開但“分散”不等于“無沖突”尤其當(dāng)項(xiàng)目里 ThreadLocal 實(shí)例特別多時(shí)查找開銷會(huì)逐漸上漲。另一個(gè)問題ThreadLocalMap 在 set 時(shí)會(huì)檢測(cè)并清理探測(cè)路徑上那些 key 已被回收的 Entry但這只在調(diào)用 set 的時(shí)候發(fā)生而且清理也只是某一段路徑。如果你的業(yè)務(wù)線程很少調(diào)用 set獲取值以 get 為主一些廢棄 Entry 就會(huì)長(zhǎng)期存留。還有擴(kuò)容當(dāng) Entry 數(shù)量超過閾值ThreadLocalMap 會(huì)重建數(shù)組并重新 rehash這是偶發(fā)但代價(jià)很高的操作。所以說 ThreadLocal 每次 get 都是“散列 探測(cè) 類型檢查”和直接訪問普通字段完全不是一個(gè)量級(jí)。1.3 弱引用 key 也救不了 value 泄漏ThreadLocalMap 的 Entry 繼承自 WeakReference這在設(shè)計(jì)上是想解決“ThreadLocal 對(duì)象被回收”的問題。假設(shè)你在一個(gè)方法里 new 了一個(gè) ThreadLocal用完之后局部變量消失此時(shí) Entry 的 key 因?yàn)槿跻每梢员换厥盏?value 仍然被 Entry 強(qiáng)引用著。只要這個(gè)線程還活著value 就清理不掉。為什么說它是泄漏因?yàn)樗加枚褍?nèi)存且無法通過 GC 自動(dòng)清理除非之后有其他 set 或 get 操作恰好清理到該槽位。在池化的線程中線程生命周期很長(zhǎng)如果業(yè)務(wù)不斷創(chuàng)建 ThreadLocal 對(duì)象并設(shè)置 value 而忘記 remove這就是一個(gè)長(zhǎng)期累積的坑。網(wǎng)上很多資料把問題全賴在弱引用上其實(shí)弱引用已經(jīng)把 key 的問題解決了大半真正的風(fēng)險(xiǎn)是 value 強(qiáng)引用。JDK 也提供了 remove 方法來幫助處理這個(gè)問題。但業(yè)務(wù)代碼很少會(huì)記得在 finally 里 remove。這一點(diǎn)是所有“線程綁定的變量”的共同難題不是換成數(shù)組索引方案就能自動(dòng)消失的。下面要講的優(yōu)化方案解決的是“更快”的問題而“及時(shí)清理”依然要靠代碼紀(jì)律。2. 拆解“吊打”背后的設(shè)計(jì)數(shù)組下標(biāo)直取2.1 從“搜抽屜”到“按號(hào)取件”在單線程內(nèi)每個(gè)變量如果能夠有一個(gè)固定編號(hào)線程又有一個(gè)“抽屜數(shù)組”那么 set 和 get 就變成Object[] variables threadVariables; variables[index] value; // set Object value variables[index]; // get這個(gè)操作沒有任何散列計(jì)算也沒有循環(huán)探測(cè)。數(shù)組只需要一次內(nèi)存訪問甚至 JIT 會(huì)優(yōu)化邊界檢查再加一次強(qiáng)轉(zhuǎn)就夠了。這個(gè)數(shù)組相當(dāng)于一個(gè)“按號(hào)取件”的柜子而 ThreadLocal 則是一個(gè)需要自己根據(jù)號(hào)碼找位置的倉(cāng)庫(kù)。柜子取件肯定更快但前提是你要提前分好號(hào)碼。這種思路其實(shí)不算新鮮很多高性能框架的本地線程變量就是按這個(gè)思路實(shí)現(xiàn)的。它通常叫 FastThreadLocal 之類的名字實(shí)現(xiàn)細(xì)節(jié)各有差異。我這里不點(diǎn)名具體某個(gè)框架我們按最樸素的思路自己做一個(gè)原理完全一樣。了解了原理看什么開源實(shí)現(xiàn)都不再是黑盒。2.2 下標(biāo)分配每個(gè)變量都有唯一索引關(guān)鍵問題是“固定編號(hào)”從哪來。最簡(jiǎn)單可靠的辦法是用一個(gè)靜態(tài)的 AtomicInteger 作為全局發(fā)號(hào)器。每個(gè) FastThreadLocal 實(shí)例在初始化時(shí)做一次 int index NEXT_INDEX.getAndIncrement()這個(gè)實(shí)例就永久占用該編號(hào)。所有線程里這個(gè)實(shí)例都放在數(shù)組的同一位置。比如第一個(gè)變量拿到 0第二個(gè)拿到 1以此類推。因?yàn)?FastThreadLocal 通常作為類的靜態(tài)字段使用數(shù)量級(jí)也就幾十個(gè)所以發(fā)號(hào)器遞增不會(huì)太大。每個(gè)線程的數(shù)組按需擴(kuò)容數(shù)組長(zhǎng)度取 2 的冪可以簡(jiǎn)單實(shí)現(xiàn)為訪問時(shí)如果 index 超出容量就擴(kuò)容到比 index1 大的下一個(gè) 2 的冪。為什么不直接復(fù)用 ThreadLocal 里的 threadLocalHashCode因?yàn)槟莻€(gè)值是用來做散列的不適合當(dāng)數(shù)組下標(biāo)。散列值可能很大也不唯一無法直接使用。而發(fā)號(hào)器保證連續(xù)且唯一剛好可以映射到數(shù)組下標(biāo)。這個(gè)設(shè)計(jì)犧牲了一點(diǎn)啟動(dòng)時(shí)分配成本換來了每次讀寫時(shí) O(1) 的確定性消耗。2.3 它解決的只是“單線程內(nèi)訪問”不是所有 ThreadLocal 問題雖然這套方案在讀寫速度上優(yōu)于 ThreadLocalMap但存在前提你得先從某個(gè)地方拿到“這個(gè)線程對(duì)應(yīng)的數(shù)組”。為了做到這一點(diǎn)最簡(jiǎn)單的辦法是給線程加一個(gè)字段。但 JDK 的 Thread 類字段是私有的普通線程并不開放所以一般做法是提供自定義 Thread 子類或者用一個(gè)包裝接口讓線程池創(chuàng)建線程時(shí)使用這種線程。如果線程本身不支持還得兜底退化成 ThreadLocal 或拋異常。另外它無法解決跨線程傳遞。ThreadLocal 的子類 InheritableThreadLocal 能在創(chuàng)建子線程時(shí)繼承值而數(shù)組索引方案的數(shù)組是全新的天然不會(huì)有父線程的數(shù)據(jù)。至于線程池中任務(wù)切換到另一線程兩者都無能為力需要額外的上下文傳遞組件去處理。所以“吊打”是有邊界的針對(duì)的是“同一個(gè)線程內(nèi)反復(fù)讀寫有限的幾個(gè)變量”這個(gè)場(chǎng)景而不是所有并發(fā)場(chǎng)景。3. 手寫一個(gè)可跑的極簡(jiǎn)高性能本地線程變量3.1 先給線程增加變量槽數(shù)組要零散列訪問先要有承載數(shù)組的線程。先定義接口 FastThreadLocalAccesspublic interface FastThreadLocalAccess { Object[] getIndexedVariables(); void setIndexedVariables(Object[] indexedVariables); }接著寫一個(gè)默認(rèn)線程子類 MyFastThread extends Thread implements FastThreadLocalAccess內(nèi)部用 Object[] 保存變量提供兩個(gè)方法實(shí)現(xiàn)。注意覆蓋 run 方法時(shí)這些字段自然成為當(dāng)前執(zhí)行的線程字段。自定義線程工廠創(chuàng)建線程時(shí)只需要 new MyFastThread(runnable) 即可。public class MyFastThread extends Thread implements FastThreadLocalAccess { private Object[] indexedVariables; public MyFastThread(Runnable target) { super(target); } Override public Object[] getIndexedVariables() { return indexedVariables; } Override public void setIndexedVariables(Object[] indexedVariables) { this.indexedVariables indexedVariables; } }生產(chǎn)上你還要考慮線程名、守護(hù)線程、異常處理器等這里只關(guān)注核心字段。3.2 FastThreadLocal 核心類get/set/remove現(xiàn)在實(shí)現(xiàn)主類import java.util.Arrays; import java.util.concurrent.atomic.AtomicInteger; public class FastThreadLocalV { private static final AtomicInteger NEXT_INDEX new AtomicInteger(0); private static final int INITIAL_SIZE 16; private final int index NEXT_INDEX.getAndIncrement(); public V get() { Object[] variables threadVariables(); if (variables ! null index variables.length) { Object value variables[index]; if (value ! null) { return (V) value; } } return initialize(); } public void set(V value) { Object[] variables threadVariables(); if (variables null) { variables new Object[Math.max(INITIAL_SIZE, expandedSize(index))]; } else if (index variables.length) { variables Arrays.copyOf(variables, expandedSize(index)); } ((FastThreadLocalAccess) Thread.currentThread()).setIndexedVariables(variables); variables[index] value; } public void remove() { Object[] variables threadVariables(); if (variables ! null index variables.length) { variables[index] null; } } protected V initialValue() { return null; } private V initialize() { Object[] variables threadVariables(); if (variables null) { variables new Object[Math.max(INITIAL_SIZE, expandedSize(index))]; } else if (index variables.length) { variables Arrays.copyOf(variables, expandedSize(index)); } ((FastThreadLocalAccess) Thread.currentThread()).setIndexedVariables(variables); V value initialValue(); variables[index] value; return value; } private static Object[] threadVariables() { Thread thread Thread.currentThread(); if (thread instanceof FastThreadLocalAccess) { return ((FastThreadLocalAccess) thread).getIndexedVariables(); } throw new IllegalStateException(當(dāng)前線程不支持 FastThreadLocalAccess請(qǐng)使用 MyFastThread 或自定義線程工廠); } private static int expandedSize(int targetIndex) { int cap INITIAL_SIZE; while (cap targetIndex) { cap 1; } return cap; } }這個(gè)類基本能跑了。get 方法有一個(gè)語義需要注意如果槽位里的值是 null會(huì)被當(dāng)成“未初始化”再次調(diào)用 initialValue。這和 ThreadLocal 的行為一致所以設(shè)計(jì)上要么讓 initialValue 返回非 null要么避免向變量寫入 null。set 傳 null 同樣會(huì)導(dǎo)致后續(xù) get 重新初始化。還要提醒這段代碼為了演示而縮略生產(chǎn)環(huán)境需要考慮 FastThreadLocal 對(duì)象本身的垃圾回收。上面代碼中靜態(tài) NEXT_INDEX 只發(fā)號(hào)但每個(gè) FastThreadLocal 實(shí)例并不會(huì)被自動(dòng)回收因?yàn)樗?index 綁定在一個(gè)數(shù)組槽位上如果類加載器被卸載這些槽位仍然需要清理。如果你的項(xiàng)目用熱部署動(dòng)態(tài)創(chuàng)建了大量 FastThreadLocal 實(shí)例建議用專門的清理機(jī)制或升級(jí)版方案不要直接套這個(gè)極簡(jiǎn)版。3.3 初始化時(shí)機(jī)與數(shù)組擴(kuò)容ThreadLocal 的 initialValue 在第一次 get 時(shí)調(diào)用。我們的 initialValue 同樣在 get 且槽位為空時(shí)調(diào)用。這里有個(gè)細(xì)節(jié)如果 get 首次調(diào)用時(shí)線程的數(shù)組還沒創(chuàng)建要先建數(shù)組再檢查是否需要擴(kuò)容然后調(diào)用 initialValue 并放入數(shù)組。如果 set 先調(diào)用也類似只是調(diào)用方傳入 value 而不調(diào) initialValue。擴(kuò)容處理需要注意因?yàn)閿?shù)組是每線程各自持有的擴(kuò)容只影響當(dāng)前線程。第二次擴(kuò)容后底層數(shù)組換了一個(gè)新數(shù)組引用會(huì)通過 setIndexedVariables 回寫。其他線程不受影響這個(gè)設(shè)計(jì)下不存在并發(fā)修改同一個(gè)數(shù)組的問題所以不需要加鎖。數(shù)組初始容量為什么選 16 而不是更小考慮到每個(gè)線程通常會(huì)有多個(gè) FastThreadLocal 變量16 可以容納大多數(shù)場(chǎng)景避免頻繁擴(kuò)容。如果你們的變量數(shù)少于 8可以改成 8。老實(shí)說擴(kuò)容成本不高就是一次數(shù)組拷貝但出現(xiàn)得越少越好。3.4 寫個(gè)簡(jiǎn)單壓測(cè)對(duì)比一下不依賴第三方環(huán)境直接用 nanoTime 循環(huán)測(cè)。注意必須用 MyFastThread 線程來跑否則 FastThreadLocal 會(huì)拋異常。測(cè)試代碼如下public class BenchmarkRun extends MyFastThread { Override public void run() { int warmup 1_000_000; int loop 10_000_000; ThreadLocalInteger tl new ThreadLocal(); FastThreadLocalInteger ftl new FastThreadLocal(); for (int i 0; i warmup; i) { tl.set(i); int v tl.get(); ftl.set(i); int w ftl.get(); } long start System.nanoTime(); for (int i 0; i loop; i) { tl.set(i); int v tl.get(); } long threadLocalTime System.nanoTime() - start; start System.nanoTime(); for (int i 0; i loop; i) { ftl.set(i); int v ftl.get(); } long fastThreadLocalTime System.nanoTime() - start; System.out.println(ThreadLocal: threadLocalTime / 1_000_000 ms); System.out.println(FastThreadLocal: fastThreadLocalTime / 1_000_000 ms); } public static void main(String[] args) throws Exception { new BenchmarkRun().start(); } }實(shí)際跑的時(shí)候不同機(jī)器差異很大但單變量 set/get 混合FastThreadLocal 通常比 ThreadLocal 快 2 到 5 倍。注意壓測(cè)有個(gè)陷阱如果只測(cè)讀取已存在的變量JIT 可能把整個(gè)循環(huán)優(yōu)化掉。我一般把 int value 累加到一個(gè)外部容器或者在每次循環(huán)里故意消費(fèi)掉結(jié)果避免死代碼消除。上面代碼里的 int v 和 int w 雖然沒用到理論上 JIT 也可能消除更嚴(yán)謹(jǐn)?shù)淖龇ㄊ抢奂雍蟠蛴?。自己跑的時(shí)候要加一個(gè)黑盒比如把 v 累加到 volatile 字段或者直接累計(jì)到一個(gè)對(duì)象。4. 實(shí)際替換的收益、邊界和踩坑4.1 我實(shí)測(cè)過的收益快是快但別被“吊打”帶偏我在網(wǎng)關(guān)的某個(gè)核心鏈路上把六個(gè)上下文變量從 ThreadLocal 換成數(shù)組索引方案后壓測(cè) QPS 提升了差不多 20% 到 30%。注意這個(gè)提升來自“高頻訪問 多變量”場(chǎng)景。如果業(yè)務(wù)接口一次請(qǐng)求只讀取一個(gè) ThreadLocal那么優(yōu)化幾乎感知不到。你需要訪問的變量數(shù)越多、頻率越高收益就越明顯。另外收益也要考慮現(xiàn)有線程是否支持。如果項(xiàng)目里所有線程都是普通 Thread 對(duì)象無法直接加字段你得先改線程工廠。很多框架內(nèi)部線程池是私有的不方便替換。這種情況下你可以退而求其次用 ThreadLocalObject[] 當(dāng)作線程數(shù)組的 holder首次獲取數(shù)組時(shí)仍走一次 ThreadLocalMap但后續(xù)在這個(gè)線程里訪問多個(gè) FastThreadLocal 變量時(shí)都復(fù)用同一個(gè)數(shù)組引用省掉了多次散列探測(cè)。這種半替代方案雖然不如自定義線程干凈但兼容性更好侵入性也更小。我建議從這種半替代方案開始評(píng)估收益再?zèng)Q定要不要?jiǎng)泳€程工廠。4.2 替換時(shí)最容易翻車的三個(gè)場(chǎng)景第一個(gè)是線程池。數(shù)組索引方案要求每個(gè)訪問線程都能拿出數(shù)組。線程池里的線程如果還是普通 Thread那么 get 會(huì)拋“不支持”異常。不要用 try-catch 掩蓋應(yīng)該從根源上統(tǒng)一線程工廠。你可以包裝一層創(chuàng)建線程時(shí)使用 MyFastThread或者在線程真正執(zhí)行目標(biāo)任務(wù)前把 Thread 換成支持接口的包裝類。第二個(gè)是繼承和傳遞。InheritableThreadLocal 的父子傳遞能力在數(shù)組索引方案里完全沒有。如果某個(gè)請(qǐng)求先在這個(gè)線程設(shè)置了一個(gè)變量然后交給另一個(gè)線程處理新線程中數(shù)組是空的讀出來必然是 null。解決思路很簡(jiǎn)單在執(zhí)行子任務(wù)前把上下文值作為參數(shù)顯式傳遞或者用包裝 Runnable 做變量遷移。如果你不想全鏈路改傳參建議保留 ThreadLocal 或引入專門上下文傳遞工具不要強(qiáng)行替換全部。第三個(gè)是動(dòng)態(tài)類加載。因?yàn)?index 是靜態(tài)發(fā)號(hào)器分配的每 new 一個(gè) FastThreadLocal 實(shí)例全局編號(hào)就加一。如果你在熱部署環(huán)境里反復(fù)加載類會(huì)不斷產(chǎn)生新的 FastThreadLocal 實(shí)例和新的 index舊實(shí)例又不回收每個(gè)線程數(shù)組里都占著一個(gè)槽位。時(shí)間久了數(shù)組會(huì)越來越大相當(dāng)于慢性的內(nèi)存泄漏。所以這類變量應(yīng)該做成類級(jí)別的靜態(tài)字段而不是每實(shí)例都 new。4.3 remove 的時(shí)機(jī)數(shù)組索引方案同樣需要 finally數(shù)組索引方案在 get 和 set 上很快但它不負(fù)責(zé)自動(dòng)回收值。線程數(shù)組是一個(gè)強(qiáng)引用容器只要數(shù)組槽位非空對(duì)象就不會(huì)被 GC 回收。在線程池場(chǎng)景里任務(wù)執(zhí)行完如果不 remove后續(xù)線程復(fù)用時(shí)會(huì)一直帶著上一個(gè)任務(wù)的變量既泄漏內(nèi)存又可能在下一次任務(wù)里讀到臟數(shù)據(jù)。安全寫法是在 try-finally 里釋放且只釋放每個(gè)任務(wù)開始時(shí)實(shí)際寫入的變量。不要無條件 remove 一堆變量那樣會(huì)把別的板塊設(shè)好的數(shù)據(jù)也清掉。比如FastThreadLocalString context ...; context.set(requestId); try { // do work } finally { context.remove(); }如果你同時(shí)用了多個(gè) FastThreadLocal可以封裝成一個(gè)上下文對(duì)象統(tǒng)一清理減少遺漏。這個(gè)習(xí)慣和 ThreadLocal 完全一致只是 ThreadLocal 的問題往往因?yàn)榈皖l訪問而被忽視高頻替換后如果不養(yǎng)成 remove 習(xí)慣問題會(huì)被放大。4.4 常見問題速查表問題可能原因解決辦法調(diào)用 get 拋 IllegalStateException當(dāng)前線程不是 FastThreadLocalAccess 子類線程工廠中統(tǒng)一使用自定義線程子線程或異步任務(wù)讀不到值數(shù)組索引方案沒有父子繼承顯式傳參或使用包裝 Runnable 遷移數(shù)據(jù)池化線程再次執(zhí)行任務(wù)時(shí)讀到舊值任務(wù)結(jié)束后沒有 removefinally 中調(diào)用 remove只清本任務(wù)設(shè)置過的變量熱部署后數(shù)組越來越大動(dòng)態(tài) new FastThreadLocal 實(shí)例占用新的 index用靜態(tài)字段持有變量杜絕每請(qǐng)求創(chuàng)建value 為 null 時(shí) get 行為異常槽位 null 被當(dāng)成未初始化initialValue 返回非 null或避免存儲(chǔ) nullset 后又 get 仍為空線程數(shù)組被替換或 remove 掉了檢查是否有其他代碼調(diào)用 remove 或持有錯(cuò)誤數(shù)組4.5 虛擬線程出現(xiàn)后還需要 ThreadLocal 嗎如果你已經(jīng)開始用虛擬線程會(huì)發(fā)現(xiàn)大量虛擬線程意味著大量線程對(duì)象ThreadLocal 的內(nèi)存占用和生命周期問題會(huì)被進(jìn)一步放大。Java 社區(qū)這幾年也在推動(dòng)更輕量的上下文傳遞方式比如把值作為參數(shù)顯式下傳或者使用不可變局部綁定。數(shù)組索引方案依賴線程對(duì)象字段虛擬線程如果支持這種訪問方式性能優(yōu)勢(shì)仍在但不同實(shí)現(xiàn)環(huán)境對(duì)線程字段的處理不一樣不能指望所有地方都按同一套來。我的建議是如果你的主要場(chǎng)景是虛擬線程優(yōu)先考慮上下文的顯式傳遞而不是繼續(xù)堆 ThreadLocal 或類 ThreadLocal 工具。等真正需要線程本地變量再按具體實(shí)現(xiàn)框架的特點(diǎn)選擇。最后分享一個(gè)我個(gè)人的習(xí)慣我不會(huì)把項(xiàng)目里所有 ThreadLocal 都換掉因?yàn)樘鎿Q本身有侵入成本而且大部分業(yè)務(wù)接口對(duì) ThreadLocal 的訪問頻率遠(yuǎn)沒有到瓶頸。只有在明確的熱點(diǎn)鏈路上并且能控制線程創(chuàng)建和變量清理的前提下我才會(huì)用數(shù)組索引方案。改動(dòng)時(shí)也從一兩個(gè)變量開始?jí)簻y(cè)、觀察內(nèi)存再逐步鋪開。真正常用的不是“吊打”這個(gè)詞而是對(duì)每次讀寫成本的敏感度。你下次寫并發(fā)代碼前不妨先問自己這個(gè)變量真的需要綁定線程嗎如果只是在一個(gè)請(qǐng)求里傳遞狀態(tài)傳參也許才是最便宜的方式。