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