12306的网站多少钱做的,免费网站建设公司,福田蒙派克6座上蓝牌京牌,小企业网站建设哪找前言C# 11 中即将到来一个可以让重视性能的开发者狂喜的重量级特性#xff0c;这个特性主要是围绕着一个重要底层性能设施 ref 和 struct 的一系列改进。但是这部分的改进涉及的内容较多#xff0c;不一定能在 .NET 7#xff08;C# 11#xff09;做完#xff0c;因此部分内… 前言C# 11 中即将到来一个可以让重视性能的开发者狂喜的重量级特性这个特性主要是围绕着一个重要底层性能设施 ref 和 struct 的一系列改进。但是这部分的改进涉及的内容较多不一定能在 .NET 7C# 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 SpanT {private readonly ref T _field;private readonly int _length;public Span(ref T value){_field ref value;_length 1;} }直观来看这样的特性将允许我们写出上面的代码这段代码中构造了一个 SpanT它持有了对其他 T 对象的引用。当然ref struct 也是可以被 default 来初始化的Spanint 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 引用的值不能被修改} }生命周期这一切看上去都很美好但是真的没有任何问题吗假设我们有下面的代码来使用上面的东西Spanint Foo() {int v 42;return new Spanint(ref v); }v 是一个局部变量在函数返回之后其生命周期就会结束那么上面这段代码就会导致 Spanint 持有的 v 的引用变成无效的。顺带一提上面这段代码是完全合法的因为 C# 之前不支持 ref 字段因此上面的代码是不可能出现逃逸问题的。但是 C# 11 加入了 ref 字段栈上的对象就有可能通过 ref 字段而发生引用逃逸于是代码变得不安全。如果我们有一个 CreateSpan 方法用来创建一个引用的 Span Spanint CreateSpan(ref int v) {// ... }这就衍生出了一系列在以前的 C# 中没问题因为 ref 的生命周期为当前方法但是在 C# 11 中由于可能存在 ref 字段而导致用安全的方式写出的非安全代码Spanint Foo(int v) {// 1return CreateSpan(ref v);// 2int local 42;return CreateSpan(ref local);// 3Spanint 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 SpanT {readonly ref T _field;readonly int _length;public Span(ref T value){// 没问题因为 x 是 thisthis 的逃逸安全范围和 value 的引用逃逸安全范围都是调用方法满足规则 1_field ref value;_length 1;} }于是很自然的就需要在字段和参数上对生命周期进行标注帮助编译器确定对象的逃逸范围。而我们在写代码的时候并不需要记住以上这么多的规则因为有了生命周期标注之后一切都变得显式和直观了。scoped在 C# 11 中引入了 scoped 关键字用来限制逃逸安全范围局部变量 s引用逃逸安全范围逃逸安全范围Spanint s当前方法调用方法scoped Spanint s当前方法当前方法ref Spanint s调用方法调用方法scoped ref Spanint s当前方法调用方法ref scoped Spanint s当前方法当前方法scoped ref scoped Spanint s当前方法当前方法其中scoped ref scoped 是多余的因为它可以被 ref scoped 隐含。而我们只需要知道 scoped 是用来把逃逸范围限制到当前方法的即可是不是非常简单如此一来我们就可以对参数进行逃逸范围生命周期的标注Spanint CreateSpan(scoped ref int v) {// ... }然后之前的代码就变得没问题了因为都是 scoped refSpanint Foo(int v) {// 1return CreateSpan(ref v);// 2int local 42;return CreateSpan(ref local);// 3Spanint span stackalloc int[42];return CreateSpan(ref span[0]); }scoped 同样可以被用在局部变量上Spanint Foo() {// 错误因为 span 不能逃逸当前方法scoped Spanint span1 default;return span1;// 没问题因为初始化器的逃逸安全范围是调用方法因为 span2 可以逃逸到调用方法Spanint span2 default;return span2;// span3 和 span4 是一样的因为初始化器的逃逸安全范围是当前方法加不加 scoped 都没区别Spanint span3 stackalloc int[42];scoped Spanint span4 stackalloc int[42]; }另外struct 的 this 也加上了 scoped ref 的逃逸范围即引用逃逸安全范围为当前方法而逃逸安全范围为调用方法。剩下的就是和 out、in 参数的配合在 C# 11 中out 参数将会默认为 scoped ref而 in 参数仍然保持默认为 refref int Foo(out int r) {r 42;return ref r; // 错误因为 r 的引用逃逸安全范围是当前方法 }这非常有用例如比如下面这个常见的情况Spanbyte Read(Spanbyte buffer, out int read) {// .. }Spanint Use() {var buffer new byte[256];// 如果不修改 out 的引用逃逸安全范围则这会报错因为编译器需要考虑 read 是可以被作为 ref 字段返回的情况// 如果修改 out 的引用逃逸安全范围则就没有问题了因为编译器不需要考虑 read 是可以被作为 ref 字段返回的情况int read;return Read(buffer, out read); }下面给出一些更多的例子Spanint CreateWithoutCapture(scoped ref int value) {// 错误因为 value 的引用逃逸安全范围是当前方法return new Spanint(ref value); }Spanint CreateAndCapture(ref int value) {// 没问题因为 value 的逃逸安全范围被限制为 value 的引用逃逸安全范围这个范围是调用方法return new Spanint(ref value) }Spanint ComplexScopedRefExample(scoped ref Spanint span) {// 没问题因为 span 的逃逸安全范围是调用方法return span;// 没问题因为 refLocal 的引用逃逸安全范围是当前方法、逃逸安全范围是调用方法// 在 ComplexScopedRefExample 的调用中它被传递给了一个 scoped ref 参数// 意味着编译器在计算生命周期时不需要考虑引用逃逸安全范围只需要考虑逃逸安全范围// 因此它返回的值的安全逃逸范围为调用方法Spanint local default;ref Spanint refLocal ref local;return ComplexScopedRefExample(ref refLocal);// 错误因为 stackLocal 的引用逃逸安全范围、逃逸安全范围都是当前方法// 在 ComplexScopedRefExample 的调用中它被传递给了一个 scoped ref 参数// 意味着编译器在计算生命周期时不需要考虑引用逃逸安全范围只需要考虑逃逸安全范围// 因此它返回的值的安全逃逸范围为当前方法Spanint 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 参数上指定 unscopedref int Foo(unscoped out int r) {r 42;return ref r; }不过有关 unscoped 的设计还属于初步阶段不会在 C# 11 中就提供。ref struct 约束从 C# 11 开始ref struct 可以作为泛型约束了因此可以编写如下方法了void FooT(T v) where T : ref struct {// ... }因此SpanT 的功能也被扩展可以声明 SpanSpanT 了比如用在 byte 或者 char 上就可以用来做高性能的字符串处理了。反射有了上面那么多东西反射自然也是要支持的。因此反射 API 也加入了 ref struct 相关的支持。实际用例有了以上基础设施之后我们就可以使用安全代码来造一些高性能轮子了。栈上定长列表struct FrugalListT {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 StackLinkedListNodeT {private T _value;private ref StackLinkedListNodeT _next;public T Value _value;public bool HasNext !Unsafe.IsNullRef(ref _next);public ref StackLinkedListNodeT Next HasNext ? ref _next : throw new InvalidOperationException(No next node.);public StackLinkedListNode(T value){this default;_value value;}public StackLinkedListNode(T value, ref StackLinkedListNodeT next){_value value;_next ref next;} }除了这两个例子之外其他的比如解析器和序列化器等等例如 Utf8JsonReader、Utf8JsonWriter 都可以用到这些东西。未来计划高级生命周期上面的生命周期设计虽然能满足绝大多数使用但是还是不够灵活因此未来有可能在此基础上扩展引入高级生命周期标注。例如void M(scopeda ref MyStruct s, scopedb Spanint span) where b a {s.Span span; }上面的方法给参数 s 和 span 分别声明了两个生命周期 a 和 b并约束 b 的生命周期不小于 a因此在这个方法里span 可以安全地被赋值给 s.Span。这个虽然不会被包含在 C# 11 中但是如果以后开发者对相关的需求增长是有可能被后续加入到 C# 中的。总结以上就是 C# 11或之后对 ref 和 struct 的改进了。有了这些基础设施开发者们将能轻松使用安全的方式来编写没有任何堆内存开销的高性能代码。尽管这些改进只能直接让小部分非常关注性能的开发者收益但是这些改进带来的将是后续基础库代码质量和性能的整体提升。如果你担心这会让语言的复杂度上升那也大可不必因为这些东西大多数人并不会用到只会影响到小部分的开发者。因此对于大多数人而言只需要写着原样的代码享受其他基础库作者利用上述设施编写好的东西即可。