前言#

C# 从 7 版本开始一直到如今的 9 版本&＃xff0c;加入了非常多的特性&＃xff0c;其中不乏改善性能、增加程序健壮性和代码简洁性、可读性的改进&＃xff0c;这里我整理一些使用新版 C# 的时候个人推荐的写法&＃xff0c;可能不适用于所有的人&＃xff0c;但是还是希望对你们有所帮助。

注意&＃xff1a;本指南适用于 .NET 5 或以上版本。

使用 ref struct 做到 0 GC#

C# 7 开始引入了一种叫做 ref struct 的结构&＃xff0c;这种结构本质是 struct &＃xff0c;结构存储在栈内存。但是与 struct 不同的是&＃xff0c;该结构不允许实现任何接口&＃xff0c;并由编译器保证该结构永远不会被装箱&＃xff0c;因此不会给 GC 带来任何的压力。相对的&＃xff0c;使用中就会有不能逃逸出栈的强制限制。

Span 就是利用 ref struct 的产物&＃xff0c;成功的封装出了安全且高性能的内存访问操作&＃xff0c;且可在大多数情况下代替指针而不损失任何的性能。

Copyref struct MyStruct{ public int Value { get; set; }} class RefStructGuide{ static void Test() { MyStruct x &＃61; new MyStruct(); x.Value &＃61; 100; Foo(x); // ok Bar(x); // error, x cannot be boxed } static void Foo(MyStruct x) { } static void Bar(object x) { }}

使用 stackalloc 在栈上分配连续内存#

对于部分性能敏感却需要使用少量的连续内存的情况&＃xff0c;不必使用数组&＃xff0c;而可以通过 stackalloc 直接在栈上分配内存&＃xff0c;并使用 Span 来安全的访问&＃xff0c;同样的&＃xff0c;这么做可以做到 0 GC 压力。

stackalloc 允许任何的值类型结构&＃xff0c;但是要注意&＃xff0c;Span 目前不支持 ref struct 作为泛型参数&＃xff0c;因此在使用 ref struct 时需要直接使用指针。

Copyref struct MyStruct{ public int Value { get; set; }}class AllocGuide{ static unsafe void RefStructAlloc() { MyStruct* x &＃61; stackalloc MyStruct[10]; for (int i &＃61; 0; i <10; i&＃43;&＃43;) { *(x &＃43; i) &＃61; new MyStruct { Value &＃61; i }; } } static void StructAlloc() { Span x &＃61; stackalloc int[10]; for (int i &＃61; 0; i

使用 Span 操作连续内存#

C# 7 开始引入了 Span&＃xff0c;它封装了一种安全且高性能的内存访问操作方法&＃xff0c;可用于在大多数情况下代替指针操作。

Copystatic void SpanTest(){ Span x &＃61; stackalloc int[10]; for (int i &＃61; 0; i

性能敏感时对于频繁调用的函数使用 SkipLocalsInit#

C# 为了确保代码的安全会将所有的局部变量在声明时就进行初始化&＃xff0c;无论是否必要。一般情况下这对性能并没有太大影响&＃xff0c;但是如果你的函数在操作很多栈上分配的内存&＃xff0c;并且该函数还是被频繁调用的&＃xff0c;那么这一消耗的副作用将会被放大变成不可忽略的损失。

因此你可以使用 SkipLocalsInit 这一特性禁用自动初始化局部变量的行为。

Copy[SkipLocalsInit]unsafe static void Main(){ Guid g; Console.WriteLine(*&g);}

上述代码将输出不可预期的结果&＃xff0c;因为 g 并没有被初始化为 0。另外&＃xff0c;访问未初始化的变量需要在 unsafe 上下文中使用指针进行访问。

使用函数指针代替 Marshal 进行互操作#

C# 9 带来了函数指针功能&＃xff0c;该特性支持 managed 和 unmanaged 的函数&＃xff0c;在进行 native interop 时&＃xff0c;使用函数指针将能显著改善性能。

例如&＃xff0c;你有如下 C&＃43;&＃43; 代码&＃xff1a;

Copy#define UNICODE#define WIN32#include extern "C" __declspec(dllexport) char* __cdecl InvokeFun(char* (*foo)(int)) { return foo(5);}

并且你编写了如下 C# 代码进行互操作&＃xff1a;

Copy[DllImport("./Test.dll")]static extern string InvokeFun(delegate* unmanaged[Cdecl] fun);[UnmanagedCallersOnly(CallConvs &＃61; new[] { typeof(CallConvCdecl) })]public static IntPtr Foo(int x){ var str &＃61; Enumerable.Repeat("x", x).Aggregate((a, b) &＃61;> $"{a}{b}"); return Marshal.StringToHGlobalAnsi(str);}static void Main(string[] args){ var callback &＃61; (delegate* unmanaged[Cdecl])(delegate*)&Foo; Console.WriteLine(InvokeFun(callback));}

上述代码中&＃xff0c;首先 C# 将自己的 Foo 方法作为函数指针传给了 C&＃43;&＃43; 的 InvokeFun 函数&＃xff0c;然后 C&＃43;&＃43; 用参数 5 调用该函数并返回其返回值到 C# 的调用方。

注意到上述代码还用了 UnmanagedCallersOnly 这一特性&＃xff0c;这样可以告诉编译器该方法只会从 unmanaged 的代码被调用&＃xff0c;因此编译器可以做一些额外的优化。

使用函数指针产生的 IL 指令非常高效&＃xff1a;

Copyldftn native int Test.Program::Foo(int32)stloc.0ldloc.0call string Test.Program::InvokeFun(method native int *(int32))

除了 unmanaged 的情况外&＃xff0c;managed 函数也是可以使用函数指针的&＃xff1a;

Copystatic void Foo(int v) { }unsafe static void Main(string[] args){ delegate* managed fun &＃61; &Foo; fun(4);}

产生的代码相对于原本的 Delegate 来说更加高效&＃xff1a;

Copyldftn void Test.Program::Foo(int32)stloc.0ldc.i4.4ldloc.0calli void(int32)

使用模式匹配#

有了if-else、as和强制类型转换&＃xff0c;为什么要使用模式匹配呢?有三方面原因&＃xff1a;性能、鲁棒性和可读性。

为什么说性能也是一个原因呢?因为 C# 编译器会根据你的模式编译出最优的匹配路径。

考虑一下以下代码(代码 1)&＃xff1a;

Copyint Match(int v){ if (v > 3) { return 5; } if (v <3) { if (v > 1) { return 6; } if (v > -5) { return 7; } else { return 8; } } return 9;}

如果改用模式匹配&＃xff0c;配合 switch 表达式写法则变成(代码 2)&＃xff1a;

Copyint Match(int v){ return v switch { > 3 &＃61;> 5, <3 and > 1 &＃61;> 6, <3 and > -5 &＃61;> 7, <3 &＃61;> 8, _ &＃61;> 9 };}

以上代码会被编译器编译为&＃xff1a;

Copyint Match(int v){ if (v > 1) { if (v <&＃61; 3) { if (v <3) { return 6; } return 9; } return 5; } if (v > -5) { return 7; } return 8;}

我们计算一下平均比较次数&＃xff1a;

代码56789总数平均代码 113442142.8代码 223223122.4

可以看到使用模式匹配时&＃xff0c;编译器选择了更优的比较方案&＃xff0c;你在编写的时候无需考虑如何组织判断语句&＃xff0c;心智负担降低&＃xff0c;并且代码 2 可读性和简洁程度显然比代码 1 更好&＃xff0c;有哪些条件分支一目了然。

甚至遇到类似以下的情况时&＃xff1a;

Copyint Match(int v){ return v switch { 1 &＃61;> 5, 2 &＃61;> 6, 3 &＃61;> 7, 4 &＃61;> 8, _ &＃61;> 9 };}

编译器会直接将代码从条件判断语句编译成 switch 语句&＃xff1a;

Copyint Match(int v){ switch (v) { case 1: return 5; case 2: return 6; case 3: return 7; case 4: return 8; default: return 9; }}

如此一来所有的判断都不需要比较(因为 switch 可根据 HashCode 直接跳转)。

编译器非常智能地为你选择了最佳的方案。

那鲁棒性从何谈起呢?假设你漏掉了一个分支&＃xff1a;

Copyint v &＃61; 5;var x &＃61; v switch{ > 3 &＃61;> 1, <3 &＃61;> 2};

此时编译的话&＃xff0c;编译器就会警告你漏掉了 v 可能为 3 的情况&＃xff0c;帮助减少程序出错的可能性。

最后一点&＃xff0c;可读性。

假设你现在有这样的东西&＃xff1a;

Copyabstract class Entry { }class UserEntry : Entry{ public int UserId { get; set; }}class DataEntry : Entry{ public int DataId { get; set; }}class EventEntry : Entry{ public int EventId { get; set; } // 如果 CanRead 为 false 则查询的时候直接返回空字符串 public bool CanRead { get; set; }}

现在有接收类型为 Entry 的参数的一个函数&＃xff0c;该函数根据不同类型的 Entry 去数据库查询对应的 Content&＃xff0c;那么只需要写&＃xff1a;

Copystring QueryMessage(Entry entry){ return entry switch { UserEntry u &＃61;> dbContext1.User.FirstOrDefault(i &＃61;> i.Id &＃61;&＃61; u.UserId).Content, DataEntry d &＃61;> dbContext1.Data.FirstOrDefault(i &＃61;> i.Id &＃61;&＃61; d.DataId).Content, EventEntry { EventId: var eventId, CanRead: true } &＃61;> dbContext1.Event.FirstOrDefault(i &＃61;> i.Id &＃61;&＃61; eventId).Content, EventEntry { CanRead: false } &＃61;> "", _ &＃61;> throw new InvalidArgumentException("无效的参数") };}

更进一步&＃xff0c;假如 Entry.Id 分布在了数据库 1 和 2 中&＃xff0c;如果在数据库 1 当中找不到则需要去数据库 2 进行查询&＃xff0c;如果 2 也找不到才返回空字符串&＃xff0c;由于 C# 的模式匹配支持递归模式&＃xff0c;因此只需要这样写&＃xff1a;

Copystring QueryMessage(Entry entry){ return entry switch { UserEntry u &＃61;> dbContext1.User.FirstOrDefault(i &＃61;> i.Id &＃61;&＃61; u.UserId) switch { null &＃61;> dbContext2.User.FirstOrDefault(i &＃61;> i.Id &＃61;&＃61; u.UserId)?.Content ?? "", var found &＃61;> found.Content }, DataEntry d &＃61;> dbContext1.Data.FirstOrDefault(i &＃61;> i.Id &＃61;&＃61; d.DataId) switch { null &＃61;> dbContext2.Data.FirstOrDefault(i &＃61;> i.Id &＃61;&＃61; u.DataId)?.Content ?? "", var found &＃61;> found.Content }, EventEntry { EventId: var eventId, CanRead: true } &＃61;> dbContext1.Event.FirstOrDefault(i &＃61;> i.Id &＃61;&＃61; eventId) switch { null &＃61;> dbContext2.Event.FirstOrDefault(i &＃61;> i.Id &＃61;&＃61; eventId)?.Content ?? "", var found &＃61;> found.Content }, EventEntry { CanRead: false } &＃61;> "", _ &＃61;> throw new InvalidArgumentException("无效的参数") };}

就全部搞定了&＃xff0c;代码非常简洁&＃xff0c;而且数据的流向一眼就能看清楚&＃xff0c;就算是没有接触过这部分代码的人看一下模式匹配的过程&＃xff0c;也能一眼就立刻掌握各分支的情况&＃xff0c;而不需要在一堆的 if-else 当中梳理这段代码到底干了什么。

使用记录类型和不可变数据#

record 作为 C# 9 的新工具&＃xff0c;配合 init 仅可初始化属性&＃xff0c;为我们带来了高效的数据交互能力和不可变性。

消除可变性意味着无副作用&＃xff0c;一个无副作用的函数无需担心数据同步互斥问题&＃xff0c;因此在无锁的并行编程中非常有用。

Copyrecord Point(int X, int Y);

简单的一句话等价于我们写了如下代码&＃xff0c;帮我们解决了 ToString() 格式化输出、基于值的 GetHashCode() 和相等判断等等各种问题&＃xff1a;

Copyinternal class Point : IEquatable{ private readonly int x; private readonly int y; protected virtual Type EqualityContract &＃61;> typeof(Point); public int X { get &＃61;> x; set &＃61;> x &＃61; value; } public int Y { get &＃61;> y; set &＃61;> y &＃61; value; } public Point(int X, int Y) { x &＃61; X; y &＃61; Y; } public override string ToString() { StringBuilder stringBuilder &＃61; new StringBuilder(); stringBuilder.Append("Point"); stringBuilder.Append(" { "); if (PrintMembers(stringBuilder)) { stringBuilder.Append(" "); } stringBuilder.Append("}"); return stringBuilder.ToString(); } protected virtual bool PrintMembers(StringBuilder builder) { builder.Append("X"); builder.Append(" &＃61; "); builder.Append(X.ToString()); builder.Append(", "); builder.Append("Y"); builder.Append(" &＃61; "); builder.Append(Y.ToString()); return true; } public static bool operator !&＃61;(Point r1, Point r2) { return !(r1 &＃61;&＃61; r2); } public static bool operator &＃61;&＃61;(Point r1, Point r2) { if ((object)r1 !&＃61; r2) { if ((object)r1 !&＃61; null) { return r1.Equals(r2); } return false; } return true; } public override int GetHashCode() { return (EqualityComparer.Default.GetHashCode(EqualityContract) * -1521134295 &＃43; EqualityComparer.Default.GetHashCode(x)) * -1521134295 &＃43; EqualityComparer.Default.GetHashCode(y); } public override bool Equals(object obj) { return Equals(obj as Point); } public virtual bool Equals(Point other) { if ((object)other !&＃61; null && EqualityContract &＃61;&＃61; other.EqualityContract && EqualityComparer.Default.Equals(x, other.x)) { return EqualityComparer.Default.Equals(y, other.y); } return false; } public virtual Point Clone() { return new Point(this); } protected Point(Point original) { x &＃61; original.x; y &＃61; original.y; } public void Deconstruct(out int X, out int Y) { X &＃61; this.X; Y &＃61; this.Y; }}

注意到 x 与 y 都是 readonly 的&＃xff0c;因此一旦实例创建了就不可变&＃xff0c;如果想要变更可以通过 with 创建一份副本&＃xff0c;于是这种方式彻底消除了任何的副作用。

Copyvar p1 &＃61; new Point(1, 2);var p2 &＃61; p1 with { Y &＃61; 3 }; // (1, 3)

当然&＃xff0c;你也可以自己使用 init 属性表示这个属性只能在初始化时被赋值&＃xff1a;

Copyclass Point{ public int X { get; init; } public int Y { get; init; }}

这样一来&＃xff0c;一旦 Point 被创建&＃xff0c;则 X 和 Y 的值就不会被修改了&＃xff0c;可以放心地在并行编程模型中使用&＃xff0c;而不需要加锁。

Copyvar p1 &＃61; new Point { X &＃61; 1, Y &＃61; 2 };p1.Y &＃61; 3; // errorvar p2 &＃61; p1 with { Y &＃61; 3 }; //ok

使用 readonly 类型#

上面说到了不可变性的重要性&＃xff0c;当然&＃xff0c;struct 也可以是只读的&＃xff1a;

Copyreadonly struct Foo{ public int X { get; set; } // error}

上面的代码会报错&＃xff0c;因为违反了 X 只读的约束。

如果改成&＃xff1a;

Copyreadonly struct Foo{ public int X { get; }}

或

Copyreadonly struct Foo{ public int X { get; init; }}

则不会存在问题。

Span 本身是一个 readonly ref struct&＃xff0c;通过这样做保证了 Span 里的东西不会被意外的修改&＃xff0c;确保不变性和安全。

使用局部函数而不是 lambda 创建临时委托#

在使用 Expression> 作为参数的 API 时&＃xff0c;使用 lambda 表达式是非常正确的&＃xff0c;因为编译器会把我们写的 lambda 表达式编译成 Expression Tree&＃xff0c;而非直观上的函数委托。

而在单纯只是 Func<>、Action<> 时&＃xff0c;使用 lambda 表达式恐怕不是一个好的决定&＃xff0c;因为这样做必定会引入一个新的闭包&＃xff0c;造成额外的开销和 GC 压力。从 C# 8 开始&＃xff0c;我们可以使用局部函数很好的替换掉 lambda&＃xff1a;

Copyint SomeMethod(Func fun){ if (fun(3) > 3) return 3; else return fun(5);}void Caller(){ int Foo(int v) &＃61;> v &＃43; 1; var result &＃61; SomeMethod(Foo); Console.WriteLine(result);}

以上代码便不会导致一个多余的闭包开销。

使用 ValueTask 代替 Task#

我们在遇到 Task 时&＃xff0c;大多数情况下只是需要简单的对其进行 await 而已&＃xff0c;而并不需要将其保存下来以后再 await&＃xff0c;那么 Task 提供的很多的功能则并没有被使用&＃xff0c;反而在高并发下&＃xff0c;由于反复分配 Task 导致 GC 压力增加。

这种情况下&＃xff0c;我们可以使用 ValueTask 代替 Task&＃xff1a;

Copyasync ValueTask Foo(){ await Task.Delay(5000); return 5;}async ValueTask Caller(){ await Foo();}

由于 ValueTask 是值类型结构&＃xff0c;因此不会在堆上分配内存&＃xff0c;于是可以做到 0 GC。

实现解构函数代替创建元组#

如果我们想要把一个类型中的数据提取出来&＃xff0c;我们可以选择返回一个元组&＃xff0c;其中包含我们需要的数据&＃xff1a;

Copyclass Foo{ private int x; private int y; public Foo(int x, int y) { this.x &＃61; x; this.y &＃61; y; } public (int, int) Deconstruct() { return (x, y); }}class Program{ static void Bar(Foo v) { var (x, y) &＃61; v.Deconstruct(); Console.WriteLine($"X &＃61; {x}, Y &＃61; {y}"); }}

上述代码会导致一个 ValueTuple 的开销&＃xff0c;如果我们将代码改成实现结构方法&＃xff1a;

Copyclass Foo{ private int x; private int y; public Foo(int x, int y) { this.x &＃61; x; this.y &＃61; y; } public void Deconstruct(out int x, out int y) { x &＃61; this.x; y &＃61; this.y; }}class Program{ static void Bar(Foo v) { var (x, y) &＃61; v; Console.WriteLine($"X &＃61; {x}, Y &＃61; {y}"); }}

则不仅省掉了 Deconstruct() 的调用&＃xff0c;同时还没有任何的额外开销。你可以看到实现 Deconstruct 函数并不需要让你的类型实现任何的接口&＃xff0c;从根本上杜绝了装箱的可能性&＃xff0c;这是一种 0 开销抽象。另外&＃xff0c;解构函数还能用于做模式匹配&＃xff0c;你可以像使用元组一样地使用解构函数(下面代码的意思是&＃xff0c;当 x 为 3 时取 y&＃xff0c;否则取 x &＃43; y)&＃xff1a;

Copyvoid Bar(Foo v){ var result &＃61; v switch { Foo (3, var y) &＃61;> y, Foo (var x, var y) &＃61;> x &＃43; y, _ &＃61;> 0 }; Console.WriteLine(result);}

总结#

在合适的时候使用 C# 的新特性&＃xff0c;不但可以提升开发效率&＃xff0c;同时还能兼顾代码质量和运行效率的提升。

但是切忌滥用。新特性的引入对于我们写高质量的代码无疑有很大的帮助&＃xff0c;但是如果不分时宜地使用&＃xff0c;可能会带来反效果。

希望本文能对各位开发者使用新版 C# 时带来一定的帮助&＃xff0c;感谢阅读。

作者&＃xff1a; hez2010

出处&＃xff1a;https://www.cnblogs.com/hez2010/p/13724904.html