一個 Task 不夠,又來一個 ValueTask ,真的學懵了!

一線碼農發表於2020-11-10

一:背景

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

圖片名稱

相關文章