Memory Management (III) - .NET CLR ? — 安德魯的部落格

Case #1: 用管理式語言移除指標以解決不可搬移的記憶體配置

Problem Statement（問題陳述）

業務場景：現有系統以 C 撰寫，廣泛使用指標與直接位址操作。應用程式長時間運作後需要配置更大的連續記憶體區塊（如匯入大檔、建構大型快取），卻在總可用記憶體尚高時仍丟出記憶體不足。開發團隊希望在不重啟系統的情況下，穩定取得大區塊記憶體以完成批次任務與關鍵報表。 技術挑戰：指標語言無法安全自動搬移物件，導致記憶體碎片化無法由執行期緊縮整理。 影響範圍：批次作業失敗、服務重啟、資料處理延遲，並造成可用硬體資源浪費。 複雜度評級：高

Root Cause Analysis（根因分析）

直接原因：

使用指標可取得物件實際位址，任何搬移都會破壞程式邏輯。
記憶體配置與釋放模式交錯，產生大量不連續自由區塊。
運行期間需要配置比單一自由區塊更大的連續區塊，造成 OOM。

深層原因：

架構層面：核心模組高度依賴位址穩定性，無抽象層隔離。
技術層面：選用指標導向語言，使自動緊縮（compaction）在技術上不可行。
流程層面：缺乏對長時間運行與大塊配置的記憶體壓力測試。

Solution Design（解決方案設計）

解決策略：以 .NET/C#（或 Java）等管理式語言取代指標操作，採用 reference 取代 pointer，使執行期得以在 GC 時進行搬移與緊縮（compact collection），系統層級根除碎片無法整理的限制。

實施步驟：

語言與平台遷移評估
- 實作細節：盤點使用指標的模組與位址相依性，規劃等價 reference 模式。
- 所需資源：架構師、資深開發、現有測試案例。
- 預估時間：2-4 週
核心資料結構重寫
- 實作細節：將指標改為陣列、集合、Span/Memory（視版本），避免暴露位址。
- 所需資源：C#/.NET 開發環境
- 預估時間：4-8 週
壓力測試與 GC 模式驗證
- 實作細節：用大區塊配置/釋放模式驗證 GC 緊縮效用（含 server GC）。
- 所需資源：壓測機、監控
- 預估時間：1-2 週

關鍵程式碼/設定：

// 以 reference 取代 pointer，允許 CLR 搬移物件
var buffers = new List<byte[]>();
buffers.Add(new byte[64 * 1024 * 1024]); // 僅能以 reference 存取，無法取得固定位址

實際案例：文章示範以 C# 改寫測試，利用 reference 取代 pointer，讓 CLR 有機會在 GC 進行 compaction。實作環境：.NET 2.0（x86），Windows Vista x86 實測數據：改善前：指標語言無法 relocation，碎片問題長期存在（需求大塊配置常失敗）改善後：啟用 server GC 後，釋放 576MB 可回收 648MB 連續空間改善幅度：可用連續空間提升為釋放量的約 112.5%

Learning Points（學習要點）核心知識點：

指標與 reference 的本質差異與對 GC 的影響
為什麼 relocation 需要移除指標暴露
compact collection 在碎片問題中的關鍵角色

技能要求：

必備技能：C# 基礎、.NET 記憶體模型
進階技能：GC 模式選擇、壓力測試設計

延伸思考：

還能應用在需要長時運行與大物件配置服務
風險：遷移成本高，性能行為變動
優化：搭配 server GC、配置策略與物件池化

Practice Exercise（練習題）

基礎練習：以 C# 將一段含指標語意的資料結構改寫為 reference 型，驗證功能等價
進階練習：設計壓測重現交錯配置/釋放，觀察不同 GC 模式的碎片差異
專案練習：將某模組由 C 遷移到 C#，並提供性能與穩定性報告

Assessment Criteria（評估標準）

功能完整性（40%）：功能等價、通過既有測試
程式碼品質（30%）：無指標相依、結構清晰
效能優化（20%）：在壓測下具可預期的記憶體行為
創新性（10%）：提出可觀測性與測量方法

Case #2: .NET 預設 GC 無法回收足夠連續空間導致 OOM

Problem Statement（問題陳述）

業務場景：在 .NET 2.0 x86 上，服務啟動後會大量配置中大型緩衝區（64MB），工作結束後釋放部分緩衝。隨後需要配置更大的緩衝（72MB）以進行下一階段處理。雖然總可用記憶體不少，但新配置仍頻繁失敗。 技術挑戰：釋放後的空間未被整理成連續區塊，導致大塊配置失敗。 影響範圍：工作排程延遲、頻繁 OOM、服務可用性下降。 複雜度評級：中

Root Cause Analysis（根因分析）

直接原因：

預設 GC（workstation）未進行足夠的 compact collection。
釋放模式交錯（留偶數釋奇數），製造嚴重碎片。
大於現有最大連續孔洞的配置請求失敗。

深層原因：

架構層面：緩衝配置策略未考慮碎片化風險。
技術層面：GC 模式選擇與實際需求不符。
流程層面：缺少針對大塊連續配置的壓測與監測。

Solution Design（解決方案設計）

解決策略：建立再現性測試驗證問題，調整 GC 模式（後續切換至 server GC）以啟用 compact 行為，確保大塊配置成功率。

實施步驟：

建置重現測試
- 實作細節：交錯配置 64MB，釋放一半，再配置 72MB 至 OOM。
- 所需資源：文章提供的 Program.cs 測試碼
- 預估時間：0.5 天
底線驗證（預設 GC）
- 實作細節：不改任何 GC 設定執行，紀錄可回收連續空間。
- 所需資源：同上
- 預估時間：0.5 天

關鍵程式碼/設定：

// 1) 連續配置 64MB 區塊至 OOM
buffer1.Add(new byte[64 * 1024 * 1024]);
buffer2.Add(new byte[64 * 1024 * 1024]);

// 2) 釋放一半（製造碎片）
buffer2.Clear();

// 3) 嘗試配置 72MB 連續區塊
buffer3.Add(new byte[72 * 1024 * 1024]);

實際案例：依文章測試，在預設 GC 下「FAIL」，放掉的空間幾乎拿不回來。實作環境：.NET 2.0（x86），Windows Vista x86 實測數據：改善前：釋放大量空間後，72MB 幾乎配置失敗（圖示為 FAIL）改善後：尚未改 GC 模式前無改善改善幅度：0

Learning Points（學習要點）核心知識點：

連續空間需求與碎片的關係
預設 GC 下大塊配置的風險
測試可再現性的重要性

技能要求：

必備技能：C#、例外處理、壓測腳本
進階技能：問題最小化重現、效能監控

延伸思考：

還能應用於任一需要大塊配置的服務
限制：預設 GC 不保證緊縮
優化：切換至 server GC 或調整配置策略

Practice Exercise（練習題）

基礎練習：重現預設 GC 下的 FAIL
進階練習：變更區塊大小與釋放策略觀察差異
專案練習：寫出自動化測試報告，含多組參數

Assessment Criteria（評估標準）

功能完整性（40%）：能穩定重現
程式碼品質（30%）：可讀、可參數化
效能優化（20%）：清楚呈現瓶頸
創新性（10%）：具可視化或報表

Case #3: 強制完整 GC.Collect 仍無法有效緊縮碎片

Problem Statement（問題陳述）

業務場景：在預設 GC 下發生大塊配置失敗，嘗試在釋放引用後立即呼叫 GC.Collect(GC.MaxGeneration) 強制回收，希望回收並整理空間以支援下一步的大塊配置。 技術挑戰：即使已釋放引用並觸發完整回收，連續空間仍不足。 影響範圍：自動回收策略失效，無法用 API 直接解決碎片。 複雜度評級：中

Root Cause Analysis（根因分析）

直接原因：

GC.Collect 觸發回收，但未保證做 compact collection。
回收後產生的空洞仍不連續，不足支援 72MB 配置。
測試證實「回收」≠「緊縮」。

深層原因：

架構層面：期望用 API 修復架構性碎片問題。
技術層面：誤把 generation 調整當作碎片解法。
流程層面：缺少對 GC 模式差異的實測與知識。

Solution Design（解決方案設計）

解決策略：保留強制回收作為輔助，但根本解法需切換 GC 模式以啟用緊縮（後續採 server GC）。

實施步驟：

在釋放引用後呼叫完整回收
- 實作細節：GC.Collect(GC.MaxGeneration) + 可能的 GC.WaitForPendingFinalizers()
- 所需資源：測試程式
- 預估時間：0.5 天
驗證成效與記錄
- 實作細節：比對可配置 72MB 區塊的數量/總量
- 所需資源：主控台輸出
- 預估時間：0.5 天

關鍵程式碼/設定：

// 釋放引用後嘗試完整回收
buffer2.Clear();
GC.Collect(GC.MaxGeneration);
// 可選：GC.WaitForPendingFinalizers(); // 確保待處理完成

實際案例：文章測試「結果好不到那裡去」，僅回收極少連續空間。實作環境：.NET 2.0（x86）實測數據：改善前：FAIL，幾乎無法配置 72MB 改善後：僅能配置約 72MB（單一區塊）改善幅度：從 0 增至約 72MB（相對整體需求仍不足）

Learning Points（學習要點）核心知識點：

垃圾回收與緊縮是兩回事
generation 調整不等於碎片解決
API 能力邊界

技能要求：

必備技能：GC API 使用
進階技能：回收/緊縮行為觀察與實測

延伸思考：

場景：高碎片下單靠 Collect 意義有限
風險：過度使用 Collect 影響效能
優化：改用 server GC 或改變配置節奏

Practice Exercise（練習題）

基礎練習：加入 GC.WaitForPendingFinalizers() 比對成效
進階練習：在不同釋放比例下測 Collect 成效
專案練習：產出結論報告，說明 Collect 的限制

Assessment Criteria（評估標準）

功能完整性（40%）：實驗設計正確
程式碼品質（30%）：記錄充分、可重現
效能優化（20%）：避免不必要 Collect
創新性（10%）：提出改進假設

Case #4: 關閉 Concurrent GC 仍無助於解決碎片

Problem Statement（問題陳述）

業務場景：懷疑 Concurrent GC 造成回收與配置節奏不一致，導致回收未完成即嘗試大塊配置，於是關閉 gcConcurrent 觀察是否能改善可用連續空間。 技術挑戰：關閉並未改善大塊配置失敗。 影響範圍：調整錯誤方向，浪費調校時間。 複雜度評級：低

Root Cause Analysis（根因分析）

直接原因：

Concurrent 僅影響回收是否併行，不保證緊縮策略改變。
碎片本質仍在，未進行 compact collection。
測試證實關閉併行 ≠ 增加連續空間。

深層原因：

架構層面：將時序問題誤判為策略問題。
技術層面：誤解 gcConcurrent 影響範圍。
流程層面：未先用對照組驗證假設。

Solution Design（解決方案設計）

解決策略：恢復預設或視情況保留，但認知其與碎片無直接關聯；真正解法仍是切換 GC 模式以啟用緊縮。

實施步驟：

關閉 gcConcurrent 並重跑測試
- 實作細節：設定
- 所需資源：app.config
- 預估時間：0.5 天
比對與回滾
- 實作細節：若無改善，撤回設定以免影響延遲
- 所需資源：同上
- 預估時間：0.5 天

關鍵程式碼/設定：

<configuration>
  <runtime>
    <gcConcurrent enabled="false" />
  </runtime>
</configuration>

實際案例：文章結論「一點幫助都沒有」，放掉的 768MB，只撈回 72MB。實作環境：.NET 2.0（x86）實測數據：改善前：釋放 768MB，回收 72MB 改善後：釋放 768MB，回收仍約 72MB 改善幅度：0

Learning Points（學習要點）核心知識點：

併行回收與緊縮策略無直接關係
假設驗證與對照實驗的重要性
GC 設定影響面向辨識

技能要求：

必備技能：app.config 操作
進階技能：實驗設計與資料比對

延伸思考：

場景：延遲敏感 vs 吞吐優先的併行取捨
風險：盲調參數影響效能
優化：聚焦正確的策略（server GC）

Practice Exercise（練習題）

基礎練習：在你環境關閉/開啟 gcConcurrent 比對配置成功次數
進階練習：加入時間戳記分析回收時序
專案練習：寫出調校備忘錄，明確界定 gcConcurrent 適用情境

Assessment Criteria（評估標準）

功能完整性（40%）：設定正確生效
程式碼品質（30%）：紀錄齊全
效能優化（20%）：避免誤用導致退化
創新性（10%）：對照分析方法

Case #5: 啟用 Server GC 觸發緊縮，大幅提升可用連續空間

Problem Statement（問題陳述）

業務場景：在預設 GC 與各種微調無效後，嘗試啟用 gcServer，期望獲得不同的回收與緊縮行為，讓大塊配置恢復成功。 技術挑戰：需驗證 server GC 是否實際執行 compact collection 並量化成效。 影響範圍：直接關係到服務能否避免 OOM 與保持吞吐。 複雜度評級：中

Root Cause Analysis（根因分析）

直接原因：

workststion GC 未有效緊縮，server GC 改變策略。
啟用 server GC 後，GC 進行 compact collection。
連續空間顯著增加，可支援後續 72MB 配置。

深層原因：

架構層面：配置策略需要與 GC 模式匹配。
技術層面：server GC 具備不同的回收壓縮行為。
流程層面：最終用實測驗證文檔曖昧之處。

Solution Design（解決方案設計）

解決策略：在 app.config 啟用，保留或視情況搭配 gcConcurrent 預設，重新執行壓測驗證。

實施步驟：

啟用 server GC
- 實作細節：app.config 設定 gcServer
- 所需資源：部署權限
- 預估時間：0.5 天
重跑測試並量化結果
- 實作細節：記錄釋放量、可配置 72MB 總量
- 所需資源：同上
- 預估時間：0.5 天

關鍵程式碼/設定：

<configuration>
  <runtime>
    <gcServer enabled="true" />
  </runtime>
</configuration>

實際案例：文章測得「放掉了 576MB，後面撈了 648MB 回來」，證實緊縮有效。實作環境：.NET 2.0（x86）實測數據：改善前：釋放 768MB，僅回收約 72MB 可用連續空間改善後：釋放 576MB，回收約 648MB 可用連續空間改善幅度：可用連續空間從 ~9% 提升到 >100%（相對釋放量）

Learning Points（學習要點）核心知識點：

server vs workstation GC 差異
compact collection 對碎片的效果
以實測驗證 GC 行為

技能要求：

必備技能：配置管理、壓測
進階技能：GC 行為解讀與決策

延伸思考：

應用：長時運行、記憶體壓力高的服務
風險：不同硬體/工作負載下的性能差異
優化：觀察延遲、吞吐再微調

Practice Exercise（練習題）

基礎練習：啟用 gcServer 後重跑案例程式
進階練習：對比不同機器核心數與結果
專案練習：撰寫切換 GC 模式的 SOP 與風險評估

Assessment Criteria（評估標準）

功能完整性（40%）：配置正確生效並改善
程式碼品質（30%）：測試紀錄與腳本
效能優化（20%）：量化吞吐/延遲
創新性（10%）：觀測指標設計

Case #6: 以 app.config 管控 GC 模式的部署化解決方案

Problem Statement（問題陳述）

業務場景：需在不改程式碼的情況下，快速切換 GC 行為以應對不同環境（開發、壓測、正式）對記憶體的需求，並可回滾。 技術挑戰：確保配置生效、可追蹤、可自動化。 影響範圍：部署效率、風險控管、回溯能力。 複雜度評級：低

Root Cause Analysis（根因分析）

直接原因：

程式碼層僅以 Collect 控制，無法觸及緊縮策略。
需要以 runtime 設定切換 server/workstation。
缺少配置管理與驗證流程。

深層原因：

架構層面：將環境特性外部化
技術層面：利用 CLR 設定開關控制 GC
流程層面：引入變更管理與回滾

Solution Design（解決方案設計）

解決策略：標準化 app.config GC 開關，納入部署流程；提供一鍵切換與驗證清單。

實施步驟：

設定範本化
- 實作細節：建立含 gcServer/gcConcurrent 的設定範本
- 所需資源：版本控管
- 預估時間：0.5 天
自動驗證
- 實作細節：啟動時輸出 GC 模式、寫入日誌
- 所需資源：輔助程式碼或啟動腳本
- 預估時間：1 天

關鍵程式碼/設定：

<configuration>
  <runtime>
    <!-- 開發/測試選擇性調整 -->
    <!--<gcConcurrent enabled="false" />-->
    <gcServer enabled="true" />
  </runtime>
</configuration>

實際案例：文章以啟用 gcServer 取得緊縮效果。實作環境：.NET 2.0（x86）實測數據：改善前：手動調整、難以追蹤改善後：設定外部化，效果可重現（648MB 回收案例）改善幅度：部署效率與一致性顯著提升

Learning Points（學習要點）核心知識點：

CLR runtime 設定的力量
配置外部化與環境差異管理
自動驗證的重要性

技能要求：

必備技能：XML 配置、部署
進階技能：DevOps 流程整合

延伸思考：

可應用於多環境多版本共存
風險：設定漂移
優化：CI/CD 驗證步驟

Practice Exercise（練習題）

基礎練習：建立兩份 config 並切換
進階練習：啟動時輸出當前 GC 模式
專案練習：將 GC 配置切換納入部署腳本

Assessment Criteria（評估標準）

功能完整性（40%）：設定切換可用
程式碼品質（30%）：有日誌與守護
效能優化（20%）：降低人為失誤
創新性（10%）：自動化程度

Case #7: 建立可再現的記憶體碎片壓測腳本

Problem Statement（問題陳述）

業務場景：團隊無法穩定重現「可用記憶體高但大塊配置失敗」的問題，導致修復方向分歧與溝通成本升高。 技術挑戰：需要簡潔可移植的壓測腳本，能穩定製造碎片並量化不同設定成效。 影響範圍：問題長期無解，浪費人力與時間。 複雜度評級：低

Root Cause Analysis（根因分析）

直接原因：

缺乏標準重現步驟與程式。
無法量化不同調整的差異。
修復與驗證脫節。

深層原因：

架構層面：缺少壓測與可觀測性設計
技術層面：測試資料與手法不一致
流程層面：缺乏實驗紀律

Solution Design（解決方案設計）

解決策略：採用文章 Program.cs 作為標準壓測腳本，固定流程：大量配置→交錯釋放→嘗試大塊配置，並記錄輸出。

實施步驟：

取得並參數化腳本
- 實作細節：將 64MB/72MB 作為可配置參數
- 所需資源：.NET SDK
- 預估時間：0.5 天
自動化執行與報表
- 實作細節：收集輸出與環境資訊形成比較報表
- 所需資源：簡易批次/PowerShell
- 預估時間：1 天

關鍵程式碼/設定：

// 將區塊大小改為參數
int blockA = int.Parse(args[0]); // e.g., 64
int blockB = int.Parse(args[1]); // e.g., 72
buffer1.Add(new byte[blockA * 1024 * 1024]);
buffer3.Add(new byte[blockB * 1024 * 1024]);

實際案例：文章以此腳本在多種設定下得到明確差異（FAIL、72MB、648MB）。實作環境：.NET 2.0（x86）實測數據：改善前：不可重現、不可比改善後：可用同一腳本比較不同 GC 模式的結果改善幅度：溝通效率與決策品質顯著提升

Learning Points（學習要點）核心知識點：

壓測可重現性原則
以最小案例定位核心問題
參數化測試的價值

技能要求：

必備技能：C#、命令列參數
進階技能：自動化報表

延伸思考：

可應用於其他記憶體議題
風險：測試與實務負載差異
優化：引入多場景模擬

Practice Exercise（練習題）

基礎練習：將程式參數化並重跑
進階練習：生成 CSV 報表對比模式
專案練習：納入夜間自動壓測

Assessment Criteria（評估標準）

功能完整性（40%）：腳本穩定重現
程式碼品質（30%）：可參數化且易讀
效能優化（20%）：執行效率與可靠性
創新性（10%）：報表與可視化

Case #8: 釋放引用後為何仍未即時回收？GC 時機與誤解剖析

Problem Statement（問題陳述）

業務場景：團隊在 Clear() 移除引用後立即嘗試大塊配置，但仍失敗。誤以為程式碼未正確釋放或有隱藏引用。 技術挑戰：理解「移除引用」到「記憶體回收」之間的非即時關係。 影響範圍：排查方向錯誤、浪費時間。 複雜度評級：低

Root Cause Analysis（根因分析）

直接原因：

GC 非即時，需等待回收週期或手動觸發。
即使回收，未必緊縮成連續空間。
誤將 Clear() 等同於可立即配置大塊。

深層原因：

架構層面：流程假設 GC 即時
技術層面：忽略 GC 策略差異
流程層面：缺少回收與配置之間的緩衝/同步

Solution Design（解決方案設計）

解決策略：在釋放引用後，視需求手動觸發 GC 並等待；若仍需大塊連續空間，切換 server GC。

實施步驟：

釋放→回收→配置的節奏
- 實作細節：Clear() 後 GC.Collect + WaitForPendingFinalizers()
- 所需資源：程式碼修改權限
- 預估時間：0.5 天
若仍失敗，調整 GC 模式
- 實作細節：啟用 server GC
- 所需資源：app.config
- 預估時間：0.5 天

關鍵程式碼/設定：

buffer2.Clear(); // 釋放引用
GC.Collect(GC.MaxGeneration);
// 若有需要：GC.WaitForPendingFinalizers();

實際案例：文章先後驗證 Clear() 後手動 Collect 改善有限，必須搭配 server GC。實作環境：.NET 2.0（x86）實測數據：改善前：釋放後仍 OOM 改善後：手動 Collect 僅得 72MB；啟用 server GC 可得 648MB 改善幅度：由幾乎無改善到顯著改善

Learning Points（學習要點）核心知識點：

釋放引用 ≠ 立即回收
回收 ≠ 緊縮
模式選擇的重要性

技能要求：

必備技能：GC API、例外處理
進階技能：回收時機設計

延伸思考：

場景：需要即時大塊配置的工作節點
風險：頻繁 Collect 的性能成本
優化：預留緩衝與批次化配置

Practice Exercise（練習題）

基礎練習：加入 WaitForPendingFinalizers 比對
進階練習：量測 Collect 耗時與收益
專案練習：設計釋放-回收-配置流程與監控

Assessment Criteria（評估標準）

功能完整性（40%）：流程可運作
程式碼品質（30%）：錯誤處理完善
效能優化（20%）：平衡耗時與收益
創新性（10%）：提出節奏優化

Case #9: 大塊連續配置需求的風險辨識與設計調整

Problem Statement（問題陳述）

業務場景：部分任務（如影像處理、資料壓縮）在特定步驟需要單一 72MB 以上連續緩衝。運行一段時間後，雖總可用記憶體足夠，仍配不到連續大塊，導致任務失敗。 技術挑戰：在碎片存在時如何確保可獲得大塊連續區塊。 影響範圍：特定工作流中斷、吞吐下降。 複雜度評級：中

Root Cause Analysis（根因分析）

直接原因：

早期配置釋放模式導致碎片。
預設 GC 未緊縮。
任務對「連續性」而非「總量」敏感。

深層原因：

架構層面：未為大塊配置留出記憶體水位
技術層面：忽略 GC 模式差異
流程層面：無大塊配置前的準備動作

Solution Design（解決方案設計）

解決策略：任務前置步驟清理並（必要時）切換至 server GC；或重構為分段處理，降低對連續性的硬性需求。

實施步驟：

前置清理與回收
- 實作細節：釋放無用緩衝→Collect→嘗試配置
- 所需資源：程式碼調整
- 預估時間：1 天
模式切換與壓測
- 實作細節：gcServer 啟用與回滾策略
- 所需資源：app.config
- 預估時間：0.5 天

關鍵程式碼/設定：

<configuration>
  <runtime>
    <gcServer enabled="true" />
  </runtime>
</configuration>

實際案例：啟用 server GC 後，配置 72MB 變得可行（648MB）。實作環境：.NET 2.0（x86）實測數據：改善前：即便釋放大量記憶體，72MB 經常失敗改善後：可持續配置多個 72MB 區塊改善幅度：由 0/少數 → 大幅提升（至 648MB）

Learning Points（學習要點）核心知識點：

連續空間 vs 總空間
模式切換與工作流結合
分段處理的備援策略

技能要求：

必備技能：工作流設計
進階技能：記憶體水位控管

延伸思考：

可應用於突發大塊需求場景
風險：模式切換對其他模組影響
優化：預留容量與限流機制

Practice Exercise（練習題）

基礎練習：在任務開始前加入清理-回收
進階練習：分段處理替代大塊配置
專案練習：建置記憶體水位監管服務

Assessment Criteria（評估標準）

功能完整性（40%）：任務成功率提升
程式碼品質（30%）：模組化與可配置
效能優化（20%）：吞吐提升或穩定
創新性（10%）：備援策略設計

Case #10: 以 OutOfMemoryException 作為邊界條件的壓測設計

Problem Statement（問題陳述）

業務場景：需要一個簡單但「貼近真實故障」的終止條件，讓壓測自動逼近上限並量化不同設定的最大可配置量。 技術挑戰：如何自動、可重現地抵達極限且不致 crash 整個流程。 影響範圍：測試可靠度與結果可信度。 複雜度評級：低

Root Cause Analysis（根因分析）

直接原因：

缺少明確終止條件導致測試不一致。
無法量化最大可配置量。
測試在極限時可能中斷整個程序。

深層原因：

架構層面：壓測與例外處理未整合
技術層面：終止條件設計不足
流程層面：缺少標準操作流程

Solution Design（解決方案設計）

解決策略：以 try/catch 捕捉 OOM 作為自然邊界，計數已成功配置的區塊總量，確保測試不中斷並可記錄。

實施步驟：

例外處理包覆配置迴圈
- 實作細節：catch OutOfMemoryException，紀錄計數
- 所需資源：程式碼調整
- 預估時間：0.5 天
輸出報告
- 實作細節：列印總配置數與總 MB
- 所需資源：主控台輸出
- 預估時間：0.5 天

關鍵程式碼/設定：

try {
  while (true) buffer3.Add(new byte[72 * 1024 * 1024]);
} catch (OutOfMemoryException) {
  // 記錄結束狀態而不中斷測試流程
}

實際案例：文章以此法穩定量化不同設定的配置上限。實作環境：.NET 2.0（x86）實測數據：改善前：邊界不明、結果不可比改善後：可清楚記錄 72MB 配置總量（如提升至 648MB）改善幅度：測試信度與可比性大幅提升

Learning Points（學習要點）核心知識點：

故障導向的壓測方法
例外即控制流程的一部分
可觀測性設計

技能要求：

必備技能：例外處理
進階技能：測試報告與統計

延伸思考：

應用於其他資源極限測試
風險：誤用例外作流程控制
優化：加入時間與記憶體曲線

Practice Exercise（練習題）

基礎練習：加入計時與統計
進階練習：將結果輸出為 CSV
專案練習：整合到 CI 壓測管線

Assessment Criteria（評估標準）

功能完整性（40%）：邊界可捕捉
程式碼品質（30%）：錯誤處理恰當
效能優化（20%）：測試可長時間運行
創新性（10%）：報表與可視化

Case #11: 以 empirical（實證）方式驗證文件未明說的 GC 行為

Problem Statement（問題陳述）

業務場景：官方文件與搜尋結果對 server GC 是否進行 compact collection 說法含糊，無法作為決策依據。 技術挑戰：需要自證流程與可重現結果，支撐切換 GC 模式的決策。 影響範圍：技術決策風險與可信度。 複雜度評級：中

Root Cause Analysis（根因分析）

直接原因：

文檔未明示行為差異。
反編譯工具看不到 native 細節。
缺乏足夠的公開案例。

深層原因：

架構層面：決策過度依賴文檔
技術層面：忽略建立實證
流程層面：缺少技術裁判機制

Solution Design（解決方案設計）

解決策略：以標準壓測腳本在不同設定下實測，將「是否 compact」改以量化結果來佐證，而非僅引用文件。

實施步驟：

設計對照組
- 實作細節：預設 GC vs Collect vs gcConcurrent=false vs gcServer=true
- 所需資源：同上
- 預估時間：1 天
結果彙整
- 實作細節：將「可配置連續空間」作為指標
- 所需資源：報表工具
- 預估時間：0.5 天

關鍵程式碼/設定：

<!-- 依序測試四種模式，保留結果 -->
<gcServer enabled="true" />

實際案例：文章以實測證明啟用 gcServer 後能緊縮（648MB）。實作環境：.NET 2.0（x86）實測數據：改善前：僅有推測，無定論改善後：以數據顯示 server GC 顯著提升連續空間改善幅度：決策信心大幅提升

Learning Points（學習要點）核心知識點：

文件空白的實證補位
對照實驗與指標選擇
工程化決策流程

技能要求：

必備技能：實驗設計、數據彙整
進階技能：提出與驗證假設

延伸思考：

亦可用於其他 runtime 行為驗證
風險：過度外推
優化：跨平台、跨版本驗證

Practice Exercise（練習題）

基礎練習：複製四種設定與結果表
進階練習：新增平台或版本再驗證
專案練習：形成「技術裁判」手冊

Assessment Criteria（評估標準）

功能完整性（40%）：實驗齊備
程式碼品質（30%）：結果可追溯
效能優化（20%）：指標選擇合理
創新性（10%）：決策框架

Case #12: 工作站 GC 與伺服器 GC 的選型方法

Problem Statement（問題陳述）

業務場景：同一套程式需在開發機、桌面端與伺服器端運行。不同環境下對延遲、吞吐與記憶體行為需求差異大，需擬定選型原則。 技術挑戰：兼顧延遲與可用連續空間的目標。 影響範圍：產品體驗與運行穩定性。 複雜度評級：中

Root Cause Analysis（根因分析）

直接原因：

workstation 與 server GC 行為不同。
桌面端偏向互動延遲，伺服端偏向吞吐與空間管理。
未制定一致原則，容易誤配。

深層原因：

架構層面：部署場景多元
技術層面：GC 策略差異不明
流程層面：缺乏決策矩陣

Solution Design（解決方案設計）

解決策略：以需求導向制定原則：伺服器負載且需大塊連續空間者採 server GC；互動應用預設 workstation；並以壓測驗證。

實施步驟：

建立選型矩陣
- 實作細節：以需求（連續空間/吞吐/延遲）映射 GC 模式
- 所需資源：團隊共識
- 預估時間：1 天
驗證與回饋
- 實作細節：針對關鍵服務以文章腳本驗證
- 所需資源：壓測環境
- 預估時間：1-2 天

關鍵程式碼/設定：

<!-- 伺服器服務 -->
<gcServer enabled="true" />
<!-- 桌面應用（預設即可） -->

實際案例：文章顯示 server GC 能顯著提升連續空間（648MB）。實作環境：.NET 2.0（x86）實測數據：改善前：模式選擇混亂改善後：依場景選擇，提高成功率與穩定性改善幅度：配置成功率提升明顯

Learning Points（學習要點）核心知識點：

模式與場景匹配原則
以實測支持選型
風險與回滾設計

技能要求：

必備技能：需求分析
進階技能：A/B 測試

延伸思考：

多租戶環境下之取捨
風險：過度一刀切
優化：引入動態配置

Practice Exercise（練習題）

基礎練習：為三種場景提出建議模式
進階練習：以數據支持選型
專案練習：撰寫 GC 選型指引文件

Assessment Criteria（評估標準）

功能完整性（40%）：指引可落地
程式碼品質（30%）：驗證數據充分
效能優化（20%）：實際改善
創新性（10%）：決策工具化

Case #13: 以雙集合交錯配置/釋放模式穩定製造碎片

Problem Statement（問題陳述）

業務場景：需要一種可控方式在測試中製造嚴重碎片，便於觀察不同 GC 模式下的緊縮成效。 技術挑戰：如何簡單且可重現地製造「鋸齒狀」空洞分佈。 影響範圍：測試有效性與結論可靠度。 複雜度評級：低

Root Cause Analysis（根因分析）

直接原因：

單集合釋放不易形成交錯空洞。
雙集合交錯配置（buffer1、buffer2）再清空其中之一可穩定製造碎片。
有助於放大差異以觀察緊縮效果。

深層原因：

架構層面：測試設計需對抗隨機性
技術層面：控制樣型產生穩定碎片
流程層面：標準化測試步驟

Solution Design（解決方案設計）

解決策略：採用兩個 List 交錯加入大塊，然後清空其中一個，形成等間距空洞，利於觀測連續空間的回收狀態。

實施步驟：

交錯配置
- 實作細節：Add 到 buffer1、buffer2 交替
- 所需資源：測試碼
- 預估時間：0.5 天
單側釋放
- 實作細節：buffer2.Clear() 形成碎片
- 所需資源：同上
- 預估時間：0.5 天

關鍵程式碼/設定：

buffer1.Add(new byte[64 * 1024 * 1024]); Console.Write("#");
buffer2.Add(new byte[64 * 1024 * 1024]); Console.Write("#");
// ...
buffer2.Clear(); // 製造等間距空洞

實際案例：文章採此模式呈現 FAIL→72MB→648MB 的差異。實作環境：.NET 2.0（x86）實測數據：改善前：碎片分佈不穩定，難比較改善後：碎片模式可重現，差異顯著改善幅度：測試穩定性顯著提升

Learning Points（學習要點）核心知識點：

碎片模式控制
觀察可比較的必要條件
輸出標記（#）的目視輔助

技能要求：

必備技能：集合運用
進階技能：測試設計

延伸思考：

也可模擬不同密度碎片
風險：過度理想化與真實差異
優化：隨機化參數組合作對照

Practice Exercise（練習題）

基礎練習：改變交錯比例觀察影響
進階練習：引入隨機大小
專案練習：建立碎片模式生成器

Assessment Criteria（評估標準）

功能完整性（40%）：碎片可控
程式碼品質（30%）：參數化易用
效能優化（20%）：生成效率
創新性（10%）：多模式支持

Case #14: 在 x86 環境下釐清虛擬位址空間與連續配置的限制

Problem Statement（問題陳述）

業務場景：在 32 位元（x86）環境下，虛擬位址空間有限，長時運行後更容易面臨連續空間不足，即使總可用記憶體尚高。 技術挑戰：辨識是位址空間限制還是碎片問題，並採取對症措施。 影響範圍：任務失敗率與穩定性。 複雜度評級：中

Root Cause Analysis（根因分析）

直接原因：

x86 位址空間受限，連續空間更珍貴。
碎片化加速連續空間耗盡。
預設 GC 未緊縮加劇問題。

深層原因：

架構層面：選擇 x86 部署但需大塊配置
技術層面：忽略位址空間與 GC 策略交互
流程層面：未預估長時運作風險

Solution Design（解決方案設計）

解決策略：在 x86 環境優先啟用 server GC 改善連續空間；中長期評估 x64 遷移以放寬位址空間（若可能）。

實施步驟：

立即措施：gcServer
- 實作細節：app.config 啟用並驗證
- 所需資源：配置權限
- 預估時間：0.5 天
中期規劃：x64 評估
- 實作細節：相容性與記憶體佈局評估
- 所需資源：PoC
- 預估時間：1-2 週

關鍵程式碼/設定：

<runtime>
  <gcServer enabled="true" />
</runtime>

實際案例：在 .NET 2.0 x86 + server GC 下，連續空間顯著改善（648MB）。實作環境：.NET 2.0（x86）實測數據：改善前：x86 + 預設 GC 容易 OOM 改善後：x86 + server GC 可配置多個 72MB 區塊改善幅度：穩定性顯著提升

Learning Points（學習要點）核心知識點：

位址空間與連續配置的關係
x86 環境的特殊風險
以配置策略緩解限制

技能要求：

必備技能：平台知識
進階技能：遷移評估

延伸思考：

可應用於受限環境設備
風險：遷移成本與相容性
優化：分段處理與池化

Practice Exercise（練習題）

基礎練習：在 x86 測試四種設定差異
進階練習：規畫 x64 遷移清單
專案練習：撰寫 x86→x64 遷移 PoC 報告

Assessment Criteria（評估標準）

功能完整性（40%）：措施可落地
程式碼品質（30%）：測試與紀錄齊備
效能優化（20%）：實際改善
創新性（10%）：遷移路線圖

Case #15: 以主控台輸出與計數建立最小可觀測性

Problem Statement（問題陳述）

業務場景：需要最小成本地觀察配置進度與數量，以便快速定位卡點與失敗點，無需引入重量級分析器。 技術挑戰：在高壓測下維持低干擾的觀測。 影響範圍：故障定位速度。 複雜度評級：低

Root Cause Analysis（根因分析）

直接原因：

無觀測就無法快速對比模式差異。
重量級工具影響行為。
需要低成本的即時回饋。

深層原因：

架構層面：缺乏最小可觀測性設計
技術層面：忽視輸出即視化
流程層面：資料蒐集不系統

Solution Design（解決方案設計）

解決策略：使用主控台輸出「#」標記每次成功配置，並在關鍵節點輸出總結，作為低干擾觀測手段。

實施步驟：

輸出標記
- 實作細節：每成功配置一塊輸出一個「#」
- 所需資源：程式碼微調
- 預估時間：0.5 天
結尾統計
- 實作細節：輸出總區塊數與 MB
- 所需資源：同上
- 預估時間：0.5 天

關鍵程式碼/設定：

buffer1.Add(new byte[64 * 1024 * 1024]); Console.Write("#");
// ...
Console.WriteLine($"Total: 64mb x {buffer1.Count}, 72mb x {buffer3.Count} ...");

實際案例：文章以此快速視覺化不同模式的配置進度與總量。實作環境：.NET 2.0（x86）實測數據：改善前：無法直觀看到卡在哪個階段改善後：可快速分辨在步驟 1/3 卡住與否改善幅度：故障定位時間明顯縮短

Learning Points（學習要點）核心知識點：

最小可觀測性的價值
壓測下的低干擾觀測
指標選擇（數量、大小、進度）

技能要求：

必備技能：輸出與格式化
進階技能：觀測與行為影響平衡

延伸思考：

可應用於其他壓測場景
風險：輸出過多反致干擾
優化：分級日誌與節流

Practice Exercise（練習題）

基礎練習：加入輸出與總結
進階練習：加上每秒統計
專案練習：實作簡易 TUI 監視

Assessment Criteria（評估標準）

功能完整性（40%）：輸出清楚
程式碼品質（30%）：不干擾主流程
效能優化（20%）：輸出節流
創新性（10%）：可視化設計

Case #16: 以參數化與多版本驗證跨平台差異（補充驗證）

Problem Statement（問題陳述）

業務場景：需在不同 OS/CLR 版本上確認 GC 模式與碎片行為是否一致，避免只在單一環境下得出偏誤結論。 技術挑戰：快速切換參數與收集不同平台結果。 影響範圍：跨環境部署風險。 複雜度評級：中

Root Cause Analysis（根因分析）

直接原因：

版本/平台差異可能影響 GC 實作細節。
單一環境結論可能不具普遍性。
缺乏參數化工具造成重工。

深層原因：

架構層面：跨平台策略不足
技術層面：測試未參數化
流程層面：缺乏回饋循環

Solution Design（解決方案設計）

解決策略：參數化區塊大小與 GC 設定，在多平台（例如不同 Windows 版本或 .NET 版本）執行，同步收集與對比。

實施步驟：

參數化與腳本化
- 實作細節：命令列參數控制大小與模式
- 所需資源：批次/PowerShell
- 預估時間：1 天
統整報表
- 實作細節：不同平台結果集中對比
- 所需資源：報表工具
- 預估時間：1 天

關鍵程式碼/設定：

// e.g., args: 64 72 server|workstation
var mode = args[2];

實際案例：文章呼籲「歡迎拿去各種平台試一下，有不一樣的結果也通知」，鼓勵跨平台驗證。實作環境：起點為 .NET 2.0（x86）實測數據：改善前：僅有單環境結果改善後：多環境對比可降低風險改善幅度：決策穩健度提升

Learning Points（學習要點）核心知識點：

跨平台驗證的重要性
參數化測試設計
結果統整方法

技能要求：

必備技能：腳本撰寫
進階技能：多環境自動化

延伸思考：

可應用於任何平台相關行為
風險：測試覆蓋不足
優化：增加樣本與自動回收

Practice Exercise（練習題）

基礎練習：將大小與模式改為參數
進階練習：在兩個 Windows 版本上跑
專案練習：自動化跨機執行與彙整

Assessment Criteria（評估標準）

功能完整性（40%）：跨環境可執行
程式碼品質（30%）：參數化清晰
效能優化（20%）：自動化程度
創新性（10%）：報表呈現

案例分類

按難度分類
- 入門級（適合初學者）
  - Case #4, #6, #7, #8, #10, #13, #15
- 中級（需要一定基礎）
  - Case #2, #3, #5, #9, #12, #14, #16
- 高級（需要深厚經驗）
  - Case #1, #11
按技術領域分類
- 架構設計類
  - Case #1, #9, #12, #14
- 效能優化類
  - Case #2, #3, #5, #10, #15, #16
- 整合開發類
  - Case #6, #7, #13
- 除錯診斷類
  - Case #4, #8, #11
- 安全防護類
  - （本篇未涉及）
按學習目標分類
- 概念理解型
  - Case #1, #8, #12, #14
- 技能練習型
  - Case #6, #7, #10, #13, #15, #16
- 問題解決型
  - Case #2, #3, #4, #5, #9, #11
- 創新應用型
  - Case #11, #16

案例關聯圖（學習路徑建議）

入門順序（先學概念與重現） 1) Case #7（建立壓測腳本與再現） 2) Case #13（用交錯模式製造碎片） 3) Case #10（用 OOM 作為邊界條件） 4) Case #15（最小可觀測性）
核心概念（建立正確心智模型） 5) Case #8（釋放 vs 回收 vs 緊縮） 6) Case #2（預設 GC 的侷限） 7) Case #3（Collect 不等於緊縮） 8) Case #4（Concurrent 與碎片無關） 9) Case #1（指標 vs 參考，遷移價值）
解決方案（根本修復） 10) Case #6（用 config 管理 GC 模式） 11) Case #5（啟用 server GC，觀察成效）
擴展決策與部署 12) Case #12（workstation vs server 選型） 13) Case #14（x86 環境與限制） 14) Case #11（以實證補足文檔空白）
強化與驗證 15) Case #16（參數化與跨平台驗證） 16) Case #9（針對連續配置需求做流程與架構調整）

依賴關係：

Case #2、#3、#4 依賴 #7、#13 的重現能力
Case #5 依賴 #6 的配置能力與 #2-#4 的對照結果
Case #12 依賴 #5 的實測與 #2-#4 的反例
Case #11、#16 以 #5 的結論為驗證核心

完整學習路徑建議：先學如何重現與觀測（#7→#13→#10→#15），建立正確心智模型（#8→#2→#3→#4→#1），再落地解法（#6→#5），最後建立選型方法與跨環境驗證（#12→#14→#11→#16），並回到業務流程優化（#9）形成閉環。這樣能從「會重現」到「懂原理」再到「能解決、會部署與能驗證」，完成實戰閉環。

Memory Management (III) - .NET CLR ?

Case #1: 用管理式語言移除指標以解決不可搬移的記憶體配置

Problem Statement（問題陳述）

Root Cause Analysis（根因分析）

Solution Design（解決方案設計）

Case #2: .NET 預設 GC 無法回收足夠連續空間導致 OOM

Problem Statement（問題陳述）

Root Cause Analysis（根因分析）

Solution Design（解決方案設計）

Case #3: 強制完整 GC.Collect 仍無法有效緊縮碎片

Problem Statement（問題陳述）

Root Cause Analysis（根因分析）

Solution Design（解決方案設計）

Case #4: 關閉 Concurrent GC 仍無助於解決碎片

Problem Statement（問題陳述）

Root Cause Analysis（根因分析）

Solution Design（解決方案設計）

Case #5: 啟用 Server GC 觸發緊縮，大幅提升可用連續空間

Problem Statement（問題陳述）

Root Cause Analysis（根因分析）

Solution Design（解決方案設計）

Case #6: 以 app.config 管控 GC 模式的部署化解決方案

Problem Statement（問題陳述）

Root Cause Analysis（根因分析）

Solution Design（解決方案設計）

Case #7: 建立可再現的記憶體碎片壓測腳本

Problem Statement（問題陳述）

Root Cause Analysis（根因分析）

Solution Design（解決方案設計）

Case #8: 釋放引用後為何仍未即時回收？GC 時機與誤解剖析

Problem Statement（問題陳述）

Root Cause Analysis（根因分析）

Solution Design（解決方案設計）

Case #9: 大塊連續配置需求的風險辨識與設計調整

Problem Statement（問題陳述）

Root Cause Analysis（根因分析）

Solution Design（解決方案設計）

Case #10: 以 OutOfMemoryException 作為邊界條件的壓測設計

Problem Statement（問題陳述）

Root Cause Analysis（根因分析）

Solution Design（解決方案設計）

Case #11: 以 empirical（實證）方式驗證文件未明說的 GC 行為

Problem Statement（問題陳述）

Root Cause Analysis（根因分析）

Solution Design（解決方案設計）

Case #12: 工作站 GC 與伺服器 GC 的選型方法

Problem Statement（問題陳述）

Root Cause Analysis（根因分析）

Solution Design（解決方案設計）

Case #13: 以雙集合交錯配置/釋放模式穩定製造碎片

Problem Statement（問題陳述）

Root Cause Analysis（根因分析）

Solution Design（解決方案設計）

Case #14: 在 x86 環境下釐清虛擬位址空間與連續配置的限制

Problem Statement（問題陳述）

Root Cause Analysis（根因分析）

Solution Design（解決方案設計）

Case #15: 以主控台輸出與計數建立最小可觀測性

Problem Statement（問題陳述）

Root Cause Analysis（根因分析）

Solution Design（解決方案設計）

Case #16: 以參數化與多版本驗證跨平台差異（補充驗證）

Problem Statement（問題陳述）

Root Cause Analysis（根因分析）

Solution Design（解決方案設計）

Facebook Pages

AI Synthesis Contents

Edit Post (Pull Request)

Post Directory