17370845950

Span在高并发下不触发GC压力，因其是栈上视图、不分配堆内存，仅持指针和长度；避免了byte[]频繁分配导致的Gen0对象洪流，且作用域结束即失效，无引用滞留，GC无需追踪。

和 stackalloc 在高并发下的内存优势">

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

Span 是栈上视图，本身不分配堆内存，只持有指向已有内存的指针 + 长度。高并发场景下大量短生命周期的字节处理（如 HTTP 请求头解析、序列化缓冲区切片），用 Span 替代 byte[] 可避免每请求都 new 一个数组——后者直接变成 GC 第 0 代对象洪流。
关键点在于：Span 不能跨 await 边界，也不能作为字段存储，一旦离开作用域就自动失效，这反而是优势：没有引用滞留，GC 完全不用追踪它。

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

直接写 stackalloc byte[1024] 看似省事，但编译器要求它必须出现在 unsafe 上下文，且不能用于返回值或逃逸到方法外。高并发下常见错误是把它塞进 async 方法体里，结果编译不过：Cannot use stackalloc in async method。
正确做法是立即转成 Span：

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

这样既利用了栈分配的低延迟，又通过 Span 获得类型安全和边界检查（Debug 模式下）。

stackalloc 大小超过 1MB 会触发 StackOverflowException

默认线程栈大小在 Windows 是 1MB（.NET Core / 6+ 默认也是约 1MB）。如果并发线程数多，每个都 stackalloc byte[2048] 看似安全，但叠加局部变量、调用栈深度后极易溢出——尤其在 IIS 或 Kestrel 的长连接场景中，栈空间比想象中紧张。
建议遵循以下原则：

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

Span + stackalloc 组合在 Socket 读写中的典型误用

高频网络服务（如自定义协议网关）常试图用 stackalloc 配合 Socket.ReceiveAsync()，但这是错的：Socket.ReceiveAsync() 要求传入 Memory，而 stackalloc 产生的 Span 无法直接升格为 Memory（因为后者可能被异步回调持有，栈内存已销毁）。
正确路径只有两条：

• 同步收发：用 Socket.Receive(Span)，配合 stackalloc + Span 完全可行
• 异步收发：必须用 ArrayPool.Shared.Rent()，收到后再用 Span 切片解析，最后 Return()

混淆这两者会导致偶发崩溃或数据错乱，而且问题在线上高并发时才暴露，复现困难。