创建临时集合的最优方式？stackalloc与collection expressions差异解析

常见临时集合创建方式 #

• 直接实例化数组：会增加垃圾回收器（GC）负担

  // 直接创建新数组
  Span<int> array = new int[]{ 1, 2 };
  

• unsafe上下文使用stackalloc：在栈上创建集合，降低GC负载

  // 在栈上创建数组
  unsafe
  {
      Span<int> stack = stackalloc int[2];
      stack[0] = 1;
      stack[1] = 2;
  }
  

• 集合表达式（C#最新版本）：语法简洁的新写法

  Span<int> span = [1, 2];
  

关于集合表达式的底层与性能疑问解答 #

1. 集合表达式和stackalloc是否等效？ #

Visual Studio建议将stackalloc转换为集合表达式，是因为集合表达式是更简洁通用的语法，但二者并非完全等效。C#规范提到，当集合表达式赋值给Span<T>或ReadOnlySpan<T>时，编译器可选择将其转换为stackalloc实现，但这是优化选项而非强制要求。

2. SharpLab查看IL代码不同，是否意味着没转为stackalloc？ #

这取决于编译器版本和具体场景。当前C#编译器处理集合表达式赋值给Span<T>时，会根据元素数量、类型等因素选择不同实现：

• 元素数量较少时，编译器可能直接生成栈上分配代码（逻辑类似stackalloc）；
• 元素数量超过栈可用空间阈值时，会自动切换为堆分配（类似直接实例化数组），避免栈溢出。

手动编写的stackalloc会强制在栈上分配（只要不超栈大小限制），因此IL代码会有差异：集合表达式的IL包含灵活的分支逻辑，而手动stackalloc的IL是直接的栈分配指令。

3. 集合表达式的性能特性，是否会产生垃圾？ #

集合表达式的性能取决于编译器优化：

• 当编译器选择栈分配实现时，性能和stackalloc完全一致，不会产生GC垃圾，所有操作在栈上完成，无需GC回收；
• 当编译器选择堆分配时，性能和直接实例化数组一致，会产生GC垃圾，需后续回收。

编译器会根据场景自动选择最优实现，在性能关键代码中，只要集合元素数量不大（不会触发栈溢出），集合表达式的性能与stackalloc相当，同时兼具语法简洁性。

内容的提问来源于stack exchange，提问作者Roy T.