一、為什么要關注.NET異常處理的性能

隨著現(xiàn)代云原生、高并發(fā)、分布式場景的大量普及，異常處理（Exception Handling）早已不再只是一個冷僻的代碼路徑。在高復雜度的微服務、網(wǎng)絡服務、異步編程環(huán)境下，服務依賴的外部資源往往不可靠，偶發(fā)失效或小概率的“雪崩”場景已經(jīng)十分常見。實際系統(tǒng)常常在高頻率地拋出、傳遞、捕獲異常，異常處理性能直接影響著系統(tǒng)的恢復速度、吞吐量，甚至是穩(wěn)定性與容錯邊界。

.NET平臺在異常處理性能方面長期落后于C++、Java等同類主流平臺——業(yè)內(nèi)社區(qū)多次對比公開跑分就證實了這一點，.NET 8時代雖然差距有所縮小，但在某些高并發(fā)/異步等極端場景下，異常高開銷持續(xù)困擾社區(qū)和大廠工程師。于是到了.NET 9，終于迎來了一次代際變革式的性能飛躍，拋出/捕獲異常的耗時基本追平C++，成為技術圈最關注的.NET runtime底層事件之一。

二、實測：.NET 9異常處理提速直觀對比

1. 測試代碼

最經(jīng)典的異常性能測試如下——C# 和 Java的實現(xiàn)基本一致

C#:

class ExceptionPerformanceTest
{
    public void Test()
    {
        var stopwatch = Stopwatch.StartNew();
        ExceptionTest(100_000);
        stopwatch.Stop();
        Console.WriteLine(stopwatch.ElapsedMilliseconds);
    }
    private void ExceptionTest(long times)
    {
        for (int i = 0; i < times; i++)
        {
            try
            {
                throw new Exception();
            }
            catch (Exception ex)
            {
                // Ignore
            }
        }
    }
}

Java:

public class ExceptionPerformanceTest {
    public void Test() {
        Instant start = Instant.now();
        ExceptionTest(100_000);
        Instant end = Instant.now();
        Duration duration = Duration.between(start, end);
        System.out.println(duration.toMillis());
    }

    private void ExceptionTest(long times) {
        for (int i = 0; i < times; i++) {
            try {
                throw new Exception();
            } catch (Exception ex) {
                // Ignore
            }
        }
    }
}

2. 早期測試結(jié)果

以.NET Core 2.2時代為例

• .NET: 2151ms
• Java: 175ms

.NET 的異常拋出/捕獲速度相較慢得多。但到了.NET 8后期和.NET 9，基準成績已翻天覆地：

3. 新時代基準結(jié)果（.NET 8 vs .NET 9）

借助 BenchmarkDotNet 可以更科學對比：

using BenchmarkDotNet.Attributes;
using BenchmarkDotNet.Columns;
using BenchmarkDotNet.Configs;
using BenchmarkDotNet.Jobs;
using BenchmarkDotNet.Reports;
using BenchmarkDotNet.Environments;

namespace ExceptionBenchmark
{
    [Config(typeof(Config))]
    [HideColumns(Column.Job, Column.RatioSD, Column.AllocRatio, Column.Gen0, Column.Gen1)]
    [MemoryDiagnoser]
    public class ExceptionBenchmark
    {
        private const int NumberOfIterations = 1000;

        [Benchmark]
        public void ThrowAndCatchException()
        {
            for (int i = 0; i < NumberOfIterations; i++)
            {
                try
                {
                    ThrowException();
                }
                catch
                {
                    // Exception caught - the cost of this is what we're measuring
                }
            }
        }

        private void ThrowException()
        {
            throw new System.Exception("This is a test exception.");
        }

        private class Config : ManualConfig
        {
            public Config()
            {
                AddJob(Job.Default.WithId(".NET 8").WithRuntime(CoreRuntime.Core80).AsBaseline());
                AddJob(Job.Default.WithId(".NET 9").WithRuntime(CoreRuntime.Core90));

                SummaryStyle =
                    SummaryStyle.Default.WithRatioStyle(RatioStyle.Percentage);
            }
        }
    }
}

如下圖結(jié)果，拋出+捕獲1000次異常：

• .NET 8：每次約 12μs
• .NET 9：每次減少至約 2.8μs （約76~80%提升）

.NET 9的性能提升幾乎讓EH成本降到C++/Java同量級，成為托管平臺的性能標桿之一。

三、.NET早期異常處理為何如此之慢？

1. 策略層面的歷史誤區(qū)

傳統(tǒng)觀點認為：“異常只為異常流程準備，主業(yè)務應以if/else或TryXXX等方式避免極端異常分支”。社區(qū)和官方因此忽視了EH系統(tǒng)的極限性能，無論架構(gòu)設計還是細節(jié)實現(xiàn)都欠缺優(yōu)化，反映在：

• 內(nèi)部優(yōu)先保證兼容性和健壯性，而不是高性能
• 代碼中凡是熱路徑，都讓開發(fā)者“自覺避開異常”

近年來，現(xiàn)代服務常常：

• 依賴于“不可靠資源” （如網(wǎng)絡、外部API、云存儲），短暫失效隨時發(fā)生
• 借助基于async/await的異步編程，異常常?？鐥?、跨線程重拋
• 在微服務系統(tǒng)中，單點故障可能導致“異常風暴”，大量請求因依賴故障極短時間內(nèi)批量失敗

這些場景下，異常處理已極易成為性能瓶頸，應用的可用性與SLA依賴于異?；謴退俣?。

2. CoreCLR/Mono 異常實現(xiàn)機制的先天劣勢

Windows實現(xiàn)

采用Windows的Structured Exception Handling (SEH)，異常拋出后，OS內(nèi)核統(tǒng)一回溯堆棧、查找/觸發(fā)catch和finally，且需要“雙遍遍歷”棧幀（第一次查catch、第二次觸發(fā)catch/finally，源數(shù)據(jù)由Windows維護）

Structured Exception Handling（結(jié)構(gòu)化異常處理，簡稱 SEH）是微軟 Windows 操作系統(tǒng)上一種異常處理機制，主要用于捕獲和處理程序運行過程中產(chǎn)生的異常，如訪問違規(guī)（Access Violation）、除零錯誤、非法指令等。在 Windows 平臺上，SEH 被底層編譯器和系統(tǒng)廣泛支持。

用戶層主要通過回調(diào)介入，絕大多數(shù)性能消耗“鎖死”在OS堆棧查找、回調(diào)和上下文切換中，優(yōu)化空間很小

Unix/Linux實現(xiàn)

沒有SEH，只能自己模擬

采用C++異常，異常拋出后靠libgcc/libunwind的_C++機制回溯托管棧，但需“橋接”托管/本地的邊界，異常對象需反復throw/catch，初始化/過濾時會有多次C++異常嵌套傳遞

libunwind 是一個開源的?；厮輲?，主要用于在運行時獲取和操作調(diào)用棧，從而支持異常處理、調(diào)試和崩潰分析等功能。

托管運行時(如ExecutionManager) 需要頻繁做函數(shù)表和異常元數(shù)據(jù)線性遍歷（鏈表查找），并發(fā)場景下會有大量鎖競爭，極易成為瓶頸

實際CPU性能熱點采樣發(fā)現(xiàn)：

• libgcc_s.so.1/_Unwind_Find_FDE等C++異常系統(tǒng)函數(shù)占用近13%的熱點
• 托管代碼層大量鏈表遍歷/鎖(ExecutionManager::FindCodeRangeWithLock等)
• 多線程/多異常場景下lock惡性競爭，棧查找速度極慢

額外開銷

• 每次拋出異常需清空/復制完整CONTEXT結(jié)構(gòu)（Windows上下文），單次就近1KB數(shù)據(jù)
• 捕獲棧信息、生成調(diào)試輔助、捕獲完整stacktrace等都增加明顯延遲

3. Async/多線程場景放大性能損耗

現(xiàn)代C#的async/await廣泛出現(xiàn)。每遇到await斷點，異常需在async狀態(tài)機多次catch/throw重入口，即使只有1層異常，實際走了多倍catch分支。多線程下，本地堆?；ゲ魂P聯(lián)，所有?；厮荨⒃獢?shù)據(jù)查找都需走OS或本地鎖/鏈表，進一步拉低性能擴展性。

4. 跨平臺和歷史兼容包袱

因Windows/Unix兩套機制并存，大量platform abstraction和邊界容錯邏輯，極大增加了維護成本和bug風險。每一次異?？缃缍夹枰厥馓幚?，開發(fā)運維和調(diào)優(yōu)都十分困難。

以下是.NET9以前多線程和單線程異常拋出耗時，可以看到隨著堆棧深度的增加，拋出異常要花費的世界越來越長。

四、技術極客視角：.NET 9徹底變革的細節(jié)原理

.NET 9之所以實現(xiàn)了異常處理的性能“質(zhì)變”，核心思路是吸收NativeAOT的極簡托管實現(xiàn)，將主力流程自托管直接管理，核心只依賴native stack walker完成功能邊界，避免一切反復嵌套或冗余環(huán)節(jié)。

（一）NativeAOT異常處理架構(gòu)剖析

1. 設計變革

• 完全托管驅(qū)動主流程異常的捕獲、catch分派、finally查找、異常對象/類型的元數(shù)據(jù)查找等主環(huán)節(jié)，全部寫成托管代碼（C#邏輯）。
• native code僅負責棧幀展開（stack walking）需要時才調(diào)用本地API（libunwind/Windows API）由native/cross平臺實現(xiàn)stack frame的move next/遍歷，極簡無其他依賴。
• 無C++異常橋接，這樣省去了_os-unwind、double catch-rethrow等所有歷史冗余。
• 功能單純、易于調(diào)優(yōu)和定制，不到300行關鍵路徑代碼。

2. 優(yōu)勢分析

• 代碼極簡，熱路徑關鍵點完全可控
• 不存在異步場景下的“狀態(tài)機分支回溯”性能急劇下滑
• 托管邏輯易于內(nèi)聯(lián)、緩存
• Native代碼只做最小功能、極易換實現(xiàn)/裁剪
• 性能調(diào)優(yōu)點固定且標志性突出（大部分耗時都在stack walker/元數(shù)據(jù)cache里）
• 兼容可擴展，后續(xù)想做特殊異常/自定義類型極為簡便

3. 技術細節(jié)

• 異常對象的stacktrace/元數(shù)據(jù)在托管代碼按需附加
• 若已知異常只在本地代碼路徑，完全可繞開“不需要的”full stacktrace/callstack/diagnostic等場景
• 可以整合cache優(yōu)化，如將每個托管JIT幀的元數(shù)據(jù)查找結(jié)果放本地線程緩存（甚至開啟pgo熱點分支識別，見后續(xù)）。

（二）.NET 9實現(xiàn)與補全 —— 同步NativeAOT設計到CoreCLR

在.NET 9，團隊把NativeAOT的異常處理模式移植到了CoreCLR上。主要技術變更包括：

• 將異常展開、catch/finally分派等環(huán)節(jié)全部搬到托管主流程
• native helper只做最小的stack frame展開，與垃圾回收棧遍歷接口復用（易于維護）
• 強化托管級緩存與元數(shù)據(jù)管理。關鍵鏈表遍歷全部升級成緩存/高速哈希表，一舉解決了多線程、深棧、頻繁異常場景下的scalability困境
• 釘死所有多余的C++ throw/catch——對Unix/Windows都生效
• 為Async/Await生成優(yōu)化代碼路徑，避免多次重復拋出/捕獲

工程落地與效果

• 性能測試實測，異常處理耗時降幅約76%~80%，多線程/高并發(fā)效果更好
• 性能剖析熱點：主要耗時已縮小到stack walker和關鍵數(shù)據(jù)結(jié)構(gòu)哈希效率上，其他已近極致
• 全平臺統(tǒng)一，無歷史特殊兼容路徑、包袱

真實圖片示例

1.單線程性能提升圖：

2.多線程性能提升圖：

（三）可進一步優(yōu)化的場景與細節(jié)

熱點分支profile（PGO）

• 異常的“常用路徑”可被profile，按pgo機制熱路徑內(nèi)聯(lián)/重編排邏輯
• 比如async await狀態(tài)機里常拋異常的分支inline獲得最佳cache局部性

Unwind Section緩存/優(yōu)化

• 比如在libunwind的findUnwindSections過程中用cache提升多線程吞吐，已實測可提速近7倍
• 類似樣板代碼見：https://gist.github.com/filipnavara/9dca9d78bf2a768a9512afe9233d4cbe

雙檢省棧trace與細粒度采集

支持僅按需采集stacktrace（避免捕獲所有調(diào)試信息）

特殊場景快速捕獲（業(yè)務異常/操作性異常）

通過拓展托管catch塊類型，可以極簡分為業(yè)務異常與系統(tǒng)異常，實現(xiàn)“無棧捕獲”，加速高頻捕獲型異常（如EndOfData、ParseError等流控制型異常）

異步異常統(tǒng)一延遲捕獲傳遞

在沒有用戶自定義try塊的async方法中，捕獲異常僅保存，真正拋出延遲到非異常主流程結(jié)束前即可。這將極大降低狀態(tài)機驅(qū)動的拋出/捕獲次數(shù)。

六、總結(jié)展望

.NET 9通過徹底擁抱NativeAOT極簡式的托管異常處理體系，把歷史包袱（OS-Specific/C++ Exception Bridge/冗余鏈表&鎖/多次catch-rethrow）一舉清除，大幅釋放了異常路徑的性能潛力。這一變革支撐了.NET在微服務、云原生、異步并發(fā)等新主流場景下的頂級運行時表現(xiàn)。未來，隨著堆棧展開、元數(shù)據(jù)cache自適應等不斷迭代，.NET有望成為托管平臺的異常處理性能“天花板”。

到此這篇關于.NET9中異常處理性能提升分析的文章就介紹到這了,更多相關.NET9異常處理內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家！