一:背景
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