深入淺析C# 11 對 ref 和 struct 的改進

2022-04-22 10:00:55

前言

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 關鍵字用來限制逃逸安全範圍：

區域性變數 s	參照逃逸安全範圍	逃逸安全範圍
`Span<int> s`	當前方法	呼叫方法
`scoped Span<int> s`	當前方法	當前方法
`ref Span<int> s`	呼叫方法	呼叫方法
`scoped ref Span<int> s`	當前方法	呼叫方法
`ref scoped Span<int> s`	當前方法	當前方法
`scoped ref scoped Span<int> s`	當前方法	當前方法

其中，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# 中的。

總結

以上就是 C# 11（或之後）對 ref 和 struct 的改進了。有了這些基礎設施，開發者們將能輕鬆使用安全的方式來編寫沒有任何堆記憶體開銷的高效能程式碼。儘管這些改進只能直接讓小部分非常關注效能的開發者收益，但是這些改進帶來的將是後續基礎庫程式碼質量和效能的整體提升。

如果你擔心這會讓語言的複雜度上升，那也大可不必，因為這些東西大多數人並不會用到，只會影響到小部分的開發者。因此對於大多數人而言，只需要寫著原樣的程式碼，享受其他基礎庫作者利用上述設施編寫好的東西即可。

到此這篇關於C# 11 對 ref 和 struct 的改進的文章就介紹到這了,更多相關C# 11 ref 和 struct改進內容請搜尋it145.com以前的文章或繼續瀏覽下面的相關文章希望大家以後多多支援it145.com！