新版 C# 高效率编程指南

时间  2020-09-25
标签 新版 c# 高效率 编程 指南 栏目 C# 繁體版
原文   原文链接

前言

C# 从 7 版本开始一直到现在的 9 版本，加入了很是多的特性，其中不乏改善性能、增长程序健壮性和代码简洁性、可读性的改进，这里我整理一些使用新版 C# 的时候我的推荐的写法，可能不适用于全部的人，可是仍是但愿对大家有所帮助。数据库

注意：本指南适用于 .NET 5 或以上版本。编程

使用 ref struct 作到 0 GC

C# 7 开始引入了一种叫作 ref struct 的结构，这种结构本质是 struct ，结构存储在栈内存。可是与 struct 不一样的是，该结构不容许实现任何接口，并由编译器保证该结构永远不会被装箱，所以不会给 GC 带来任何的压力。相对的，使用中就会有不能逃逸出栈的强制限制。数组

Span<T> 就是利用 ref struct 的产物，成功的封装出了安全且高性能的内存访问操做，且可在大多数状况下代替指针而不损失任何的性能。安全

ref struct MyStruct
{
    public int Value { get; set; }
}
    
class RefStructGuide
{
    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) { }
}

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

对于部分性能敏感却须要使用少许的连续内存的状况，没必要使用数组，而能够经过 stackalloc 直接在栈上分配内存，并使用 Span<T> 来安全的访问，一样的，这么作能够作到 0 GC 压力。闭包

stackalloc 容许任何的值类型结构，可是要注意，Span<T> 目前不支持 ref struct 做为泛型参数，所以在使用 ref struct 时须要直接使用指针。并发

ref struct MyStruct
{
    public int Value { get; set; }
}

class AllocGuide
{
    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 = stackalloc int[10];
        for (int i = 0; i < x.Length; i++)
        {
            x[i] = i;
        }
    }
}

使用 Span 操做连续内存

C# 7 开始引入了 Span<T>，它封装了一种安全且高性能的内存访问操做方法，可用于在大多数状况下代替指针操做。async

static 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# 为了确保代码的安全会将全部的局部变量在声明时就进行初始化，不管是否必要。通常状况下这对性能并无太大影响，可是若是你的函数在操做不少栈上分配的内存，而且该函数仍是被频繁调用的，那么这一消耗的反作用将会被放大变成不可忽略的损失。ide

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

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

上述代码将输出不可预期的结果，由于 g 并无被初始化为 0。另外，访问未初始化的变量须要在 unsafe 上下文中使用指针进行访问。高并发

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

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

例如，你有以下 C++ 代码：

#define UNICODE
#define WIN32
#include <cstring>

extern "C" __declspec(dllexport) char* __cdecl InvokeFun(char* (*foo)(int)) {
    return foo(5);
}

而且你编写了以下 C# 代码进行互操做：

[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 指令很是高效：

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

除了 unmanaged 的状况外，managed 函数也是可使用函数指针的：

static void Foo(int v) { }
unsafe static void Main(string[] args)
{
    delegate* managed<int, void> fun = &Foo;
    fun(4);
}

产生的代码相对于本来的 Delegate 来讲更加高效：

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

使用模式匹配

有了if-else、as和强制类型转换，为何要使用模式匹配呢?有三方面缘由：性能、鲁棒性和可读性。

为何说性能也是一个缘由呢?由于 C# 编译器会根据你的模式编译出最优的匹配路径。

考虑一下如下代码（代码 1）：

int 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;
}

若是改用模式匹配，配合 switch 表达式写法则变成（代码 2）：

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

以上代码会被编译器编译为：

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

咱们计算一下平均比较次数：

代码 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 更好，有哪些条件分支一目了然。

甚至遇到相似如下的状况时：

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

编译器会直接将代码从条件判断语句编译成 switch 语句：

int 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 直接跳转）。

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

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

int v = 5;
var x = v switch
{
    > 3 => 1,
    < 3 => 2
};

此时编译的话，编译器就会警告你漏掉了 v 可能为 3 的状况，帮助减小程序出错的可能性。

最后一点，可读性。

假设你如今有这样的东西：

abstract 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 的参数的一个函数，该函数根据不一样类型的 Entry 去数据库查询对应的 Content，那么只须要写：

string 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# 的模式匹配支持递归模式，所以只须要这样写：

string 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 } => "",
        _ => throw new InvalidArgumentException("无效的参数")
    };
}

就所有搞定了，代码很是简洁，并且数据的流向一眼就能看清楚，就算是没有接触过这部分代码的人看一下模式匹配的过程，也能一眼就马上掌握各分支的状况，而不须要在一堆的 if-else 当中梳理这段代码到底干了什么。

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

record 做为 C# 9 的新工具，配合 init 仅可初始化属性，为咱们带来了高效的数据交互能力和不可变性。

消除可变性意味着无反作用，一个无反作用的函数无需担忧数据同步互斥问题，所以在无锁的并行编程中很是有用。

record Point(int X, int Y);

简单的一句话等价于咱们写了以下代码，帮咱们解决了 ToString() 格式化输出、基于值的 GetHashCode() 和相等判断等等各类问题：

internal class Point : IEquatable<Point>
{
    private readonly int x;
    private readonly int y;

    protected virtual Type EqualityContract => typeof(Point);

    public int X
    {
        get => x;
        set => x = value;
    }

    public int 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());
        return true;
    }

    public static bool operator !=(Point r1, Point r2)
    {
        return !(r1 == r2);
    }

    public static bool operator ==(Point r1, Point r2)
    {
        if ((object)r1 != r2)
        {
            if ((object)r1 != null)
            {
                return r1.Equals(r2);
            }
            return false;
        }
        return true;
    }

    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);
    }

    public virtual bool Equals(Point other)
    {
        if ((object)other != null && EqualityContract == other.EqualityContract && EqualityComparer<int>.Default.Equals(x, other.x))
        {
            return EqualityComparer<int>.Default.Equals(y, other.y);
        }
        return false;
    }

    public virtual Point Clone()
    {
        return new Point(this);
    }

    protected Point(Point original)
    {
        x = original.x;
        y = original.y;
    }

    public void Deconstruct(out int X, out int Y)
    {
        X = this.X;
        Y = this.Y;
    }
}

注意到 x 与 y 都是 readonly 的，所以一旦实例建立了就不可变，若是想要变动能够经过 with 建立一份副本，因而这种方式完全消除了任何的反作用。

var p1 = new Point(1, 2);
var p2 = p1 with { Y = 3 }; // (1, 3)

固然，你也能够本身使用 init 属性表示这个属性只能在初始化时被赋值：

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

这样一来，一旦 Point 被建立，则 X 和 Y 的值就不会被修改了，能够放心地在并行编程模型中使用，而不须要加锁。

var p1 = new Point { X = 1, Y = 2 };
p1.Y = 3; // error
var p2 = p1 with { Y = 3 }; //ok

使用 readonly 类型

上面说到了不可变性的重要性，固然，struct 也能够是只读的：

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

上面的代码会报错，由于违反了 X 只读的约束。

若是改为：

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

或

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

则不会存在问题。

Span<T> 自己是一个 readonly ref struct，经过这样作保证了 Span<T> 里的东西不会被意外的修改，确保不变性和安全。

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

在使用 Expression<Func<>> 做为参数的 API 时，使用 lambda 表达式是很是正确的，由于编译器会把咱们写的 lambda 表达式编译成 Expression Tree，而非直观上的函数委托。

而在单纯只是 Func<>、Action<> 时，使用 lambda 表达式恐怕不是一个好的决定，由于这样作一定会引入一个新的闭包，形成额外的开销和 GC 压力。从 C# 8 开始，咱们可使用局部函数很好的替换掉 lambda：

int SomeMethod(Func<int, int> fun)
{
    if (fun(3) > 3) return 3;
    else return fun(5);
}

void Caller()
{
    int Foo(int v) => v + 1;

    var result = SomeMethod(Foo);
    Console.WriteLine(result);
}

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

使用 ValueTask 代替 Task

咱们在遇到 Task<T> 时，大多数状况下只是须要简单的对其进行 await 而已，而并不须要将其保存下来之后再 await，那么 Task<T> 提供的不少的功能则并无被使用，反而在高并发下，因为反复分配 Task 致使 GC 压力增长。

这种状况下，咱们可使用 ValueTask<T> 代替 Task<T>：

async ValueTask<int> Foo()
{
    await Task.Delay(5000);
    return 5;
}

async ValueTask Caller()
{
    await Foo();
}

因为 ValueTask<T> 是值类型结构，所以不会在堆上分配内存，因而能够作到 0 GC。

实现解构函数代替建立元组

若是咱们想要把一个类型中的数据提取出来，咱们能够选择返回一个元组，其中包含咱们须要的数据：

class Foo
{
    private int x;
    private int y;

    public Foo(int x, int y)
    {
        this.x = x;
        this.y = y;
    }

    public (int, int) Deconstruct()
    {
        return (x, y);
    }
}

class Program
{
    static void Bar(Foo v)
    {
        var (x, y) = v.Deconstruct();
        Console.WriteLine($"X = {x}, Y = {y}");
    }
}

上述代码会致使一个 ValueTuple<int, int> 的开销，若是咱们将代码改为实现解构方法：

class Foo
{
    private int x;
    private int y;

    public Foo(int x, int y)
    {
        this.x = x;
        this.y = y;
    }

    public void Deconstruct(out int x, out int y)
    {
        x = this.x;
        y = this.y;
    }
}

class Program
{
    static void Bar(Foo v)
    {
        var (x, y) = v;
        Console.WriteLine($"X = {x}, Y = {y}");
    }
}

则不只省掉了 Deconstruct() 的调用，同时尚未任何的额外开销。你能够看到实现 Deconstruct 函数并不须要让你的类型实现任何的接口，从根本上杜绝了装箱的可能性，这是一种 0 开销抽象。另外，解构函数还能用于作模式匹配，你能够像使用元组同样地使用解构函数（下面代码的意思是，当 x 为 3 时取 y，不然取 x + y）：

void Bar(Foo v)
{
    var result = v switch
    {
        Foo (3, var y) => y,
        Foo (var x, var y) => x + y,
        _ => 0
    };

    Console.WriteLine(result);
}

总结

在合适的时候使用 C# 的新特性，不但能够提高开发效率，同时还能兼顾代码质量和运行效率的提高。

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

但愿本文能对各位开发者使用新版 C# 时带来必定的帮助，感谢阅读。

相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程