核心警示：
所謂的"最佳實踐"未必正確。
?? 本文價值
我們曾有一個遵循所有"最佳實踐"的 .NET 微服務(wù)——異步、緩存、Minimal API 一應(yīng)俱全。但它仍在 3K RPS 時崩潰。原因何在？我們輕信了宣傳，而非性能分析器。
本文用真實指標(biāo)揭穿 .NET 最頑固的性能神話，并提供可落地的解決方案。
?? 神話 1：緩存萬能提速
?? 真相：過度緩存反而損害性能
盲目緩存會導(dǎo)致：
- ? 內(nèi)存膨脹（GC 壓力增加 Gen2 回收）
- ? 數(shù)據(jù)陳舊（用戶看到過期內(nèi)容）
?? 解決方案：
var cacheEntryOptions = new MemoryCacheEntryOptions
{
SlidingExpiration = TimeSpan.FromMinutes(10),
Size = 1 // 限制條目大小
};
_memoryCache.Set("user:123", userData, cacheEntryOptions);
?? 反例：
緩存分頁列表或?qū)崟r儀表盤數(shù)據(jù) → 低重用率 + 數(shù)據(jù)過時
?? 神話 2：GC 是性能元兇
?? 真相：GC 是 .NET 的優(yōu)勢，而非敵人
問題通常源于：
?? 解決方案：
var pool = ArrayPool<byte>.Shared;
byte[] buffer = pool.Rent(1024); // 租用緩沖區(qū)
// 使用緩沖區(qū)...
pool.Return(buffer); // 歸還資源
?? 反例：
在單例服務(wù)緩存大型結(jié)果集 → 內(nèi)存固定 + 阻止 Gen0/1 回收
?? 神話 3：HttpClient 單例永遠(yuǎn)正確
?? 真相：云環(huán)境中會導(dǎo)致 DNS 陳舊問題
后端 IP 變更時持續(xù)訪問舊地址
?? 解決方案：
services.AddHttpClient("Weather", client =>
{
client.BaseAddress = new Uri("https://api.weather.com");
}); // 連接池自動處理 DNS 輪轉(zhuǎn)
?? 神話 4：值類型永遠(yuǎn)更快
?? 真相：誤用 struct 導(dǎo)致裝箱開銷
struct Point : IComparable // 反例
{
public int X, Y;
public int CompareTo(object obj) => 0; // 引發(fā)裝箱
}
?? 適用場景：
- ? 小型（≤16字節(jié)）短生命周期數(shù)據(jù)
- ? 無需多態(tài)或頻繁轉(zhuǎn)型的場景
?? 神話 5：Span 是萬能救星
?? 真相：濫用導(dǎo)致棧溢出/緩沖區(qū)溢出
?? 適用場景：
Span<byte> buffer = stackalloc byte[256]; // 高效切片
ReadOnlySpan<byte> header = buffer.Slice(0, 4);
?? 禁用場景：
- ? 大型棧分配（謹(jǐn)慎使用
stackalloc）
?? 神話 6：async/await 必然提升性能
?? 真相：提升擴(kuò)展性而非原始速度
?? 解決方案：
// I/O 密集型：使用 async
await _httpClient.GetAsync(url);
// CPU 密集型：顯式卸載
await Task.Run(() => DoHeavyCalculation());
?? 神話 7：Minimal API 永遠(yuǎn)快于 MVC
?? 真相：真實負(fù)載下性能差距可忽略
?? 適用場景：
- ? 無過濾器/約定的簡單端點
? 勿為性能遷移 MVC 項目
?? 神話 8：Release 構(gòu)建永遠(yuǎn)最快
?? 真相：未啟用高級優(yōu)化仍存瓶頸
?? 解決方案：
<PropertyGroup>
<TieredCompilation>true</TieredCompilation> <!-- 分層編譯 -->
<ReadyToRun>true</ReadyToRun> <!-- 預(yù)編譯優(yōu)化 -->
</PropertyGroup>
?? 神話 9：List 永遠(yuǎn)快于 IEnumerable
?? 真相：單次迭代時強(qiáng)制轉(zhuǎn) List 增加內(nèi)存壓力
?? 解決方案：
IEnumerable<int> GenerateSequence() // 惰性求值
{
for (int i = 0; i < 1000; i++)
yield return i;
}
?? 神話 10：必須避免 LINQ
?? 真相：清晰度優(yōu)于過早優(yōu)化
?? 高性能技巧：
if (items.TryGetNonEnumeratedCount(out int count)) // .NET6+ 特性
{
// 避免不必要的枚舉
}
? 性能優(yōu)化黃金清單
| |
| |
| 監(jiān)控 GC 的 %Time 指標(biāo) | |
| |
| 值類型用于小型數(shù)據(jù)結(jié)構(gòu) | |
| 大型數(shù)據(jù)使用 stackalloc |
| |
| |
| |
| 所有集合強(qiáng)轉(zhuǎn) List |
| LINQ 配合 TryGetNonEnumeratedCount | |
?? 終極忠告
性能神話不僅浪費 CPU 周期——更浪費工程師生命。
不要追隨最響亮的聲音，
遵循你的性能分析器、監(jiān)控指標(biāo)和官方指南。
記住：當(dāng) 3AM 的生產(chǎn)告警響起時，只有真實數(shù)據(jù)能拯救你。
閱讀原文：https://mp.weixin.qq.com/s/CKWvjZngX-D-APxh6HssVg
該文章在 2025/7/26 9:51:13 編輯過
400 186 1886
