深入浅析C# 11 对 ref 和 struct 的改进

前言

C# 11 中即将到来一个可以让重视性能的开发者狂喜的重量级特性，这个特性主要是围绕着一个重要底层性能设施 ref 和 struct 的一系列改进。

但是这部分的改进涉及的内容较多，不一定能在 .NET 7（C# 11）做完，因此部分内容推迟到 C# 12 也是有可能的。当然，还是很有希望能在 C# 11 的时间点就看到完全体的。

本文仅仅就这一个特性进行介绍，因为 C# 11 除了本特性之外，还有很多其他的改进，一篇文章根本说不完，其他那些我们就等到 .NET 7 快正式发布的时候再说吧。

背景

C# 自 7.0 版本引入了新的 ref struct 用来表示不可被装箱的栈上对象，但是当时局限性很大，甚至无法被用于泛型约束，也无法作为 struct 的字段。在 C# 11 中，由于特性 ref 字段的推动，需要允许类型持有其它值类型的引用，这方面的东西终于有了大幅度进展。

这些设施旨在允许开发者使用安全的代码编写高性能代码，而无需面对不安全的指针。接下来我就来对 C# 11 甚至 12 在此方面的即将到来的改进进行介绍。

ref 字段

C# 以前是不能在类型中持有对其它值类型的引用的，但是在 C# 11 中，这将变得可能。从 C# 11 开始，将允许 ref struct 定义 ref 字段。

readonly ref struct Span<T>
{
   private readonly ref T _field;
   private readonly int _length;
   public Span(ref T value)
   {
       _field = ref value;
       _length = 1;
   }
}

直观来看，这样的特性将允许我们写出上面的代码，这段代码中构造了一个 Span<T>，它持有了对其他 T 对象的引用。

当然，ref struct 也是可以被 default 来初始化的：

Span<int> span = default;

但这样 _field 就会是个空引用，不过我们可以通过 Unsafe.IsNullRef 方法来进行检查：

if (Unsafe.IsNullRef(ref _field))
{
   throw new NullReferenceException(...);
}

另外，ref字段的可修改性也是一个非常重要的事情，因此引入了：

• readonly ref：一个对对象的只读引用，这个引用本身不能在构造方法或 init 方法之外被修改

• ref readonly：一个对只读对象的引用，这个引用指向的对象不能在构造方法或 init 方法之外被修改

• readonly ref readonly：一个对只读对象的只读引用，是上述两种的组合

例如：

ref struct Foo
{
   ref readonly int f1;
   readonly ref int f2;
   readonly ref readonly int f3;

void Bar(int[] array)
   {
       f1 = ref array[0];  // 没问题
       f1 = array[0];      // 错误，因为 f1 引用的值不能被修改
       f2 = ref array[0];  // 错误，因为 f2 本身不能被修改
       f2 = array[0];      // 没问题
       f3 = ref array[0];  // 错误：因为 f3 本身不能被修改
       f3 = array[0];      // 错误：因为 f3 引用的值不能被修改
   }
}

生命周期

这一切看上去都很美好，但是真的没有任何问题吗？

假设我们有下面的代码来使用上面的东西：

Span<int> Foo()
{
   int v = 42;
   return new Span<int>(ref v);
}

v 是一个局部变量，在函数返回之后其生命周期就会结束，那么上面这段代码就会导致 Span<int> 持有的 v 的引用变成无效的。顺带一提，上面这段代码是完全合法的，因为 C# 之前不支持 ref 字段，因此上面的代码是不可能出现逃逸问题的。但是 C# 11 加入了 ref 字段，栈上的对象就有可能通过 ref 字段而发生引用逃逸，于是代码变得不安全。

如果我们有一个 CreateSpan 方法用来创建一个引用的 Span ：

Span<int> CreateSpan(ref int v)
{
    // ...
}

这就衍生出了一系列在以前的 C# 中没问题（因为 ref 的生命周期为当前方法），但是在 C# 11 中由于可能存在 ref 字段而导致用安全的方式写出的非安全代码：

Span<int> Foo(int v)
{
   // 1
   return CreateSpan(ref v);
   // 2
   int local = 42;
   return CreateSpan(ref local);
   // 3
   Span<int> span = stackalloc int[42];
   return CreateSpan(ref span[0]);
}

因此，在 C# 11 中则不得不引入破坏性更改，不允许上述代码通过编译。但这并没有完全解决问题。

为了解决逃逸问题， C# 11 制定了引用逃逸安全规则。对于一个在 e 中的字段 f：

• 如果 f 是个 ref 字段，并且 e是this，则 f 在它被包围的方法中是引用逃逸安全的

• 否则如果 f 是个 ref 字段，则 f 的引用逃逸安全范围和 e 的逃逸安全范围相同

• 否则如果 e 是一个引用类型，则 f 的引用逃逸安全范围是调用它的方法

• 否则 f 的引用逃逸安全范围和 e 相同

• 由于 C# 中的方法是可以返回引用的，因此根据上面的规则，一个 ref struct 中的方法将不能返回一个对非 ref 字段的引用：

ref struct Foo
{
   private ref int _f1;
   private int f2;

public ref int P1 => ref _f1; // 没问题
   public ref int P2 => ref _f2; // 错误，因为违反了第四条规则
}

除了引用逃逸安全规则之外，同样还有对 ref 赋值的规则：

• 对于 x.e1 = ref e2， 其中 x 是在调用方法中逃逸安全的，那么 e2 必须在调用方法中是引用逃逸安全的

• 对于 e1 = ref e2，其中 e1 是个局部变量，那么 e2 的引用逃逸安全范围必须至少和 e1 的引用逃逸安全范围一样大

于是， 根据上述规则，下面的代码是没问题的：

readonly ref struct Span<T>
{
   readonly ref T _field;
   readonly int _length;

public Span(ref T value)
   {
       // 没问题，因为 x 是 this，this 的逃逸安全范围和 value 的引用逃逸安全范围都是调用方法，满足规则 1
       _field = ref value;
       _length = 1;
   }
}

于是很自然的，就需要在字段和参数上对生命周期进行标注，帮助编译器确定对象的逃逸范围。

而我们在写代码的时候，并不需要记住以上这么多的规则，因为有了生命周期标注之后一切都变得显式和直观了。

scoped

在 C# 11 中，引入了 scoped 关键字用来限制逃逸安全范围：

其中，scoped ref scoped 是多余的，因为它可以被 ref scoped 隐含。而我们只需要知道 scoped 是用来把逃逸范围限制到当前方法的即可，是不是非常简单？

如此一来，我们就可以对参数进行逃逸范围（生命周期）的标注：

Span<int> CreateSpan(scoped ref int v)
{
   // ...
}

然后，之前的代码就变得没问题了，因为都是 scoped ref：

Span<int> Foo(int v)
{
   // 1
   return CreateSpan(ref v);

// 2
   int local = 42;
   return CreateSpan(ref local);
   // 3
   Span<int> span = stackalloc int[42];
   return CreateSpan(ref span[0]);
}

scoped 同样可以被用在局部变量上：

Span<int> Foo()
{
   // 错误，因为 span 不能逃逸当前方法
   scoped Span<int> span1 = default;
   return span1;

// 没问题，因为初始化器的逃逸安全范围是调用方法，因为 span2 可以逃逸到调用方法
   Span<int> span2 = default;
   return span2;
   // span3 和 span4 是一样的，因为初始化器的逃逸安全范围是当前方法，加不加 scoped 都没区别
   Span<int> span3 = stackalloc int[42];
   scoped Span<int> span4 = stackalloc int[42];
}

另外，struct 的 this 也加上了 scoped ref 的逃逸范围，即引用逃逸安全范围为当前方法，而逃逸安全范围为调用方法。

剩下的就是和 out、in 参数的配合，在 C# 11 中，out 参数将会默认为 scoped ref，而 in 参数仍然保持默认为 ref：

ref int Foo(out int r)
{
   r = 42;
   return ref r; // 错误，因为 r 的引用逃逸安全范围是当前方法
}

这非常有用，例如比如下面这个常见的情况：

Span<byte> Read(Span<byte> buffer, out int read)
{
   // ..
}

Span<int> Use()
   var buffer = new byte[256];
   // 如果不修改 out 的引用逃逸安全范围，则这会报错，因为编译器需要考虑 read 是可以被作为 ref 字段返回的情况
   // 如果修改 out 的引用逃逸安全范围，则就没有问题了，因为编译器不需要考虑 read 是可以被作为 ref 字段返回的情况
   int read;
   return Read(buffer, out read);

下面给出一些更多的例子：

Span<int> CreateWithoutCapture(scoped ref int value)
{
   // 错误，因为 value 的引用逃逸安全范围是当前方法
   return new Span<int>(ref value);
}

Span<int> CreateAndCapture(ref int value)
   // 没问题，因为 value 的逃逸安全范围被限制为 value 的引用逃逸安全范围，这个范围是调用方法
   return new Span<int>(ref value)
Span<int> ComplexScopedRefExample(scoped ref Span<int> span)
   // 没问题，因为 span 的逃逸安全范围是调用方法
   return span;
   // 没问题，因为 refLocal 的引用逃逸安全范围是当前方法、逃逸安全范围是调用方法
   // 在 ComplexScopedRefExample 的调用中它被传递给了一个 scoped ref 参数，
   // 意味着编译器在计算生命周期时不需要考虑引用逃逸安全范围，只需要考虑逃逸安全范围
   // 因此它返回的值的安全逃逸范围为调用方法
   Span<int> local = default;
   ref Span<int> refLocal = ref local;
   return ComplexScopedRefExample(ref refLocal);
   // 错误，因为 stackLocal 的引用逃逸安全范围、逃逸安全范围都是当前方法
   // 因此它返回的值的安全逃逸范围为当前方法
   Span<int> stackLocal = stackalloc int[42];
   return ComplexScopedRefExample(ref stackLocal);

unscoped

上述的设计中，仍然有个问题没有被解决：

struct S
{
   int _field;

// 错误，因为 this 的引用逃逸安全范围是当前方法
   public ref int Prop => ref _field;
}

因此引入一个 unscoped，允许扩展逃逸范围到调用方法上，于是，上面的方法可以改写为：

struct S
{
   private int _field;
   // 没问题，引用逃逸安全范围被扩展到了调用方法
   public unscoped ref int Prop => ref _field;
}

这个 unscoped 也可以直接放到 struct 上：

unscoped struct S
{
   private int _field;
   public unscoped ref int Prop => ref _field;
}

同理，嵌套的 struct 也没有问题：

unscoped struct Child
{
   int _value;
   public ref int Value => ref _value;
}

unscoped struct Container
{
   Child _child;
   public ref int Value => ref _child.Value;
}

此外，如果需要恢复以前的 out 逃逸范围的话，也可以在 out 参数上指定 unscoped：

ref int Foo(unscoped out int r)
{
   r = 42;
   return ref r;
}

不过有关 unscoped 的设计还属于初步阶段，不会在 C# 11 中就提供。

ref struct 约束

从 C# 11 开始，ref struct 可以作为泛型约束了，因此可以编写如下方法了：

void Foo<T>(T v) where T : ref struct
{
   // ...
}

因此，Span<T> 的功能也被扩展，可以声明 Span<Span<T>> 了，比如用在 byte 或者 char 上，就可以用来做高性能的字符串处理了。

反射

有了上面那么多东西，反射自然也是要支持的。因此，反射 API 也加入了 ref struct 相关的支持。

实际用例

有了以上基础设施之后，我们就可以使用安全代码来造一些高性能轮子了。

栈上定长列表

struct FrugalList<T>
{
   private T _item0;
   private T _item1;
   private T _item2;

public readonly int Count = 3;
   public unscoped ref T this[int index] => index switch
   {
       0 => ref _item1,
       1 => ref _item2,
       2 => ref _item3,
       _ => throw new OutOfRangeException("Out of range.")
   };
}

栈上链表

ref struct StackLinkedListNode<T>
{
   private T _value;
   private ref StackLinkedListNode<T> _next;

public T Value => _value;
   public bool HasNext => !Unsafe.IsNullRef(ref _next);
   public ref StackLinkedListNode<T> Next => HasNext ? ref _next : throw new InvalidOperationException("No next node.");
   public StackLinkedListNode(T value)
   {
       this = default;
       _value = value;
   }
   public StackLinkedListNode(T value, ref StackLinkedListNode<T> next)
       _next = ref next;
}

除了这两个例子之外，其他的比如解析器和序列化器等等，例如 Utf8JsonReader、Utf8JsonWriter 都可以用到这些东西。

未来计划

高级生命周期

上面的生命周期设计虽然能满足绝大多数使用，但是还是不够灵活，因此未来有可能在此基础上扩展，引入高级生命周期标注。例如：

void M(scoped<'a> ref MyStruct s, scoped<'b> Span<int> span) where 'b >= 'a
{
   s.Span = span;
}

上面的方法给参数 s 和 span 分别声明了两个生命周期 'a 和 'b，并约束 'b 的生命周期不小于 'a，因此在这个方法里，span 可以安全地被赋值给 s.Span。

这个虽然不会被包含在 C# 11 中，但是如果以后开发者对相关的需求增长，是有可能被后续加入到 C# 中的。

来源：https://www.cnblogs.com/hez2010/p/ref-struct-improvements-in-csharp-11.html