背景

ShenDesk 是一套針對企業設計的即時線上客服與訪客行為追蹤系統，支援 SaaS 與地端部署（On-Premises Deployment）。本系統基於 .NET 構建，核心技術包含高並發 WebSocket 通道、即時訊息處理、訪客追蹤（Visitor Tracking）資料流分析，以及具備擴充性的 Open APIs。

我是 ShenDesk 的作者。這套系統從最初的「開發完成」到如今能穩定支撐真實的商用環境，中間經歷過多次效能瓶頸（Performance Bottleneck）與架構重構（Refactoring）。

正是因為這些真實工程問題的挑戰，驅使我開始深入研究 .NET 的記憶體模型（Memory Model）與高效能程式設計技術。

引言

在高並發與低延遲逐漸成為標配要求的今天，現代 .NET 應用程式已經很難再容忍「不自覺的記憶體配置（Memory Allocation）」。尤其是在大數據處理、檔案解析、網路通訊以及即時系統中，頻繁的陣列複製與字串配置，往往才是效能瓶頸的真正元兇。

我們在開發 ShenDesk 的伺服器端應用（Server Application）時，曾遇到一個典型的問題：
高頻率的 WebSocket 訊息處理與訪客追蹤（Visitor Tracking）資料流解析，在尖峰時段會產生大量短生命週期的物件（Short-lived objects）。這導致 GC 壓力上升，延遲震盪（Latency Jitter）明顯，整體吞吐量（Throughput）也因此受限。

如果繼續沿用傳統的陣列加字串拼接模式，優化的空間非常有限。

這正是 C# 引入 Span<T> 與 Memory<T> 的意義所在。

它們允許我們在不產生額外 Heap Allocation 的前提下，對記憶體進行切片（Slicing）與操作。透過 Stack Allocation 與受控的記憶體參照機制，我們可以：

• 避免不必要的陣列複製
• 減少 GC 觸發頻率
• 降低延遲震盪
• 提高吞吐穩定性

在 ShenDesk 的即時訊息通道與協定解析層中，導入 Span<T> 顯著降低了瞬時配置量，使系統在高並發場景下運行更加平穩。

本文將結合實際工程場景，深入探討：

• Span<T> 與 Memory<T> 的底層原理
• 它們如何避免記憶體配置
• 在 Web API / WebSocket / I/O 處理中如何正確使用
• 以及在真實生產系統中的效能收益

如果你正在構建高效能的 .NET 系統，或者已經遇到 GC 震盪、延遲異常等問題，那麼理解這兩個類型，不再只是「進階技巧」，而是工程開發的必修課。

什麼是 Span？

Span<T> 是一種輕量級的值型別（Value Type），它代表一段連續的記憶體區域。與傳統的陣列操作不同，Span 允許開發者直接存取並操作記憶體中的資料，而無需進行資料複製。

Span 可以指向多種記憶體來源：

• 陣列（Arrays）
• 堆疊記憶體（Stack Memory）
• 原生記憶體（Native/Unmanaged Memory）
• 字串（Strings）

Span 的核心優勢在於它能避免不必要的記憶體配置（Memory Allocation）。傳統的陣列或字串操作通常會建立新的物件並複製資料，而 Span 直接在現有的記憶體上運作，這使得應用程式執行起來更加高效。

// 範例：使用 Span 操作陣列
int[] array = new int[100];
Span<int> span = array.AsSpan();

// 直接修改原始陣列
span[0] = 10;
span.Slice(10, 20).Fill(1); // 對部分區段進行填充（Slicing & Filling）

Span 的重要性

傳統的操作（例如取得子字串或陣列切片）通常會在記憶體中建立新的物件。這些額外的記憶體配置（Allocation）不僅增加了垃圾回收機制（GC）的負擔，更會降低應用程式的效能。

Span 透過建立對現有記憶體的「視圖（View）」而非複製資料來解決這個問題，這帶來了以下優勢：

• 更快的執行速度
• 減少記憶體使用量
• 提升整體效能
• 降低垃圾回收（GC）頻率

Span 特別適用於對於效能要求極致的應用場景，例如：

• Web 伺服器
• 資料解析器（Parsers）
• 即時系統（Real-time Systems）
• 大規模資料處理

Span 的主要特性

Span 提供了多項重要特性，使其成為高效能記憶體處理的理想選擇：

• 非堆積配置（Non-heap Allocation）：Span 本身不透過堆積（Heap）配置記憶體，進而提升效能。
• 切片（Slicing）支援：允許直接操作陣列的部分資料，而無需進行資料複製。
• 型別與記憶體安全：提供安全的存取方式，防止記憶體存取超出範圍（Out of bounds）等問題。
• 減輕 GC 壓力：有效減少垃圾回收機制（Garbage Collector）的工作負擔。
• 大數據處理：在處理大型資料集（Big Data）的場景中表現優異。

// 範例：Span 的切片操作 (Slicing)
byte[] buffer = new byte[1024];
Span<byte> bufferSpan = buffer.AsSpan();

// 處理前 512 位元組
ProcessData(bufferSpan.Slice(0, 512));

// 處理後 512 位元組
ProcessData(bufferSpan.Slice(512));

什麼是 Memory？

Memory<T> 型別與 Span 類似，但它是為了更廣泛的場景（特別是非同步程式設計）而設計。其關鍵區別在於：

• Span 只能用於同步方法（受限於堆疊配置 Stack-only）。
• Memory 可用於非同步（Async）方法，且可以儲存在**欄位（Fields）**中。
• Memory 代表可以存在於**堆積（Heap）**上的記憶體，因此能在非同步操作之間傳遞。
• 雖然 Memory 的存取速度比 Span 稍微慢一點，但它提供了更大的靈活性，同時依然保持優異的效能。

// 範例：在非同步方法中使用 Memory
async Task ProcessDataAsync(Memory<byte> dataMemory)
{
    // 非同步處理資料
    // 在需要時透過 .Span 屬性轉換為 Span 進行操作
    await Task.Run(() => ProcessData(dataMemory.Span));
    
    // 可以將 Memory 儲存起來供後續使用
    _storedMemory = dataMemory;
}

何時使用 Span

在以下情境中，Span 是最佳選擇：

• 同步程式碼中處理陣列、Buffer 或字串。
• 資料解析：例如解析通訊協定（Protocols）、檔案格式等。
• 檔案處理：高效地讀寫大型檔案。
• 大規模資料集：需要極致效能處理時。
• 效能關鍵路徑（Hot Path）：當記憶體優化至關重要時。

// 範例：使用 Span 解析字串
string s = "127.0.0.1:8080";
ReadOnlySpan<char> span = s.AsSpan();

// 尋找冒號位置
int colonPos = span.IndexOf(':');
if (colonPos > 0)
{
    // 透過 Slice 取得子區段，完全不產生新的字串物件
    var ipSpan = span.Slice(0, colonPos);
    var portSpan = span.Slice(colonPos + 1);
    
    // 處理 IP 和連接埠 (Port)
    // 例如：int.Parse(portSpan) 在現代 .NET 中支援直接傳入 Span
}

何時使用 Memory

在以下情境中，應該選擇 Memory<T>：

• 非同步（Async）方法中處理記憶體資料。
• 需要儲存並傳遞記憶體參照（Memory Reference）時。
• 非同步檔案操作：例如背景檔案處理。
• 管道處理（Pipeline Processing）：例如資料流水線。
• 背景處理（Background Tasks）：需要長時間持有資料時。

// 範例：使用 Memory 進行非同步檔案處理
async Task<Memory<byte>> ReadFileAsync(string path)
{
    // 在非同步環境下，byte[] 可以隱式轉換為 Memory<byte>
    byte[] buffer = await File.ReadAllBytesAsync(path);
    return new Memory<byte>(buffer);
}

實際應用情境

Span 與 Memory 已被廣泛應用於各種對效能要求極致的領域：

• 高效能 Web API：ASP.NET Core 內部大量使用 Span 來提升整體效能。
• 檔案處理系統：能高效處理大型檔案（Large Files）。
• 網路應用程式：用於通訊協定解析（Protocol Parsing）與資料封包處理。
• 即時系統（Real-time Systems）：達成低延遲的資料處理。
• 遊戲開發：進行高效的記憶體操作。
• 解析器與序列化器（Parsers & Serializers）：加速資料格式轉換。

例如，ASP.NET Core 在其內部 Pipeline 中大量運用 Span 來優化請求處理效能，特別是在以下方面：

• 要求標頭（Request Headers）解析
• URL 解碼（Decoding）
• JSON 序列化與反序列化（Serialization / Deserialization）
• 回應（Response）寫入

效能優勢

使用 Span 與 Memory 能帶來顯著的效能提升：

• 減少記憶體配置：避免不必要的記憶體配置（Allocation）與資料複製。
• 提升執行速度：直接操作記憶體，減少中間處理步驟。
• 降低 GC 壓力：減少垃圾回收頻率與系統暫停（Pause）時間。
• 高效資源利用：更適合高負載（High-load）的應用程式。

根據測試數據顯示，在某些情境下使用 Span 可以達成：

• 記憶體配置減少 90% 以上
• 執行速度提升 2 至 5 倍
• GC 暫停時間顯著縮短

// 效能對比範例：字串處理
// 傳統方式 - 會產生新的字串物件 (Allocation)
string substring = bigString.Substring(start, length);

// 使用 Span - 完全無額外配置 (Zero-allocation)
ReadOnlySpan<char> span = bigString.AsSpan().Slice(start, length);

結論

高效能並不是某種「炫技」，而是一種工程態度。

Span<T> 與 Memory<T> 本質上解決的，並不單純只是記憶體配置問題，而是幫助我們重新理解資料在系統中的流動方式——資料是否必須複製？是否真的需要堆積配置（Heap Allocation）？GC 壓力是否可以從源頭避免？

當你開始嘗試以「記憶體生命週期（Memory Lifecycle）」與「配置成本（Allocation Cost）」來審視程式碼時，你會發現許多所謂的效能瓶頸，其實只是不自覺的編程習慣所導致。

在 ShenDesk 持續演進的過程中，這種思維轉變帶來的收益，遠遠超過單次的微優化（Micro-optimization）。系統在高並發場景下表現得更加穩定，延遲曲線（Latency Curve）更加平順，資源利用也更加可控。

如果你正在建構針對真實使用者的 .NET 系統，我的建議非常直接：
不要等效能問題爆發之後才去補救，而是盡早理解這些底層能力，並將「避免不必要的配置」作為預設原則。

工程品質，從來不是在系統上線那一刻決定的，而是在每一次撰寫程式碼時的選擇。

結語（Wrapping up）

ShenDesk 仍在持續進化中。

如果你曾經開發或部署過即時聊天系統（Real-time Chat System），我非常希望能聽聽你的經驗——
例如你在生產環境中是如何處理即時更新（Live Updates）、負載平衡（Load Balancing），或是如何應對靈活的部署模式。

歡迎留言交流，讓我們一起交換心得。

如果你感興趣

我目前正在開發 ShenDesk，這是一個專為企業設計的**即時客服（Chat）系統，旨在確保無論是在雲端環境還是你自己的基礎設施（Infrastructure）**上都能穩定運行。

• 🌐 官方網站：https://shendesk.com
• 📘 技術文件：https://docs.shendesk.com

無論你偏好雲端代管（Hosted）還是自我託管（Self-hosting/地端部署），都可以免費試用。

如果你對自建系統、即時通訊技術或「客戶體驗工程（Customer Experience Engineering）」感興趣，非常歡迎提供任何回饋與建議。