.NET 伺服器開發疑難雜症：高併發下的記憶體洩漏與效能優化

經過長期迭代，伺服器版本從 1.0 升級至 3.6，架構從「一客戶端一執行緒」演進為異步處理網路，但實戰經驗仍嫌不足，特向社群專家請教優化方向。

系統架構概覽

客戶端分為 PC 端與車載終端，Session 層需分別維護兩端狀態。網路部分設計如下：

啟動 HandleCar 與 HandleUser 的 StartListen 執行緒分別接收終端與客戶端資料。終端每 10 秒發送一包資料，處理流程：

在 AnylizeGpsData 中，需查詢資料庫該終端所屬路線的所有線上用戶（透過 Session 中的 Socket），轉發資料並存庫。目前做法是「來一包就查一次線上用戶」，疑似效能瓶頸。

當前遇到的三大問題

1. 記憶體持續增長：220 個終端連接，運行 1-2 天記憶體破 1GB，且隨時間遞增
2. UI 凍結：基類事件通知 UI 上下線訊息，執行幾分鐘後 UI 停響（執行緒安全已處理）
3. SQL Server 記憶體暴漲：同樣 1-2 天達 1GB+，隨時間增長

疑似原因分析與優化方向

1. 資料庫查詢頻率過高

每包資料都查詢資料庫獲取線上用戶列表，嚴重拖垮資料庫效能。建議：在記憶體中維護「路線 → 線上用戶 Session」的索引結構，避免頻繁查庫。

2. 反射建立物件的開銷

終端連接時使用反射創建物件，高併發下會增加 GC 壓力。建議：改用物件池或工廠模式預先暖機，減少反射調用。

3. 目標：支援 2000 終端併發

架構改進方向：

• 採用 SocketAsyncEventArgs + 物件池模式（參考 .NET 3.5 增強 API）
• 引入訊息佇列解耦接收與處理邏輯
• Session 狀態改用 ConcurrentDictionary 或 Redis 等分散式快取
• 資料庫寫入採用批次非同步寫入，減少連線池壓力

4. 記憶體洩漏排查

• 使用 Windbg + SOS 擴充套件分析 Managed Heap
• 檢查事件處理器是否正確解除訂閱（-=）
• 確認 IDisposable 物件（Socket、DbConnection 等）正確釋放
• 啟用 GC 記憶體壓力監控（GC.GetTotalMemory）

期待社群大神具體指導，後續將分享優化成果。