.NET Core 跨平台 #2, 記憶體管理大考驗 - setup environment

以下為基於原文整合出的 16 個可操作的問題解決案例，聚焦於 .NET/.NET Core 記憶體碎片、GC 行為、跨平台與容器/虛擬化測試設計。每個案例均提供完整教學結構、可落地的步驟與程式片段。原文尚未提供最終量測數據；因此各案例在「實測數據」欄位以「指標設計與驗收口徑」呈現，便於日後補充與評估。

Case #1: 統一虛擬化測試環境，消除外部干擾

Problem Statement（問題陳述）

業務場景：團隊要比較 .NET Core 在多平台（Windows、Linux、容器）下對大物件配置與碎片化的行為，若不先統一測試環境，數據易受宿主機背景程序、動態記憶體、其他 VM/容器的干擾而不具可比性。需建立可重現、可對比的基線環境，作為後續優化與平台選型的依據。技術挑戰：如何在單一實體主機上，讓多個不同 OS/容器測試條件一致，並避免相互影響。影響範圍：錯誤結論、錯誤平台選型、無法重現 OOM 與碎片化行為。複雜度評級：中

Root Cause Analysis（根因分析）

直接原因：

Hyper-V 動態記憶體導致 VM 實際可用 RAM 波動
多 VM 並行導致宿主資源爭奪，引發偶發性抖動
宿主機背景程序（索引、更新）影響測試穩定深層原因：
- 架構層面：缺少隔離/基線控制的測試架構
- 技術層面：未固定 CPU/RAM/SWAP/磁碟等資源配置
- 流程層面：缺乏一次只開一台 VM 的測試流程規範

Solution Design（解決方案設計）

解決策略：建立統一的 Hyper-V VM 標準規格（CPU 1、RAM 1024MB、SWAP 4096MB、VHDX 32GB），一次只啟動一台 VM 進行測試；禁用動態記憶體，統一視訊與儲存配置，確保測試可重現可對比。

實施步驟：

建立 VM 範本
- 實作細節：配置 CPU=1、RAM=1024MB（Disable Dynamic Memory）、VHDX 32GB、解析度 1366x768
- 所需資源：Windows 10 Hyper-V、ISO（Boot2Docker/Ubuntu/Windows Server）
- 預估時間：1 小時
固定資源並紀錄
- 實作細節：禁用宿主自動更新與背景索引；建立測試紀錄模板（VM 名稱/CPU/RAM/SWAP/磁碟）
- 所需資源：本機群組原則、PowerShell
- 預估時間：30 分鐘
串接單機序列測試
- 實作細節：以 PowerShell 自動化「關閉其它 VM → 啟動目標 VM → 跑測試 → 收數據」
- 所需資源：PowerShell、Hyper-V 模組
- 預估時間：1 小時

關鍵程式碼/設定：

# PowerShell: 確保一次只開一台 VM 進行基準測試
param([string]$TargetVm)

Get-VM | Where-Object { $_.Name -ne $TargetVm } | Stop-VM -Force
Start-VM -Name $TargetVm
# TODO: 進 VM 執行測試腳本與收集輸出（可用 PowerShell Direct 或 SSH）

實際案例：原文以單一 PC（i7-2600K/24GB RAM/Win10）建立 4 組 VM：Boot2Docker、Ubuntu 15.10+Docker、Windows Server 2012 R2、Windows 2016 TP4（Windows 容器）實作環境：Hyper-V on Windows 10；各 VM 統一配置（CPU 1、RAM 1024MB（Disable Dynamic Memory）、SWAP 4096MB、VHDX 32GB）實測數據：改善前：不同測試 run 結果差異大、不可重現改善後：結果趨於穩定、跨平台可對比改善幅度：以「同平台連續三次測試的最大/最小差異%」做為指標，目標 < 5%

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

基準測試的「隔離與一致性」原則
動態記憶體與宿主背景負載對測試的影響
單機序列化測試流程設計技能要求：
必備技能：Hyper-V/VM 建置、PowerShell 自動化
進階技能：基準測試方法學、結果統計延伸思考：
能應用於 CPU/IO/網路等跨平台效能比較
風險：老舊 OS/工具在新硬體上相容性
優化：以 Terraform/Packer 建立 VM 模板

Practice Exercise（練習題）基礎練習：手動建立一台 Ubuntu VM，配置 RAM 1024MB、SWAP 4096MB（30 分鐘）進階練習：寫 PowerShell 腳本自動停止全部 VM、只啟動指定 VM 並執行測試（2 小時）專案練習：建立四套 VM 並完成跨平台測試自動執行與報表（8 小時）

Assessment Criteria（評估標準）功能完整性（40%）：VM 規格統一、一次僅一台 VM 運行程式碼品質（30%）：PowerShell 腳本結構清晰、可維護效能優化（20%）：測試波動度明顯降低創新性（10%）：自動化報表或環境快照能力

Case #2: 容器內 .NET 記憶體測試的 cgroups 與記憶體上限控制

Problem Statement（問題陳述）

業務場景：要在 Docker 容器中驗證 .NET Core 於 Linux/Windows 容器的記憶體碎片行為，若不設定 cgroups/memory 限制，結果易受宿主可用 RAM 與 swap 影響，導致 OOM 行為不一致。技術挑戰：讓 .NET 看到的可用記憶體和容器限制一致，並跨 OS 容器一致。影響範圍：誤判 GC/LOH 能力、跨平台結論失真。複雜度評級：中

Root Cause Analysis（根因分析）

直接原因：

預設容器不限制記憶體，.NET 以宿主可用 RAM 做判斷
不同 OS 的 OOM Killer/Commit 行為不同
Swap 開啟導致 OOM 時機不同深層原因：
- 架構層面：缺少資源限制策略
- 技術層面：cgroups/memory、Windows Job Object 認知不足
- 流程層面：容器啟動參數未標準化

Solution Design（解決方案設計）

解決策略：以 docker run 設定 memory/memory-swap 與 CPU 限制，並記錄參數進報表；同時在 Linux 調整 overcommit 與 swappiness 以穩定 OOM 行為。

實施步驟：

定義容器資源模板
- 實作細節：–memory=768m –memory-swap=768m –cpus=1
- 所需資源：Docker 1.9.1+（或更新）
- 預估時間：30 分鐘
啟動容器執行測試
- 實作細節：掛載測試程式，輸出結果到宿主
- 所需資源：Dockerfile、dotnet SDK/runtime
- 預估時間：1 小時
記錄環境指標
- 實作細節：將 docker inspect 的限制與 /proc/meminfo 記錄到測試輸出
- 所需資源：Shell/PowerShell
- 預估時間：30 分鐘

關鍵程式碼/設定：

# Linux 容器建議命令
docker run --rm \
  --memory=768m --memory-swap=768m --cpus=1 \
  -v $(pwd)/publish:/app mcr.microsoft.com/dotnet/runtime:8.0 \
  dotnet /app/MemFrag.dll

實際案例：原文在 Boot2Docker 與 Ubuntu + Docker 1.9.1 上測試 .NET Core 實作環境：Docker 1.9.1（或更新）、.NET Core Runtime（CoreCLR）實測數據：改善前：OOM 行為隨宿主波動改善後：OOM 行為與 cgroups 限制一致改善幅度：以「OOM 觸發點的可重現性（區塊數標準差）」作為指標，目標標準差 < 1

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

cgroups/memory 與 .NET 的記憶體可見性
容器資源限制對 GC/OOM 判斷的影響
swap 與 overcommit 對測試的干擾技能要求：
必備技能：Docker 基礎、容器配置
進階技能：Linux 記憶體管理（cgroups、/proc）延伸思考：
可應用於生產容器資源治理
風險：舊版 Docker 與新 runtime 相容性
優化：導入 docker-compose 統一規格

Practice Exercise（練習題）基礎練習：用 –memory 啟動容器並成功執行測試程式（30 分鐘）進階練習：輸出容器內 /proc/meminfo 與 cgroup 限制至檔案（2 小時）專案練習：建立多容器（Linux/Windows）一致測試流水線（8 小時）

Assessment Criteria（評估標準）功能完整性（40%）：容器限制生效且被測程式可執行程式碼品質（30%）：啟動腳本、Dockerfile 清晰效能優化（20%）：測試 OOM 點可重現創新性（10%）：自動紀錄容器限制與測試輸出

Case #3: Windows 容器中安裝並運行 .NET Core 測試

Problem Statement（問題陳述）

業務場景：需在 Windows 容器（WindowsServerCore/Nano）內執行 .NET Core 記憶體測試，確認 Windows 容器與 Linux 容器的差異。技術挑戰：早期 Windows 容器相依項多，runtime 安裝與路徑配置較複雜。影響範圍：難以跨 OS 容器對照、測試流程中斷。複雜度評級：中

Root Cause Analysis（根因分析）

直接原因：

Windows 容器基底映像精簡，缺少 .NET Core 相依
檔案系統與路徑差異導致執行失敗
早期 Tech Preview 功能限制深層原因：
- 架構層面：容器基底映像設計差異
- 技術層面：CoreCLR 相依性、VS/CLI 發佈模型差異
- 流程層面：無標準化 Dockerfile/發佈流程

Solution Design（解決方案設計）

解決策略：採用官方 dotnet runtime 基底映像（建議），或在 windowsservercore 上安裝 CoreCLR 與相依，使用自包含發佈，確保不依賴容器內已安裝的 SDK。

實施步驟：

建構 Dockerfile
- 實作細節：FROM mcr.microsoft.com/dotnet/runtime:8.0-windowsservercore-ltscXXXX
- 所需資源：Docker for Windows、Windows Server 基底映像
- 預估時間：30 分鐘
發佈自包含應用
- 實作細節：dotnet publish -r win-x64 -c Release –self-contained true
- 所需資源：.NET SDK
- 預估時間：30 分鐘
執行與紀錄
- 實作細節：docker run 設定記憶體限制、輸出日誌
- 所需資源：Docker
- 預估時間：30 分鐘

關鍵程式碼/設定：

# Windows 容器 Dockerfile
FROM mcr.microsoft.com/dotnet/runtime:8.0-windowsservercore-ltsc2022
WORKDIR /app
COPY publish/ .
ENTRYPOINT ["MemFrag.exe"]

實際案例：原文在 Windows 2016 TP4 Nano + windowsservercore container 測試 CoreCLR 實作環境：Windows 10 + Docker for Windows（或 Windows Server 2016/2019/2022）實測數據：改善前：執行失敗或相依缺失改善後：容器內成功運行與輸出數據改善幅度：成功率從不穩定提升至 100%（以 3 次重跑為準）

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

Windows 容器與 Linux 容器差異
自包含發佈降低相依風險
基底映像選型策略技能要求：
必備技能：Dockerfile、.NET 發佈
進階技能：Windows 容器相依診斷延伸思考：
生產環境中建議採用官方 dotnet 映像
風險：TP/舊版相容性
優化：多階段建置縮小映像

Practice Exercise（練習題）基礎練習：基於 runtime 映像運行範例（30 分鐘）進階練習：自包含發佈並於容器中執行（2 小時）專案練習：建立 Linux/Windows 雙容器流水線（8 小時）

Assessment Criteria（評估標準）功能完整性（40%）：容器可成功啟動並輸出結果程式碼品質（30%）：Dockerfile 簡潔、可維護效能優化（20%）：映像尺寸與啟動時間合理創新性（10%）：多平台自動化發佈

Case #4: 設計可重現的大物件碎片化測試程式

Problem Statement（問題陳述）

業務場景：為了比較不同平台 GC 在 LOH 碎片情境下的行為，需要一支測試程式能系統化地製造碎片並觀測 OOM 與配置次數。技術挑戰：如何有效製造「可控」碎片並紀錄指標。影響範圍：測試不可重現、無法解讀 GC 行為。複雜度評級：中

Root Cause Analysis（根因分析）

直接原因：

未能穩定觸發 LOH 碎片化場景
缺乏統一的輸出指標（次數、時間）
OOM 可能中斷流程深層原因：
- 架構層面：測試程式缺少步驟設計（A→B→C）
- 技術層面：不理解 LOH 閾值與 GC 壓縮
- 流程層面：未規範輸出格式與錯誤處理

Solution Design（解決方案設計）

解決策略：按照三步驟實作測試：1) 連續配置 64MB；2) 釋放偶數區塊+GC；3) 連續配置 72MB；透過 try/catch 處理 OOM 並輸出統計與耗時。

實施步驟：

撰寫測試邏輯
- 實作細節：使用 List<byte[]> 保留參考、釋放 buffer2、GC.Collect
- 所需資源：.NET SDK
- 預估時間：30 分鐘
加入時間與計數輸出
- 實作細節：統計次數、耗時、總量
- 所需資源：標準 Console API
- 預估時間：15 分鐘
包裝錯誤處理
- 實作細節：捕捉 OutOfMemoryException、不中斷流程
- 所需資源：C# 例外處理
- 預估時間：15 分鐘

關鍵程式碼/設定：

// 依原文測試邏輯（節錄）
var buffer1 = new List<byte[]>();
var buffer2 = new List<byte[]>();
var buffer3 = new List<byte[]>();

// 1) 連續配置 64MB
try {
    while (true) {
        buffer1.Add(new byte[64 * 1024 * 1024]);
        Console.Write("#");
        buffer2.Add(new byte[64 * 1024 * 1024]);
        Console.Write("#");
    }
} catch (OutOfMemoryException) {}

// 2) 釋放偶數（buffer2）
buffer2.Clear();
GC.Collect(GC.MaxGeneration);

// 3) 連續配置 72MB
try {
    while (true) {
        buffer3.Add(new byte[72 * 1024 * 1024]);
        Console.Write("#");
    }
} catch (OutOfMemoryException) {}

實際案例：原文提供完整程式碼與三步驟測試法實作環境：.NET Core Runtime（CoreCLR）、Windows/Linux/容器實測數據：改善前：無法穩定觸發碎片化與 OOM 改善後：可穩定重現碎片化下「無法配置 72MB」情境改善幅度：以「第三步驟成功的配置次數」作為指標；期望顯著低於第一步驟的比例

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

LOH（Large Object Heap）與閾值（> 85K）
碎片化對大物件配置的影響
OOM 與例外處理技能要求：
必備技能：C#、GC 基礎
進階技能：測試場景設計延伸思考：
可延伸加入不同塊大小（96MB/128MB）
風險：不同平台 defer-commit 行為
優化：抽象為可重用測試框架

Practice Exercise（練習題）基礎練習：自行實作三步驟測試並編譯執行（30 分鐘）進階練習：加入 CSV 輸出結果（2 小時）專案練習：支援多種塊大小與自動化批次測試（8 小時）

Assessment Criteria（評估標準）功能完整性（40%）：三步驟如期執行且不中斷程式碼品質（30%）：結構清晰、可讀性佳效能優化（20%）：最小化額外開銷創新性（10%）：可組態化與擴充性

Case #5: 以 InitBuffer 強迫頁面實際配置，避免 overcommit 誤導

Problem Statement（問題陳述）

業務場景：在 Linux 或某些平台上，僅配置大陣列可能只保留虛擬位址，未實際觸碰頁面，導致看似可「配置更多」但不代表可用，誤導測試與結論。技術挑戰：如何讓每個配置的記憶體確實被「觸碰／實佔」，反映真實可用量。影響範圍：指標高估、跨平台不可比。複雜度評級：中

Root Cause Analysis（根因分析）

直接原因：

Linux 記憶體 overcommit（僅分配虛擬位址）
Windows 懶分頁（first-touch 才供應清零頁）
測試未觸碰頁面深層原因：
- 架構層面：缺乏實佔檢核
- 技術層面：不了解 OS 實際分頁策略
- 流程層面：缺少觸碰步驟

Solution Design（解決方案設計）

解決策略：為每次配置的 byte[] 呼叫 InitBuffer 以亂數填滿，強制觸碰每一頁面，讓 OS 真的交付實體頁，避免 overcommit 假象。

實施步驟：

加入 InitBuffer
- 實作細節：rnd.NextBytes(buffer);（觸碰全部頁面）
- 所需資源：System.Random
- 預估時間：10 分鐘
控制是否啟用
- 實作細節：以旗標控制開關，便於對照
- 所需資源：命令列參數
- 預估時間：20 分鐘
記錄差異
- 實作細節：分別在啟用/停用下收集配置次數與 OOM 點
- 所需資源：輸出記錄
- 預估時間：30 分鐘

關鍵程式碼/設定：

static Random rnd = new Random();
static void InitBuffer(byte[] buffer) => rnd.NextBytes(buffer);

// 使用範例
var buf = new byte[64 * 1024 * 1024];
InitBuffer(buf); // 確保已觸碰每一頁

實際案例：原文新增 InitBuffer 方法並明確指出用途實作環境：Linux（Boot2Docker/Ubuntu）、Windows 實測數據：改善前：配置計數偏高（虛擬分配）改善後：反映實佔能力（真實可用）改善幅度：以「啟用前後，第一步驟可配置 64MB 區塊數差異」為指標，預期啟用後次數下降且更接近實況

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

Overcommit 與 First-touch 配頁
為何要「觸碰」每一頁面
測試真實性設計技能要求：
必備技能：C#、Random 使用
進階技能：OS 記憶體管理原理延伸思考：
也可採用 Span.Fill 或 memset for 性能
風險：填充本身帶來額外時間成本
優化：採樣式觸碰以兼顧性能

Practice Exercise（練習題）基礎練習：加入 InitBuffer 並比較啟用/關閉下配置次數（30 分鐘）進階練習：實作「只觸碰每 4KB」版本並比較（2 小時）專案練習：建立不同觸碰策略的性能/準確性曲線（8 小時）

Assessment Criteria（評估標準）功能完整性（40%）：可切換觸碰策略程式碼品質（30%）：抽象良好、可重用效能優化（20%）：控制額外耗時創新性（10%）：多策略比較與報表

Case #6: 正確釋放物件參考並觸發 GC 回收

Problem Statement（問題陳述）

業務場景：在步驟二釋放偶數區塊後，記憶體未明顯下降，導致第三步驟配置受限。技術挑戰：如何保證釋放參考後，GC 確實回收，最大化可用空間。影響範圍：測試不準、碎片分布不可控。複雜度評級：低

Root Cause Analysis（根因分析）

直接原因：

List 仍保留參考，GC 不會回收
垃圾回收尚未發生
背景 GC 模式延後回收深層原因：
- 架構層面：資料結構選擇影響回收時機
- 技術層面：未正確使用 GC API
- 流程層面：釋放與回收步驟未明確化

Solution Design（解決方案設計）

解決策略：呼叫 buffer2.Clear() 去除參考，隨後執行 GC.Collect(GC.MaxGeneration) 與 GC.WaitForPendingFinalizers()，確保釋放作業完成。

實施步驟：

清空參考
- 實作細節：buffer2.Clear();（或 buffer2 = new List<byte[]>();）
- 所需資源：C#
- 預估時間：10 分鐘
觸發並等待 GC
- 實作細節：GC.Collect(GC.MaxGeneration); GC.WaitForPendingFinalizers();
- 所需資源：System.GC
- 預估時間：10 分鐘

關鍵程式碼/設定：

buffer2.Clear();
GC.Collect(GC.MaxGeneration);
GC.WaitForPendingFinalizers(); // 確保清理完成

實際案例：原文已示範 Clear + GC.Collect 實作環境：通用實測數據：改善前：記憶體釋放不可控改善後：釋放更即時，碎片模式可預期改善幅度：以第三步驟的 72MB 成功配置次數作為指標，期待更接近理論碎片上限

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

參考持有與 GC 回收關係
GC.Collect 與 Finalizers
受控釋放的重要性技能要求：
必備技能：C#、集合操作
進階技能：GC 調試延伸思考：
注意過度 Collect 對性能影響
風險：阻塞等待造成測試時間增加
優化：只在關鍵步驟強制回收

Practice Exercise（練習題）基礎練習：加入 WaitForPendingFinalizers 並觀察差異（30 分鐘）進階練習：比較背景/Server GC 模式差異（2 小時）專案練習：建立自動化 GC 行為 A/B 測試（8 小時）

Assessment Criteria（評估標準）功能完整性（40%）：釋放步驟正確執行程式碼品質（30%）：清晰簡潔效能優化（20%）：減少不必要的 Collect 創新性（10%）：自動化比較

Case #7: LOH 碎片化下啟用一次性 LOH 壓縮

Problem Statement（問題陳述）

業務場景：釋放偶數區塊後嘗試配置 72MB 失敗，推測為 LOH 碎片化導致無連續空間。技術挑戰：如何在 .NET 中壓縮 LOH，以嘗試回收出足夠連續空間。影響範圍：大物件配置失敗、服務 OOM。複雜度評級：中

Root Cause Analysis（根因分析）

直接原因：

85KB 的大物件進入 LOH，預設不壓縮（歷史行為）
交錯釋放造成 LOH 高度碎片
連續空間不足以容納 72MB 深層原因：
- 架構層面：大物件生命週期/模式未設計
- 技術層面：未啟用 LOH 壓縮能力
- 流程層面：釋放節奏與配置節奏不當

Solution Design（解決方案設計）

解決策略：在關鍵時間點設定 GCSettings.LargeObjectHeapCompactionMode = CompactOnce，隨後 GC.Collect()，觀察是否能配置 72MB。

實施步驟：

啟用 LOH 壓縮
- 實作細節：在步驟二之後、步驟三之前設定 CompactOnce
- 所需資源：System.Runtime
- 預估時間：15 分鐘
觀察配置成功率
- 實作細節：記錄步驟三成功次數變化
- 所需資源：統計輸出
- 預估時間：30 分鐘

關鍵程式碼/設定：

using System.Runtime;

GCSettings.LargeObjectHeapCompactionMode = GCLargeObjectHeapCompactionMode.CompactOnce;
GC.Collect(GC.MaxGeneration); // 觸發 LOH 壓縮

實際案例：原文未實作此步驟，但屬於該測試常見補強策略實作環境：.NET Framework 4.5.1+ 或 .NET Core/5+/6+/8+ 實測數據：改善前：步驟三配置 72MB 幾乎為 0 改善後：可成功配置部分 72MB 區塊改善幅度：以成功配置的 72MB 區塊數比較，期望 > 0

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

LOH 壓縮能力與使用時機
碎片化與連續空間
壓縮成本與停頓技能要求：
必備技能：GC API
進階技能：停頓分析延伸思考：
不適合高頻使用，建議離峰或維護窗
風險：長暫停（STW）
優化：結合物件池策略（另案）

Practice Exercise（練習題）基礎練習：加入 CompactOnce 前後比較（30 分鐘）進階練習：測量暫停時間與成功配置數（2 小時）專案練習：建置「自動判斷是否執行壓縮」策略（8 小時）

Assessment Criteria（評估標準）功能完整性（40%）：成功觸發 LOH 壓縮程式碼品質（30%）：開關式實作、安全效能優化（20%）：控制暫停影響創新性（10%）：策略化壓縮判斷

Case #8: 以 Stopwatch 與結構化輸出取代 DateTime 計時

Problem Statement（問題陳述）

業務場景：需要準確比較多平台耗時，DateTime 計時解析度與誤差可能影響精度。技術挑戰：如何得到高精度、可結構化分析的測試數據。影響範圍：誤判效能優劣、結論不可信。複雜度評級：低

Root Cause Analysis（根因分析）

直接原因：

DateTime 解析度不足
輸出非結構化（難以機器處理）
無 run id 與環境標記深層原因：
- 架構層面：缺少數據管線
- 技術層面：計時 API 誤用
- 流程層面：無統一輸出格式

Solution Design（解決方案設計）

解決策略：使用 Stopwatch 進行計時，輸出 CSV/JSON，包含 run-id、平台、配置次數、耗時等欄位，便於後續自動分析。

實施步驟：

改用 Stopwatch
- 實作細節：StartNew/ElapsedMilliseconds
- 所需資源：System.Diagnostics
- 預估時間：10 分鐘
結構化輸出
- 實作細節：CSV 標頭 + 數據列
- 所需資源：I/O
- 預估時間：20 分鐘

關鍵程式碼/設定：

var sw = Stopwatch.StartNew();
// ... 測試 ...
sw.Stop();
File.AppendAllText("result.csv",
  $"run={Guid.NewGuid()},step=1,count={buffer1.Count+buffer2.Count},ms={sw.ElapsedMilliseconds}\n");

實際案例：原文採 DateTime；本案為精度優化實作環境：通用實測數據：改善前：無法精準比較改善後：可機器分析、可回歸驗證改善幅度：以「多次重跑耗時標準差」為指標，期望降低

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

Stopwatch 精度
可機器解析的數據格式技能要求：
必備技能：I/O、Stopwatch
進階技能：數據分析延伸思考：
可串接 SQLite/InfluxDB
風險：I/O 對計時干擾（可緩存）
優化：緩寫、批次輸出

Practice Exercise（練習題）基礎練習：用 Stopwatch 替換 DateTime（30 分鐘）進階練習：輸出 CSV 並用外部工具做統計（2 小時）專案練習：建立圖表儀表板（8 小時）

Assessment Criteria（評估標準）功能完整性（40%）：計時與輸出正確程式碼品質（30%）：輸出格式清晰效能優化（20%）：減少 I/O 干擾創新性（10%）：自動化分析

Case #9: 確保 64 位元執行，避免 32 位元位址空間瓶頸

Problem Statement（問題陳述）

業務場景：測試需大量位址空間，若誤以 32 位元進程運行，將早早 OOM，結論失真。技術挑戰：確保在各平台均以 x64 進程執行。影響範圍：提前 OOM、無法比較平台差異。複雜度評級：低

Root Cause Analysis（根因分析）

直接原因：

AnyCPU + Prefer32Bit 預設值
發佈未指定 runtime 標誌
容器基底映像可能是 x86（少見但需防）深層原因：
- 架構層面：發佈流程未鎖定目標架構
- 技術層面：csproj 設定缺失
- 流程層面：未檢查進程位元數

Solution Design（解決方案設計）

解決策略：停用 Prefer32Bit、指定 x64 RuntimeIdentifier，於啟動時輸出 IntPtr.Size 校驗。

實施步驟：

csproj 設定
- 實作細節：x64 或 publish -r win-x64/linux-x64
- 所需資源：.NET SDK
- 預估時間：10 分鐘
執行時校驗
- 實作細節：輸出 IntPtr.Size==8
- 所需資源：C#
- 預估時間：5 分鐘

關鍵程式碼/設定：

<!-- csproj -->
<PropertyGroup>
  <PlatformTarget>x64</PlatformTarget>
  <Prefer32Bit>false</Prefer32Bit>
</PropertyGroup>

Console.WriteLine($"x64? {(IntPtr.Size == 8)}");

實際案例：原文隱含 x64 假設；此案補強流程實作環境：通用實測數據：改善前：提早 OOM 改善後：符合測試需求的位址空間改善幅度：以「第一步驟可配置 64MB 區塊數」做檢核，x64 明顯 > x86

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

位址空間與 OOM 關聯
發佈架構鎖定技能要求：
必備技能：.NET 發佈
進階技能：部署檢核延伸思考：
ARM64 平台的對照
風險：第三方原生依賴
優化：CI 建置多架構

Practice Exercise（練習題）基礎練習：輸出 IntPtr.Size 校驗（30 分鐘）進階練習：多架構發佈與比較（2 小時）專案練習：CI 建置 x64/arm64 並自動測試（8 小時）

Assessment Criteria（評估標準）功能完整性（40%）：x64 執行確認程式碼品質（30%）：設定清晰效能優化（20%）：避免不必要失敗創新性（10%）：多架構自動化

Case #10: 控制 Linux overcommit 與 swap，穩定 OOM 行為

Problem Statement（問題陳述）

業務場景：Linux 下 OOM 行為不穩，與 overcommit 與 swap 設定強相關。技術挑戰：如何讓 OOM 時機可預期，便於跨平台比較。影響範圍：測試不可對比、誤判 GC 能力。複雜度評級：中

Root Cause Analysis（根因分析）

直接原因：

vm.overcommit_memory 預設允許過度配置
swap 預設開啟，延後 OOM
容器內與宿主設定不一致深層原因：
- 架構層面：測試未定義 OS 設定基準
- 技術層面：不了解 Linux 記憶體策略
- 流程層面：未在測試前調整/紀錄

Solution Design（解決方案設計）

解決策略：設 vm.overcommit_memory=2（嚴格）、vm.swappiness=1（或 0），容器以 –memory-swap= 等於 –memory，禁用 swap 影響。

實施步驟：

調整 sysctl
- 實作細節：sysctl -w vm.overcommit_memory=2; sysctl -w vm.swappiness=1
- 所需資源：root 權限
- 預估時間：10 分鐘
控制容器 swap
- 實作細節：–memory=768m –memory-swap=768m
- 所需資源：Docker
- 預估時間：10 分鐘

關鍵程式碼/設定：

sudo sysctl -w vm.overcommit_memory=2
sudo sysctl -w vm.swappiness=1
docker run --rm --memory=768m --memory-swap=768m ...

實際案例：原文於 Linux 容器/VM 測試實作環境：Ubuntu 15.10 + Docker 1.9.1（或更新）實測數據：改善前：OOM 點飄移改善後：OOM 點穩定改善幅度：以「第一步 OOM 發生的 64MB 區塊數」標準差衡量，目標 < 1

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

overcommit/swappiness 概念
容器 swap 控制技能要求：
必備技能：Linux 管理
進階技能：容器資源控制延伸思考：
生產上通常禁用容器 swap
風險：過嚴限制導致應用受限
優化：依服務特性調整

Practice Exercise（練習題）基礎練習：臨時調整 sysctl（30 分鐘）進階練習：寫入 /etc/sysctl.conf 永久化（2 小時）專案練習：以 Ansible/Shell 腳本系統化（8 小時）

Assessment Criteria（評估標準）功能完整性（40%）：設定生效程式碼品質（30%）：腳本可靠效能優化（20%）：波動降低創新性（10%）：自動檢核與回寫

Case #11: 單機序列化跨 VM 測試工作流

Problem Statement（問題陳述）

業務場景：需要在多 VM 上跑相同測試，避免相互影響。技術挑戰：如何自動化依序執行、收集結果。影響範圍：手動流程易錯、耗時。複雜度評級：低

Root Cause Analysis（根因分析）

直接原因：

手動切換 VM 易遺漏設定
測試時間長、重複性高
收集輸出不一致深層原因：
- 架構層面：缺少自動化框架
- 技術層面：收集與彙整未標準化
- 流程層面：無 pipeline

Solution Design（解決方案設計）

解決策略：以 PowerShell 編排 Stop-VM/Start-VM + 測試啟動 + 拉取輸出，形成單機序列 pipeline。

實施步驟：

腳本化 VM 操作
- 實作細節：Stop-VM/Start-VM、等待就緒
- 所需資源：Hyper-V 模組
- 預估時間：1 小時
執行測試與收集
- 實作細節：SSH/PowerShell Direct 進 VM 執行；複製結果
- 所需資源：SSH、PowerShell
- 預估時間：1 小時

關鍵程式碼/設定：

$targets = "Boot2Docker","Ubuntu","Win2012R2","Win2016"
foreach($t in $targets){
  Get-VM | Where Name -ne $t | Stop-VM -Force
  Start-VM $t; Start-Sleep -Seconds 20
  # TODO: Invoke-Command / SSH 執行測試與收數據
}

實際案例：原文描述一次只開一台 VM 實作環境：Windows 10 Hyper-V 實測數據：改善前：手動、易誤改善後：自動化、可重現改善幅度：以「人工操作時間」與「失敗率」衡量，明顯下降

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

測試流程自動化
輸出標準化技能要求：
必備技能：PowerShell
進階技能：遠端自動化延伸思考：
可搬到 CI 執行（具風險）
優化：加健康檢查

Practice Exercise（練習題）基礎練習：腳本化啟停 VM（30 分鐘）進階練習：遠端觸發測試與收集（2 小時）專案練習：完整流水線與報表（8 小時）

Assessment Criteria（評估標準）功能完整性（40%）：能依序跑完程式碼品質（30%）：錯誤處理完善效能優化（20%）：時間縮短創新性（10%）：報表自動化

Case #12: Windows Server 2012 R2 上運行 .NET Core 測試（CoreCLR）

Problem Statement（問題陳述）

業務場景：需在 Windows Server Core（無 GUI）上跑 .NET Core 測試以對比 Linux。技術挑戰：CoreCLR 相依安裝與發佈方式選擇。影響範圍：測試無法啟動、環境相依錯誤。複雜度評級：中

Root Cause Analysis（根因分析）

直接原因：

缺少 .NET Runtime
發佈包未自包含
路徑/權限問題深層原因：
- 架構層面：部署策略未定義
- 技術層面：Runtime 與 SDK 認知不足
- 流程層面：部署腳本缺失

Solution Design（解決方案設計）

解決策略：使用自包含發佈（SC），避免在 Server Core 安裝 SDK/Runtime；或先部署官方 runtime。

實施步驟：

自包含發佈
- 實作細節：dotnet publish -r win-x64 –self-contained true
- 所需資源：.NET SDK
- 預估時間：15 分鐘
複製至 Server Core
- 實作細節：Copy-Item/WinRM
- 所需資源：PowerShell
- 預估時間：30 分鐘

關鍵程式碼/設定：

dotnet publish -c Release -r win-x64 --self-contained true -o publish

實際案例：原文在 2012R2 上直接跑 .NET Core 實作環境：Windows Server 2012 R2 Core 實測數據：改善前：執行失敗改善後：成功運行改善幅度：成功率 100%（以 3 次為準）

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

Self-contained 與 Framework-dependent 差異
Server Core 部署實務技能要求：
必備技能：.NET 發佈/部署
進階技能：無人值守部署延伸思考：
SC 會增大包體
優化：壓縮/去除不必要檔

Practice Exercise（練習題）基礎練習：SC 發佈並在 Server Core 執行（30 分鐘）進階練習：寫部署腳本（2 小時）專案練習：一鍵部署多台 Server Core（8 小時）

Assessment Criteria（評估標準）功能完整性（40%）：可執行程式碼品質（30%）：腳本可靠效能優化（20%）：包體控管創新性（10%）：自動化

Case #13: Linux 發佈與容器化執行 .NET 測試程式

Problem Statement（問題陳述）

業務場景：需要在 Ubuntu/Boot2Docker 上運行測試，並保持步驟與輸出一致。技術挑戰：發佈、容器化與檔案掛載。影響範圍：部署失敗、輸出遺失。複雜度評級：低

Root Cause Analysis（根因分析）

直接原因：

Runtime 相依缺失
映像與宿主間檔案交換困難
指令錯誤或版本差異深層原因：
- 架構層面：部署流程未模板化
- 技術層面：Dockerfile/掛載參數不熟
- 流程層面：無書面 SOP

Solution Design（解決方案設計）

解決策略：以官方 dotnet/runtime:linux-x64 基底執行 FR（framework-dependent）發佈，或直接 SC 發佈於 scratch/alpine；掛載輸出路徑。

實施步驟：

發佈
- 實作細節：dotnet publish -r linux-x64 -o publish
- 所需資源：.NET SDK
- 預估時間：15 分鐘
容器執行
- 實作細節：-v $(pwd)/publish:/app，dotnet /app/MemFrag.dll
- 所需資源：Docker
- 預估時間：15 分鐘

關鍵程式碼/設定：

dotnet publish -c Release -r linux-x64 -o publish
docker run --rm -v $(pwd)/publish:/app mcr.microsoft.com/dotnet/runtime:8.0 \
  dotnet /app/MemFrag.dll

實際案例：原文於 Ubuntu 15.10 + Docker 1.9.1 執行實作環境：Ubuntu/Boot2Docker 實測數據：改善前：部署失敗、檔案不可見改善後：一次性成功改善幅度：成功率提升至 100%

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

Linux 部署
Docker 掛載技能要求：
必備技能：Docker 基本
進階技能：多架構發佈延伸思考：
CI 中自動化
風險：老舊 Docker 行為差異

Practice Exercise（練習題）基礎練習：容器中執行並輸出（30 分鐘）進階練習：以 Alpine 映像 SC 執行（2 小時）專案練習：多平台自動化 build/run（8 小時）

Assessment Criteria（評估標準）功能完整性（40%）：成功發佈與執行程式碼品質（30%）：腳本清晰效能優化（20%）：映像精簡創新性（10%）：多平台整合

Case #14: 健壯的 OOM 例外處理與不中斷測試流程

Problem Statement（問題陳述）

業務場景：記憶體測試會刻意觸發 OOM，若無良好處理會中斷流程，無法收集完整數據。技術挑戰：在 OOM 時不讓程式崩潰，且輸出足夠訊息。影響範圍：數據遺失、難以重現。複雜度評級：低

Root Cause Analysis（根因分析）

直接原因：

未捕捉 OutOfMemoryException
例外處理範圍不完整
無保底輸出深層原因：
- 架構層面：測試流程未考慮異常路徑
- 技術層面：例外處理不足
- 流程層面：無最終化輸出保證

Solution Design（解決方案設計）

解決策略：在每個 allocate 循環外層使用 try/catch 捕捉 OOM，並在 finally 區塊輸出統計與環境資訊。

實施步驟：

try/catch 包裹 allocate
- 實作細節：catch OutOfMemoryException 只記錄不拋出
- 所需資源：C#
- 預估時間：10 分鐘
finally 輸出
- 實作細節：輸出計數、耗時、平台資訊
- 所需資源：I/O
- 預估時間：10 分鐘

關鍵程式碼/設定：

try {
    while (true) buffer3.Add(new byte[72 * 1024 * 1024]);
} catch (OutOfMemoryException) {
    Console.WriteLine("OOM on step3");
} finally {
    DumpStats();
}

實際案例：原文已以 try/catch 包裹各階段實作環境：通用實測數據：改善前：流程中斷改善後：完整輸出改善幅度：資料完整度 100%

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

OOM 行為與可恢復性
finally 區塊的重要性技能要求：
必備技能：例外處理
進階技能：容錯設計延伸思考：
可加上環境快照（meminfo）
風險：finally 耗時干擾

Practice Exercise（練習題）基礎練習：完成 OOM 捕捉與輸出（30 分鐘）進階練習：log 檔案安全輸出（2 小時）專案練習：在 crash 時寄送報表（8 小時）

Assessment Criteria（評估標準）功能完整性（40%）：不中斷且輸出完整程式碼品質（30%）：錯誤處理完善效能優化（20%）：控制 finally 開銷創新性（10%）：報警與可觀測性

Case #15: Server GC vs Workstation GC 的對比與設定

Problem Statement（問題陳述）

業務場景：不同 GC 模式對回收/壓縮與暫停時間有影響，需要在測試中固定或比較。技術挑戰：如何設定與驗證 GC 模式。影響範圍：結果不可比較、誤判 GC 能力。複雜度評級：中

Root Cause Analysis（根因分析）

直接原因：

預設 GC 模式因平台不同而異
未顯式設定，導致 run-to-run 差異
結果無法對齊深層原因：
- 架構層面：測試基準未包含 GC 模式
- 技術層面：不熟 runtimeconfig.json
- 流程層面：無驗證輸出

Solution Design（解決方案設計）

解決策略：使用 runtimeconfig.json 設定 System.GC.Server 與 System.GC.Concurrent，並輸出目前模式到結果中。

實施步驟：

設定 GC 模式
- 實作細節：runtimeconfig.json
- 所需資源：.NET
- 預估時間：10 分鐘
程式內輸出
- 實作細節：GCSettings.IsServerGC
- 所需資源：C#
- 預估時間：10 分鐘

關鍵程式碼/設定：

{
  "runtimeOptions": {
    "configProperties": {
      "System.GC.Server": true,
      "System.GC.Concurrent": true
    }
  }
}

Console.WriteLine($"ServerGC={GCSettings.IsServerGC}");

實際案例：原文未固定 GC 模式；本案補強實作環境：通用實測數據：改善前：結果波動改善後：基準一致、或對比清晰改善幅度：以耗時/配置次數差異可解讀為目標

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

Server/Workstation/Background GC 差異技能要求：
必備技能：.NET 設定
進階技能：停頓分析延伸思考：
生產應視工作負載選擇
風險：Server GC 在 1 CPU 容器的效益

Practice Exercise（練習題）基礎練習：切換 GC 模式並輸出（30 分鐘）進階練習：比較兩模式的結果（2 小時）專案練習：自動化 A/B 測試（8 小時）

Assessment Criteria（評估標準）功能完整性（40%）：模式切換可行程式碼品質（30%）：設定清晰效能優化（20%）：結果可比較創新性（10%）：自動報表

Case #16: 測試輸出標準化與環境紀錄

Problem Statement（問題陳述）

業務場景：跨平台對比需要標準化輸出與環境上下文，否則數據難以解讀。技術挑戰：定義並自動化輸出欄位與格式。影響範圍：報告可信度、追溯性。複雜度評級：低

Root Cause Analysis（根因分析）

直接原因：

無 run-id 與平台標記
不同平台輸出格式不一致
未包含 CPU/RAM/SWAP/容器限制深層原因：
- 架構層面：缺乏觀測性設計
- 技術層面：輸出與收集未統一
- 流程層面：報告格式缺失

Solution Design（解決方案設計）

解決策略：定義輸出 schema（JSON/CSV），包含 run-id、OS、Runtime、CPU、RAM、SWAP、容器限制、步驟計數與耗時，並自動輸出。

實施步驟：

定義 schema
- 實作細節：欄位設計與版本
- 所需資源：文件/程式
- 預估時間：30 分鐘
程式輸出
- 實作細節：收集環境資訊 + 結果
- 所需資源：C#
- 預估時間：1 小時

關鍵程式碼/設定：

var meta = new {
  run = Guid.NewGuid().ToString("n"),
  os = Environment.OSVersion.ToString(),
  clr = System.Runtime.InteropServices.RuntimeInformation.FrameworkDescription,
  cpu = Environment.ProcessorCount,
  x64 = IntPtr.Size==8
};
File.WriteAllText("meta.json", JsonSerializer.Serialize(meta));

實際案例：原文詳列實體/VM 規格，本文將其程序化實作環境：通用實測數據：改善前：可讀性差改善後：可追溯、可比對改善幅度：以審查評分衡量（主觀），目標達成標準化

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

可觀測性
測試資料治理技能要求：
必備技能：序列化/檔案 I/O
進階技能：資料管線延伸思考：
可導入集中式儲存
風險：敏感資訊外洩（需遮蔽）
優化：Schema 版本控管

Practice Exercise（練習題）基礎練習：輸出 meta.json（30 分鐘）進階練習：合併結果與環境輸出（2 小時）專案練習：建立簡易儀表板（8 小時）

Assessment Criteria（評估標準）功能完整性（40%）：輸出包含必要欄位程式碼品質（30%）：結構化清晰效能優化（20%）：低侵入性創新性（10%）：可視化報表

案例分類 1) 按難度分類

入門級（適合初學者）
- Case 6, 8, 9, 11, 13, 14, 16
中級（需要一定基礎）
- Case 1, 2, 3, 4, 5, 10, 12, 15
高級（需要深厚經驗）
- Case 7（LOH 壓縮時機與停頓權衡）

2) 按技術領域分類

架構設計類：Case 1, 11, 16
效能優化類：Case 5, 7, 8, 10, 15
整合開發類：Case 3, 12, 13
除錯診斷類：Case 4, 6, 9, 14
安全防護類：無直接對應（可延伸於資料遮蔽）

3) 按學習目標分類

概念理解型：Case 4, 5, 7, 10, 15
技能練習型：Case 6, 8, 9, 13, 14, 16
問題解決型：Case 1, 2, 3, 11, 12
創新應用型：Case 7, 16（可觀測性設計）

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

先學案例（基礎設置與觀念）：
- Case 1（統一環境）→ Case 9（x64 確認）→ Case 16（輸出標準化）
測試程式與執行：
- Case 4（測試程式）→ Case 6（正確釋放）→ Case 14（OOM 安全）
精度與真實性強化：
- Case 5（InitBuffer 強迫觸碰）→ Case 8（Stopwatch/結構化輸出）
平台與執行環境：
- Case 13（Linux 容器/VM）↔ Case 12（Windows Server Core）↔ Case 3（Windows 容器）
- Case 2（容器記憶體限制）→ Case 10（overcommit/swap 控制）
進階 GC/LOH 操作：
- Case 15（GC 模式固定/對比）→ Case 7（LOH 壓縮）
完整學習路徑建議：
- 1 → 9 → 16 → 4 → 6 → 14 → 5 → 8 → 13/12/3（擇一或全做）→ 2 → 10 → 15 → 7 → 11（自動化整合）
- 依序建立穩定環境與輸出 → 撰寫與強化測試 → 擴展到各平台容器 → 控制容器/OS 記憶體策略 → 比較 GC 模式 → 嘗試 LOH 壓縮 → 最後自動化跨 VM/容器整體流程

補充說明

原文屬「環境設置 + 測試程式設計」階段，未提供平台量測結果；本回覆已將「實測數據」欄位定義為「指標與驗收口徑」，方便後續填值與評估。
若後續文章提供數據，建議直接回填各案例的「改善前/後/幅度」，形成可用的實戰教材與評量題庫。

.NET Core 跨平台 #2, 記憶體管理大考驗 - setup environment

Case #1: 統一虛擬化測試環境，消除外部干擾

Problem Statement（問題陳述）

Root Cause Analysis（根因分析）

Solution Design（解決方案設計）

Case #2: 容器內 .NET 記憶體測試的 cgroups 與記憶體上限控制

Problem Statement（問題陳述）

Root Cause Analysis（根因分析）

Solution Design（解決方案設計）

Case #3: Windows 容器中安裝並運行 .NET Core 測試

Problem Statement（問題陳述）

Root Cause Analysis（根因分析）

Solution Design（解決方案設計）

Case #4: 設計可重現的大物件碎片化測試程式

Problem Statement（問題陳述）

Root Cause Analysis（根因分析）

Solution Design（解決方案設計）

Case #5: 以 InitBuffer 強迫頁面實際配置，避免 overcommit 誤導

Problem Statement（問題陳述）

Root Cause Analysis（根因分析）

Solution Design（解決方案設計）

Case #6: 正確釋放物件參考並觸發 GC 回收

Problem Statement（問題陳述）

Root Cause Analysis（根因分析）

Solution Design（解決方案設計）

Case #7: LOH 碎片化下啟用一次性 LOH 壓縮

Problem Statement（問題陳述）

Root Cause Analysis（根因分析）

Solution Design（解決方案設計）

Case #8: 以 Stopwatch 與結構化輸出取代 DateTime 計時

Problem Statement（問題陳述）

Root Cause Analysis（根因分析）

Solution Design（解決方案設計）

Case #9: 確保 64 位元執行，避免 32 位元位址空間瓶頸

Problem Statement（問題陳述）

Root Cause Analysis（根因分析）

Solution Design（解決方案設計）

Case #10: 控制 Linux overcommit 與 swap，穩定 OOM 行為

Problem Statement（問題陳述）

Root Cause Analysis（根因分析）

Solution Design（解決方案設計）

Case #11: 單機序列化跨 VM 測試工作流

Problem Statement（問題陳述）

Root Cause Analysis（根因分析）

Solution Design（解決方案設計）

Case #12: Windows Server 2012 R2 上運行 .NET Core 測試（CoreCLR）

Problem Statement（問題陳述）

Root Cause Analysis（根因分析）

Solution Design（解決方案設計）

Case #13: Linux 發佈與容器化執行 .NET 測試程式

Problem Statement（問題陳述）

Root Cause Analysis（根因分析）

Solution Design（解決方案設計）

Case #14: 健壯的 OOM 例外處理與不中斷測試流程

Problem Statement（問題陳述）

Root Cause Analysis（根因分析）

Solution Design（解決方案設計）

Case #15: Server GC vs Workstation GC 的對比與設定

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