.NET 應用程式記憶體優化實戰：從避免臨時物件到 P/Invoke 混合編程

案例背景

開發「鍵盤精靈」類功能：載入 20 萬筆文字資料（~10MB）至記憶體，依使用者輸入快速檢索最符合的 10 筆。初期載入 6 萬筆測試資料即佔用 70-80MB，目標大幅降低記憶體佔用。

階段一：避免建立不必要的物件

原始流程

1. 讀檔實例化物件集合
2. 條件篩選 → 產生中間結果集 1（如 4 萬筆）
3. 計算匹配度 → 產生結果集 2（KeyValuePair）
4. 排序 → 取前 10 筆

問題：大量臨時集合與物件造成 GC 壓力、記憶體暴增。

優化後流程

1. 讀檔實例化
2. 單次遍歷：符合條件 → 計算匹配度 → 存入 容量固定 11 的 SortedList
3. 插入後若超過 10 筆，移除最後一筆（匹配度最低）
4. 遍歷結束直接回傳此集合

效果：記憶體從 70-80MB 降至 30-40MB（降 50%+）。核心原則：**只保留最終需要的資料結構，中間過程零分配**。

階段二：優化資料型別與演算法

• 精簡欄位：僅保留搜尋需要的 4 欄位（代碼、名稱、拼音、市場），捨棄其它欄位。
• 資料結構選擇：string[] 優於自訂類別/結構（避免物件頭部開銷、參數傳遞複製）。
• 分塊索引：依首字元（0-9, a-z）分桶，縮小掃描範圍。
• 不完全搜尋 + 預排序：資料預先按類型、代碼排序；依優先級順序查找，集滿 10 筆即返回，利用有序性保證後續結果不更優。

階段三：引入非托管代碼（C++ DLL + P/Invoke）

動機

.NET 執行時期（CLR、GC、物件頭）有固定記憶體開銷。同樣 10MB 文字資料：

• .NET string 載入佔 20-30MB
• C++ std::string/vector 僅佔 9-10MB，且幾無波動

實作架構

• C++ Win32 DLL (SecuData)：4 個匯出函式 InitData、SetPriority、Search、UnloadData，核心邏輯以 STL 實現。
• C# WinForms (SecuDataTest)：DllImport 引入函式，StringBuilder 接收查詢結果字串。

關鍵細節

• StringBuilder 必須預先配置足夠容量（new StringBuilder(maxSize)），否則 C++ 寫入會拋異常。
• 偵錯：C++ 專案設定「啟動外部程式」指向 C# 執行檔，輸出目錄同步，即可混合偵錯。
• 發布：C++ 專案屬性 → 執行階段程式庫 → 多執行緒 (/MT)，靜態連結 CRT，避免客戶機缺少 VC++ 執行階段。
• 

成果

資料載入記憶體穩定在 10MB 左右，滿足嚴格記憶體限制。

總結：.NET 記憶體優化四層次

結語

.NET 開發便利性來自 GC，但也容易讓開發者忽視記憶體成本。結合良好習慣、高效演算法、必要時混合非托管代碼，可在保留 .NET 生產力的同時，達到接近原生的記憶體效能。