一個 Task 不夠，又來一個 ValueTask ，真的學懵了！

一：背景

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 的 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 的 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