Span<T>如何在.NET垃圾回收机制中存活？

• Span确实不持有托管数组的引用，也不会固定内存
  你的初始判断是对的：Span从数组创建时，不会像fixed那样固定底层数组的物理内存，也没有在底层隐藏持有对数组的托管引用——所有官方文档的描述是准确的。它的结构就是地址、长度、类型信息的组合，但这里的地址是运行时临时的逻辑地址，而非固定不变的物理地址。

• 靠ref struct的生命周期约束保证GC安全
  Span是C#中的ref struct（引用类结构体），编译器和运行时对它施加了极其严格的生命周期规则：

  • 只能在栈上分配，永远无法进入托管堆（不能被装箱、不能作为类的字段、不能存入集合等）
  • 生命周期被编译器严格追踪，必须保证Span存活的时间内，它引用的托管数组始终处于GC的可达状态——也就是说，只要Span还在栈上有效，编译器会确保原数组不会被GC回收，自然不会出现地址失效的问题。
  • 禁止在异步方法、lambda捕获等场景中使用，避免生命周期脱离栈帧控制。

• GetPinnableReference()的作用是应对特殊场景
  Span.GetPinnableReference()并不是为了弥补“Span不固定内存”的缺陷，而是为了在需要与非托管代码交互的场景下，提供一个可以配合fixed关键字固定的引用。这是特殊的扩展用法，不是Span常规使用时必须依赖的机制——常规的托管代码中使用Span，完全不需要固定内存，靠生命周期约束就足够安全。

• 关于“生命周期跨越多次内存分配”的误解
  Span的生命周期被严格限制在当前栈帧范围内，无法长期存活。你所说的“跨越无数次内存分配和对象遗忘”的情况，实际上是不可能出现的——一旦Span所在的栈帧执行完毕（比如方法返回），Span就会被销毁，不存在持续持有失效地址的问题。

内容的提问来源于stack exchange，提问作者Bananach