前言
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 的參考逃逸安全范圍、逃逸安全范圍都是當前方法
// 在 ComplexScopedRefExample 的呼叫中它被傳遞給了一個 scoped ref 引數，
// 意味著編譯器在計算生命周期時不需要考慮參考逃逸安全范圍，只需要考慮逃逸安全范圍
// 因此它回傳的值的安全逃逸范圍為當前方法
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 =https://www.cnblogs.com/hez2010/p/> 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 =https://www.cnblogs.com/hez2010/p/> _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 = https://www.cnblogs.com/hez2010/p/value;
}
public StackLinkedListNode(T value, ref StackLinkedListNode next)
{
_value = value;
_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 的改進了，有了這些基礎設施，開發者們將能輕松使用安全的方式來撰寫沒有任何堆記憶體開銷的高性能代碼，盡管這些改進只能直接讓小部分非常關注性能的開發者收益，但是這些改進帶來的將是后續基礎庫代碼質量和性能的整體提升，
如果你擔心這會讓語言的復雜度上升，那也大可不必，因為這些東西大多數人并不會用到，只會影響到小部分的開發者，因此對于大多數人而言，只需要寫著原樣的代碼，享受其他基礎庫作者利用上述設施撰寫好的東西即可，
轉載請註明出處，本文鏈接：https://www.uj5u.com/net/460707.html
標籤：C#