.NET 開發者常見 4 大致命錯誤：連線洩漏、物件未釋放、Debug 發布、連線池耗盡

前言

開發環境測試通過，上線卻頻傳 Timeout、記憶體暴漲、CPU 100%、回應緩慢。這四大「隱形殺手」在新手與資深開發者身上反覆上演，本文逐一拆解根因與修正模式。

一、資料庫連線未關閉 → 連線池耗盡 → Timeout

錯誤代碼

Public Shared Function GetData() As DataTable
    Dim conn As New SqlConnection(connStr)
    conn.Open()  ' 開啟
    Dim cmd As New SqlCommand(sql, conn)
    Dim dt As New DataTable()
    dt.Load(cmd.ExecuteReader())
    Return dt      ' 忘記 conn.Close() / Dispose()
End Function

後果

• ADO.NET 連線池預設上限 100 條。
• 每次呼叫佔用一條，未釋放 → 池滿 → 新請求等待 15 秒 (預設) → Timeout expired。
• 開發機單用戶測試感覺不到，生產環境併發即暴雷。

正確模式：using 區塊 / try-finally

// C# 推薦
using (var conn = new SqlConnection(connStr))
using (var cmd = new SqlCommand(sql, conn))
{
    conn.Open();
    using (var reader = cmd.ExecuteReader())
    {
        var dt = new DataTable();
        dt.Load(reader);
        return dt;
    }
} // 自動 Dispose → 關閉連線、歸還池

// VB.NET
Using conn As New SqlConnection(connStr)
    Using cmd As New SqlCommand(sql, conn)
        conn.Open()
        Using reader = cmd.ExecuteReader()
            Dim dt As New DataTable()
            dt.Load(reader)
            Return dt
        End Using
    End Using
End Using

二、建立物件只管用、不釋放 → 記憶體洩漏 / GC 壓力

高危物件

DataTable、DataSet、DataReader、DataAdapter、SqlConnection、FileStream、GDI+ 物件、COM 物件 等實作 IDisposable 的類別。

錯誤模式

Dim dt As New DataTable() ' 迴圈內重複 new，舊物件成 Gen 2 垃圾
For Each row In rows
    dt = GetDataTable()   ' 未 Dispose
    Process(dt)
Next

正確模式

// 迴圈外建立、迴圈內重用、最後 Dispose
var dt = new DataTable();
try {
    foreach (var row in rows) {
        dt.Clear();
        FillDataTable(dt, row);
        Process(dt);
    }
} finally {
    dt.Dispose();
}

// 或每次 using (較簡潔，效能略低)
foreach (var row in rows) {
    using (var dt = new DataTable()) {
        FillDataTable(dt, row);
        Process(dt);
    }
}

關鍵原則

1. 實作 IDisposable → 必須 Dispose() 或 using。
2. Dispose() 放在 finally 區塊，異常時也能釋放。
3. 避免在迴圈中重複 new 大型物件；改用 Clear() 重用。
4. For Each 比 for i=0 to Count-1 效率更高（避免索引器多次呼叫）。

三、Debug 模式編譯直接部署生產環境 → 記憶體暴漲、效能劣化

現象

• Web.config：<compilation debug="true">
• Visual Studio 建置配置：Debug 而非 Release。

微軟官方說明

Debug 模式：
- 不優化 JIT 碼、保留完整 PDB 符號、啟用編輯繼續。
- 批次編譯關閉 → 每個頁面獨立組件 → 組件數暴增。
- 腳本/資源不快取、ViewState 不加密壓縮。
- 記憶體佔用可達 Release 模式 3-5 倍。

生產環境必檢清單

Configuration: Release
Platform: Any CPU / x64

真實案例

刀片伺服器 32GB RAM，部署 Debug 版本 → 2 天記憶體飆至 2.5GB → IIS 回收才緩解。改 Release + debug=false → 穩定在 1.2GB。

四、實戰經驗分享：連線池調優與記憶體上限

案例 1：後台 Job 記憶體洩漏

• 服務運行 2-3 天無回應，記憶體 2.5GB → 關閉 Job 降至 1.5GB。
• 原因：大量 DataTable/DataSet 未釋放、大物件堆積 (LOH) 碎片化。
• 修正：全面 using、定期 GC.Collect()（僅限長時間運行服務）、改用 SqlDataReader 流式處理。

案例 2：CPU 100% 因請求風暴

• 產線回報緩慢，CPU 100%，回收 AppPool 即恢復。
• 微軟支援分析：無單一執行緒高 CPU，但 DB 請求併發極高（附件多、刷新快），總和拖垮 CPU。
• 發現大量 DLL 為 Debug Build 佔用額外記憶體。
• 修正：
  1. 全部改 Release Build。
  2. AppPool 設定：Private Memory Limit = 1.5GB、Queue Length = 5000、Idle Timeout = 0。
  3. 啟用 Web Garden (多 Worker Process) 分散載入。
  4. 資料庫端優化索引、加快查詢。

AppPool 記憶體上限知識

• 32 位元進程：2GB 使用者模式虛擬位址空間，實際 1.5GB 即易發生 OOM（記憶體碎片）。
• 64 位元進程：理論無上限，建議設定 Private Memory Limit 防止佔盡實體 RAM。
• 每個 AppPool = 獨立 w3wp.exe = 獨立記憶體空間。

總結檢查表

結語

這四大錯誤本質上都是「資源管理不當」與「環境配置疏忽」。養成 using 肌肉記憶、上線前跑一次 Release Build 檢查清單、建立 APM 監控基準線，即能消除 90% 的上線驚魂。工程品質，始於細節。