【5min+】 秋名山的競速。 ValueTask 和 Task

系列介紹

簡介

【五分鐘的dotnet】是一個利用您的碎片化時間來學習和豐富.net知識的博文系列。它所包含了.net體系中可能會涉及到的方方面面，好比C#的小細節，AspnetCore，微服務中的.net知識等等。

場景

您能夠在下班坐地鐵的時候，拿出手機逛一逛博客園，利用短短的五分鐘完成閱讀。

誕生原因

• 曾經學過的內容可能過不了多久就忘了，咱們須要一些文章來幫咱們查漏補缺。
• 太長篇幅的文章看着滾動條就懼怕了，咱們可能更指望文字少的文章。
• .net體系的內容太多了，平時也不知道該學哪些，咱們可能須要一點點知識線索。

文章質量

固然，並不意味着它篇幅短就質量差。所謂麻雀雖小五臟俱全，咱們會盡量保證利用最少的文字去詳細的闡述內容。

正文

伴隨着dotnet core的不斷迭代，咱們在享受.net性能上的提高以外，還收穫了許許多多新出現的API。不知您有沒有發現，有這樣一個類型在開始逐漸出如今咱們的視野中 ———— ValueTask。

好比在最新的EF Core中：

public virtual async ValueTask<EntityEntry> AddAsync(
    object entity,
    CancellationToken cancellationToken = default)

以上代碼是EF Core中DBContext的AddAsync簽名，咱們能夠發現它的返回類型爲ValueTask,可能就如同您想的同樣，既然AddAsync是這樣，那異步查找方法返回的類型也是這樣。是的，曾經這些由Task來包裹的結果，如今所有交由VauleTask來處理了。

在最新的C# 8的特性中，引入了 異步流 的概念。它在原有的同步迭代器的基礎上，擴充了異步的迭代器版本：

IAsyncEnumerable 和 IAsyncEnumerator

若是您還不瞭解同步的迭代器接口，能夠查看本系列的 上一篇文章。

而這個異步迭代器接口的方法簽名是這樣的：

public interface IAsyncEnumerator<out T> : IAsyncDisposable
{
    T Current { get; }
    ValueTask<bool> MoveNextAsync();
}

OMG，又是ValueTask！！！

那麼，ValueTask究竟是什麼東西呢？它和傳統的Task又有什麼區別呢？該在何時使用它。

不要慌，接下來的五分鐘您將Get到它。

開胃菜

在開始以前，咱們先來了解一下我們.NET中對內存中對象的存儲格式：堆與棧。

先來看棧和堆的區別：

• 棧，或多或少負責跟蹤正在程序中運行的代碼。棧空間比較小，可是讀取速度快
• 堆，或多或少負責跟蹤程序對象或數據。堆空間比較大，可是讀取速度慢

而在C#裏面（其它.NET語言同理哈），我們都知道有Class 和 Struct這兩個類別，這兩個類別對應的就是引用類型和值類型。

咱們先拿實例化一個類來講，好比咱們在執行 var newInstance = new ClassA()的時候，咱們就會創建一個A的對象，而這個對象的數據通常來講就是分配在堆上的，而同時會創建一個引用ID，該ID就通常就置放在棧上面。

那麼值類型的數據呢？通常來講它是存放在棧上的。固然這句話不全對：

"值類型存儲在棧中, 引用類型存儲在堆中」 這句話的前半句是有爭議的，「變量的值是在它聲明的位置存儲的，假如一個類中有一個int類型的實例變量，那麼在這個類的任何對象中，該變量的值老是和對象中的其餘數據在一塊兒，也就是在堆上，只有局部變量（方法內部聲明的變量）和方法參數在棧上。而對於C#2以及更高版本，不少局部變量並不徹底存放在棧中」引用-《C# in depth》及譯本《深刻理解C#》.

這也是爲何咱們會將結構化的小數據建立爲Struct的緣由，好比具備(R,G,B)三個屬性的結構Color。

棧裏面的數據通常來講由於空間小，讀取數據庫的緣由，它的生命週期就比較小，好比一個返回值爲int的方法，當方法完成以後，該棧中的數據就銷燬了。而堆呢？堆保存了幾乎全部類中的數據，它怎麼銷燬數據來保存內存不溢出呢？ 是的，您會想到GC，在.NET中就是一個專門的垃圾回收器來完成該操做。

開始飆車

回到本篇文章的主題，ValueTask。 Task可能你們都用的比較多了，畢竟從DotNET Framework的年代就流傳至今，而ValueTask卻從DotNET Core2.0才引入。

咱們先來看看 MSDN 中對ValueTask的闡述：

提供異步操做的可等待結果。提供包裝 Task 和 TResult（僅使用其中之一）的值類型。

往下滑MSDN，就能看到裏面有一個很重要的一點：

There are tradeoffs to using a ValueTask instead of a Task . For example, while a ValueTask can help avoid an allocation in the case where the successful result is available synchronously, it also contains multiple fields, whereas a Task as a reference type is a single field.

不要問爲何這個是英文，由於我嘗試MSDN的機翻。唉…………能讀懂個鬼，強烈建議給MSDN負責翻譯的人員扣雞腿。

上面大體的意思就是說，ValueTask會避免同步狀況下一些沒必要要的內存分配，從而提高應用總體的性能。

因此說，如今就能明白ValueTask出現的目的是爲了提高性能，而被提高的對象就是Task。二位秋名山車神的競速之路：

若是您足夠仔細，您會發現我上面說的是同步的狀況。 「？？？納尼，我用Task不是異步嗎？怎麼成同步了？」

別急，回想下您是否寫過這樣的代碼：

return Task.FromResult(42);

您確定寫過（就算沒寫過也看過😝），那麼爲何會有這種代碼呢？ 由於咱們須要在方法中部分執行異步，而後使用awit關鍵字等待它返回一個肯定的結果，而後進行一波同步運算後返回結果。

因此如今問題就來了，之前的版本咱們都是這樣寫，這沒有一點問題，可是咱們須要明白一點：Task是一個類，開胃菜中咱們得知了，類在實例化的時候數據量會被存放在堆中，等待沒有引用以後就被GC回收掉。因此來看剛纔那句代碼，咱們的返回類型是什麼，一個Task<int>。

若是咱們以同步方式來實現直接返回一個int是什麼樣呢？ 數據被置放在棧中，方法完成後，內存中的數據就消失了。這個週期很是的短，並且內存分配極小。

那麼使用Task以後呢，實例化了一個Task對象，放在堆中，堆裏面置放了大量的Task緩存對象。直至最後來等待GC回收。

來看看下面這個代碼:

public async Task<int> ReadNextByteAsync()
{
    if (_bufferedCount == 0)
    {
        await FillBuffer();
    }

    if (_bufferedCount == 0)
    {
        return -1;
    }

    _bufferedCount--;
    return _buffer[_position++];
}

假如它是一個讀取文本的方法，則ReadNextByteAsync可能會被調用無數次，好比10w+，那麼按照咱們的猜測結果是什麼樣子呢？ 內存堆中存了10w+被包裹的Task對象數據。哪怕一個Task的所須要的內存量極小，那麼10w+以後會是什麼樣呢？那麼1000w+呢？

OMG，不敢想象。（隔壁：128G海盜船請求出戰）

因此，救星來了：ValueTask。它從遙遠的M78星雲…………哦，不對，它從.NET Core2.0中出現了。

public readonly struct ValueTask : IEquatable<ValueTask>
{
}

是的，它就是這個樣子。它是一個結構體，也就是值類型。若是按照咱們以前對值類型和引用類型的說法來猜測，使用ValueTask完成上面的ReadNextByteAsync是什麼樣子呢？ 它將數據存放在棧中，每次方法結束後它將被釋放，避免沒必要要的內存開銷。

因此這也是以前MSDN上說的，在同步中它會提升性能的緣由。

因此之後咱們能夠嘗試將如下代碼替換：

//brefore
return Task.FromResult(42);

//after
return new ValueTask(42);

不是全部狀況它都是車神

ValueTask 被講的這麼好，是否是全部用Task的地方均可以用ValueTask了呢？

若是真的要回答這個問題的話，答案是：不是的。

回到MSDN對它的定義，您會發現，它是對Task的包裝。由於是包裝的緣由，因此您可將全部用Task的地方轉換爲ValueTask，編譯器並不會報錯，並且ValueTask還能夠轉換爲Task，畢竟是個包裝器嘛。

來看看ValueTask的源碼：

也就是說若是咱們不是經過同步的方式直接獲得結果，而是對Task的包裝的話，獲取ValueTask結果的內部其實仍是經過Task在進行操做。

因此若是異步操做須要返回Task的狀況下，咱們將返回值更改成ValueTask反而增大了內存存儲量（有一個Task對象，又有一個ValueTask對象）。

那麼？異步的狀況我也想避免沒必要要的開銷怎麼辦呢？ 可能您發現了在ValueTask裏面還出現了另外的一個東西：IValueTaskSource 。

本文因爲篇幅有限，因此只能在後期爲你們帶來該接口的介紹（雖然有點吊胃口哈，不過這確實超綱了😭），若是您有興趣，能夠參考如下Stephen在文中所說起到的有關IValueTaskSource的部分。

總結

因此，到這裏咱們大體瞭解了ValueTask出現的目的，以及它和Task的區別。您能夠想一下，您如今所作的項目中是否能夠引入ValueTask，雖然它在core 2.0以後引入，可是因爲.NET standard的特性，core和farmework都可以使用它。

如下是ValueTask使用的一些誤區，是摘自MSDN，若是您看懂了本篇的內容，您就能夠很容易知道它爲何不能這麼使用。對了，因爲MSDN翻譯問題，因此這裏仍是英文。（再次說一句，翻譯扣雞腿）。

對了，小聲說一句：「噓，點波關注哈」

The following operations should never be performed on a ValueTask<TResult> instance:

• Awaiting the instance multiple times.
• Calling AsTask multiple times.
• Using .Result or .GetAwaiter().GetResult() when the operation hasn't yet completed, or using them multiple times.
• Using more than one of these techniques to consume the instance.