一：背景

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?=?0x000001932896ac780x0000004DA3B7E6E0?=?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?objects0: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 吧，現實中還沒有遇到在這個上面碰到性能瓶頸的，高能的還是留給高階玩家吧！

總結

以上是生活随笔為你收集整理的一个 Task 不够，又来一个 ValueTask ，真的学懵了！的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。