一：背景
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
轉載請註明出處，本文鏈接：https://www.uj5u.com/net/209514.html
標籤：C#