高性能 .NET 开发：Span<T> 与 Memory<T> 内存优化实战

吴长建先生重名了
2 阅读4分钟

在构建高并发、低延迟的 .NET 应用时，开发者经常会遇到一个隐形杀手：垃圾回收（GC）压力。当系统频繁处理大量的小型对象（如字符串切片、字节数组片段）时，堆内存的频繁分配与回收会导致 GC 停顿（Stop-the-world），进而引发系统吞吐量下降和响应延迟波动。

为了解决这一问题，.NET 引入了 Span<T> 和 Memory<T>。这两个类型通过“零拷贝（Zero-copy）”的思想，允许开发者在不创建新对象的情况下，直接操作现有内存的连续片段。本文将深入探讨这两个类型的核心原理、应用场景及其在异步编程中的差异。

传统内存操作的痛点

在传统的 .NET 开发中，如果我们处理一段长字符串或字节数组，并需要提取其中的某个子部分，通常会使用 string.Substring 或 Array.Copy。

string longString = "User_ID:12345_Timestamp:20231027";
// 传统的做法：产生一个新的字符串对象
string userId = longString.Substring(8, 5);

在上述代码中，Substring 方法会在堆上分配一个新的字符串对象。如果这段逻辑位于一个每秒处理万级请求的循环中，就会产生海量的短命对象。这些对象会迅速填满第 0 代（Gen 0）堆，触发频繁的 GC。在高负载环境下，这种内存分配模式是性能优化的重灾区。

Span：栈上的内存视图

Span<T> 是 .NET Core 2.1 引入的一种新型类型，它本质上是一个指向连续内存区域的“视图”。它不仅可以指向堆上的数组，还可以指向栈上的内存（stackalloc）或非托管内存。

其核心优势在于：它不拥有内存，只负责观察内存。

使用 Span<T> 改写上述逻辑：

string longString = "User_ID:12345_Timestamp:20231027";
// 使用 Span 进行切片，不产生新对象
ReadOnlySpan<char> span = longString.AsSpan();
ReadOnlySpan<char> userIdSpan = span.Slice(8, 5);

// 直接读取内容，无需分配新字符串
Console.WriteLine(userIdSpan.ToString());

通过 AsSpan() 和 Slice()，我们仅仅是创建了一个轻量级的结构体，它记录了起始地址和长度，而没有在堆上复制数据。

核心约束：ref struct

理解 Span<T> 的关键在于它的底层定义：它是一个 ref struct。这意味着 Span<T> 只能存在于栈上。由于它被强制限制在栈上，编译器可以确保它不会被装箱（Boxing）到堆中，也不会被存储在类（Class）的字段里。

这种设计虽然带来了极致的性能，但也带来了一个显著的局限性：Span<T> 不能出现在异步方法（async/await）中，也不能作为类的字段。因为异步方法的执行可能会跨越线程，而栈空间是线程私有的，一旦方法返回，栈上的 Span<T> 就会失效，这会导致严重的内存安全问题。

Memory：异步环境的桥梁

为了弥补 Span<T> 在异步编程和堆存储方面的不足，.NET 引入了 Memory<T>。

Memory<T> 的设计初衷就是为了解决 ref struct 的限制。它不是 ref struct，因此可以被存储在堆上，可以作为类的字段，也可以在 async 方法中使用。

在异步流处理中，如果你需要从网络流中读取一段数据并进行异步处理，Memory<T> 是唯一的选择：

public async Task ProcessDataAsync(Memory<byte> data)
{
    // 在异步方法中使用 Memory<T>
    await Task.Delay(10); 
    var slice = data.Slice(0, 10);
    // 处理 slice...
}

虽然 Memory<T> 的性能略逊于 Span<T>（因为它涉及更多的对象管理开销），但它依然比传统的 Array.Copy 高效得多。一个常见的实践模式是：在异步层使用 Memory<T>，当逻辑进入到同步的计算密集型方法时，通过 .Span 属性将其转换为 Span<T> 以获得极致性能。

实战建议与最佳实践

在实际的项目开发中，我们可以遵循以下准则来优化内存使用：

  1. 优先使用 ReadOnlySpan：如果你只需要读取数据而不需要修改，务必使用 ReadOnlySpan<T>。这不仅能明确语义，还能在处理字符串等不可变类型时提供更好的支持。
  2. 结合 ArrayPool 使用：在处理频繁变长的字节缓冲区时，结合 Span<T> 与 ArrayPool<T>.Shared 使用。先从池中租借数组，使用 Span 进行操作，最后归还。这能几乎完全消除堆分配。
  3. 区分使用场景：
    • 同步、高性能计算、局部逻辑 →\rightarrow Span<T>。
    • 异步、跨方法传递、存储在对象中 →\rightarrow Memory<T>。
  4. 避免过度设计：如果你的应用逻辑对延迟不敏感，且数据量极小，传统的 Substring 或 ToArray 可能会使代码更易读。只有在性能分析（Profiling）确认内存分配是瓶颈时，才引入这些高级特性。

小结

Span<T> 与 Memory<T> 的出现，标志着 .NET 从“以对象为中心”向“以内存视图为中心”的编程范式转变。通过合理利用这两个工具，开发者可以在不牺牲代码安全性的前提下，实现接近 C++ 的内存控制能力。掌握这两者的差异与应用边界，是进阶高性能 .NET 开发者的必经之路。

avatar
文章
阅读
粉丝