最近小編研究了C# 15的一批新語法翻到集合表達(dá)式時(shí)突然被with(capacity:)這個(gè)不起眼的修飾符勾住了。說起來有點(diǎn)不好意思寫 .NET 這么多年我一直是能用就行派Listint items new();然后閉眼往循環(huán)里Add。直到上周做數(shù)據(jù)處理往 List 里塞了幾百萬條記錄肉眼可見地卡頓我才認(rèn)真把預(yù)分配這三個(gè)字掰開揉碎研究了一遍。先別急著寫代碼List的成長煩惱你了解嗎ListT的本質(zhì)是一個(gè)會(huì)自動(dòng)長大的數(shù)組。它內(nèi)部維護(hù)一塊連續(xù)內(nèi)存_items數(shù)組不夠用時(shí)就擴(kuò)容。擴(kuò)容策略簡單粗暴容量翻倍——0 → 4 → 8 → 16 → 32 → …… 一直翻到裝得下為止。每次擴(kuò)容要干兩件事重新申請一塊更大的內(nèi)存。把舊數(shù)組的所有元素逐個(gè)拷貝過去。// ListT 擴(kuò)容的真實(shí)邏輯源碼簡化版 private void Grow(int capacity) { // 新容量 舊容量 * 2空數(shù)組時(shí)下限是 4 int newCapacity _items.Length 0 ? 4 : 2 * _items.Length; // 翻倍還不夠裝直接用需要的容量 if ((uint)newCapacity (uint)capacity) newCapacity capacity; // 新數(shù)組 老數(shù)據(jù)全量拷貝一步到位 Array.Resize(ref _items, newCapacity); }以 10 萬個(gè) int 為例無預(yù)分配時(shí)容量要經(jīng)歷 4、8、16、……、65536、131072一共 16 次擴(kuò)容累計(jì)拷貝約 13 萬個(gè)元素。單看數(shù)據(jù)量不大但請注意131072 × 4 字節(jié) 512KB已經(jīng)超過 85KB 的大對(duì)象堆LOH閾值。也就是說擴(kuò)容到后期申請的全是大數(shù)組頻繁分配 拷貝會(huì)造成 LOH 碎片和額外的 GC 壓力數(shù)據(jù)量再大幾倍卡頓就來了。這里有個(gè)新手極易踩坑的地方很多文章只說翻倍擴(kuò)容卻沒人提 LOH當(dāng)集合元素超過約 2 萬個(gè) int或同等字節(jié)數(shù)時(shí)底層數(shù)組就進(jìn)了大對(duì)象堆反復(fù)擴(kuò)容的代價(jià)比你想的高得多。三種寫法直接上實(shí)測我寫了個(gè)小實(shí)驗(yàn)往 List 里塞 10 萬個(gè)元素分別用三種方式創(chuàng)建。寫法一祖?zhèn)?new() 無腦 Add// 零預(yù)分配全靠擴(kuò)容硬扛 Listint items new(); for (int i 0; i 100_000; i) items.Add(i);寫法二老派的 new(capacity) 預(yù)分配// 提前告訴 List 我要 10 萬個(gè)避免中途擴(kuò)容 Listint items new(100_000); for (int i 0; i 100_000; i) items.Add(i);寫法三C# 15 的 with(capacity:) 集合表達(dá)式// 集合表達(dá)式 with(capacity:) 預(yù)分配 展開運(yùn)算符填充 Listint items [with(capacity: 100_000), ..Enumerable.Range(0, 100_000)];完整測速代碼如下using System.Diagnostics; const int Size 100_000; // 教訓(xùn)來自我第一次跑出來的假數(shù)據(jù) // 毫秒精度 無預(yù)熱 固定順序結(jié)果完全失真 var sw Stopwatch.StartNew(); // 先熱熱身把 JIT 編譯和啟動(dòng)開銷排除在外 Warmup(); // 寫法一無預(yù)分配 sw.Restart(); Listint noCap new(); for (int i 0; i Size; i) noCap.Add(i); Console.WriteLine($無預(yù)分配 : {sw.ElapsedTicks / 10f:F1} us); // 寫法二傳統(tǒng)容量預(yù)分配 sw.Restart(); Listint old new(Size); for (int i 0; i Size; i) old.Add(i); Console.WriteLine($new(capacity) 預(yù)分配 : {sw.ElapsedTicks / 10f:F1} us); // 寫法三C# 15 with(capacity:) sw.Restart(); Listint modern [with(capacity: Size), ..Enumerable.Range(0, Size)]; Console.WriteLine($with(capacity:) : {sw.ElapsedTicks / 10f:F1} us); static void Warmup() { var list new Listint(); for (int i 0; i Size; i) list.Add(i); }結(jié)果我跑了好幾輪取的是中位數(shù)new()無腦版最慢new(Size)和with(capacity:)速度接近都是無預(yù)分配版的2 倍以上with() 版本在部分輪次略快但差距基本在誤差范圍內(nèi)。先潑盆冷水第一次實(shí)測我差點(diǎn)被數(shù)據(jù)騙了說實(shí)話第一次跑的時(shí)候我的結(jié)果完美得可疑——with() 版本穩(wěn)壓 50% 以上。后來一查才發(fā)現(xiàn)問題全出在測量方式上毫秒精度太粗ElapsedMilliseconds是整數(shù)毫秒10 萬元素這種量級(jí)本來就幾毫秒誤差直接把真實(shí)差距淹沒了。沒有預(yù)熱第一段代碼吃滿 JIT 編譯和啟動(dòng)開銷誰先跑誰吃虧。固定執(zhí)行順序執(zhí)行順序本身就是個(gè)隱藏變量。這也是很多性能帖子的通病結(jié)論不是代碼跑出來的是測量方式跑出來的。我后來改成預(yù)熱 亂序 多輪取中位數(shù)這才看到真實(shí)差距——預(yù)分配確實(shí)贏但贏在少擴(kuò)容而不是語法本身。with(capacity:) 到底香在哪我的答案是可讀性 上限保護(hù)先說性能new(Size)和[with(capacity: Size), ..]本質(zhì)都在做同一件事——提前確定底層數(shù)組大小省掉擴(kuò)容。二者是同一個(gè)量級(jí)誰也別想碾壓誰。那新語法價(jià)值在哪我認(rèn)為有三點(diǎn)聲明式表達(dá)集合表達(dá)式把建集合 定容量 填充壓成一行語義自文檔化讀代碼的人一眼就知道你要干什么。容量上限保護(hù)with(capacity:)讓你在填充前就把規(guī)模預(yù)期寫死從寫法上杜絕忘了預(yù)分配。生態(tài)統(tǒng)一C# 15 之后集合初始化越來越值語義配合 spread 運(yùn)算符..拼裝數(shù)據(jù)流的代碼能寫得非常順。適用場景我的判斷明確知道規(guī)模批量灌數(shù)據(jù)、從數(shù)據(jù)庫讀 N 條→ 必須預(yù)分配熱點(diǎn)路徑高頻創(chuàng)建集合→ 預(yù)分配能明顯降 GC不知道規(guī)?！?別硬猜new()EnsureCapacity按需兜底。避坑清單預(yù)分配不是無腦抄容量別拍腦袋with(capacity: 1_000_000)但只塞 10 條純屬浪費(fèi)內(nèi)存。預(yù)分配的是內(nèi)存不是保險(xiǎn)。大集合留意 LOH超過 85KB 的數(shù)組進(jìn)大對(duì)象堆頻繁擴(kuò)容更容易碎片化。能一次到位就一次到位。測性能先講方法論預(yù)熱、亂序、多輪、取中位數(shù)別拿ElapsedMilliseconds唬自己。注意版本要求with(capacity:)是 C# 15 語法需要 .NET 10 及以上 SDK生產(chǎn)環(huán)境沒升級(jí)就老老實(shí)實(shí)用new(capacity)?？偨Y(jié)List 預(yù)分配這事說到底是數(shù)組擴(kuò)容成本和內(nèi)存占用的博弈。new()不是不能用而是你要知道它在背后默默擴(kuò)容了 16 次new(capacity)是性價(jià)比最高的傳統(tǒng)解C# 15 的with(capacity:)則是把這件事做成了聲明式語法代碼更干凈心智負(fù)擔(dān)更小。大家對(duì)這個(gè)with的這個(gè)新語法有什么看法歡迎留言討論。參考https://learn.microsoft.com/zh-cn/dotnet/csharp/whats-new/csharp-15#collection-expression-arguments