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