目录

前言背景ref 字段生命周期scopedunscopedref 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
{
    private readonly ref T _field;
    private readonly int _length;
    public Span(ref T value)
    {
        _field = ref value;
        _length = 1;
    }
}

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

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

Span 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 Foo()
{
    int v = 42;
    return new Span(ref v);
}

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

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

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

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

Span Foo(int v)
{
    // 1
    return CreateSpan(ref v);
    // 2
    int local = 42;
    return CreateSpan(ref local);
    // 3
    Span 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
{
    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关键字用来限制逃逸安全范围：

局部变量 s	引用逃逸安全范围	逃逸安全范围
Span s	当前方法	调用方法
scoped Span s	当前方法	当前方法
ref Span s	调用方法	调用方法
scoped ref Span s	当前方法	调用方法
ref scoped Span s	当前方法	当前方法
scoped ref scoped Span s	当前方法	当前方法

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

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

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

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

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

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

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

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

    // 没问题，因为初始化器的逃逸安全范围是调用方法，因为 span2 可以逃逸到调用方法
    Span span2 = default;
    return span2;
    // span3 和 span4 是一样的，因为初始化器的逃逸安全范围是当前方法，加不加 scoped 都没区别
    Span span3 = stackalloc int[42];
    scoped Span 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 Read(Span buffer, out int read)
{
    // .. 
}

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

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

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

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

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

反射

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

实际用例

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

栈上定长列表

struct FrugalList
{
    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
{
    private T _value;
    private ref StackLinkedListNode _next;

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

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

未来计划

高级生命周期

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

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

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

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

总结

以上就是 C# 11（或之后）对 ref和 struct的改进了。有了这些基础设施，开发者们将能轻松使用安全的方式来编写没有任何堆内存开销的高性能代码。尽管这些改进只能直接让小部分非常关注性能的开发者收益，但是这些改进带来的将是后续基础库代码质量和性能的整体提升。

如果你担心这会让语言的复杂度上升，那也大可不必，因为这些东西大多数人并不会用到，只会影响到小部分的开发者。因此对于大多数人而言，只需要写着原样的代码，享受其他基础库作者利用上述设施编写好的东西即可。

到此这篇关于C#11对ref和struct的改进的文章就介绍到这了,更多相关C#11ref和struct改进内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！

关键词： 安全范围 生命周期 局部变量 高级生命