关于c#:一个-Task-不够又来一个-ValueTask-真的学懵了

38次阅读

共计 6258 个字符，预计需要花费 16 分钟才能阅读完成。

一：背景

1. 讲故事

前几天在我的项目中用 MemoryStream 的时候意外发现 ReadAsync 办法多了一个返回 ValueTask 的重载，真是日了狗了，一个 Task 曾经够学了，又来一个 ValueTask，晕，办法签名如下：


    public class MemoryStream : Stream
    {public override ValueTask<int> ReadAsync(Memory<byte> buffer, CancellationToken cancellationToken = default(CancellationToken))
        {}}

既然是新玩意，我就比拟好奇，看看这个 ValueTask 是个啥玩意，翻翻源码看看类定义：


    public readonly struct ValueTask<TResult> : IEquatable<ValueTask<TResult>>
    { }

原来是搞了一个 值类型的 Task，有数的优化教训通知我，值类型相比援用类型要节俭空间的多，不信的话能够用 windbg 去校验一下，别离在 List 中灌入 1000 个 Task 和 1000 个 ValueTask，看看所占空间大小。


0:000> !clrstack -l
OS Thread Id: 0x44cc (0)
        Child SP               IP Call Site
0000004DA3B7E630 00007ffaf84329a6 ConsoleApp2.Program.Main(System.String[]) [E:\net5\ConsoleApp1\ConsoleApp2\Program.cs @ 17]
    LOCALS:
        0x0000004DA3B7E6E8 = 0x000001932896ac78
        0x0000004DA3B7E6E0 = 0x000001932897e700
0:000> !objsize 0x000001932896ac78
sizeof(000001932896AC78) = 80056 (0x138b8) bytes (System.Collections.Generic.List`1[[System.Threading.Tasks.Task`1[[System.Int32, System.Private.CoreLib]], System.Private.CoreLib]])
0:000> !objsize 0x000001932897e700
sizeof(000001932897E700) = 16056 (0x3eb8) bytes (System.Collections.Generic.List`1[[System.Threading.Tasks.ValueTask`1[[System.Int32, System.Private.CoreLib]], System.Private.CoreLib]])

下面的代码能够看出，1000 个 Task 需占用 80056 byte，1000 个 ValueTask 需占用 16056 byte，相差大略 5 倍，空间利用率的确失去了大大晋升，除了这个，ValueTask 还想解决什么问题呢？

二：ValueTask 原理剖析

1. 从 MemoryStream 中寻找答案

大家能够认真想一想，既然 MemoryStream 中多了一个 ReadAsync 扩大，必然是现存的 ReadAsync 不能满足某些业务，那不能满足什么业务呢？只能从办法源码中寻找答案，简化后的代码如下：


public override Task<int> ReadAsync(byte[] buffer, int offset, int count, CancellationToken cancellationToken)
{if (cancellationToken.IsCancellationRequested)
    {return Task.FromCanceled<int>(cancellationToken);
    }

    int num = Read(buffer, offset, count);
    Task<int> lastReadTask = _lastReadTask;
    return (lastReadTask != null && lastReadTask.Result == num) ? lastReadTask : (_lastReadTask = Task.FromResult(num));
}

看完这段代码，不晓得大家有没有什么纳闷？反正我是有纳闷的。

2. 我的纳闷

1) 异步 居然包装了 cpu 密集型操作

C# 引入异步实质上是用来解决 IO 密集型 的场景，利用磁盘驱动器的强势染指进而开释了调用线程，进步线程的利用率和吞吐率，而恰好这里的 ReadAsync 中的 Read 其实是一个简略的纯内存操作，也就是 CPU 密集型 的场景，这个时候用异步来解决其实没有任何成果可言，说重大一点就是为了异步而异步，或者就是为了对立异步编程模型吧。

2) CPU 密集型处理速度瞬息万里

纯内存操作速度是相当快的，1s 内可达千万次执行，那有什么问题呢？这问题大了，大家看清楚了，这个 ReadAsync 返回的是一个 Task 对象，这就意味着霎时会在托管堆中生成千万个 Task 对象，造成的结果可能就是 GC 一直痉挛，重大影响程序的性能。

3. 语言团队的解决方案

可能基于我方才聊到的二点，尤其是第二点，语言团队给出了 ValueTask 这个解决方案，毕竟它是值类型，也就不会在托管堆上调配任何内存，和 GC 就没有任何关系了，有些敌人会说，空口无凭，Talk is cheap. Show me the code。

三：Task 和 ValueTask 在 MemoryStream 上的演示

1. Task<int> 的 ReadAsync 演示

为了不便解说，我筹备灌入一段文字到 MemoryStream 中去，而后再用 ReadAsync 一个 byte 一个 byte 的读出来，目标就是让 while 多循环几次，多生成一些 Task 对象, 代码如下：


    class Program
    {static void Main(string[] args)
        {var content = GetContent().Result;

            Console.WriteLine(content);

            Console.ReadKey();}

        public static async Task<string> GetContent()
        {
            string str = "个别状况是：学生不在意草稿纸摆放在桌上的地位（他通常不会把纸摆正），总是棘手在空白处演算，杂乱无序。然而，我曾见到有位学生在草稿纸上按程序编号。他通知我，这样做的益处是：无论是考试还是做作业，在最初测验时，依据编号，他很快就能找到先前的演算过程，这样大略能够省下两三分钟。这个习惯，可能会跟着他一辈子，他的毕生中能够有无数个两三分钟，而且很可能会有几次要害的两三分钟。";

            using (MemoryStream ms = new MemoryStream(Encoding.UTF8.GetBytes(str)))
            {byte[] bytes = new byte[1024];

                ms.Seek(0, SeekOrigin.Begin);
                int cursor = 0;
                var offset = 0;
                int count = 1;

                while ((offset = await ms.ReadAsync(bytes, cursor, count)) != 0)
                {cursor += offset;}

                return Encoding.UTF8.GetString(bytes, 0, cursor);
            }
        }
    }

输入后果是没有任何问题的，接下来用 windbg 看一看托管堆上生成了多少个 Task。。。


0:000> !dumpheap -type Task -stat
Statistics:
              MT    Count    TotalSize Class Name
00007ffaf2404650        1           24 System.Threading.Tasks.Task+<>c
00007ffaf24042b0        1           40 System.Threading.Tasks.TaskFactory
00007ffaf23e3848        1           64 System.Threading.Tasks.Task
00007ffaf23e49d0        1           72 System.Threading.Tasks.Task`1[[System.String, System.Private.CoreLib]]
00007ffaf23e9658        2          144 System.Threading.Tasks.Task`1[[System.Int32, System.Private.CoreLib]]
Total 6 objects

从托管堆上看，我去，Task<int> 为啥只有两个呢？，???????? 了，难道我推演错啦？？？不可能的，看看源码去。


public override Task<int> ReadAsync(byte[] buffer, int offset, int count, CancellationToken cancellationToken)
{int num = Read(buffer, offset, count);
        Task<int> lastReadTask = _lastReadTask;
        return (lastReadTask != null && lastReadTask.Result == num) ? lastReadTask : (_lastReadTask = Task.FromResult(num));
}

下面最初一句代码不晓得大家有没有看懂，MemoryStream 用了 _lastReadTask 玩了一个小技巧，只有 num 雷同返回的都是一个 Task，如果不同则会生成新的 Task 对象，显然这是依据特定场景进行优化的，为了普适性，我必定要绕过这个技巧，做法就是每次 num 数字不一样就能够了，将 while 批改成代码如下：


        while ((offset = await ms.ReadAsync(bytes, cursor, count++ % 2 == 0 ? 1 : 2)) != 0)
        {cursor += offset;}

而后再用 windbg 看一下：


0:000> !dumpheap -type Task -stat
Statistics:
              MT    Count    TotalSize Class Name
00007ffaf7f04650        1           24 System.Threading.Tasks.Task+<>c
00007ffaf7f042b0        1           40 System.Threading.Tasks.TaskFactory
00007ffaf7ee3848        1           64 System.Threading.Tasks.Task
00007ffaf7ee49d0        1           72 System.Threading.Tasks.Task`1[[System.String, System.Private.CoreLib]]
00007ffaf7ee9658      371        26712 System.Threading.Tasks.Task`1[[System.Int32, System.Private.CoreLib]]
Total 375 objects

从最初一行代码能够看到 Count=371，哈哈，这要是千万级的，那这里的 Task 有多恐怖可想而知哈。

2. ValueTask<int> 的 ReadAsync 演示

后面例子的危害性大家也分明了，这种场景下解决方案天然就是 C# 团队提供的新 ReadAsync 办法，代码如下：


   class Program
   {static void Main(string[] args)
        {var content = GetContent().Result;

            Console.WriteLine(content);

            Console.ReadKey();}

        public static async Task<string> GetContent()
        {
            string str = "个别状况是：学生不在意草稿纸摆放在桌上的地位（他通常不会把纸摆正），总是棘手在空白处演算，杂乱无序。然而，我曾见到有位学生在草稿纸上按程序编号。他通知我，这样做的益处是：无论是考试还是做作业，在最初测验时，依据编号，他很快就能找到先前的演算过程，这样大略能够省下两三分钟。这个习惯，可能会跟着他一辈子，他的毕生中能够有无数个两三分钟，而且很可能会有几次要害的两三分钟。";

            using (MemoryStream ms = new MemoryStream(Encoding.UTF8.GetBytes(str)))
            {byte[] bytes = new byte[1024];

                Memory<byte> memory = new Memory<byte>(bytes);

                ms.Seek(0, SeekOrigin.Begin);
                int cursor = 0;
                var offset = 0;
                var count = 1;

                while ((offset = await ms.ReadAsync(memory.Slice(cursor, count++ % 2 == 0 ? 1 : 2))) != 0)
                {cursor += offset;}

                return Encoding.UTF8.GetString(bytes, 0, cursor);
            }
        }
    }

很开心，用 ValueTask 也实现了同样的性能，而且还不给 GC 添任何麻烦，不信的话，用 windbg 校验下：


0:000> !dumpheap -type Task -stat
Statistics:
              MT    Count    TotalSize Class Name
00007ffaf23f7bf0        1           24 System.Threading.Tasks.Task+<>c
00007ffaf23f7850        1           40 System.Threading.Tasks.TaskFactory
00007ffaf23c3848        1           64 System.Threading.Tasks.Task
00007ffaf23c49d0        1           72 System.Threading.Tasks.Task`1[[System.String, System.Private.CoreLib]]
Total 4 objects

0:000> !dumpheap -type ValueTask -stat
Statistics:
              MT    Count    TotalSize Class Name
Total 0 objects

能够看到，托管堆上没有任何形迹，几乎就是完满。

四：ValueTask 真的完满吗？

如果真是完满的话，我置信底层框架中都会改成 ValueTask，而事实并没有，也就阐明 ValueTask 只是某一些场景下的优选计划，如果你明确了下面两个案例，你应该会明确 ValueTask 特地适宜于那些 CPU 密集型的 异步工作，因为是个假异步，当你 await 的时候，其实后果曾经进去了，毕竟人家是纯内存操作，不和底层的驱动器打交道，速度天然相当快。

struct 在多线程模式下有很多种限度，如果用的不当，会有太多的潜在问题和不确定性，你能够想一想为啥 lock 锁中大多会用援用类型，而不是值类型，其实是一样的情理，所以它注定是一个高阶玩法，置信 95% 的敌人在我的项目开发中都不会用到，用用 Task 就好了，根本包治百病 ????????????

五：总结

从 ValueTask 要解决的问题上能够看出 C# 语言团队对高并发场景下的性能优化曾经快走火入魔了，而且现有类库中 99% 的办法还是采纳 Task，所以一般玩家还是老老实实的用 Task 吧，事实中还没有遇到在这个下面碰到性能瓶颈的，高能的还是留给高阶玩家吧！

更多高质量干货：参见我的 GitHub: dotnetfly

正文完
c#
发表至： c#
2020-11-10
 0
关于.net:进击吧Blazor系列入门教程-第一章-7图表
关于c:linux-查看程序函数占用时间gprof
关于c#:5-堪比JMeter的Net压测工具-Crank-实战篇-接口以及场景压测
关于c#:Unity的IPreprocessBuild深入解析与实用案例