GC實(shí)現(xiàn))
.NET Core GC 后臺(tái) GC 實(shí)現(xiàn)篇章07-源碼深度-.NET Core GC |閱讀時(shí)間約 40 分鐘一、引言后臺(tái) GCBackground GC以下簡(jiǎn)稱 BGC是 .NET Core GC 并發(fā)能力的核心GC 線程在后臺(tái)與應(yīng)用線程同時(shí)運(yùn)行把 STW 暫停從毫秒級(jí)壓到微秒級(jí)幾乎是服務(wù)器應(yīng)用的標(biāo)準(zhǔn)配置。對(duì)延遲敏感的 Web API、微服務(wù)、桌面交互應(yīng)用來說BGC 是壓住 P99 尾延遲的頭號(hào)手段對(duì)吞吐優(yōu)先的批處理任務(wù)它反而可能成為應(yīng)該關(guān)掉的開銷。但后臺(tái) GC 把暫停降到 1ms 以下這句話本身是不完整的。它沒有回答標(biāo)記到一半時(shí)應(yīng)用又在改引用怎么辦并發(fā)標(biāo)記期間 Gen0 預(yù)算用完了怎么辦后臺(tái)清掃和用戶分配同時(shí)搶一段內(nèi)存怎么辦分配速率高到后臺(tái)標(biāo)記追不上運(yùn)行時(shí)又會(huì)做什么這些問題的答案構(gòu)成了一臺(tái)狀態(tài)機(jī)理解這臺(tái)狀態(tài)機(jī)才算真正理解后臺(tái) GC。本文按動(dòng)機(jī)、生命周期、交互、清掃、觸發(fā)與回退、模式差異、源碼走讀、配置、代價(jià)、監(jiān)控、誤區(qū)、對(duì)比的順序展開。讀完你應(yīng)該能回答三個(gè)問題BGC 的每一次暫停分別在等什么前臺(tái) GC 什么時(shí)候會(huì)插進(jìn)來后臺(tái)標(biāo)記追不上分配時(shí)系統(tǒng)會(huì)退化成什么樣。二、為什么 Gen2 需要一條后臺(tái)路徑2.1 阻塞式 Gen2 回收的賬最樸素的回收流程是全程 Stop-The-World掛起所有托管線程標(biāo)記、清掃、壓縮一次做完再恢復(fù)。Gen0 和 Gen1 用這套流程沒問題因?yàn)樗鼈円幚淼拇婊顚?duì)象少、區(qū)間小暫停本來就在亞毫秒到幾毫秒量級(jí)。Gen2 不一樣它面對(duì)的是整個(gè)老年代加 LOH單次阻塞式 Gen2 回收的典型范圍是 5 到 50ms典型估算視堆規(guī)模、存活率與硬件而定不是承諾值。對(duì) 60FPS 的客戶端這是幾幀的凍結(jié)對(duì) Web 服務(wù)這是一批請(qǐng)求的尾延遲一起抖動(dòng)。問題的本質(zhì)是暫停時(shí)長(zhǎng)與什么成正比。阻塞式回收的標(biāo)記階段要遍歷整個(gè)存活集暫停時(shí)間因此近似與堆大小成正比堆只漲不縮的服務(wù)停頓只會(huì)越來越長(zhǎng)。而一次回收真正不得不暫停的部分只有根掃描線程棧、靜態(tài)字段、寄存器里的引用應(yīng)用線程隨時(shí)在改GC 必須獨(dú)占一致視圖才能掃。至于從根出發(fā)遍歷對(duì)象圖應(yīng)用線程在旁邊跑是可行的——只要把它們改過的引用記錄下來最后補(bǔ)掃一遍。后臺(tái) GC 就是按這筆賬設(shè)計(jì)的把與堆大小成正比的那部分挪到后臺(tái)線程與應(yīng)用并發(fā)執(zhí)行只把與根集合規(guī)模成正比的部分留在 STW 里。堆漲十倍根集合漲不了多少所以單次停頓基本不動(dòng)——這是 BGC 最值錢的性質(zhì)也是暫停降到微秒到亞毫秒級(jí)這句話成立的前提條件。2.2 并發(fā)不是免費(fèi)的BGC 用三樣?xùn)|西換低延遲寫屏障與卡表在并發(fā)期間持續(xù)記錄引用變更的 CPU 開銷標(biāo)記棧、臟卡緩沖等額外內(nèi)存以及并發(fā)協(xié)調(diào)本身的復(fù)雜度——后臺(tái)線程與前臺(tái)線程要在正確的時(shí)刻互相等待任何一處同步出錯(cuò)都是堆損壞。常見的量化口徑是總 GC 時(shí)間增加約 30%寫屏障的 CPU 開銷約 5% 到 10%兩組均為典型估算量級(jí)不是實(shí)測(cè)常數(shù)實(shí)際取決于分配與引用寫入的密度。這筆賬和 Unity 增量 GC 的賬是同一筆用吞吐?lián)Q延遲。還有個(gè)隱性成本并發(fā)標(biāo)記期間堆會(huì)繼續(xù)膨脹瞬時(shí)占用高于穩(wěn)態(tài)配額緊張的容器里這段膨脹有時(shí)會(huì)頂?shù)较揞~選型時(shí)要算進(jìn)去詳見第十節(jié)。2.3 常見誤解先糾正第一后臺(tái) GC 不是讓 GC 整體變快它讓暫停變短、讓總耗時(shí)變長(zhǎng)。第二后臺(tái) GC 只負(fù)責(zé) Gen2Gen0/Gen1 從來就是短暫停的前臺(tái)回收BGC 開不開它們都在。第三后臺(tái) GC 不是完全無暫停它有兩次有時(shí)是三次短暫 STW 切片只是這些切片的長(zhǎng)度跟根集合走、跟堆大小無關(guān)。第四BGC 期間照樣可能退化成阻塞式 Gen2 回收而且那次的暫停比平常更長(zhǎng)——這是第六節(jié)的主題。三、后臺(tái) GC 的完整生命周期與狀態(tài)機(jī)3.1 四段式結(jié)構(gòu)一輪后臺(tái) GC 的骨架是初始標(biāo)記短 STW→ 并發(fā)標(biāo)記 → 最終標(biāo)記短 STW→ 并發(fā)清掃。它和前臺(tái)阻塞式回收的差別只在執(zhí)行方式阻塞式把四步串在一個(gè)暫停里做完后臺(tái)模式把中間兩步放到與應(yīng)用并發(fā)的時(shí)間窗里。一輪后臺(tái) GC 的時(shí)序簡(jiǎn)化示意暫停時(shí)長(zhǎng)為典型量級(jí)非實(shí)測(cè)常數(shù) 時(shí)間軸 ────────────────────────────────────────────────────────────? 應(yīng)用線程 [運(yùn)行] ▓停▓ [運(yùn)行并發(fā)分配] ▓停▓ [運(yùn)行并發(fā)分配] ▓停▓ [運(yùn)行] … │ │ │ 初始標(biāo)記 最終標(biāo)記 清掃收尾 根 臟卡快照 補(bǔ)掃并發(fā)期的臟卡 短暫同步點(diǎn) 與堆大小無關(guān) 與堆大小無關(guān) 后臺(tái)GC線程 ├────── 并發(fā)標(biāo)記 gen2 ──────┤────── 并發(fā)清掃 ──────┤ 完成 BGC thread │ 遍歷對(duì)象圖寫屏障/卡表 │ 標(biāo)記為死的對(duì)象與段 │ │ 記錄應(yīng)用改過的引用 │ 一邊歸還一邊供分配復(fù)用 │ 前臺(tái)GC 并發(fā)標(biāo)記期間任意時(shí)刻 foreground Gen0 / Gen1 照常觸發(fā)短 STW → 壓縮短暫段 → 立即還線程 └ 兩者互不替代可理解為兩條并行的流水線 失敗分支第六節(jié) 并發(fā)標(biāo)記追不上分配 ──? 中止 BGC ──? 退化為阻塞式 Gen2 回收 比平常更長(zhǎng)的一次 STW把這張圖讀成狀態(tài)機(jī)BGC 的主干狀態(tài)就是空閑 → 初始標(biāo)記暫停→ 并發(fā)標(biāo)記 → 最終標(biāo)記暫?！?并發(fā)清掃 → 收尾暫停→ 空閑外加一條從并發(fā)標(biāo)記指向阻塞式 Gen2的失敗轉(zhuǎn)移。運(yùn)行時(shí)源碼里后臺(tái)標(biāo)記與后臺(tái)清掃各自對(duì)應(yīng)獨(dú)立的階段函數(shù)如background_mark_phase/background_sweep_phase這一族命名具體簽名隨運(yùn)行時(shí)版本演進(jìn)此處按公開設(shè)計(jì)意圖做示意標(biāo)注非逐字引用狀態(tài)切換由 GC 自己的同步原語控制而不是簡(jiǎn)單的函數(shù)調(diào)用順序。3.2 三次暫停分別在等什么暫停點(diǎn)觸發(fā)位置獨(dú)占視圖要保護(hù)什么時(shí)長(zhǎng)量級(jí)典型估算初始標(biāo)記BGC 啟動(dòng)瞬間掃描線程棧與靜態(tài)根建立標(biāo)記起點(diǎn)給卡表拍起始快照亞毫秒隨根集合與核數(shù)變化最終標(biāo)記并發(fā)標(biāo)記接近完成消化并發(fā)期間積累的臟卡與引用變更把標(biāo)記收口閉合亞毫秒到毫秒級(jí)清掃收尾并發(fā)清掃結(jié)束后臺(tái)線程與前臺(tái)分配線程對(duì)段狀態(tài)做最后同步極短關(guān)鍵在于三次暫停的長(zhǎng)度都只跟根集合、臟卡數(shù)量、線程數(shù)相關(guān)不跟堆大小相關(guān)。所以 4GB 的堆和 400MB 的堆BGC 的單次停頓差別不大——這正是阻塞式回收做不到的。臟卡數(shù)量理論上可以隨堆增大而增多但實(shí)踐里它取決于并發(fā)期間被改寫的老年代對(duì)象數(shù)量而不是堆總量所以增長(zhǎng)是溫和的、有界的。3.3 暫停與恢復(fù)是怎么發(fā)生的GC 掛起托管線程用的是協(xié)作式掛起運(yùn)行時(shí)在安全點(diǎn)safepoint檢查掛起請(qǐng)求線程到達(dá)安全點(diǎn)后主動(dòng)交出控制權(quán)遲遲不到的線程由 GC 線程劫持hijack其托管幀強(qiáng)制停下恢復(fù)時(shí)反向操作。這意味著兩件事暫停時(shí)長(zhǎng)包含等最慢線程到達(dá)安全點(diǎn)的成分線程長(zhǎng)時(shí)間執(zhí)行非托管代碼或長(zhǎng)循環(huán)里沒有安全點(diǎn)都會(huì)拉長(zhǎng) STW暫停的進(jìn)出又是全局同步操作核多的機(jī)器上每多一次暫停就多付一次同步開銷這也是 BGC 不把暫停切得更碎的原因。實(shí)用推論BGC 停頓異常偏長(zhǎng)時(shí)先別懷疑標(biāo)記算法先查有沒有線程卡在非托管調(diào)用里不出來。這類問題在 Profiler 里表現(xiàn)為GC 開始時(shí)間與線程恢復(fù)時(shí)間之間有一段空隙而不是標(biāo)記本身很慢。四、后臺(tái)標(biāo)記與前臺(tái) gen0/gen1 回收的交互4.1 兩條流水線并行不悖后臺(tái)標(biāo)記只盯 gen2。Gen0 和 Gen1 的分配照常進(jìn)行g(shù)en0 預(yù)算用完時(shí)運(yùn)行時(shí)插入一次前臺(tái)的 Gen0 或 Gen1 回收短暫 STW把短暫段里活下來的對(duì)象壓縮到一端然后立刻把線程還給應(yīng)用和后臺(tái)標(biāo)記。兩條流水線互不替代——這就是后臺(tái) GC 期間 gen0/gen1 短暫停回收照常發(fā)生的準(zhǔn)確含義。對(duì)應(yīng)用來說BGC 期間觀察到的暫停分布是一串很短的 gen0/gen1 回收 兩次極短的 BGC 切片而不是完全沒有暫停評(píng)估效果要看這個(gè)混合分布的尾部。兩者在資源上也會(huì)互相牽制都要掃根、都要?jiǎng)涌ū矶虝憾蔚膲嚎s還會(huì)改變 gen1 晉升的落點(diǎn)所以運(yùn)行時(shí)在階段切換處有明確的先后順序按公開設(shè)計(jì)意圖做示意推斷。4.2 并發(fā)期間的分配去哪了并發(fā)標(biāo)記跑著應(yīng)用還在分配 gen0/gen1 對(duì)象從 gen1 晉升進(jìn) gen2 的對(duì)象會(huì)落在哪運(yùn)行時(shí)給后臺(tái)標(biāo)記期間預(yù)留了專門的 gen2 分配窗口gen2 allocation context 一類的機(jī)制晉升對(duì)象先從這個(gè)預(yù)留窗口里取地而不是去搶后臺(tái)標(biāo)記正在處理的區(qū)域。這樣并發(fā)標(biāo)記看到的 gen2 布局不會(huì)被實(shí)時(shí)分配打亂標(biāo)記進(jìn)度也不會(huì)被頻繁重置。預(yù)留窗口不是無限的它是一塊固定量級(jí)的緩沖區(qū)分配速率高、標(biāo)記進(jìn)度慢時(shí)會(huì)被耗盡——耗盡那一刻就是 BGC 的失敗轉(zhuǎn)移點(diǎn)詳見第六節(jié)?？梢园阉斫獬尚庞妙~度標(biāo)記每推進(jìn)一段額度就續(xù)上一些標(biāo)記停滯則只出不進(jìn)歸零即違約。它也解釋了后臺(tái)標(biāo)記期間堆暫時(shí)變高屬于正常現(xiàn)象晉升的活對(duì)象先堆在窗口里等標(biāo)記完成后再由后續(xù)回收統(tǒng)一整理。4.3 引用變更如何不被漏標(biāo)并發(fā)標(biāo)記期間應(yīng)用改引用是所有并發(fā) GC 的核心難題。語義上 BGC 接近 SATBSnapshot At The Beginning原始快照式并發(fā)開始時(shí)的存活狀態(tài)被當(dāng)作快照期間改寫出來的引用都要在結(jié)束前被看到。但 .NET 并不照搬 G1 那套獨(dú)立 SATB 隊(duì)列它的記錄載體是卡表加寫屏障引用寫進(jìn)老年代對(duì)象時(shí)屏障順手標(biāo)臟對(duì)應(yīng)卡后臺(tái)標(biāo)記遇到臟卡就重掃最終標(biāo)記那次 STW 把剩余臟卡一次消化干凈。部分版本的屏障還會(huì)在標(biāo)記期對(duì)新寫入引用做更積極的補(bǔ)錄具體策略隨版本演進(jìn)以上按公開設(shè)計(jì)意圖做示意推斷。這套機(jī)制的成本落點(diǎn)很明確引用寫入密集的老年代改寫會(huì)推高臟卡率臟卡率高則最終標(biāo)記那段 STW 變長(zhǎng)同時(shí)后臺(tái)標(biāo)記要反復(fù)回掃同一片區(qū)域進(jìn)度被拖慢。這直接連到第六節(jié)的失敗回退——寫屏障記錄得再全標(biāo)記追不上分配一樣要出事。反過來寫屏障本身也有收益它在前臺(tái) gen0/gen1 回收里承擔(dān)老到新的記錄職責(zé)同一套屏障兩處復(fù)用這是分代 GC 攤薄寫屏障成本的標(biāo)準(zhǔn)做法。五、并發(fā)清掃與用戶分配共處5.1 清掃為什么也能并發(fā)阻塞式回收里清掃要跑完才恢復(fù)應(yīng)用。BGC 把這一步也放到后臺(tái)標(biāo)記已確定哪些對(duì)象是死的清掃只需按段處理這些已知死對(duì)象不必獨(dú)占整個(gè)堆。應(yīng)用在清掃期間分配走分配上下文與段的空閑區(qū)后臺(tái)清掃線程一邊回收死對(duì)象空間一邊把不再使用的段解提交decommit歸還物理頁保留虛擬地址甚至整段釋放。兩邊操作的區(qū)域由段狀態(tài)協(xié)調(diào)互不踩踏。標(biāo)記解決誰是垃圾清掃解決垃圾占的空間什么時(shí)候還兩者都發(fā)生在應(yīng)用運(yùn)行的同時(shí)。缺了并發(fā)清掃標(biāo)記省下的暫停會(huì)在清掃那一步全吐回去缺了并發(fā)標(biāo)記清掃根本無從下手。真正被留在 STW 里的只有收口動(dòng)作。這里有個(gè)容易誤解的點(diǎn)SOH 上的壓縮移動(dòng)對(duì)象并不是每輪 BGC 都在后臺(tái)完成。并發(fā)清掃主要是把空間收回來而把幸存對(duì)象搬在一起的壓縮動(dòng)作與前臺(tái)回收的分工隨運(yùn)行時(shí)版本與回收配置變化按公開設(shè)計(jì)意圖做示意推斷。可以確定的邊界是BGC 保證標(biāo)記并發(fā)、清掃并發(fā)而涉及全局對(duì)象移動(dòng)的重活仍然存在短暫同步點(diǎn)——這也是為什么 LOH 壓縮這類操作必須顯式觸發(fā)參見本專欄 07-04 對(duì)清掃與壓縮時(shí)機(jī)的拆解。5.2 清掃階段的分配友好性清掃期間的分配還有個(gè)收益后臺(tái)把死對(duì)象空間陸續(xù)交還分配慢路徑向堆要新窗口的頻率隨之下降應(yīng)用不必等一次完整的回收結(jié)束才有地方分配。反過來如果清掃追不上分配典型的高分配速率場(chǎng)景堆的已提交內(nèi)存會(huì)持續(xù)上行直到觸發(fā)更激進(jìn)的回收動(dòng)作。所以觀察到BGC 期間堆水位單調(diào)上漲不一定是泄漏先確認(rèn)清掃是否被分配速率壓制——區(qū)分手段是看GC Heap Size曲線在一輪 background 結(jié)束后有沒有回落有回落是節(jié)奏問題無回落才是泄漏嫌疑。清掃還會(huì)順手做段的歸還默認(rèn)物理頁 decommit 而虛擬地址保留System.GC.RetainVM打開后連地址空間一起歸還代價(jià)是下次擴(kuò)張要重新要地址。它的收益點(diǎn)恰好落在后臺(tái)清掃這一段——清掃越積極歸還越頻繁工作集越貼近真實(shí)需求。六、觸發(fā)條件、失敗與回退6.1 什么時(shí)候會(huì)進(jìn)入后臺(tái)模式BGC 的觸發(fā)和普通 GC 一樣由分配預(yù)算驅(qū)動(dòng)Gen2 預(yù)算耗盡或慢路徑拿不到空間時(shí)觸發(fā) Gen2 回收只要延遲模式允許且開關(guān)未關(guān)System.GC.Concurrent默認(rèn) true這次回收就以后臺(tái)方式執(zhí)行。沒有定時(shí)器在背后周期性跑 BGC——它是被分配叫醒的分配少就跑得少。顯式調(diào)用GC.Collect(2, GCCollectionMode.Forced, blocking: false)同樣走后臺(tái)路徑blocking: true則強(qiáng)制阻塞測(cè)試要確定性復(fù)現(xiàn)某類暫停時(shí)靠這個(gè)參數(shù)切換。另外兩個(gè)會(huì)主動(dòng)壓制或關(guān)閉 BGC 的開關(guān)GCLatencyMode.Batch關(guān)閉后臺(tái)回收換取吞吐LowLatency與SustainedLowLatency反過來壓制 Gen2 回收本身讓 BGC 更少被觸發(fā)代價(jià)是借未來的債堆只漲不縮。四種延遲模式的完整語義在 03-05 第七節(jié)有表格本文不重復(fù)。6.2 追不上了退化為阻塞式 Gen2這是本文最重要的失敗模型。并發(fā)標(biāo)記期間晉升與分配持續(xù)消耗 gen2 預(yù)留窗口只要后臺(tái)標(biāo)記的推進(jìn)速度低于消耗速度窗口終會(huì)耗盡。運(yùn)行時(shí)的處理是中止當(dāng)前后臺(tái) GC改為發(fā)起一次完整的阻塞式 Gen2 回收所有線程停下標(biāo)記清掃一次做完然后再恢復(fù)正常運(yùn)行。這次退化懲罰是雙重的。第一這一輪同時(shí)付了已經(jīng)跑掉的并發(fā)標(biāo)記開銷白付和一次完整阻塞暫停照付是標(biāo)準(zhǔn)的最差情況。第二退化時(shí)的堆通常正處于分配最快、存活最多的時(shí)刻阻塞暫停比穩(wěn)態(tài)下的 Gen2 回收更長(zhǎng)——量級(jí)上是 5 到 15ms典型估算非實(shí)測(cè)常數(shù)實(shí)際隨堆規(guī)模上浮。識(shí)別信號(hào)在 GC 日志里很清楚本該成對(duì)出現(xiàn)的 background 起止事件被一次 blocking Gen2 打斷或者回收計(jì)數(shù)在漲而 background 完成數(shù)不同步。什么樣的負(fù)載會(huì)把 BGC 逼到退化兩類行為疊加最危險(xiǎn)高分配速率每秒幾十 MB 量級(jí)的臨時(shí)對(duì)象示例量級(jí)和高臟卡率頻繁改寫老年代里的引用讓標(biāo)記反復(fù)回掃典型場(chǎng)景是每幀重建大對(duì)象集合的游戲邏輯、無池化的序列化流水線。應(yīng)對(duì)方向和 Unity 增量 GC 的回退應(yīng)對(duì)是同一條先把分配速率壓下來池化、復(fù)用、把大對(duì)象的重建挪到低峰期讓后臺(tái)標(biāo)記有完成一輪的喘息空間。指望調(diào) BGC 參數(shù)解決分配過多是把因果關(guān)系搞反了。6.3 失敗回退的判定口徑判斷是否頻繁退化建議用兩個(gè)差值單位時(shí)間內(nèi) blocking Gen2 的次數(shù)以及它的單次時(shí)長(zhǎng)分位數(shù)。前者高說明分配壓力大后者高說明退化代價(jià)重。只看% Time in GC會(huì)把兩者混在一起——它超過 5%經(jīng)驗(yàn)閾值示例口徑時(shí)先分清是后臺(tái)跑得多還是退化跑得多前者通常良性后者才要?jiǎng)邮?。一句話版的現(xiàn)場(chǎng)口徑就是監(jiān)控 GC 觸發(fā)頻率前臺(tái)觸發(fā)過多即后臺(tái)負(fù)載過重落到工具上是第十一節(jié)的兩條曲線。七、Server 與 Workstation 下的差異Workstation 模式下只有一個(gè)堆、一個(gè) GC 線程后臺(tái)標(biāo)記的所有活都?jí)涸谶@一個(gè)線程上與應(yīng)用線程搶核。Server 模式下每個(gè)邏輯處理器各有一個(gè)堆和對(duì)應(yīng)的 GC 線程Gen2 回收時(shí)各堆并行推進(jìn)后臺(tái)標(biāo)記的吞吐隨核數(shù)上升單個(gè)堆的規(guī)模也更小同樣的分配速率下后臺(tái)標(biāo)記更容易跑贏。維度Workstation BGCServer BGC堆與 GC 線程1 堆 1 GC 線程每邏輯處理器 1 堆 1 GC 線程可用DOTNET_GCHeapCount覆蓋后臺(tái)標(biāo)記的并行度單線程推進(jìn)與應(yīng)用搶核多堆并行各堆獨(dú)立推進(jìn)線程綁核無綁核需求默認(rèn)按掩碼綁核DOTNET_GCHeapAffinitizeMask、DOTNET_GCNoAffinitize可控退化風(fēng)險(xiǎn)單核推進(jìn)慢高分配速率下更易退化單堆更小推進(jìn)更快但多堆要協(xié)調(diào)全局階段切換內(nèi)存開銷一套堆元數(shù)據(jù)元數(shù)據(jù)按堆復(fù)制通常占堆總量 3%~5%典型估算適用場(chǎng)景桌面、低核容器、內(nèi)存緊張多核服務(wù)器、吞吐與延遲都要還有一個(gè)差異是全局階段同步Server 模式下所有堆必須一起進(jìn)入和退出某個(gè)階段比如一起完成初始標(biāo)記所以最快的堆要等最慢的堆。堆之間負(fù)載不均時(shí)這個(gè)等待會(huì)出現(xiàn)在暫停時(shí)長(zhǎng)里。配置上把DOTNET_GCHeapCount設(shè)得比實(shí)際核數(shù)少容器里很常見既能減少內(nèi)存開銷也能減少階段同步的等待者數(shù)量——03-05 第八節(jié)講容器配置時(shí)給的建議就是從這條來的。反方向也要提一句Workstation 也能開并發(fā)標(biāo)記兩種模式跑的是同一套狀態(tài)機(jī)差別只在誰來跑、跑多快、跟誰搶。所以別把我要低延遲直接翻譯成開 Server GC——1 到 2 核的容器里堆數(shù)太少并行收益覆蓋不了內(nèi)存開銷反而讓后臺(tái)標(biāo)記和應(yīng)用在僅有的核上互踩。八、代碼級(jí)走讀后臺(tái)線程與標(biāo)記循環(huán)先看后臺(tái)線程的骨架。下面這段是簡(jiǎn)化偽代碼按公開的線程模型整理非逐字源碼// 簡(jiǎn)化偽代碼 / 示意后臺(tái) GC 線程主循環(huán)結(jié)構(gòu)對(duì)應(yīng)運(yùn)行時(shí)的后臺(tái)回收線程模型 DWORD BackgroundGCThread(LPVOID param) { while (true) { WaitForGCRequest(); // 等待 GC 觸發(fā)信號(hào) // 后臺(tái)標(biāo)記與應(yīng)用并發(fā) BackgroundMark(); // 后臺(tái)清掃與應(yīng)用并發(fā) BackgroundSweep(); } }逐段解讀WaitForGCRequest()說明后臺(tái)線程平時(shí)是掛起的它不輪詢、不空轉(zhuǎn)只有 Gen2 回收被觸發(fā)且被判定為可后臺(tái)執(zhí)行時(shí)才被喚醒——這對(duì)應(yīng)第六節(jié)沒有定時(shí)器BGC 被分配叫醒的結(jié)論。BackgroundMark()與BackgroundSweep()前后相接兩者內(nèi)部各自完成暫停—恢復(fù)的往返進(jìn)入時(shí)短暫 STW 拿一致視圖拿到后立刻 ResumeAllThreads 放應(yīng)用繼續(xù)跑。循環(huán)結(jié)構(gòu)本身解釋了為什么 BGC 是一輪一輪的——每輪從請(qǐng)求開始、到清掃結(jié)束兩輪之間應(yīng)用完全不受影響。真實(shí)實(shí)現(xiàn)里這個(gè)循環(huán)還要處理退化分支BackgroundMark()內(nèi)部發(fā)現(xiàn)預(yù)留窗口耗盡時(shí)不會(huì)走到BackgroundSweep()而是直接轉(zhuǎn)入阻塞式 Gen2這一點(diǎn)偽代碼沒有畫出來讀源碼時(shí)要特別留意。再看標(biāo)記循環(huán)本身同樣是簡(jiǎn)化偽代碼 / 示意void BackgroundMark() { // 1. 初始標(biāo)記短暫 STW掃描 Roots SuspendAllThreads(); ScanRoots(); ResumeAllThreads(); // 2. 并發(fā)標(biāo)記后臺(tái)進(jìn)行 while (HasWork()) { MarkStep(); // 標(biāo)記一批對(duì)象 // 應(yīng)用線程在此期間可以運(yùn)行 } // 3. 最終標(biāo)記短暫 STW處理積壓 SuspendAllThreads(); ProcessSATBBuffer(); ResumeAllThreads(); }逐段解讀第一段的SuspendAllThreads / ScanRoots / ResumeAllThreads就是第三節(jié)表格里的初始標(biāo)記它必須包住根掃描因?yàn)楦S時(shí)在變沒有獨(dú)占視圖的根掃描結(jié)果不可信。第二段的while (HasWork())是并發(fā)標(biāo)記的主體注意循環(huán)體里沒有暫?！狹arkStep()每次推進(jìn)一小批對(duì)象就返回把 CPU 讓回給應(yīng)用進(jìn)度由標(biāo)記棧和游標(biāo)持久保存被前臺(tái) gen0/gen1 回收打斷后能精確續(xù)上這正是第四節(jié)兩條流水線并行的實(shí)現(xiàn)基礎(chǔ)。第三段的ProcessSATBBuffer對(duì)應(yīng)并發(fā)期間積累的引用變更在這個(gè)簡(jiǎn)化模型里把它畫成獨(dú)立緩沖實(shí)際運(yùn)行時(shí)的載體以臟卡表為主、輔以屏障的補(bǔ)錄策略語義都是把并發(fā)期間改出來的引用收口。整個(gè)函數(shù)的結(jié)構(gòu)印證了核心結(jié)論兩次 Suspend 之間隔著的正是與堆大小成正比的那部分工作而 Suspend 本身只承擔(dān)與根集合成正比的開銷。還有一處留白HasWork()的判定不只看標(biāo)記?？詹豢者€要看臟卡處理進(jìn)度否則會(huì)出現(xiàn)對(duì)象圖掃完了但卡還沒清的假完成。讀源碼時(shí)建議順著background_mark_phase的入口把每個(gè) return 條件抄在紙上它們就是這臺(tái)狀態(tài)機(jī)的全部出口。九、配置與開關(guān)9.1 延遲模式與后臺(tái)開關(guān)// 啟用后臺(tái) GC默認(rèn)啟用 GCSettings.LatencyMode GCLatencyMode.Batch; // 關(guān)閉后臺(tái) GC高吞吐量模式 GCSettings.LatencyMode GCLatencyMode.Interactive; // 啟用后臺(tái) GC默認(rèn)這段代碼的讀法要注意LatencyMode不只是后臺(tái) GC 的開關(guān)它是延遲策略的總閘。Interactive默認(rèn)開啟后臺(tái)回收、把 Gen2 拆成短暫停Batch關(guān)閉后臺(tái)回收換總吞吐LowLatency與SustainedLowLatency走反方向壓制 Gen2 回收本身的頻率。運(yùn)行時(shí)另有獨(dú)立于 LatencyMode 的顯式開關(guān)配置鍵System.GC.Concurrent、環(huán)境變量DOTNET_GCConcurrent關(guān)掉它 Gen2 回收一律阻塞與 LatencyMode 設(shè)成什么無關(guān)。生產(chǎn)環(huán)境建議啟動(dòng)日志里同時(shí)打印GCSettings.IsServerGC與LatencyMode否則配置鍵拼錯(cuò)、環(huán)境變量沒注入容器這類事故會(huì)一直潛伏——監(jiān)控觸發(fā)頻率的第一步就是先確認(rèn)開關(guān)落沒落上。9.2 配置鍵速查配置鍵 / 環(huán)境變量作用與 BGC 的關(guān)系System.GC.Concurrent/DOTNET_GCConcurrent后臺(tái) GC 總開關(guān)默認(rèn) true關(guān)閉即回到全程阻塞 Gen2System.GC.Server/DOTNET_GCServerServer GC 開關(guān)決定后臺(tái)標(biāo)記是單線程還是多堆并行DOTNET_GCHeapCount顯式指定堆數(shù)影響后臺(tái)標(biāo)記并行度與階段同步等待DOTNET_GCHeapAffinitizeMaskGC 線程綁核掩碼決定后臺(tái)線程落在哪些核上DOTNET_GCNoAffinitize關(guān)閉綁核容器內(nèi)核會(huì)被遷移時(shí)改用GCSettings.LatencyMode延遲策略總閘Interactive 默認(rèn)允許 BGCBatch 關(guān)閉配置建議可以歸到這張表里默認(rèn)開啟追求吞吐才關(guān)Batch 或System.GC.Concurrentfalse高分配速率場(chǎng)景要盯著前臺(tái)觸發(fā)頻率觸發(fā)過多即后臺(tái)負(fù)載過重。四條建議分別落在開不開和看什么兩端中間缺的正是第六節(jié)的失敗模型——關(guān)不關(guān)只是入口判斷跟不跟得上才是運(yùn)維期的常態(tài)問題。9.3 Unity 語境下的位置放到 Unity 語境里再補(bǔ)一層背景傳統(tǒng) Unity 的 IL2CPP 與 Mono 棧不使用 .NET Core GC這條后臺(tái) GC 鏈路對(duì)它們不可用Mono 自帶的 SGen 有有限度的并發(fā)標(biāo)記支持語義上更接近并發(fā)而非完整后臺(tái)狀態(tài)機(jī)Unity Incremental GC 是游戲場(chǎng)景下最接近后臺(tái) GC的替代方案——它同樣做并發(fā)標(biāo)記加短 STW 收口但底座是不分代不壓縮的 Boehm。Unity 6 引入的 CoreCLR 后端是唯一會(huì)真正跑上 .NET 后臺(tái) GC 的 Unity 路徑遷移前后的評(píng)估對(duì)象完全不同邊界結(jié)論見 03-04 第八節(jié)。十、代價(jià)與適用場(chǎng)景10.1 后臺(tái) GC 不是免費(fèi)的三條代價(jià)各自的作用機(jī)理如下總 GC 時(shí)間增加約 30%并發(fā)標(biāo)記的協(xié)調(diào)開銷——典型估算非實(shí)測(cè)常數(shù)。來源是寫屏障的持續(xù)開銷、標(biāo)記進(jìn)度的跨線程維護(hù)、以及并發(fā)期堆膨脹導(dǎo)致的額外標(biāo)記量。寫屏障的 CPU 開銷約 5% 到 10%每次賦值都檢查——典型估算非實(shí)測(cè)常數(shù)。落點(diǎn)在引用寫入密集的熱循環(huán)老年代改寫越頻繁卡表越臟實(shí)際開銷越靠上限。額外的內(nèi)存開銷標(biāo)記棧、臟卡緩沖以及并發(fā)期的堆膨脹——量級(jí)隨堆規(guī)模與核數(shù)變化Server 模式下按堆復(fù)制再疊上 03-05 說過的 3% 到 5% 堆元數(shù)據(jù)。把總賬放在一起說后臺(tái) GC 將暫停時(shí)間從 5 到 50ms 降到 1ms 以下代價(jià)是約 30% 的總 GC 時(shí)間增加兩處均為典型估算量級(jí)非實(shí)測(cè)常數(shù)對(duì)于延遲敏感的 Server 應(yīng)用這是值得的權(quán)衡。三條代價(jià)給出選型分界線后臺(tái) GC 適合延遲敏感型應(yīng)用Web API、交互式應(yīng)用不適合批處理型應(yīng)用數(shù)據(jù)處理、離線計(jì)算——批處理的停頓不面向用戶拆碎暫停只換來更高的總 CPU不如一次阻塞收干凈。10.2 場(chǎng)景清單與歸因場(chǎng)景結(jié)論歸因Web APIASP.NET默認(rèn)開啟暫停 1ms請(qǐng)求尾延遲直接受單次 STW 影響1ms 為典型量級(jí)非承諾值微服務(wù)推薦開啟延遲敏感對(duì)外 RPC 的 P99 就是 SLA暫停抖動(dòng)會(huì)傳導(dǎo)到調(diào)用方WPF 桌面推薦開啟UI 流暢渲染線程被 GC 凍結(jié)會(huì)直接掉幀桌面場(chǎng)景對(duì)尖峰同樣敏感批處理關(guān)閉以獲得更高吞吐無人等待延遲寫屏障與協(xié)調(diào)是純損耗計(jì)算密集減少后臺(tái)線程的 CPU 競(jìng)爭(zhēng)后臺(tái)標(biāo)記與業(yè)務(wù)線程搶核算力已打滿時(shí)并發(fā)反成負(fù)擔(dān)分配速率極高后臺(tái)跟不上時(shí)觸發(fā)前臺(tái) GC 反而更差直接命中第六節(jié)的退化路徑付雙份錢最后一行最有價(jià)值BGC 有明確的能力邊界負(fù)載超過邊界后不是效果變差而是比不開還差。判斷邊界靠的不是感覺是第十一節(jié)的監(jiān)控?cái)?shù)據(jù)。十一、后臺(tái) GC 的監(jiān)控與診斷監(jiān)控入口是性能計(jì)數(shù)器與 dotnet-counters% Time in GC應(yīng)小于 5%經(jīng)驗(yàn)閾值示例口徑超過即 GC 壓力過大實(shí)時(shí)監(jiān)控命令一行就夠——dotnet-counters monitor --process-id pid System.Runtime配套的觀察方法再往前推一步。盯三條曲線GC Heap Size看堆水位是否在一輪 background 后回落GC Count看回收頻率的斜率二者一起能把后臺(tái)跑得多和退化跑得多分開。再加一條信號(hào)監(jiān)控 GC 日志里的background關(guān)鍵字。落到事件層就是 GCStart/GCEnd 事件里帶的代數(shù)與 blocking 標(biāo)記一次 Gen2 回收如果標(biāo)記為 background成對(duì)出現(xiàn)說明完整跑完如果中間插進(jìn)一次 blocking Gen2就是退化現(xiàn)場(chǎng)。診斷順序壓成三步先用 dotnet-counters 看趨勢(shì)水位、頻率再用 dotnet-trace 或 PerfView 抓事件確認(rèn)每輪 Gen2 是 background 還是 blocking、單次時(shí)長(zhǎng)分位數(shù)多少最后才談?wù){(diào)參或改分配。跳過前兩步直接調(diào)DOTNET_GCHeapCount最常見的結(jié)局是調(diào)了半天發(fā)現(xiàn)進(jìn)程根本沒跑在預(yù)期模式上。十二、常見誤區(qū)與反模式誤區(qū)一開了 BGC 就不會(huì)再有長(zhǎng)暫停。錯(cuò)誤做法是把延遲預(yù)算全押在開關(guān)上。為什么錯(cuò)BGC 有三次短暫 STW還可能退化成阻塞式 Gen2線程卡在非托管調(diào)用里也會(huì)拉長(zhǎng)任意一次暫停。正確做法是驗(yàn)收看分布尾部P99 單次 STW、blocking Gen2 次數(shù)出現(xiàn)長(zhǎng)暫停先分類BGC 切片變長(zhǎng)、退化、還是掛起等待三者解法完全不同。誤區(qū)二后臺(tái) GC 能解決分配太多的問題。錯(cuò)誤做法是把分配速率失控歸咎于GC 不夠快反復(fù)開關(guān)后臺(tái)模式。為什么錯(cuò)BGC 只重排暫停它不減少任何分配反而因?yàn)椴l(fā)期堆膨脹讓內(nèi)存曲線更難看。正確做法是回到分配本身——池化、復(fù)用、緩存結(jié)果、把大對(duì)象重建挪出關(guān)鍵路徑讓 gen2 預(yù)留窗口的消耗速度低于標(biāo)記推進(jìn)速度退化自然消失。誤區(qū)三批處理也開后臺(tái) GC 更安全。錯(cuò)誤做法是低延遲開關(guān)無腦全開。為什么錯(cuò)批處理沒有延遲收益寫屏障與并發(fā)協(xié)調(diào)換不來任何東西只有總 CPU 上升。正確做法是顯式設(shè)Batch把這 30% 量級(jí)的總開銷典型估算拿回來同時(shí)保留 dotnet-counters 監(jiān)控防止內(nèi)存失控。誤區(qū)四% Time in GC高就一定說明后臺(tái) GC 失效。錯(cuò)誤做法是看到超過 5% 立刻動(dòng)配置。為什么錯(cuò)它把良性并發(fā)開銷和惡性退化暫?；煸谝黄?。正確做法是拆開看background 輪次的總 CPU 高但單次 STW 短是良性的blocking Gen2 次數(shù)與單次時(shí)長(zhǎng)分位數(shù)在漲才是需要干預(yù)的信號(hào)。十三、橫向?qū)Ρ扰c在全專欄中的位置維度Unity 增量 GCBoehmMono SGen 并發(fā).NET 后臺(tái) GC并發(fā)做什么分片標(biāo)記跨幀推進(jìn)可選并發(fā)標(biāo)記并發(fā)標(biāo)記 并發(fā)清掃完整狀態(tài)機(jī)暫停結(jié)構(gòu)兩次短 STW 加一次性清掃STW 為主有限并發(fā)三次短 STW初始/最終/收尾分代否兩代三代 LOH POH失敗退化回退為全量 STW 標(biāo)記并發(fā)中途退化為阻塞預(yù)留窗口耗盡退化為阻塞 Gen2多核并行無無Server 模式多堆并行關(guān)閉開關(guān)GarbageCollector.GCModeMONO_GC_PARAMSSystem.GC.Concurrent/LatencyMode這張表的關(guān)鍵在第三列到第四列的跨越SGen 的并發(fā)是可以開.NET 的后臺(tái) GC 是一臺(tái)帶失敗轉(zhuǎn)移的完整狀態(tài)機(jī)——兩者都做并發(fā)標(biāo)記但只有后者把并發(fā)清掃、預(yù)留窗口、退化路徑、多堆同步這些工程配套一并做完。它也建立在本章前四篇的地基上不理解段與分配上下文就無法理解并發(fā)標(biāo)記期間的分配去哪了不理解清掃與壓縮的分工就無法理解后臺(tái)清掃能并發(fā)到什么程度。07-06 從另一個(gè)方向接續(xù)狀態(tài)機(jī)保證能并發(fā)優(yōu)化技術(shù)決定并發(fā)得有多便宜。本章總結(jié)后臺(tái) GC 的本質(zhì)是把與堆大小成正比的標(biāo)記工作挪出 STW只留下與根集合成正比的暫停三次暫停各司其職長(zhǎng)度基本不隨堆增長(zhǎng)。生命周期是初始標(biāo)記STW→ 并發(fā)標(biāo)記 → 最終標(biāo)記STW→ 并發(fā)清掃 → 收尾STW的循環(huán)外加一條指向阻塞式 Gen2 的失敗轉(zhuǎn)移。并發(fā)標(biāo)記與前臺(tái) gen0/gen1 回收是兩條并行流水線前臺(tái)回收照常發(fā)生晉升對(duì)象走 gen2 預(yù)留窗口寫屏障加卡表保證引用變更不被漏標(biāo)。BGC 的能力邊界由分配速率決定預(yù)留窗口耗盡即退化退化輪付出雙份開銷解藥在分配側(cè)而不在配置側(cè)。Server 與 Workstation 共享同一套狀態(tài)機(jī)差別在并行度、綁核與階段同步容器里DOTNET_GCHeapCount必須與配額對(duì)齊。配置默認(rèn)可用System.GC.Concurrent與LatencyMode.Interactive已開批處理才顯式關(guān)驗(yàn)收看 P99 單次 STW 與 blocking Gen2 次數(shù)不看平均值。一句話記憶點(diǎn)后臺(tái) GC 不消滅暫停它把暫停從隨堆增長(zhǎng)改成隨根集合走并用一條退化路徑為分配速率失控兜底——守住分配速率這條路徑就永遠(yuǎn)不會(huì)被走到。 07-05-源碼-.NET Core GC后臺(tái)GC實(shí)現(xiàn)
.NET Core GC 后臺(tái) GC 實(shí)現(xiàn)篇章07-源碼深度-.NET Core GC |閱讀時(shí)間約 40 分鐘一、引言后臺(tái) GCBackground GC以下簡(jiǎn)稱 BGC是 .NET Core GC 并發(fā)能力的核心GC 線程在后臺(tái)與應(yīng)用線程同時(shí)運(yùn)行把 STW 暫停從毫秒級(jí)壓到微秒級(jí)幾乎是服務(wù)器應(yīng)用的標(biāo)準(zhǔn)配置。對(duì)延遲敏感的 Web API、微服務(wù)、桌面交互應(yīng)用來說BGC 是壓住 P99 尾延遲的頭號(hào)手段對(duì)吞吐優(yōu)先的批處理任務(wù)它反而可能成為應(yīng)該關(guān)掉的開銷。但后臺(tái) GC 把暫停降到 1ms 以下這句話本身是不完整的。它沒有回答標(biāo)記到一半時(shí)應(yīng)用又在改引用怎么辦并發(fā)標(biāo)記期間 Gen0 預(yù)算用完了怎么辦后臺(tái)清掃和用戶分配同時(shí)搶一段內(nèi)存怎么辦分配速率高到后臺(tái)標(biāo)記追不上運(yùn)行時(shí)又會(huì)做什么這些問題的答案構(gòu)成了一臺(tái)狀態(tài)機(jī)理解這臺(tái)狀態(tài)機(jī)才算真正理解后臺(tái) GC。本文按動(dòng)機(jī)、生命周期、交互、清掃、觸發(fā)與回退、模式差異、源碼走讀、配置、代價(jià)、監(jiān)控、誤區(qū)、對(duì)比的順序展開。讀完你應(yīng)該能回答三個(gè)問題BGC 的每一次暫停分別在等什么前臺(tái) GC 什么時(shí)候會(huì)插進(jìn)來后臺(tái)標(biāo)記追不上分配時(shí)系統(tǒng)會(huì)退化成什么樣。二、為什么 Gen2 需要一條后臺(tái)路徑2.1 阻塞式 Gen2 回收的賬最樸素的回收流程是全程 Stop-The-World掛起所有托管線程標(biāo)記、清掃、壓縮一次做完再恢復(fù)。Gen0 和 Gen1 用這套流程沒問題因?yàn)樗鼈円幚淼拇婊顚?duì)象少、區(qū)間小暫停本來就在亞毫秒到幾毫秒量級(jí)。Gen2 不一樣它面對(duì)的是整個(gè)老年代加 LOH單次阻塞式 Gen2 回收的典型范圍是 5 到 50ms典型估算視堆規(guī)模、存活率與硬件而定不是承諾值。對(duì) 60FPS 的客戶端這是幾幀的凍結(jié)對(duì) Web 服務(wù)這是一批請(qǐng)求的尾延遲一起抖動(dòng)。問題的本質(zhì)是暫停時(shí)長(zhǎng)與什么成正比。阻塞式回收的標(biāo)記階段要遍歷整個(gè)存活集暫停時(shí)間因此近似與堆大小成正比堆只漲不縮的服務(wù)停頓只會(huì)越來越長(zhǎng)。而一次回收真正不得不暫停的部分只有根掃描線程棧、靜態(tài)字段、寄存器里的引用應(yīng)用線程隨時(shí)在改GC 必須獨(dú)占一致視圖才能掃。至于從根出發(fā)遍歷對(duì)象圖應(yīng)用線程在旁邊跑是可行的——只要把它們改過的引用記錄下來最后補(bǔ)掃一遍。后臺(tái) GC 就是按這筆賬設(shè)計(jì)的把與堆大小成正比的那部分挪到后臺(tái)線程與應(yīng)用并發(fā)執(zhí)行只把與根集合規(guī)模成正比的部分留在 STW 里。堆漲十倍根集合漲不了多少所以單次停頓基本不動(dòng)——這是 BGC 最值錢的性質(zhì)也是暫停降到微秒到亞毫秒級(jí)這句話成立的前提條件。2.2 并發(fā)不是免費(fèi)的BGC 用三樣?xùn)|西換低延遲寫屏障與卡表在并發(fā)期間持續(xù)記錄引用變更的 CPU 開銷標(biāo)記棧、臟卡緩沖等額外內(nèi)存以及并發(fā)協(xié)調(diào)本身的復(fù)雜度——后臺(tái)線程與前臺(tái)線程要在正確的時(shí)刻互相等待任何一處同步出錯(cuò)都是堆損壞。常見的量化口徑是總 GC 時(shí)間增加約 30%寫屏障的 CPU 開銷約 5% 到 10%兩組均為典型估算量級(jí)不是實(shí)測(cè)常數(shù)實(shí)際取決于分配與引用寫入的密度。這筆賬和 Unity 增量 GC 的賬是同一筆用吞吐?lián)Q延遲。還有個(gè)隱性成本并發(fā)標(biāo)記期間堆會(huì)繼續(xù)膨脹瞬時(shí)占用高于穩(wěn)態(tài)配額緊張的容器里這段膨脹有時(shí)會(huì)頂?shù)较揞~選型時(shí)要算進(jìn)去詳見第十節(jié)。2.3 常見誤解先糾正第一后臺(tái) GC 不是讓 GC 整體變快它讓暫停變短、讓總耗時(shí)變長(zhǎng)。第二后臺(tái) GC 只負(fù)責(zé) Gen2Gen0/Gen1 從來就是短暫停的前臺(tái)回收BGC 開不開它們都在。第三后臺(tái) GC 不是完全無暫停它有兩次有時(shí)是三次短暫 STW 切片只是這些切片的長(zhǎng)度跟根集合走、跟堆大小無關(guān)。第四BGC 期間照樣可能退化成阻塞式 Gen2 回收而且那次的暫停比平常更長(zhǎng)——這是第六節(jié)的主題。三、后臺(tái) GC 的完整生命周期與狀態(tài)機(jī)3.1 四段式結(jié)構(gòu)一輪后臺(tái) GC 的骨架是初始標(biāo)記短 STW→ 并發(fā)標(biāo)記 → 最終標(biāo)記短 STW→ 并發(fā)清掃。它和前臺(tái)阻塞式回收的差別只在執(zhí)行方式阻塞式把四步串在一個(gè)暫停里做完后臺(tái)模式把中間兩步放到與應(yīng)用并發(fā)的時(shí)間窗里。一輪后臺(tái) GC 的時(shí)序簡(jiǎn)化示意暫停時(shí)長(zhǎng)為典型量級(jí)非實(shí)測(cè)常數(shù) 時(shí)間軸 ────────────────────────────────────────────────────────────? 應(yīng)用線程 [運(yùn)行] ▓停▓ [運(yùn)行并發(fā)分配] ▓停▓ [運(yùn)行并發(fā)分配] ▓停▓ [運(yùn)行] … │ │ │ 初始標(biāo)記 最終標(biāo)記 清掃收尾 根 臟卡快照 補(bǔ)掃并發(fā)期的臟卡 短暫同步點(diǎn) 與堆大小無關(guān) 與堆大小無關(guān) 后臺(tái)GC線程 ├────── 并發(fā)標(biāo)記 gen2 ──────┤────── 并發(fā)清掃 ──────┤ 完成 BGC thread │ 遍歷對(duì)象圖寫屏障/卡表 │ 標(biāo)記為死的對(duì)象與段 │ │ 記錄應(yīng)用改過的引用 │ 一邊歸還一邊供分配復(fù)用 │ 前臺(tái)GC 并發(fā)標(biāo)記期間任意時(shí)刻 foreground Gen0 / Gen1 照常觸發(fā)短 STW → 壓縮短暫段 → 立即還線程 └ 兩者互不替代可理解為兩條并行的流水線 失敗分支第六節(jié) 并發(fā)標(biāo)記追不上分配 ──? 中止 BGC ──? 退化為阻塞式 Gen2 回收 比平常更長(zhǎng)的一次 STW把這張圖讀成狀態(tài)機(jī)BGC 的主干狀態(tài)就是空閑 → 初始標(biāo)記暫停→ 并發(fā)標(biāo)記 → 最終標(biāo)記暫?！?并發(fā)清掃 → 收尾暫停→ 空閑外加一條從并發(fā)標(biāo)記指向阻塞式 Gen2的失敗轉(zhuǎn)移。運(yùn)行時(shí)源碼里后臺(tái)標(biāo)記與后臺(tái)清掃各自對(duì)應(yīng)獨(dú)立的階段函數(shù)如background_mark_phase/background_sweep_phase這一族命名具體簽名隨運(yùn)行時(shí)版本演進(jìn)此處按公開設(shè)計(jì)意圖做示意標(biāo)注非逐字引用狀態(tài)切換由 GC 自己的同步原語控制而不是簡(jiǎn)單的函數(shù)調(diào)用順序。3.2 三次暫停分別在等什么暫停點(diǎn)觸發(fā)位置獨(dú)占視圖要保護(hù)什么時(shí)長(zhǎng)量級(jí)典型估算初始標(biāo)記BGC 啟動(dòng)瞬間掃描線程棧與靜態(tài)根建立標(biāo)記起點(diǎn)給卡表拍起始快照亞毫秒隨根集合與核數(shù)變化最終標(biāo)記并發(fā)標(biāo)記接近完成消化并發(fā)期間積累的臟卡與引用變更把標(biāo)記收口閉合亞毫秒到毫秒級(jí)清掃收尾并發(fā)清掃結(jié)束后臺(tái)線程與前臺(tái)分配線程對(duì)段狀態(tài)做最后同步極短關(guān)鍵在于三次暫停的長(zhǎng)度都只跟根集合、臟卡數(shù)量、線程數(shù)相關(guān)不跟堆大小相關(guān)。所以 4GB 的堆和 400MB 的堆BGC 的單次停頓差別不大——這正是阻塞式回收做不到的。臟卡數(shù)量理論上可以隨堆增大而增多但實(shí)踐里它取決于并發(fā)期間被改寫的老年代對(duì)象數(shù)量而不是堆總量所以增長(zhǎng)是溫和的、有界的。3.3 暫停與恢復(fù)是怎么發(fā)生的GC 掛起托管線程用的是協(xié)作式掛起運(yùn)行時(shí)在安全點(diǎn)safepoint檢查掛起請(qǐng)求線程到達(dá)安全點(diǎn)后主動(dòng)交出控制權(quán)遲遲不到的線程由 GC 線程劫持hijack其托管幀強(qiáng)制停下恢復(fù)時(shí)反向操作。這意味著兩件事暫停時(shí)長(zhǎng)包含等最慢線程到達(dá)安全點(diǎn)的成分線程長(zhǎng)時(shí)間執(zhí)行非托管代碼或長(zhǎng)循環(huán)里沒有安全點(diǎn)都會(huì)拉長(zhǎng) STW暫停的進(jìn)出又是全局同步操作核多的機(jī)器上每多一次暫停就多付一次同步開銷這也是 BGC 不把暫停切得更碎的原因。實(shí)用推論BGC 停頓異常偏長(zhǎng)時(shí)先別懷疑標(biāo)記算法先查有沒有線程卡在非托管調(diào)用里不出來。這類問題在 Profiler 里表現(xiàn)為GC 開始時(shí)間與線程恢復(fù)時(shí)間之間有一段空隙而不是標(biāo)記本身很慢。四、后臺(tái)標(biāo)記與前臺(tái) gen0/gen1 回收的交互4.1 兩條流水線并行不悖后臺(tái)標(biāo)記只盯 gen2。Gen0 和 Gen1 的分配照常進(jìn)行g(shù)en0 預(yù)算用完時(shí)運(yùn)行時(shí)插入一次前臺(tái)的 Gen0 或 Gen1 回收短暫 STW把短暫段里活下來的對(duì)象壓縮到一端然后立刻把線程還給應(yīng)用和后臺(tái)標(biāo)記。兩條流水線互不替代——這就是后臺(tái) GC 期間 gen0/gen1 短暫停回收照常發(fā)生的準(zhǔn)確含義。對(duì)應(yīng)用來說BGC 期間觀察到的暫停分布是一串很短的 gen0/gen1 回收 兩次極短的 BGC 切片而不是完全沒有暫停評(píng)估效果要看這個(gè)混合分布的尾部。兩者在資源上也會(huì)互相牽制都要掃根、都要?jiǎng)涌ū矶虝憾蔚膲嚎s還會(huì)改變 gen1 晉升的落點(diǎn)所以運(yùn)行時(shí)在階段切換處有明確的先后順序按公開設(shè)計(jì)意圖做示意推斷。4.2 并發(fā)期間的分配去哪了并發(fā)標(biāo)記跑著應(yīng)用還在分配 gen0/gen1 對(duì)象從 gen1 晉升進(jìn) gen2 的對(duì)象會(huì)落在哪運(yùn)行時(shí)給后臺(tái)標(biāo)記期間預(yù)留了專門的 gen2 分配窗口gen2 allocation context 一類的機(jī)制晉升對(duì)象先從這個(gè)預(yù)留窗口里取地而不是去搶后臺(tái)標(biāo)記正在處理的區(qū)域。這樣并發(fā)標(biāo)記看到的 gen2 布局不會(huì)被實(shí)時(shí)分配打亂標(biāo)記進(jìn)度也不會(huì)被頻繁重置。預(yù)留窗口不是無限的它是一塊固定量級(jí)的緩沖區(qū)分配速率高、標(biāo)記進(jìn)度慢時(shí)會(huì)被耗盡——耗盡那一刻就是 BGC 的失敗轉(zhuǎn)移點(diǎn)詳見第六節(jié)?？梢园阉斫獬尚庞妙~度標(biāo)記每推進(jìn)一段額度就續(xù)上一些標(biāo)記停滯則只出不進(jìn)歸零即違約。它也解釋了后臺(tái)標(biāo)記期間堆暫時(shí)變高屬于正常現(xiàn)象晉升的活對(duì)象先堆在窗口里等標(biāo)記完成后再由后續(xù)回收統(tǒng)一整理。4.3 引用變更如何不被漏標(biāo)并發(fā)標(biāo)記期間應(yīng)用改引用是所有并發(fā) GC 的核心難題。語義上 BGC 接近 SATBSnapshot At The Beginning原始快照式并發(fā)開始時(shí)的存活狀態(tài)被當(dāng)作快照期間改寫出來的引用都要在結(jié)束前被看到。但 .NET 并不照搬 G1 那套獨(dú)立 SATB 隊(duì)列它的記錄載體是卡表加寫屏障引用寫進(jìn)老年代對(duì)象時(shí)屏障順手標(biāo)臟對(duì)應(yīng)卡后臺(tái)標(biāo)記遇到臟卡就重掃最終標(biāo)記那次 STW 把剩余臟卡一次消化干凈。部分版本的屏障還會(huì)在標(biāo)記期對(duì)新寫入引用做更積極的補(bǔ)錄具體策略隨版本演進(jìn)以上按公開設(shè)計(jì)意圖做示意推斷。這套機(jī)制的成本落點(diǎn)很明確引用寫入密集的老年代改寫會(huì)推高臟卡率臟卡率高則最終標(biāo)記那段 STW 變長(zhǎng)同時(shí)后臺(tái)標(biāo)記要反復(fù)回掃同一片區(qū)域進(jìn)度被拖慢。這直接連到第六節(jié)的失敗回退——寫屏障記錄得再全標(biāo)記追不上分配一樣要出事。反過來寫屏障本身也有收益它在前臺(tái) gen0/gen1 回收里承擔(dān)老到新的記錄職責(zé)同一套屏障兩處復(fù)用這是分代 GC 攤薄寫屏障成本的標(biāo)準(zhǔn)做法。五、并發(fā)清掃與用戶分配共處5.1 清掃為什么也能并發(fā)阻塞式回收里清掃要跑完才恢復(fù)應(yīng)用。BGC 把這一步也放到后臺(tái)標(biāo)記已確定哪些對(duì)象是死的清掃只需按段處理這些已知死對(duì)象不必獨(dú)占整個(gè)堆。應(yīng)用在清掃期間分配走分配上下文與段的空閑區(qū)后臺(tái)清掃線程一邊回收死對(duì)象空間一邊把不再使用的段解提交decommit歸還物理頁保留虛擬地址甚至整段釋放。兩邊操作的區(qū)域由段狀態(tài)協(xié)調(diào)互不踩踏。標(biāo)記解決誰是垃圾清掃解決垃圾占的空間什么時(shí)候還兩者都發(fā)生在應(yīng)用運(yùn)行的同時(shí)。缺了并發(fā)清掃標(biāo)記省下的暫停會(huì)在清掃那一步全吐回去缺了并發(fā)標(biāo)記清掃根本無從下手。真正被留在 STW 里的只有收口動(dòng)作。這里有個(gè)容易誤解的點(diǎn)SOH 上的壓縮移動(dòng)對(duì)象并不是每輪 BGC 都在后臺(tái)完成。并發(fā)清掃主要是把空間收回來而把幸存對(duì)象搬在一起的壓縮動(dòng)作與前臺(tái)回收的分工隨運(yùn)行時(shí)版本與回收配置變化按公開設(shè)計(jì)意圖做示意推斷。可以確定的邊界是BGC 保證標(biāo)記并發(fā)、清掃并發(fā)而涉及全局對(duì)象移動(dòng)的重活仍然存在短暫同步點(diǎn)——這也是為什么 LOH 壓縮這類操作必須顯式觸發(fā)參見本專欄 07-04 對(duì)清掃與壓縮時(shí)機(jī)的拆解。5.2 清掃階段的分配友好性清掃期間的分配還有個(gè)收益后臺(tái)把死對(duì)象空間陸續(xù)交還分配慢路徑向堆要新窗口的頻率隨之下降應(yīng)用不必等一次完整的回收結(jié)束才有地方分配。反過來如果清掃追不上分配典型的高分配速率場(chǎng)景堆的已提交內(nèi)存會(huì)持續(xù)上行直到觸發(fā)更激進(jìn)的回收動(dòng)作。所以觀察到BGC 期間堆水位單調(diào)上漲不一定是泄漏先確認(rèn)清掃是否被分配速率壓制——區(qū)分手段是看GC Heap Size曲線在一輪 background 結(jié)束后有沒有回落有回落是節(jié)奏問題無回落才是泄漏嫌疑。清掃還會(huì)順手做段的歸還默認(rèn)物理頁 decommit 而虛擬地址保留System.GC.RetainVM打開后連地址空間一起歸還代價(jià)是下次擴(kuò)張要重新要地址。它的收益點(diǎn)恰好落在后臺(tái)清掃這一段——清掃越積極歸還越頻繁工作集越貼近真實(shí)需求。六、觸發(fā)條件、失敗與回退6.1 什么時(shí)候會(huì)進(jìn)入后臺(tái)模式BGC 的觸發(fā)和普通 GC 一樣由分配預(yù)算驅(qū)動(dòng)Gen2 預(yù)算耗盡或慢路徑拿不到空間時(shí)觸發(fā) Gen2 回收只要延遲模式允許且開關(guān)未關(guān)System.GC.Concurrent默認(rèn) true這次回收就以后臺(tái)方式執(zhí)行。沒有定時(shí)器在背后周期性跑 BGC——它是被分配叫醒的分配少就跑得少。顯式調(diào)用GC.Collect(2, GCCollectionMode.Forced, blocking: false)同樣走后臺(tái)路徑blocking: true則強(qiáng)制阻塞測(cè)試要確定性復(fù)現(xiàn)某類暫停時(shí)靠這個(gè)參數(shù)切換。另外兩個(gè)會(huì)主動(dòng)壓制或關(guān)閉 BGC 的開關(guān)GCLatencyMode.Batch關(guān)閉后臺(tái)回收換取吞吐LowLatency與SustainedLowLatency反過來壓制 Gen2 回收本身讓 BGC 更少被觸發(fā)代價(jià)是借未來的債堆只漲不縮。四種延遲模式的完整語義在 03-05 第七節(jié)有表格本文不重復(fù)。6.2 追不上了退化為阻塞式 Gen2這是本文最重要的失敗模型。并發(fā)標(biāo)記期間晉升與分配持續(xù)消耗 gen2 預(yù)留窗口只要后臺(tái)標(biāo)記的推進(jìn)速度低于消耗速度窗口終會(huì)耗盡。運(yùn)行時(shí)的處理是中止當(dāng)前后臺(tái) GC改為發(fā)起一次完整的阻塞式 Gen2 回收所有線程停下標(biāo)記清掃一次做完然后再恢復(fù)正常運(yùn)行。這次退化懲罰是雙重的。第一這一輪同時(shí)付了已經(jīng)跑掉的并發(fā)標(biāo)記開銷白付和一次完整阻塞暫停照付是標(biāo)準(zhǔn)的最差情況。第二退化時(shí)的堆通常正處于分配最快、存活最多的時(shí)刻阻塞暫停比穩(wěn)態(tài)下的 Gen2 回收更長(zhǎng)——量級(jí)上是 5 到 15ms典型估算非實(shí)測(cè)常數(shù)實(shí)際隨堆規(guī)模上浮。識(shí)別信號(hào)在 GC 日志里很清楚本該成對(duì)出現(xiàn)的 background 起止事件被一次 blocking Gen2 打斷或者回收計(jì)數(shù)在漲而 background 完成數(shù)不同步。什么樣的負(fù)載會(huì)把 BGC 逼到退化兩類行為疊加最危險(xiǎn)高分配速率每秒幾十 MB 量級(jí)的臨時(shí)對(duì)象示例量級(jí)和高臟卡率頻繁改寫老年代里的引用讓標(biāo)記反復(fù)回掃典型場(chǎng)景是每幀重建大對(duì)象集合的游戲邏輯、無池化的序列化流水線。應(yīng)對(duì)方向和 Unity 增量 GC 的回退應(yīng)對(duì)是同一條先把分配速率壓下來池化、復(fù)用、把大對(duì)象的重建挪到低峰期讓后臺(tái)標(biāo)記有完成一輪的喘息空間。指望調(diào) BGC 參數(shù)解決分配過多是把因果關(guān)系搞反了。6.3 失敗回退的判定口徑判斷是否頻繁退化建議用兩個(gè)差值單位時(shí)間內(nèi) blocking Gen2 的次數(shù)以及它的單次時(shí)長(zhǎng)分位數(shù)。前者高說明分配壓力大后者高說明退化代價(jià)重。只看% Time in GC會(huì)把兩者混在一起——它超過 5%經(jīng)驗(yàn)閾值示例口徑時(shí)先分清是后臺(tái)跑得多還是退化跑得多前者通常良性后者才要?jiǎng)邮?。一句話版的現(xiàn)場(chǎng)口徑就是監(jiān)控 GC 觸發(fā)頻率前臺(tái)觸發(fā)過多即后臺(tái)負(fù)載過重落到工具上是第十一節(jié)的兩條曲線。七、Server 與 Workstation 下的差異Workstation 模式下只有一個(gè)堆、一個(gè) GC 線程后臺(tái)標(biāo)記的所有活都?jí)涸谶@一個(gè)線程上與應(yīng)用線程搶核。Server 模式下每個(gè)邏輯處理器各有一個(gè)堆和對(duì)應(yīng)的 GC 線程Gen2 回收時(shí)各堆并行推進(jìn)后臺(tái)標(biāo)記的吞吐隨核數(shù)上升單個(gè)堆的規(guī)模也更小同樣的分配速率下后臺(tái)標(biāo)記更容易跑贏。維度Workstation BGCServer BGC堆與 GC 線程1 堆 1 GC 線程每邏輯處理器 1 堆 1 GC 線程可用DOTNET_GCHeapCount覆蓋后臺(tái)標(biāo)記的并行度單線程推進(jìn)與應(yīng)用搶核多堆并行各堆獨(dú)立推進(jìn)線程綁核無綁核需求默認(rèn)按掩碼綁核DOTNET_GCHeapAffinitizeMask、DOTNET_GCNoAffinitize可控退化風(fēng)險(xiǎn)單核推進(jìn)慢高分配速率下更易退化單堆更小推進(jìn)更快但多堆要協(xié)調(diào)全局階段切換內(nèi)存開銷一套堆元數(shù)據(jù)元數(shù)據(jù)按堆復(fù)制通常占堆總量 3%~5%典型估算適用場(chǎng)景桌面、低核容器、內(nèi)存緊張多核服務(wù)器、吞吐與延遲都要還有一個(gè)差異是全局階段同步Server 模式下所有堆必須一起進(jìn)入和退出某個(gè)階段比如一起完成初始標(biāo)記所以最快的堆要等最慢的堆。堆之間負(fù)載不均時(shí)這個(gè)等待會(huì)出現(xiàn)在暫停時(shí)長(zhǎng)里。配置上把DOTNET_GCHeapCount設(shè)得比實(shí)際核數(shù)少容器里很常見既能減少內(nèi)存開銷也能減少階段同步的等待者數(shù)量——03-05 第八節(jié)講容器配置時(shí)給的建議就是從這條來的。反方向也要提一句Workstation 也能開并發(fā)標(biāo)記兩種模式跑的是同一套狀態(tài)機(jī)差別只在誰來跑、跑多快、跟誰搶。所以別把我要低延遲直接翻譯成開 Server GC——1 到 2 核的容器里堆數(shù)太少并行收益覆蓋不了內(nèi)存開銷反而讓后臺(tái)標(biāo)記和應(yīng)用在僅有的核上互踩。八、代碼級(jí)走讀后臺(tái)線程與標(biāo)記循環(huán)先看后臺(tái)線程的骨架。下面這段是簡(jiǎn)化偽代碼按公開的線程模型整理非逐字源碼// 簡(jiǎn)化偽代碼 / 示意后臺(tái) GC 線程主循環(huán)結(jié)構(gòu)對(duì)應(yīng)運(yùn)行時(shí)的后臺(tái)回收線程模型 DWORD BackgroundGCThread(LPVOID param) { while (true) { WaitForGCRequest(); // 等待 GC 觸發(fā)信號(hào) // 后臺(tái)標(biāo)記與應(yīng)用并發(fā) BackgroundMark(); // 后臺(tái)清掃與應(yīng)用并發(fā) BackgroundSweep(); } }逐段解讀WaitForGCRequest()說明后臺(tái)線程平時(shí)是掛起的它不輪詢、不空轉(zhuǎn)只有 Gen2 回收被觸發(fā)且被判定為可后臺(tái)執(zhí)行時(shí)才被喚醒——這對(duì)應(yīng)第六節(jié)沒有定時(shí)器BGC 被分配叫醒的結(jié)論。BackgroundMark()與BackgroundSweep()前后相接兩者內(nèi)部各自完成暫停—恢復(fù)的往返進(jìn)入時(shí)短暫 STW 拿一致視圖拿到后立刻 ResumeAllThreads 放應(yīng)用繼續(xù)跑。循環(huán)結(jié)構(gòu)本身解釋了為什么 BGC 是一輪一輪的——每輪從請(qǐng)求開始、到清掃結(jié)束兩輪之間應(yīng)用完全不受影響。真實(shí)實(shí)現(xiàn)里這個(gè)循環(huán)還要處理退化分支BackgroundMark()內(nèi)部發(fā)現(xiàn)預(yù)留窗口耗盡時(shí)不會(huì)走到BackgroundSweep()而是直接轉(zhuǎn)入阻塞式 Gen2這一點(diǎn)偽代碼沒有畫出來讀源碼時(shí)要特別留意。再看標(biāo)記循環(huán)本身同樣是簡(jiǎn)化偽代碼 / 示意void BackgroundMark() { // 1. 初始標(biāo)記短暫 STW掃描 Roots SuspendAllThreads(); ScanRoots(); ResumeAllThreads(); // 2. 并發(fā)標(biāo)記后臺(tái)進(jìn)行 while (HasWork()) { MarkStep(); // 標(biāo)記一批對(duì)象 // 應(yīng)用線程在此期間可以運(yùn)行 } // 3. 最終標(biāo)記短暫 STW處理積壓 SuspendAllThreads(); ProcessSATBBuffer(); ResumeAllThreads(); }逐段解讀第一段的SuspendAllThreads / ScanRoots / ResumeAllThreads就是第三節(jié)表格里的初始標(biāo)記它必須包住根掃描因?yàn)楦S時(shí)在變沒有獨(dú)占視圖的根掃描結(jié)果不可信。第二段的while (HasWork())是并發(fā)標(biāo)記的主體注意循環(huán)體里沒有暫?！狹arkStep()每次推進(jìn)一小批對(duì)象就返回把 CPU 讓回給應(yīng)用進(jìn)度由標(biāo)記棧和游標(biāo)持久保存被前臺(tái) gen0/gen1 回收打斷后能精確續(xù)上這正是第四節(jié)兩條流水線并行的實(shí)現(xiàn)基礎(chǔ)。第三段的ProcessSATBBuffer對(duì)應(yīng)并發(fā)期間積累的引用變更在這個(gè)簡(jiǎn)化模型里把它畫成獨(dú)立緩沖實(shí)際運(yùn)行時(shí)的載體以臟卡表為主、輔以屏障的補(bǔ)錄策略語義都是把并發(fā)期間改出來的引用收口。整個(gè)函數(shù)的結(jié)構(gòu)印證了核心結(jié)論兩次 Suspend 之間隔著的正是與堆大小成正比的那部分工作而 Suspend 本身只承擔(dān)與根集合成正比的開銷。還有一處留白HasWork()的判定不只看標(biāo)記?？詹豢者€要看臟卡處理進(jìn)度否則會(huì)出現(xiàn)對(duì)象圖掃完了但卡還沒清的假完成。讀源碼時(shí)建議順著background_mark_phase的入口把每個(gè) return 條件抄在紙上它們就是這臺(tái)狀態(tài)機(jī)的全部出口。九、配置與開關(guān)9.1 延遲模式與后臺(tái)開關(guān)// 啟用后臺(tái) GC默認(rèn)啟用 GCSettings.LatencyMode GCLatencyMode.Batch; // 關(guān)閉后臺(tái) GC高吞吐量模式 GCSettings.LatencyMode GCLatencyMode.Interactive; // 啟用后臺(tái) GC默認(rèn)這段代碼的讀法要注意LatencyMode不只是后臺(tái) GC 的開關(guān)它是延遲策略的總閘。Interactive默認(rèn)開啟后臺(tái)回收、把 Gen2 拆成短暫停Batch關(guān)閉后臺(tái)回收換總吞吐LowLatency與SustainedLowLatency走反方向壓制 Gen2 回收本身的頻率。運(yùn)行時(shí)另有獨(dú)立于 LatencyMode 的顯式開關(guān)配置鍵System.GC.Concurrent、環(huán)境變量DOTNET_GCConcurrent關(guān)掉它 Gen2 回收一律阻塞與 LatencyMode 設(shè)成什么無關(guān)。生產(chǎn)環(huán)境建議啟動(dòng)日志里同時(shí)打印GCSettings.IsServerGC與LatencyMode否則配置鍵拼錯(cuò)、環(huán)境變量沒注入容器這類事故會(huì)一直潛伏——監(jiān)控觸發(fā)頻率的第一步就是先確認(rèn)開關(guān)落沒落上。9.2 配置鍵速查配置鍵 / 環(huán)境變量作用與 BGC 的關(guān)系System.GC.Concurrent/DOTNET_GCConcurrent后臺(tái) GC 總開關(guān)默認(rèn) true關(guān)閉即回到全程阻塞 Gen2System.GC.Server/DOTNET_GCServerServer GC 開關(guān)決定后臺(tái)標(biāo)記是單線程還是多堆并行DOTNET_GCHeapCount顯式指定堆數(shù)影響后臺(tái)標(biāo)記并行度與階段同步等待DOTNET_GCHeapAffinitizeMaskGC 線程綁核掩碼決定后臺(tái)線程落在哪些核上DOTNET_GCNoAffinitize關(guān)閉綁核容器內(nèi)核會(huì)被遷移時(shí)改用GCSettings.LatencyMode延遲策略總閘Interactive 默認(rèn)允許 BGCBatch 關(guān)閉配置建議可以歸到這張表里默認(rèn)開啟追求吞吐才關(guān)Batch 或System.GC.Concurrentfalse高分配速率場(chǎng)景要盯著前臺(tái)觸發(fā)頻率觸發(fā)過多即后臺(tái)負(fù)載過重。四條建議分別落在開不開和看什么兩端中間缺的正是第六節(jié)的失敗模型——關(guān)不關(guān)只是入口判斷跟不跟得上才是運(yùn)維期的常態(tài)問題。9.3 Unity 語境下的位置放到 Unity 語境里再補(bǔ)一層背景傳統(tǒng) Unity 的 IL2CPP 與 Mono 棧不使用 .NET Core GC這條后臺(tái) GC 鏈路對(duì)它們不可用Mono 自帶的 SGen 有有限度的并發(fā)標(biāo)記支持語義上更接近并發(fā)而非完整后臺(tái)狀態(tài)機(jī)Unity Incremental GC 是游戲場(chǎng)景下最接近后臺(tái) GC的替代方案——它同樣做并發(fā)標(biāo)記加短 STW 收口但底座是不分代不壓縮的 Boehm。Unity 6 引入的 CoreCLR 后端是唯一會(huì)真正跑上 .NET 后臺(tái) GC 的 Unity 路徑遷移前后的評(píng)估對(duì)象完全不同邊界結(jié)論見 03-04 第八節(jié)。十、代價(jià)與適用場(chǎng)景10.1 后臺(tái) GC 不是免費(fèi)的三條代價(jià)各自的作用機(jī)理如下總 GC 時(shí)間增加約 30%并發(fā)標(biāo)記的協(xié)調(diào)開銷——典型估算非實(shí)測(cè)常數(shù)。來源是寫屏障的持續(xù)開銷、標(biāo)記進(jìn)度的跨線程維護(hù)、以及并發(fā)期堆膨脹導(dǎo)致的額外標(biāo)記量。寫屏障的 CPU 開銷約 5% 到 10%每次賦值都檢查——典型估算非實(shí)測(cè)常數(shù)。落點(diǎn)在引用寫入密集的熱循環(huán)老年代改寫越頻繁卡表越臟實(shí)際開銷越靠上限。額外的內(nèi)存開銷標(biāo)記棧、臟卡緩沖以及并發(fā)期的堆膨脹——量級(jí)隨堆規(guī)模與核數(shù)變化Server 模式下按堆復(fù)制再疊上 03-05 說過的 3% 到 5% 堆元數(shù)據(jù)。把總賬放在一起說后臺(tái) GC 將暫停時(shí)間從 5 到 50ms 降到 1ms 以下代價(jià)是約 30% 的總 GC 時(shí)間增加兩處均為典型估算量級(jí)非實(shí)測(cè)常數(shù)對(duì)于延遲敏感的 Server 應(yīng)用這是值得的權(quán)衡。三條代價(jià)給出選型分界線后臺(tái) GC 適合延遲敏感型應(yīng)用Web API、交互式應(yīng)用不適合批處理型應(yīng)用數(shù)據(jù)處理、離線計(jì)算——批處理的停頓不面向用戶拆碎暫停只換來更高的總 CPU不如一次阻塞收干凈。10.2 場(chǎng)景清單與歸因場(chǎng)景結(jié)論歸因Web APIASP.NET默認(rèn)開啟暫停 1ms請(qǐng)求尾延遲直接受單次 STW 影響1ms 為典型量級(jí)非承諾值微服務(wù)推薦開啟延遲敏感對(duì)外 RPC 的 P99 就是 SLA暫停抖動(dòng)會(huì)傳導(dǎo)到調(diào)用方WPF 桌面推薦開啟UI 流暢渲染線程被 GC 凍結(jié)會(huì)直接掉幀桌面場(chǎng)景對(duì)尖峰同樣敏感批處理關(guān)閉以獲得更高吞吐無人等待延遲寫屏障與協(xié)調(diào)是純損耗計(jì)算密集減少后臺(tái)線程的 CPU 競(jìng)爭(zhēng)后臺(tái)標(biāo)記與業(yè)務(wù)線程搶核算力已打滿時(shí)并發(fā)反成負(fù)擔(dān)分配速率極高后臺(tái)跟不上時(shí)觸發(fā)前臺(tái) GC 反而更差直接命中第六節(jié)的退化路徑付雙份錢最后一行最有價(jià)值BGC 有明確的能力邊界負(fù)載超過邊界后不是效果變差而是比不開還差。判斷邊界靠的不是感覺是第十一節(jié)的監(jiān)控?cái)?shù)據(jù)。十一、后臺(tái) GC 的監(jiān)控與診斷監(jiān)控入口是性能計(jì)數(shù)器與 dotnet-counters% Time in GC應(yīng)小于 5%經(jīng)驗(yàn)閾值示例口徑超過即 GC 壓力過大實(shí)時(shí)監(jiān)控命令一行就夠——dotnet-counters monitor --process-id pid System.Runtime配套的觀察方法再往前推一步。盯三條曲線GC Heap Size看堆水位是否在一輪 background 后回落GC Count看回收頻率的斜率二者一起能把后臺(tái)跑得多和退化跑得多分開。再加一條信號(hào)監(jiān)控 GC 日志里的background關(guān)鍵字。落到事件層就是 GCStart/GCEnd 事件里帶的代數(shù)與 blocking 標(biāo)記一次 Gen2 回收如果標(biāo)記為 background成對(duì)出現(xiàn)說明完整跑完如果中間插進(jìn)一次 blocking Gen2就是退化現(xiàn)場(chǎng)。診斷順序壓成三步先用 dotnet-counters 看趨勢(shì)水位、頻率再用 dotnet-trace 或 PerfView 抓事件確認(rèn)每輪 Gen2 是 background 還是 blocking、單次時(shí)長(zhǎng)分位數(shù)多少最后才談?wù){(diào)參或改分配。跳過前兩步直接調(diào)DOTNET_GCHeapCount最常見的結(jié)局是調(diào)了半天發(fā)現(xiàn)進(jìn)程根本沒跑在預(yù)期模式上。十二、常見誤區(qū)與反模式誤區(qū)一開了 BGC 就不會(huì)再有長(zhǎng)暫停。錯(cuò)誤做法是把延遲預(yù)算全押在開關(guān)上。為什么錯(cuò)BGC 有三次短暫 STW還可能退化成阻塞式 Gen2線程卡在非托管調(diào)用里也會(huì)拉長(zhǎng)任意一次暫停。正確做法是驗(yàn)收看分布尾部P99 單次 STW、blocking Gen2 次數(shù)出現(xiàn)長(zhǎng)暫停先分類BGC 切片變長(zhǎng)、退化、還是掛起等待三者解法完全不同。誤區(qū)二后臺(tái) GC 能解決分配太多的問題。錯(cuò)誤做法是把分配速率失控歸咎于GC 不夠快反復(fù)開關(guān)后臺(tái)模式。為什么錯(cuò)BGC 只重排暫停它不減少任何分配反而因?yàn)椴l(fā)期堆膨脹讓內(nèi)存曲線更難看。正確做法是回到分配本身——池化、復(fù)用、緩存結(jié)果、把大對(duì)象重建挪出關(guān)鍵路徑讓 gen2 預(yù)留窗口的消耗速度低于標(biāo)記推進(jìn)速度退化自然消失。誤區(qū)三批處理也開后臺(tái) GC 更安全。錯(cuò)誤做法是低延遲開關(guān)無腦全開。為什么錯(cuò)批處理沒有延遲收益寫屏障與并發(fā)協(xié)調(diào)換不來任何東西只有總 CPU 上升。正確做法是顯式設(shè)Batch把這 30% 量級(jí)的總開銷典型估算拿回來同時(shí)保留 dotnet-counters 監(jiān)控防止內(nèi)存失控。誤區(qū)四% Time in GC高就一定說明后臺(tái) GC 失效。錯(cuò)誤做法是看到超過 5% 立刻動(dòng)配置。為什么錯(cuò)它把良性并發(fā)開銷和惡性退化暫?；煸谝黄?。正確做法是拆開看background 輪次的總 CPU 高但單次 STW 短是良性的blocking Gen2 次數(shù)與單次時(shí)長(zhǎng)分位數(shù)在漲才是需要干預(yù)的信號(hào)。十三、橫向?qū)Ρ扰c在全專欄中的位置維度Unity 增量 GCBoehmMono SGen 并發(fā).NET 后臺(tái) GC并發(fā)做什么分片標(biāo)記跨幀推進(jìn)可選并發(fā)標(biāo)記并發(fā)標(biāo)記 并發(fā)清掃完整狀態(tài)機(jī)暫停結(jié)構(gòu)兩次短 STW 加一次性清掃STW 為主有限并發(fā)三次短 STW初始/最終/收尾分代否兩代三代 LOH POH失敗退化回退為全量 STW 標(biāo)記并發(fā)中途退化為阻塞預(yù)留窗口耗盡退化為阻塞 Gen2多核并行無無Server 模式多堆并行關(guān)閉開關(guān)GarbageCollector.GCModeMONO_GC_PARAMSSystem.GC.Concurrent/LatencyMode這張表的關(guān)鍵在第三列到第四列的跨越SGen 的并發(fā)是可以開.NET 的后臺(tái) GC 是一臺(tái)帶失敗轉(zhuǎn)移的完整狀態(tài)機(jī)——兩者都做并發(fā)標(biāo)記但只有后者把并發(fā)清掃、預(yù)留窗口、退化路徑、多堆同步這些工程配套一并做完。它也建立在本章前四篇的地基上不理解段與分配上下文就無法理解并發(fā)標(biāo)記期間的分配去哪了不理解清掃與壓縮的分工就無法理解后臺(tái)清掃能并發(fā)到什么程度。07-06 從另一個(gè)方向接續(xù)狀態(tài)機(jī)保證能并發(fā)優(yōu)化技術(shù)決定并發(fā)得有多便宜。本章總結(jié)后臺(tái) GC 的本質(zhì)是把與堆大小成正比的標(biāo)記工作挪出 STW只留下與根集合成正比的暫停三次暫停各司其職長(zhǎng)度基本不隨堆增長(zhǎng)。生命周期是初始標(biāo)記STW→ 并發(fā)標(biāo)記 → 最終標(biāo)記STW→ 并發(fā)清掃 → 收尾STW的循環(huán)外加一條指向阻塞式 Gen2 的失敗轉(zhuǎn)移。并發(fā)標(biāo)記與前臺(tái) gen0/gen1 回收是兩條并行流水線前臺(tái)回收照常發(fā)生晉升對(duì)象走 gen2 預(yù)留窗口寫屏障加卡表保證引用變更不被漏標(biāo)。BGC 的能力邊界由分配速率決定預(yù)留窗口耗盡即退化退化輪付出雙份開銷解藥在分配側(cè)而不在配置側(cè)。Server 與 Workstation 共享同一套狀態(tài)機(jī)差別在并行度、綁核與階段同步容器里DOTNET_GCHeapCount必須與配額對(duì)齊。配置默認(rèn)可用System.GC.Concurrent與LatencyMode.Interactive已開批處理才顯式關(guān)驗(yàn)收看 P99 單次 STW 與 blocking Gen2 次數(shù)不看平均值。一句話記憶點(diǎn)后臺(tái) GC 不消滅暫停它把暫停從隨堆增長(zhǎng)改成隨根集合走并用一條退化路徑為分配速率失控兜底——守住分配速率這條路徑就永遠(yuǎn)不會(huì)被走到。