您现在的位置：程式碼之家 >> 編程語言 > >> .NET 網頁程式設計 >> C# >> 關於C#

C# 程式碼優化實戰指南：Finalize 代價、轉換開銷、實值型別、StringBuilder、內聯與現代高效能模式

編輯：關於C#

前言：效能優化從理解執行平台開始

.NET 執行平台（CLR）提供自動記憶體管理、JIT 編譯、型別安全等服務，但錯誤的程式設計模式會抵消這些優勢。本文針對終結化、托管/非托管轉換、實值型別 vs 參考型別、字串操作、方法內聯、現代高效能 API（Span/Memory/ArrayPool/ValueTask）提供可落地的優化策略與基準測試建議。

一、終結化與 `IDisposable`：避免 GC 雙重收集代價

1.1 終結化機制回顧

擁有 ~Finalizer() 的物件 → 配置時登記於「終結化佇列」。
GC 標記不可達 → 移至「f-reachable 佇列」→ 專用終結化執行緒執行 Finalize → **下一次 GC 才回收記憶體**。
代價：至少兩次 GC 週期、記憶體滯留、終結化順序不定、執行緒不安全、例外吞沒風險。

1.2 標準 `IDisposable` 模式抑制終結化


public sealed class ResourceHolder : IDisposable
{
    private IntPtr _handle;
    private bool _disposed;

    public void Dispose()
    {
        Dispose(true);
        GC.SuppressFinalize(this); // 關鍵：移出終結化佇列
    }

    private void Dispose(bool disposing)
    {
        if (_disposed) return;
        if (disposing) { /* 釋放受控資源 */ }
        if (_handle != IntPtr.Zero) { Native.Release(_handle); _handle = IntPtr.Zero; }
        _disposed = true;
    }

    ~ResourceHolder() => Dispose(false); // 僅作為安全網
}

最佳實務：能實作 IDisposable 就不寫 Finalizer；非受控資源封裝於 SafeHandle 衍生類別，完全移除 Finalizer。

1.3 `SafeHandle`：框架級非受控資源封裝


internal sealed class SafeLibraryHandle : SafeHandleZeroOrMinusOneIsInvalid
{
    private SafeLibraryHandle() : base(true) { }
    public static SafeLibraryHandle Load(string path) => 
        new SafeLibraryHandle { handle = Native.LoadLibrary(path) };
    protected override bool ReleaseHandle() => Native.FreeLibrary(handle);
}

關鍵終結化（Critical Finalization）：即使 AppDomain 卸載、執行緒中止也保證執行。
無需手寫 Dispose/Finalize，消除錯誤風險。

二、托管/非托管轉換：最小化 P/Invoke 呼叫頻率

2.1 轉換開銷來源

參數封送（複製、固定、轉換字串編碼、陣列釘選）。
堆疊框架轉換（Managed → Unmanaged 呼叫慣例切換）。
安全性檢查（SecurityPermissionFlags.UnmanagedCode）。
估計每次呼叫 10–40 條指令 + 可能的頁面錯誤/快取未命中。

2.2 批次化策略


// 不佳：迴圈中逐筆呼叫
foreach (var id in ids) Native.Process(id);

// 優化：批次 API 或緩衝區傳遞
Native.ProcessBatch(ids, ids.Length); // 單次轉換處理陣列
// 或
var buffer = Marshal.AllocHGlobal(ids.Length * sizeof(int));
try { Marshal.Copy(ids, 0, buffer, ids.Length); Native.ProcessBuffer(buffer, ids.Length); }
finally { Marshal.FreeHGlobal(buffer); }

2.3 `Span<T>`/`Memory<T>` 零複製互操作


// .NET 5+ 支援 Span 釘選
Span span = stackalloc byte[256];
unsafe {
    fixed (byte* ptr = span) {
        Native.FillBuffer(ptr, span.Length); // 無複製、無釘選開銷（堆疊記憶體）
    }
}
// 或使用 MemoryMarshal.GetArrayDataReference 配合固定大小陣列

三、實值型別：堆疊配置、無 GC 壓力、避免裝箱

3.1 何時選擇 `struct`

小型（≤ 16/24 bytes）、不可變、高頻配置、邏輯上為單一值（座標、金額、日期、資料庫識別碼）。
readonly struct（C# 7.2+）防禦性複製最佳化。
ref struct（C# 7.2+）僅限堆疊（Span<T>、ref struct 自訂）。

3.2 避免隱性裝箱陷阱

程式碼	裝箱原因	修正
`object o = myStruct;`	指派給 `object`/介面	使用泛型 `T`、`IEquatable<T>`、`ISpanFormattable`
`Console.WriteLine(myStruct);`	`WriteLine(object)` 多載	`Console.WriteLine(myStruct.ToString())` 或實作 `ISpanFormattable`
`list.Add(myStruct);` (ArrayList)	非泛型集合	改用 `List<T>`
`var eq = myStruct.Equals(other);`	呼叫 `ValueType.Equals(object)`	實作 `IEquatable<T>`、覆寫 `Equals(T)`

四、字串操作：`StringBuilder`、`string.Create`、`Utf8String`、插值處理器

4.1 字串不可變性導致的配置風暴


// 不佳：每次連接配置新字串
string s = "";
for (int i = 0; i < 1000; i++) s += i.ToString(); // 1000 次配置、複製

// 良好：StringBuilder
var sb = new StringBuilder(1000 * 4);
for (int i = 0; i < 1000; i++) sb.Append(i);
string result = sb.ToString();

// 最佳（.NET Core 2.1+）：string.Create + 插值處理器
string result = string.Create(1000 * 4, 1000, static (span, count) => {
    var handler = new System.Text.StringBuilderInterpolatedStringHandler(0, 0, null, span);
    for (int i = 0; i < count; i++) handler.AppendFormatted(i);
});

4.2 高效能場景：UTF-8 直接輸出


// 避免 UTF-16 → UTF-8 轉換
var utf8Bytes = "Hello World"u8.ToArray(); // C# 11+ UTF-8 字串常值
// 或
var writer = new System.IO.Pipelines.PipeWriter(stream);
writer.Write("Hello World"u8);
writer.FlushAsync();

五、方法內聯與 `AggressiveInlining`、`sealed` 消除虛擬呼叫

5.1 JIT 內聯啟發式條件

方法體 IL 大小 ≤ 32 bytes（可透過 MethodImplOptions.AggressiveInlining 放寬）。
無複雜控制流（try/catch、lock、虛擬呼叫、await 等）。
非遞迴、非透過委派/介面呼叫。

5.2 手動內聯標記


[MethodImpl(MethodImplOptions.AggressiveInlining)]
public static int Add(int a, int b) => a + b;

// 熱路徑小型方法建議標記
[MethodImpl(MethodImplOptions.AggressiveInlining)]
public static bool IsValid(this T? obj) where T : class => obj != null;

5.3 `sealed` 類別/方法消除虛擬調度


public sealed class LeafService : IService { // 類別 sealed → 所有虛擬方法隱含 sealed
    public void Execute() { } // 非虛擬，直接呼叫
}

public class Base {
    public virtual void Compute() { }
}
public sealed class Derived : Base {
    public sealed override void Compute() { } // 封鎖進一步覆寫，JIT 可內聯
}

六、現代高效能 API 工具箱

API	用途	關鍵優勢
`Span<T>` / `Memory<T>`	記憶體切片、零複製子範圍	避免陣列複製、支援堆疊/非受控/托管記憶體統一存取
`ArrayPool<T>`.Shared	陣列重用池	減少 Gen 0/1 GC 壓力、避免大型陣列進入 LOH
`ValueTask<T>`	同步完成路徑無配置	避免 `Task<T>` 物件配置、支援 `IValueTaskSource`
`MemoryMarshal`	記憶體進階操作	`CreateSpan`、`AsBytes`、`Cast` 零複製型別重新解讀
`System.Buffers.Binary.BinaryPrimitives`	端序無關二進位讀寫	無位移/遮罩手寫、JIT 內聯單指令
`string.Create` / 插值處理器	直接寫入字串緩衝區	單次配置、無中間 `StringBuilder`
`Utf8String` (C# 11+)	UTF-8 原生字串	避免編碼轉換、互操作/網路/日誌直通

七、基準測試驗證優化成果


// BenchmarkDotNet 範例
[MemoryDiagnoser]
[SimpleJob(RuntimeMoniker.Net80)]
public class StringBenchmarks
{
    [Benchmark(Baseline = true)]
    public string ConcatLoop() {
        string s = "";
        for (int i = 0; i < 100; i++) s += i;
        return s;
    }

    [Benchmark]
    public string StringBuilder() {
        var sb = new StringBuilder(400);
        for (int i = 0; i < 100; i++) sb.Append(i);
        return sb.ToString();
    }

    [Benchmark]
    public string StringCreate() => string.Create(400, 100, static (span, count) => {
        var h = new System.Text.StringBuilderInterpolatedStringHandler(0, 0, null, span);
        for (int i = 0; i < count; i++) h.AppendFormatted(i);
    });
}

典型結果：StringCreate 比 ConcatLoop 快 50–100 倍、配置量降低 99%。

八、效能分析工具鏈

BenchmarkDotNet：微基準測試黃金標準。
PerfView / dotnet-trace / dotnet-counters：GC 統計、CPU 取樣、事件追蹤 (ETW/LTTng)。
Visual Studio Profiler：CPU 使用率、記憶體分析、非同步呼叫鏈。
dotnet-gcdump：堆疊快照分析物件保留鏈。
disasmo / JIT Dump：檢視 JIT 產生的組合語言、內聯決策。

結語

效能優化不是早期優化，而是「架構層級選對資料結構與 API，熱路徑微調」。優先消除終結化、最小化轉換、善用實值型別避免裝箱、字串操作採 StringBuilder/string.Create、熱路徑標記 AggressiveInlining、密封類別/方法消除虛擬呼叫、大量配置改用 ArrayPool/Span、非同步熱路徑用 ValueTask。配合 BenchmarkDotNet 持續驗證，方能在 .NET 平台上榨乾硬體效能。