【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的特性中,引入了 異步流 的概念。它在原有的同步迭代器的基礎上,擴充了異步的迭代器版本:

IAsyncEnumerableIAsyncEnumerator

如果您還不瞭解同步的迭代器接口,可以查看本系列的 上一篇文章

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

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。二位秋名山車神的競速之路:

x

如果您足夠仔細,您會發現我上面說的是同步的情況。 “???納尼,我用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的源碼:

1
2

也就是說如果我們不是通過同步的方式直接得到結果,而是對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.
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章