C# 开发必备：新版高效编程全攻略
C# 开发必备：新版高效编程全攻略
前言
C# 从 7 版本开始一直到现在的版本，加入了非常多的特性，其中不乏改善性能、增加程序健壮性和代码简洁性、可读性的改进，这里我整理一些使用新版 C# 的时候个人推荐的写法，可能不适用于所有的人，但是还是希望对你们有所帮助。
注意：本指南适用于 .NET 5 或以上版本。
使用 ref struct 做到 0 GC
C# 7 开始引入了一种叫做 ref struct 的结构，这种结构本质是 struct ，结构存储在栈内存。但是与 struct 不同的是，该结构不允许实现任何接口，并由编译器保证该结构永远不会被装箱，因此不会给 GC 带来任何的压力。相对的，使用中就会有不能逃逸出栈的强制限制。
Span<T> 就是利用 ref struct 的产物，成功的封装出了安全且高性能的内存访问操作，且可在大多数情况下代替指针而不损失任何的性能。
Copyref struct MyStruct
{
publicint Value { get; set; }
}
classRefStructGuide
{
static void Test()
{
MyStruct x = new MyStruct();
x.Value = 100;
Foo(x); // ok
Bar(x); // error, x cannot be boxed
}
static void Foo(MyStruct x) { }
static void Bar(object x) { }
}
使用 in 关键字传递不可修改的引用
当参数以 ref 传递时，虽然传递的是引用但是无法确保引用值不被对方修改，这个时候只需要将 ref 改为 in，便能确保安全性：
CopySomeBigReadonlyStruct x = ...;
Foo(x);
void Foo(in SomeBigReadonlyStruct v)
{
v = ...; // error
}
在使用大的 readonly struct 时收益非常明显。
使用 stackalloc 在栈上分配连续内存
对于部分性能敏感却需要使用少量的连续内存的情况，不必使用数组，而可以通过 stackalloc 直接在栈上分配内存，并使用 Span<T> 来安全的访问，同样的，这么做可以做到 0 GC 压力。
stackalloc 允许任何的值类型结构，但是要注意，Span<T> 目前不支持 ref struct 作为泛型参数，因此在使用 ref struct 时需要直接使用指针。
Copyref struct MyStruct
{
publicint Value { get; set; }
}
classAllocGuide
{
static unsafe void RefStructAlloc()
{
MyStruct* x = stackalloc MyStruct[10];
for (int i = 0; i < 10; i++)
{
*(x + i) = new MyStruct { Value = i };
}
}
static void StructAlloc()
{
Span<int> x = stackallocint[10];
for (int i = 0; i < x.Length; i++)
{
x[i] = i;
}
}
}
使用 Span 操作连续内存
C# 7 开始引入了 Span<T>，它封装了一种安全且高性能的内存访问操作方法，可用于在大多数情况下代替指针操作。
Copystatic void SpanTest()
{
Span<int> x = stackalloc int[10];
for (int i = 0; i < x.Length; i++)
{
x[i] = i;
}
ReadOnlySpan<char> str = "12345".AsSpan();
for (int i = 0; i < str.Length; i++)
{
Console.WriteLine(str[i]);
}
}
性能敏感时对于频繁调用的函数使用 SkipLocalsInit
C# 为了确保代码的安全会将所有的局部变量在声明时就进行初始化，无论是否必要。一般情况下这对性能并没有太大影响，但是如果你的函数在操作很多栈上分配的内存，并且该函数还是被频繁调用的，那么这一消耗的副作用将会被放大变成不可忽略的损失。
因此你可以使用 SkipLocalsInit 这一特性禁用自动初始化局部变量的行为。
Copy[SkipLocalsInit]
unsafe static void Main()
{
Guid g;
Console.WriteLine(*&g);
}
上述代码将输出不可预期的结果，因为 g 并没有被初始化为 0。另外，访问未初始化的变量需要在 unsafe 上下文中使用指针进行访问。
使用函数指针代替 Marshal 进行互操作
C# 9 带来了函数指针功能，该特性支持 managed 和 unmanaged 的函数，在进行 native interop 时，使用函数指针将能显著改善性能。
例如，你有如下 C++ 代码：
Copy#define UNICODE
#define WIN32
#include <cstring>
extern "C" __declspec(dllexport) char* __cdecl InvokeFun(char* (*foo)(int)) {
return foo(5);
}
并且你编写了如下 C# 代码进行互操作：
Copy[DllImport("./Test.dll")]
static extern string InvokeFun(delegate* unmanaged[Cdecl]<int, IntPtr> fun);
[UnmanagedCallersOnly(CallConvs = new[] { typeof(CallConvCdecl) })]
public static IntPtr Foo(int x)
{
var str = Enumerable.Repeat("x", x).Aggregate((a, b) => $"{a}{b}");
return Marshal.StringToHGlobalAnsi(str);
}
static void Main(string[] args)
{
var callback = (delegate* unmanaged[Cdecl]<int, nint>)(delegate*<int, nint>)&Foo;
Console.WriteLine(InvokeFun(callback));
}
上述代码中，首先 C# 将自己的 Foo 方法作为函数指针传给了 C++ 的 InvokeFun 函数，然后 C++ 用参数 5 调用该函数并返回其返回值到 C# 的调用方。
注意到上述代码还用了 UnmanagedCallersOnly 这一特性，这样可以告诉编译器该方法只会从 unmanaged 的代码被调用，因此编译器可以做一些额外的优化。
使用函数指针产生的 IL 指令非常高效：
Copyldftn native int Test.Program::Foo(int32)
stloc.0
ldloc.0
call string Test.Program::InvokeFun(method native int *(int32))
除了 unmanaged 的情况外，managed 函数也是可以使用函数指针的：
Copystatic void Foo(int v) { }
unsafe static void Main(string[] args)
{
delegate* managed<int, void> fun = &Foo;
fun(4);
}
产生的代码相对于原本的 Delegate 来说更加高效：
Copyldftn void Test.Program::Foo(int32)
stloc.0
ldc.i4.4
ldloc.0
calli void(int32)
使用模式匹配
有了if-else、as和强制类型转换，为什么要使用模式匹配呢?有三方面原因：性能、鲁棒性和可读性。
为什么说性能也是一个原因呢?因为 C# 编译器会根据你的模式编译出最优的匹配路径。
考虑一下以下代码（代码 1）：
Copyint Match(int v)
{
if (v > 3)
{
return5;
}
if (v < 3)
{
if (v > 1)
{
return6;
}
if (v > -5)
{
return7;
}
else
{
return8;
}
}
return9;
}
如果改用模式匹配，配合 switch 表达式写法则变成（代码 2）：
Copyint Match(int v)
{
return v switch
{
> 3 => 5,
< 3 and > 1 => 6,
< 3 and > -5 => 7,
< 3 => 8,
_ => 9
};
}
以上代码会被编译器编译为：
Copyint Match(int v)
{
if (v > 1)
{
if (v <= 3)
{
if (v < 3)
{
return6;
}
return9;
}
return5;
}
if (v > -5)
{
return7;
}
return8;
}
我们计算一下平均比较次数：
| 代码 | 5 | 6 | 7 | 8 | 9 | 总数 | 平均 |
|---|---|---|---|---|---|---|---|
| 代码 1 | 1 | 3 | 4 | 4 | 2 | 14 | 2.8 |
| 代码 2 | 2 | 3 | 2 | 2 | 3 | 12 | 2.4 |
可以看到使用模式匹配时，编译器选择了更优的比较方案，你在编写的时候无需考虑如何组织判断语句，心智负担降低，并且代码 2 可读性和简洁程度显然比代码 1 更好，有哪些条件分支一目了然。
甚至遇到类似以下的情况时：
Copyint Match(int v)
{
return v switch
{
1 => 5,
2 => 6,
3 => 7,
4 => 8,
_ => 9
};
}
编译器会直接将代码从条件判断语句编译成 switch 语句：
Copyint Match(int v)
{
switch (v)
{
case1:
return5;
case2:
return6;
case3:
return7;
case4:
return8;
default:
return9;
}
}
如此一来所有的判断都不需要比较（因为 switch 可根据 HashCode 直接跳转）。
编译器非常智能地为你选择了最佳的方案。
那鲁棒性从何谈起呢?假设你漏掉了一个分支：
Copyint v = 5;
var x = v switch
{
> 3 => 1,
< 3 => 2
};
此时编译的话，编译器就会警告你漏掉了 v 可能为 3 的情况，帮助减少程序出错的可能性。
最后一点，可读性。
假设你现在有这样的东西：
Copyabstract class Entry { }
classUserEntry : Entry
{
publicint UserId { get; set; }
}
classDataEntry : Entry
{
publicint DataId { get; set; }
}
classEventEntry : Entry
{
publicint EventId { get; set; }
// 如果 CanRead 为 false 则查询的时候直接返回空字符串
publicbool CanRead { get; set; }
}
现在有接收类型为 Entry 的参数的一个函数，该函数根据不同类型的 Entry 去数据库查询对应的 Content，那么只需要写：
Copystring QueryMessage(Entry entry)
{
return entry switch
{
UserEntry u => dbContext1.User.FirstOrDefault(i => i.Id == u.UserId).Content,
DataEntry d => dbContext1.Data.FirstOrDefault(i => i.Id == d.DataId).Content,
EventEntry { EventId: var eventId, CanRead: true } => dbContext1.Event.FirstOrDefault(i => i.Id == eventId).Content,
EventEntry { CanRead: false } => "",
_ => throw new InvalidArgumentException("无效的参数")
};
}
更进一步，假如 Entry.Id 分布在了数据库 1 和 2 中，如果在数据库 1 当中找不到则需要去数据库 2 进行查询，如果 2 也找不到才返回空字符串，由于 C# 的模式匹配支持递归模式，因此只需要这样写：
Copystring QueryMessage(Entry entry)
{
return entry switch
{
UserEntry u => dbContext1.User.FirstOrDefault(i => i.Id == u.UserId) switch
{
null => dbContext2.User.FirstOrDefault(i => i.Id == u.UserId)?.Content ?? "",
var found => found.Content
},
DataEntry d => dbContext1.Data.FirstOrDefault(i => i.Id == d.DataId) switch
{
null => dbContext2.Data.FirstOrDefault(i => i.Id == u.DataId)?.Content ?? "",
var found => found.Content
},
EventEntry { EventId: var eventId, CanRead: true } => dbContext1.Event.FirstOrDefault(i => i.Id == eventId) switch
{
null => dbContext2.Event.FirstOrDefault(i => i.Id == eventId)?.Content ?? "",
var found => found.Content
},
EventEntry { CanRead: false } => "",
_ => thrownew InvalidArgumentException("无效的参数")
};
}
就全部搞定了，代码非常简洁，而且数据的流向一眼就能看清楚，就算是没有接触过这部分代码的人看一下模式匹配的过程，也能一眼就立刻掌握各分支的情况，而不需要在一堆的 if-else 当中梳理这段代码到底干了什么。
使用记录类型和不可变数据
record 作为 C# 9 的新工具，配合 init 仅可初始化属性，为我们带来了高效的数据交互能力和不可变性。
消除可变性意味着无副作用，一个无副作用的函数无需担心数据同步互斥问题，因此在无锁的并行编程中非常有用。
Copyrecord Point(int X, int Y);
简单的一句话等价于我们写了如下代码，帮我们解决了 ToString() 格式化输出、基于值的 GetHashCode() 和相等判断等等各种问题：
Copyinternal class Point : IEquatable<Point>
{
privatereadonlyint x;
privatereadonlyint y;
protectedvirtual Type EqualityContract => typeof(Point);
publicint X
{
get => x;
set => x = value;
}
publicint Y
{
get => y;
set => y = value;
}
public Point(int X, int Y)
{
x = X;
y = Y;
}
public override string ToString()
{
StringBuilder stringBuilder = 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(" = ");
builder.Append(X.ToString());
builder.Append(", ");
builder.Append("Y");
builder.Append(" = ");
builder.Append(Y.ToString());
returntrue;
}
publicstaticbooloperator !=(Point r1, Point r2)
{
return !(r1 == r2);
}
publicstaticbooloperator ==(Point r1, Point r2)
{
if ((object)r1 != r2)
{
if ((object)r1 != null)
{
return r1.Equals(r2);
}
returnfalse;
}
returntrue;
}
public override int GetHashCode()
{
return (EqualityComparer<Type>.Default.GetHashCode(EqualityContract) * -1521134295 + EqualityComparer<int>.Default.GetHashCode(x)) * -1521134295 + EqualityComparer<int>.Default.GetHashCode(y);
}
public override bool Equals(object obj)
{
return Equals(obj as Point);
}