C# stackalloc与数组的性能对比 - 临时小数组的最佳选择

stackalloc配合Span是处理临时小数组最高效方案；它在栈分配、免GC、缓存友好，适合≤128字节且生命周期短的场景，但需unsafe上下文且不可逃逸。

在C#中处理临时小数组时，stackalloc 和常规堆数组（如 new int[10]）各有优劣。选择哪个更高效，取决于使用场景、数组大小和生命周期。下面我们从性能角度分析两者的差异，并给出实际建议。

内存分配位置与GC影响

stackalloc 在栈上分配内存，不经过垃圾回收器（GC），释放由方法调用结束自动完成，几乎没有额外开销。

• 堆数组通过 new[] 分配，内存位于托管堆，会增加GC压力，尤其是频繁创建的小数组。
• 栈分配适合生命周期短、作用域明确的场景，避免不必要的GC暂停。

性能实测对比（小数组）

以创建长度为8~32的整型数组为例：

• stackalloc：分配时间几乎为零，访问速度更快（局部性好，缓存友好）。
• 堆数组：即使很小，也会触发堆分配，CLR需记录对象头、同步块等元数据，带来固定开销。

在高频率循环中使用临时数组时，stackalloc 可显著减少分配次数，提升吞吐量。

使用限制与安全考虑

stackalloc 并非万能，有几点需要注意：

蚂蚁PPT

AI在线智能生成PPT

113

查看详情

• 只能用于 unsafe 上下文或允许栈分配的表达式（C# 7.3+ 放宽了部分限制）。
• 分配大小必须是编译时常量或受控表达式，避免栈溢出（例如不能分配几KB以上）。
• 返回或逃逸栈指针是危险操作，需配合 red">Span<T> 安全封装使用。

推荐写法：

Span<int> buffer = stackalloc int[16];

这样既安全又能享受栈分配优势。

实际建议：何时用哪个？

• 临时缓冲区（如格式化字符串、简单计算），长度小于 128 字节 → 优先 stackalloc + Span。
• 数组需跨方法传递、生命周期较长 → 使用堆数组或 ArrayPool 共享池。
• 不确定大小或可能较大（> 1KB）→ 避免 stackalloc，改用 ArrayPool<T>.Shared。

基本上就这些。对于临时小数组，stackalloc 配合 Span 是目前最轻量、高效的方案，合理使用可明显降低内存负载，提升性能。

以上就是C# stackalloc与数组的性能对比 - 临时小数组的最佳选择的详细内容，更多请关注php中文网其它相关文章！