c# Span 和 stackalloc 在高并发下的内存优势

来源：这里教程网时间：2026-02-21 17:37:01 作者：

Span 为什么在高并发下不触发 GC 压力

Span<t></t>

是栈上视图，本身不分配堆内存，只持有指向已有内存的指针 + 长度。高并发场景下大量短生命周期的字节处理（如 HTTP 请求头解析、序列化缓冲区切片），用

Span<byte></byte>

替代

byte[]

可避免每请求都 new 一个数组——后者直接变成 GC 第 0 代对象洪流。
关键点在于：

Span<t></t>

不能跨 await 边界，也不能作为字段存储，一旦离开作用域就自动失效，这反而是优势：没有引用滞留，GC 完全不用追踪它。

stackalloc 在循环和高并发中必须配合 fixed 或 Span 使用

直接写

stackalloc byte[1024]

看似省事，但编译器要求它必须出现在 unsafe 上下文，且不能用于返回值或逃逸到方法外。高并发下常见错误是把它塞进 async 方法体里，结果编译不过：

Cannot use stackalloc in async method

。
正确做法是立即转成

Span<t></t>

：

unsafe
{
    byte* ptr = stackalloc byte[1024];
    Span<byte> buffer = new Span<byte>(ptr, 1024);
    // 后续所有操作基于 buffer，安全且零分配
}

这样既利用了栈分配的低延迟，又通过

Span<t></t>

获得类型安全和边界检查（Debug 模式下）。

stackalloc 大小超过 1MB 会触发 StackOverflowException

默认线程栈大小在 Windows 是 1MB（.NET Core / 6+ 默认也是约 1MB）。如果并发线程数多，每个都

stackalloc byte[2048]

看似安全，但叠加局部变量、调用栈深度后极易溢出——尤其在 IIS 或 Kestrel 的长连接场景中，栈空间比想象中紧张。
建议遵循以下原则：

单次
stackalloc
不超过 8KB，更稳妥是 ≤ 4KB 对不确定长度的数据（如用户上传的 JSON body），绝不用
stackalloc
，改用
ArrayPool<byte>.Shared.Rent()</byte>
用
Span<t>.TryCopyTo()</t>
做安全回退，避免因容量不足导致逻辑分支爆炸