C# 迭代器

接《async/await 在 C# 語(yǔ)言中是如何工作的？（上）》，今天我們繼續(xù)介紹 C# 迭代器和 async/await under the covers。

這個(gè)解決方案的伏筆實(shí)際上是在 Task 出現(xiàn)的幾年前，即 C# 2.0，當(dāng)時(shí)它增加了對(duì)迭代器的支持。

迭代器允許你編寫(xiě)一個(gè)方法，然后由編譯器用來(lái)實(shí)現(xiàn) IEnumerable<T> 和/或 IEnumerator<T>。例如，如果我想創(chuàng)建一個(gè)產(chǎn)生斐波那契數(shù)列的枚舉數(shù)，我可以這樣寫(xiě):

public static IEnumerable<int> Fib(){
    int prev = 0, next = 1;
    yield return prev;
    yield return next;
    while (true)
    {
        int sum = prev + next;
        yield return sum;
        prev = next;
        next = sum;
    }}

然后我可以用 foreach 枚舉它:

foreach (int i in Fib()){
    if (i > 100) break;
    Console.Write($"{i} ");}

我可以通過(guò)像 System.Linq.Enumerable 上的組合器將它與其他 IEnumerable<T> 進(jìn)行組合：

foreach (int i in Fib().Take(12)){
    Console.Write($"{i} ");}

或者我可以直接通過(guò) IEnumerator<T> 來(lái)手動(dòng)枚舉它：

using IEnumerator<int> e = Fib().GetEnumerator();while (e.MoveNext()){
    int i = e.Current;
    if (i > 100) break;
    Console.Write($"{i} ");}

以上所有的結(jié)果是這樣的輸出:

0 1 1 2 3 5 8 13 21 34 55 89

真正有趣的是，為了實(shí)現(xiàn)上述目標(biāo)，我們需要能夠多次進(jìn)入和退出 Fib 方法。我們調(diào)用 MoveNext，它進(jìn)入方法，然后該方法執(zhí)行，直到它遇到 yield return，此時(shí)對(duì) MoveNext 的調(diào)用需要返回 true，隨后對(duì) Current 的訪問(wèn)需要返回 yield value。然后我們?cè)俅握{(diào)用 MoveNext，我們需要能夠在 Fib 中從我們上次停止的地方開(kāi)始，并且保持上次調(diào)用的所有狀態(tài)不變。迭代器實(shí)際上是由 C# 語(yǔ)言/編譯器提供的協(xié)程，編譯器將 Fib 迭代器擴(kuò)展為一個(gè)成熟的狀態(tài)機(jī)。

所有關(guān)于 Fib 的邏輯現(xiàn)在都在 MoveNext 方法中，但是作為跳轉(zhuǎn)表的一部分，它允許實(shí)現(xiàn)分支到它上次離開(kāi)的位置，這在枚舉器類型上生成的狀態(tài)字段中被跟蹤。而我寫(xiě)的局部變量，如 prev、next 和 sum，已經(jīng)被 "提升 "為枚舉器上的字段，這樣它們就可以在調(diào)用 MoveNext 時(shí)持續(xù)存在。

在我之前的例子中，我展示的最后一種枚舉形式涉及手動(dòng)使用 IEnumerator<T>。在那個(gè)層面上，我們手動(dòng)調(diào)用 MoveNext()，決定何時(shí)是重新進(jìn)入循環(huán)程序的適當(dāng)時(shí)機(jī)。但是，如果不這樣調(diào)用它，而是讓 MoveNext 的下一次調(diào)用實(shí)際成為異步操作完成時(shí)執(zhí)行的延續(xù)工作的一部分呢？如果我可以 yield 返回一些代表異步操作的東西，并讓消耗代碼將 continuation 連接到該 yield 對(duì)象，然后在該 continuation 執(zhí)行 MoveNext 時(shí)會(huì)怎么樣？使用這種方法，我可以編寫(xiě)一個(gè)輔助方法:

static Task IterateAsync(IEnumerable<Task> tasks){
    var tcs = new TaskCompletionSource();
    IEnumerator<Task> e = tasks.GetEnumerator();
    void Process()
    {
        try
        {
            if (e.MoveNext())
            {
                e.Current.ContinueWith(t => Process());
                return;
            }
        }
        catch (Exception e)
        {
            tcs.SetException(e);
            return;
        }
        tcs.SetResult();
    };
    Process();
    return tcs.Task;}

現(xiàn)在變得有趣了。我們得到了一個(gè)可迭代的任務(wù)列表。每次我們 MoveNext 到下一個(gè) Task 并獲得一個(gè)時(shí)，我們將該任務(wù)的 continuation 連接起來(lái)；當(dāng)這個(gè) Task 完成時(shí)，它只會(huì)回過(guò)頭來(lái)調(diào)用執(zhí)行 MoveNext、獲取下一個(gè) Task 的相同邏輯，以此類推。這是建立在將 Task 作為任何異步操作的單一表示的思想之上的，所以我們輸入的枚舉表可以是一個(gè)任何異步操作的序列。這樣的序列是從哪里來(lái)的呢?當(dāng)然是通過(guò)迭代器。

還記得我們之前的 CopyStreamToStream 例子嗎？考慮一下這個(gè)：

static Task CopyStreamToStreamAsync(Stream source, Stream destination){
    return IterateAsync(Impl(source, destination));
    static IEnumerable<Task> Impl(Stream source, Stream destination)
    {
        var buffer = new byte[0x1000];
        while (true)
        {
            Task<int> read = source.ReadAsync(buffer, 0, buffer.Length);
            yield return read;
            int numRead = read.Result;
            if (numRead <= 0)
            {
                break;
            }
            Task write = destination.WriteAsync(buffer, 0, numRead);
            yield return write;
            write.Wait();
        }
    }}

我們正在調(diào)用那個(gè) IterateAsync 助手，而我們提供給它的枚舉表是由一個(gè)處理所有控制流的迭代器產(chǎn)生的。它調(diào)用 Stream.ReadAsync 然后 yield 返回 Task；yield task 在調(diào)用 MoveNext 之后會(huì)被傳遞給 IterateAsync，而 IterateAsync 會(huì)將一個(gè) continuation 掛接到那個(gè) task 上，當(dāng)它完成時(shí)，它會(huì)回調(diào) MoveNext 并在 yield 之后回到這個(gè)迭代器。此時(shí)，Impl 邏輯獲得方法的結(jié)果，調(diào)用 WriteAsync，并再次生成它生成的 Task。以此類推。

這就是 C# 和 .NET 中 async/await 的開(kāi)始。

在 C# 編譯器中支持迭代器和 async/await 的邏輯中，大約有95%左右的邏輯是共享的。不同的語(yǔ)法，不同的類型，但本質(zhì)上是相同的轉(zhuǎn)換。

事實(shí)上，在 async/await 出現(xiàn)之前，一些開(kāi)發(fā)人員就以這種方式使用迭代器進(jìn)行異步編程。在實(shí)驗(yàn)性的 Axum 編程語(yǔ)言中也有類似的轉(zhuǎn)換原型，這是 C# 支持異步的關(guān)鍵靈感來(lái)源。Axum 提供了一個(gè)可以放在方法上的 async 關(guān)鍵字，就像 C# 中的 async 一樣。

Task 還不普遍，所以在異步方法中，Axum 編譯器啟發(fā)式地將同步方法調(diào)用與 APM 對(duì)應(yīng)的方法相匹配，例如，如果它看到你調(diào)用 stream.Read，它會(huì)找到并利用相應(yīng)的 stream.BeginRead 和 stream.EndRead 方法，合成適當(dāng)?shù)奈袀鬟f給 Begin 方法，同時(shí)還為定義為可組合的 async 方法生成完整的 APM 實(shí)現(xiàn)。它甚至還集成了 SynchronizationContext！雖然 Axum 最終被擱置，但它為 C# 中的 async/await 提供了一個(gè)很棒的原型。

async/await under the covers

現(xiàn)在我們知道了我們是如何做到這一點(diǎn)的，讓我們深入研究它實(shí)際上是如何工作的。作為參考，下面是我們的同步方法示例:

public void CopyStreamToStream(Stream source, Stream destination){
    var buffer = new byte[0x1000];
    int numRead;
    while ((numRead = source.Read(buffer, 0, buffer.Length)) != 0)
    {
        destination.Write(buffer, 0, numRead);
    }}

下面是 async/await 對(duì)應(yīng)的方法:

public async Task CopyStreamToStreamAsync(Stream source, Stream destination){
    var buffer = new byte[0x1000];
    int numRead;
    while ((numRead = await source.ReadAsync(buffer, 0, buffer.Length)) != 0)
    {
        await destination.WriteAsync(buffer, 0, numRead);
    }}

簽名從 void 變成了 async Task，我們分別調(diào)用了 ReadAsync 和 WriteAsync，而不是 Read 和 Write，這兩個(gè)操作都帶 await 前綴。編譯器和核心庫(kù)接管了其余部分，從根本上改變了代碼實(shí)際執(zhí)行的方式。讓我們深入了解一下是如何做到的。

編譯器轉(zhuǎn)換

我們已經(jīng)看到，和迭代器一樣，編譯器基于狀態(tài)機(jī)重寫(xiě)了 async 方法。我們?nèi)匀挥幸粋€(gè)與開(kāi)發(fā)人員寫(xiě)的簽名相同的方法(public Task CopyStreamToStreamAsync(Stream source, Stream destination))，但該方法的主體完全不同:

[AsyncStateMachine(typeof(<CopyStreamToStreamAsync>d__0))]public Task CopyStreamToStreamAsync(Stream source, Stream destination){
    <CopyStreamToStreamAsync>d__0 stateMachine = default;
    stateMachine.<>t__builder = AsyncTaskMethodBuilder.Create();
    stateMachine.source = source;
    stateMachine.destination = destination;
    stateMachine.<>1__state = -1;
    stateMachine.<>t__builder.Start(ref stateMachine);
    return stateMachine.<>t__builder.Task;}
private struct <CopyStreamToStreamAsync>d__0 : IAsyncStateMachine{
    public int <>1__state;
    public AsyncTaskMethodBuilder <>t__builder;
    public Stream source;
    public Stream destination;
    private byte[] <buffer>5__2;
    private TaskAwaiter <>u__1;
    private TaskAwaiter<int> <>u__2;
    ...}

注意，與開(kāi)發(fā)人員所寫(xiě)的簽名的唯一區(qū)別是缺少 async 關(guān)鍵字本身。Async 實(shí)際上不是方法簽名的一部分；就像 unsafe 一樣，當(dāng)你把它放在方法簽名中，你是在表達(dá)方法的實(shí)現(xiàn)細(xì)節(jié)，而不是作為契約的一部分實(shí)際公開(kāi)出來(lái)的東西。使用 async/await 實(shí)現(xiàn) task -return 方法是實(shí)現(xiàn)細(xì)節(jié)。

編譯器已經(jīng)生成了一個(gè)名為 <CopyStreamToStreamAsync>d__0 的結(jié)構(gòu)體，并且它在堆棧上對(duì)該結(jié)構(gòu)體的實(shí)例進(jìn)行了零初始化。重要的是，如果異步方法同步完成，該狀態(tài)機(jī)將永遠(yuǎn)不會(huì)離開(kāi)堆棧。這意味著沒(méi)有與狀態(tài)機(jī)相關(guān)的分配，除非該方法需要異步完成，也就是說(shuō)它需要等待一些尚未完成的任務(wù)。稍后會(huì)有更多關(guān)于這方面的內(nèi)容。

該結(jié)構(gòu)體是方法的狀態(tài)機(jī)，不僅包含開(kāi)發(fā)人員編寫(xiě)的所有轉(zhuǎn)換邏輯，還包含用于跟蹤該方法中當(dāng)前位置的字段，以及編譯器從方法中提取的所有“本地”狀態(tài)，這些狀態(tài)需要在 MoveNext 調(diào)用之間生存。它在邏輯上等價(jià)于迭代器中的 IEnumerable<T>/IEnumerator<T> 實(shí)現(xiàn)。(請(qǐng)注意，我展示的代碼來(lái)自發(fā)布版本；在調(diào)試構(gòu)建中，C# 編譯器將實(shí)際生成這些狀態(tài)機(jī)類型作為類，因?yàn)檫@樣做可以幫助某些調(diào)試工作)。

在初始化狀態(tài)機(jī)之后，我們看到對(duì) AsyncTaskMethodBuilder.Create() 的調(diào)用。雖然我們目前關(guān)注的是 Tasks，但 C# 語(yǔ)言和編譯器允許從異步方法返回任意類型(“task-like”類型)，例如，我可以編寫(xiě)一個(gè)方法 public async MyTask CopyStreamToStreamAsync，只要我們以適當(dāng)?shù)姆绞綌U(kuò)展我們前面定義的 MyTask，它就能順利編譯。這種適當(dāng)性包括聲明一個(gè)相關(guān)的“builder”類型，并通過(guò) AsyncMethodBuilder 屬性將其與該類型關(guān)聯(lián)起來(lái):

[AsyncMethodBuilder(typeof(MyTaskMethodBuilder))]public class MyTask{
    ...}
public struct MyTaskMethodBuilder{
    public static MyTaskMethodBuilder Create() { ... }
    public void Start<TStateMachine>(ref TStateMachine stateMachine) where TStateMachine : IAsyncStateMachine { ... }
    public void SetStateMachine(IAsyncStateMachine stateMachine) { ... }
    public void SetResult() { ... }
    public void SetException(Exception exception) { ... }
    public void AwaitOnCompleted<TAwaiter, TStateMachine>(
        ref TAwaiter awaiter, ref TStateMachine stateMachine)
        where TAwaiter : INotifyCompletion
        where TStateMachine : IAsyncStateMachine { ... }
    public void AwaitUnsafeOnCompleted<TAwaiter, TStateMachine>(
        ref TAwaiter awaiter, ref TStateMachine stateMachine)
        where TAwaiter : ICriticalNotifyCompletion
        where TStateMachine : IAsyncStateMachine { ... }
    public MyTask Task { get { ... } }}

在這種情況下，這樣的“builder”知道如何創(chuàng)建該類型的實(shí)例(Task 屬性)，如何成功完成并在適當(dāng)?shù)那闆r下有結(jié)果(SetResult)或有異常(SetException)，以及如何處理連接等待尚未完成的事務(wù)的延續(xù)(AwaitOnCompleted/AwaitUnsafeOnCompleted)。在 System.Threading.Tasks.Task 的情況下，它默認(rèn)與 AsyncTaskMethodBuilder 相關(guān)聯(lián)。通常情況下，這種關(guān)聯(lián)是通過(guò)應(yīng)用在類型上的 [AsyncMethodBuilder(…)] 屬性提供的，但在 C# 中，Task 是已知的，因此實(shí)際上沒(méi)有該屬性。因此，編譯器已經(jīng)讓構(gòu)建器使用這個(gè)異步方法，并使用模式中的 Create 方法構(gòu)建它的實(shí)例。請(qǐng)注意，與狀態(tài)機(jī)一樣，AsyncTaskMethodBuilder 也是一個(gè)結(jié)構(gòu)體，因此這里也沒(méi)有內(nèi)存分配。

然后用這個(gè)入口點(diǎn)方法的參數(shù)填充狀態(tài)機(jī)。這些參數(shù)需要能夠被移動(dòng)到 MoveNext 中的方法體訪問(wèn)，因此這些參數(shù)需要存儲(chǔ)在狀態(tài)機(jī)中，以便后續(xù)調(diào)用 MoveNext 時(shí)代碼可以引用它們。該狀態(tài)機(jī)也被初始化為初始-1狀態(tài)。如果 MoveNext 被調(diào)用且狀態(tài)為-1，那么邏輯上我們將從方法的開(kāi)始處開(kāi)始。

現(xiàn)在是最不顯眼但最重要的一行：調(diào)用構(gòu)建器的 Start 方法。這是模式的另一部分，必須在 async 方法的返回位置所使用的類型上公開(kāi)，它用于在狀態(tài)機(jī)上執(zhí)行初始的 MoveNext。構(gòu)建器的 Start 方法實(shí)際上是這樣的:

public void Start<TStateMachine>(ref TStateMachine stateMachine) where TStateMachine : IAsyncStateMachine{
    stateMachine.MoveNext();}

例如，調(diào)用 stateMachine.<>t__builder.Start(ref stateMachine); 實(shí)際上只是調(diào)用 stateMachine.MoveNext()。在這種情況下，為什么編譯器不直接發(fā)出這個(gè)信號(hào)呢？為什么還要有 Start 呢？答案是，Start 的內(nèi)容比我所說(shuō)的要多一點(diǎn)。但為此，我們需要簡(jiǎn)單地了解一下 ExecutionContext。

? ExecutionContext

我們都熟悉在方法之間傳遞狀態(tài)。調(diào)用一個(gè)方法，如果該方法指定了形參，就使用實(shí)參調(diào)用該方法，以便將該數(shù)據(jù)傳遞給被調(diào)用方。這是顯式傳遞數(shù)據(jù)。但還有其他更隱蔽的方法。例如，方法可以是無(wú)參數(shù)的，但可以指定在調(diào)用方法之前填充某些特定的靜態(tài)字段，然后從那里獲取狀態(tài)。這個(gè)方法的簽名中沒(méi)有任何東西表明它接收參數(shù)，因?yàn)樗_實(shí)沒(méi)有：只是調(diào)用者和被調(diào)用者之間有一個(gè)隱含的約定，即調(diào)用者可能填充某些內(nèi)存位置，而被調(diào)用者可能讀取這些內(nèi)存位置。被調(diào)用者和調(diào)用者甚至可能沒(méi)有意識(shí)到它的發(fā)生，如果他們是中介，方法 A 可能填充靜態(tài)信息，然后調(diào)用 B, B 調(diào)用 C, C 調(diào)用 D，最終調(diào)用 E，讀取這些靜態(tài)信息的值。這通常被稱為“環(huán)境”數(shù)據(jù)：它不是通過(guò)參數(shù)傳遞給你的，而是掛在那里，如果需要的話，你可以使用。

我們可以更進(jìn)一步，使用線程局部狀態(tài)。線程局部狀態(tài)，在 .NET 中是通過(guò)屬性為 [ThreadStatic] 的靜態(tài)字段或通過(guò) ThreadLocal<T> 類型實(shí)現(xiàn)的，可以以相同的方式使用，但數(shù)據(jù)僅限于當(dāng)前執(zhí)行的線程，每個(gè)線程都能夠擁有這些字段的自己的隔離副本。這樣，您就可以填充線程靜態(tài)，進(jìn)行方法調(diào)用，然后在方法完成后將更改還原到線程靜態(tài)，從而啟用這種隱式傳遞數(shù)據(jù)的完全隔離形式。

如果我們進(jìn)行異步方法調(diào)用，而異步方法中的邏輯想要訪問(wèn)環(huán)境數(shù)據(jù)，它會(huì)怎么做?如果數(shù)據(jù)存儲(chǔ)在常規(guī)靜態(tài)中，異步方法將能夠訪問(wèn)它，但一次只能有一個(gè)這樣的方法在運(yùn)行，因?yàn)槎鄠€(gè)調(diào)用者在寫(xiě)入這些共享靜態(tài)字段時(shí)可能會(huì)覆蓋彼此的狀態(tài)。如果數(shù)據(jù)存儲(chǔ)在線程靜態(tài)信息中，異步方法將能夠訪問(wèn)它，但只有在調(diào)用線程停止同步運(yùn)行之前；如果它將 continuation 連接到它發(fā)起的某個(gè)操作，并且該 continuation 最終在某個(gè)其他線程上運(yùn)行，那么它將不再能夠訪問(wèn)線程靜態(tài)信息。即使它碰巧運(yùn)行在同一個(gè)線程上，無(wú)論是偶然的還是由于調(diào)度器的強(qiáng)制，在它這樣做的時(shí)候，數(shù)據(jù)可能已經(jīng)被該線程發(fā)起的其他操作刪除和/或覆蓋。對(duì)于異步，我們需要一種機(jī)制，允許任意環(huán)境數(shù)據(jù)在這些異步點(diǎn)上流動(dòng)，這樣在 async 方法的整個(gè)邏輯中，無(wú)論何時(shí)何地運(yùn)行，它都可以訪問(wèn)相同的數(shù)據(jù)。

輸入 ExecutionContext。ExecutionContext 類型是異步操作和異步操作之間傳遞環(huán)境數(shù)據(jù)的媒介。它存在于一個(gè) [ThreadStatic] 中，但是當(dāng)某些異步操作啟動(dòng)時(shí)，它被“捕獲”(從該線程靜態(tài)中讀取副本的一種奇特的方式)，存儲(chǔ)，然后當(dāng)該異步操作的延續(xù)被運(yùn)行時(shí)，ExecutionContext 首先被恢復(fù)到即將運(yùn)行該操作的線程中的 [ThreadStatic] 中。ExecutionContext 是實(shí)現(xiàn) AsyncLocal<T> 的機(jī)制(事實(shí)上，在 .NET Core 中，ExecutionContext 完全是關(guān)于 AsyncLocal<T> 的，僅此而已)，例如，如果你將一個(gè)值存儲(chǔ)到 AsyncLocal<T> 中，然后例如隊(duì)列一個(gè)工作項(xiàng)在 ThreadPool 上運(yùn)行，該值將在該 AsyncLocal<T> 中可見(jiàn)，在該工作項(xiàng)上運(yùn)行：

var number = new AsyncLocal<int>();
number.Value = 42;ThreadPool.QueueUserWorkItem(_ => Console.WriteLine(number.Value));
number.Value = 0;
Console.ReadLine();

這段代碼每次運(yùn)行時(shí)都會(huì)打印42。在我們對(duì)委托進(jìn)行排隊(duì)之后，我們將 AsyncLocal<int> 的值重置為0，這無(wú)關(guān)緊要，因?yàn)?ExecutionContext 是作為 QueueUserWorkItem 調(diào)用的一部分被捕獲的，而該捕獲包含了當(dāng)時(shí) AsyncLocal<int> 的狀態(tài)。

? Back To Start

當(dāng)我在寫(xiě) AsyncTaskMethodBuilder.Start 的實(shí)現(xiàn)時(shí)，我們繞道討論了 ExecutionContext，我說(shuō)這是有效的：

public void Start<TStateMachine>(ref TStateMachine stateMachine) where TStateMachine : IAsyncStateMachine{
    stateMachine.MoveNext();}

然后建議我簡(jiǎn)化一下。這種簡(jiǎn)化忽略了一個(gè)事實(shí)，即該方法實(shí)際上需要將 ExecutionContext 考慮在內(nèi)，因此更像是這樣:

public void Start<TStateMachine>(ref TStateMachine stateMachine) where TStateMachine : IAsyncStateMachine{
    ExecutionContext previous = Thread.CurrentThread._executionContext; // [ThreadStatic] field
    try
    {
        stateMachine.MoveNext();
    }
    finally
    {
        ExecutionContext.Restore(previous); // internal helper
    }}

這里不像我之前建議的那樣只調(diào)用 statemmachine .MoveNext()，而是在這里做了一個(gè)動(dòng)作：獲取當(dāng)前的 ExecutionContext，再調(diào)用 MoveNext，然后在它完成時(shí)將當(dāng)前上下文重置為調(diào)用 MoveNext 之前的狀態(tài)。

這樣做的原因是為了防止異步方法將環(huán)境數(shù)據(jù)泄露給調(diào)用者。一個(gè)示例方法說(shuō)明了為什么這很重要:

async Task ElevateAsAdminAndRunAsync(){
    using (WindowsIdentity identity = LoginAdmin())
    {
        using (WindowsImpersonationContext impersonatedUser = identity.Impersonate())
        {
            await DoSensitiveWorkAsync();
        }
    }}

“冒充”是將當(dāng)前用戶的環(huán)境信息改為其他人的；這讓代碼可以代表其他人，使用他們的特權(quán)和訪問(wèn)權(quán)限。在 .NET 中，這種模擬跨異步操作流動(dòng)，這意味著它是 ExecutionContext 的一部分。現(xiàn)在想象一下，如果 Start 沒(méi)有恢復(fù)之前的上下文，考慮下面的代碼:

Task t = ElevateAsAdminAndRunAsync();PrintUser();await t;

這段代碼可以發(fā)現(xiàn)，ElevateAsAdminAndRunAsync 中修改的 ExecutionContext 在 ElevateAsAdminAndRunAsync 返回到它的同步調(diào)用者之后仍然存在(這發(fā)生在該方法第一次等待尚未完成的內(nèi)容時(shí))。這是因?yàn)樵谡{(diào)用 Impersonate 之后，我們調(diào)用了 DoSensitiveWorkAsync 并等待它返回的任務(wù)。假設(shè)任務(wù)沒(méi)有完成，它將導(dǎo)致對(duì) ElevateAsAdminAndRunAsync 的調(diào)用 yield 并返回到調(diào)用者，模擬仍然在當(dāng)前線程上有效。這不是我們想要的。因此，Start 設(shè)置了這個(gè)保護(hù)機(jī)制，以確保對(duì) ExecutionContext 的任何修改都不會(huì)從同步方法調(diào)用中流出，而只會(huì)隨著方法執(zhí)行的任何后續(xù)工作一起流出。

? MoveNext

因此，調(diào)用了入口點(diǎn)方法，初始化了狀態(tài)機(jī)結(jié)構(gòu)體，調(diào)用了 Start，然后調(diào)用了 MoveNext。什么是 MoveNext？這個(gè)方法包含了開(kāi)發(fā)者方法中所有的原始邏輯，但做了一大堆修改。讓我們先看看這個(gè)方法的腳手架。下面是編譯器為我們的方法生成的反編譯版本，但刪除了生成的 try 塊中的所有內(nèi)容:

private void MoveNext(){
    try
    {
        ... // all of the code from the CopyStreamToStreamAsync method body, but not exactly as it was written
    }
    catch (Exception exception)
    {
        <>1__state = -2;
        <buffer>5__2 = null;
        <>t__builder.SetException(exception);
        return;
    }
    <>1__state = -2;
    <buffer>5__2 = null;
    <>t__builder.SetResult();}

無(wú)論 MoveNext 執(zhí)行什么其他工作，當(dāng)所有工作完成后，它都有責(zé)任完成 async Task 方法返回的任務(wù)。如果 try 代碼塊的主體拋出了未處理的異常，那么任務(wù)就會(huì)拋出該異常。如果 async 方法成功到達(dá)它的終點(diǎn)(相當(dāng)于同步方法返回)，它將成功完成返回的任務(wù)。在任何一種情況下，它都將設(shè)置狀態(tài)機(jī)的狀態(tài)以表示完成。(我有時(shí)聽(tīng)到開(kāi)發(fā)人員從理論上說(shuō)，當(dāng)涉及到異常時(shí)，在第一個(gè) await 之前拋出的異常和在第一個(gè) await 之后拋出的異常是有區(qū)別的……基于上述，應(yīng)該清楚情況并非如此。任何未在 async 方法中處理的異常，不管它在方法的什么位置，也不管方法是否產(chǎn)生了結(jié)果，都會(huì)在上面的 catch 塊中結(jié)束，然后被捕獲的異常會(huì)存儲(chǔ)在 async 方法返回的任務(wù)中。)

還要注意，這個(gè)完成過(guò)程是通過(guò)構(gòu)建器完成的，使用它的 SetException 和 SetResult 方法，這是編譯器預(yù)期的構(gòu)建器模式的一部分。如果 async 方法之前已經(jīng)掛起了，那么構(gòu)建器將不得不再掛起處理中創(chuàng)建一個(gè) Task (稍后我們會(huì)看到如何以及在哪里執(zhí)行)，在這種情況下，調(diào)用 SetException/SetResult 將完成該任務(wù)。然而，如果 async 方法之前沒(méi)有掛起，那么我們還沒(méi)有創(chuàng)建任務(wù)或向調(diào)用者返回任何東西，因此構(gòu)建器在生成任務(wù)時(shí)有更大的靈活性。如果你還記得之前在入口點(diǎn)方法中，它做的最后一件事是將任務(wù)返回給調(diào)用者，它通過(guò)訪問(wèn)構(gòu)建器的 Task 屬性返回結(jié)果：

public Task CopyStreamToStreamAsync(Stream source, Stream destination)
{
    ...
    return stateMachine.<>t__builder.Task;
}

構(gòu)建器知道該方法是否掛起過(guò)，如果掛起了，它就會(huì)返回已經(jīng)創(chuàng)建的任務(wù)。如果方法從未掛起，而且構(gòu)建器還沒(méi)有任務(wù)，那么它可以在這里創(chuàng)建一個(gè)完成的任務(wù)。在成功完成的情況下，它可以直接使用 Task.CompletedTask 而不是分配一個(gè)新的任務(wù)，避免任何分配。如果是一般的任務(wù) <TResult>，構(gòu)建者可以直接使用 Task.FromResult<TResult>（TResult result）。

構(gòu)建器還可以對(duì)它創(chuàng)建的對(duì)象進(jìn)行任何它認(rèn)為合適的轉(zhuǎn)換。例如，Task 實(shí)際上有三種可能的最終狀態(tài):成功、失敗和取消。AsyncTaskMethodBuilder 的 SetException 方法處理特殊情況 OperationCanceledException，將任務(wù)轉(zhuǎn)換為 TaskStatus。如果提供的異常是 OperationCanceledException 或源自 OperationCanceledException，則將任務(wù)轉(zhuǎn)換為 TaskStatus.Canceled 最終狀態(tài)；否則，任務(wù)以 TaskStatus.Faulted 結(jié)束；這種區(qū)別在使用代碼時(shí)往往不明顯；因?yàn)闊o(wú)論異常被標(biāo)記為取消還是故障，都會(huì)被存儲(chǔ)到 Task 中，等待該任務(wù)的代碼將無(wú)法觀察到狀態(tài)之間的區(qū)別（無(wú)論哪種情況，原始異常都會(huì)被傳播）...... 它只影響與任務(wù)直接交互的代碼，例如通過(guò) ContinueWith，它具有重載，允許僅為完成狀態(tài)的子集調(diào)用 continuation。

現(xiàn)在我們了解了生命周期方面的內(nèi)容，下面是在 MoveNext 的 try 塊內(nèi)填寫(xiě)的所有內(nèi)容：

private void MoveNext()
{
    try
    {
        int num = <>1__state;
        TaskAwaiter<int> awaiter;
        if (num != 0)
        {
            if (num != 1)
            {
                <buffer>5__2 = new byte[4096];
                goto IL_008b;
            }
            awaiter = <>u__2;
            <>u__2 = default(TaskAwaiter<int>);
            num = (<>1__state = -1);
            goto IL_00f0;
        }
        TaskAwaiter awaiter2 = <>u__1;
        <>u__1 = default(TaskAwaiter);
        num = (<>1__state = -1);
        IL_0084:
        awaiter2.GetResult();
        IL_008b:
        awaiter = source.ReadAsync(<buffer>5__2, 0, <buffer>5__2.Length).GetAwaiter();
        if (!awaiter.IsCompleted)
        {
            num = (<>1__state = 1);
            <>u__2 = awaiter;
            <>t__builder.AwaitUnsafeOnCompleted(ref awaiter, ref this);
            return;
        }
        IL_00f0:
        int result;
        if ((result = awaiter.GetResult()) != 0)
        {
            awaiter2 = destination.WriteAsync(<buffer>5__2, 0, result).GetAwaiter();
            if (!awaiter2.IsCompleted)
            {
                num = (<>1__state = 0);
                <>u__1 = awaiter2;
                <>t__builder.AwaitUnsafeOnCompleted(ref awaiter2, ref this);
                return;
            }
            goto IL_0084;
        }
    }
    catch (Exception exception)
    {
        <>1__state = -2;
        <buffer>5__2 = null;
        <>t__builder.SetException(exception);
        return;
    }
    <>1__state = -2;
    <buffer>5__2 = null;
    <>t__builder.SetResult();
}

這種復(fù)雜的情況可能感覺(jué)有點(diǎn)熟悉。還記得我們基于 APM 手動(dòng)實(shí)現(xiàn)的 BeginCopyStreamToStream 有多復(fù)雜嗎？這沒(méi)有那么復(fù)雜，但也更好，因?yàn)榫幾g器為我們做了這些工作，以延續(xù)傳遞的形式重寫(xiě)了方法，同時(shí)確保為這些延續(xù)保留了所有必要的狀態(tài)。即便如此，我們也可以瞇著眼睛跟著走。請(qǐng)記住，狀態(tài)在入口點(diǎn)被初始化為-1。然后我們進(jìn)入 MoveNext，發(fā)現(xiàn)這個(gè)狀態(tài)(現(xiàn)在存儲(chǔ)在本地 num 中)既不是0也不是1，因此執(zhí)行創(chuàng)建臨時(shí)緩沖區(qū)的代碼，然后跳轉(zhuǎn)到標(biāo)簽 IL_008b，在這里調(diào)用 stream.ReadAsync。注意，在這一點(diǎn)上，我們?nèi)匀粡恼{(diào)用 MoveNext 同步運(yùn)行，因此從開(kāi)始到入口點(diǎn)都同步運(yùn)行，這意味著開(kāi)發(fā)者的代碼調(diào)用了 CopyStreamToStreamAsync，它仍然在同步執(zhí)行，還沒(méi)有返回一個(gè) Task 來(lái)表示這個(gè)方法的最終完成。

我們調(diào)用 Stream.ReadAsync，從中得到一個(gè) Task<int>。讀取可能是同步完成的，也可能是異步完成的，但速度快到現(xiàn)在已經(jīng)完成，也可能還沒(méi)有完成。不管怎么說(shuō)，我們有一個(gè)表示最終完成的 Task<int>，編譯器發(fā)出的代碼會(huì)檢查該 Task<int> 以決定如何繼續(xù)：如果該 Task<int> 確實(shí)已經(jīng)完成（不管它是同步完成還是只是在我們檢查時(shí)完成），那么這個(gè)方法的代碼就可以繼續(xù)同步運(yùn)行......當(dāng)我們可以在這里繼續(xù)運(yùn)行時(shí)，沒(méi)有必要花不必要的開(kāi)銷排隊(duì)處理該方法執(zhí)行的剩余部分。但是為了處理 Task<int> 還沒(méi)有完成的情況，編譯器需要發(fā)出代碼來(lái)為 Task 掛上一個(gè)延續(xù)。因此，它需要發(fā)出代碼，詢問(wèn)任務(wù) "你完成了嗎？" 它是否是直接與任務(wù)對(duì)話來(lái)問(wèn)這個(gè)問(wèn)題？

如果你在 C# 中唯一可以等待的東西是 System.Threading.Tasks.Task，這將是一種限制。同樣地，如果 C# 編譯器必須知道每一種可能被等待的類型，那也是一種限制。相反，C# 在這種情況下通常會(huì)做的是：它采用了一種 api 模式。代碼可以等待任何公開(kāi)適當(dāng)模式(“awaiter”模式)的東西(就像您可以等待任何提供適當(dāng)?shù)?ldquo;可枚舉”模式的東西一樣)。例如，我們可以增強(qiáng)前面寫(xiě)的 MyTask 類型來(lái)實(shí)現(xiàn) awaiter 模式:

class MyTask
{
    ...
    public MyTaskAwaiter GetAwaiter() => new MyTaskAwaiter { _task = this };
    public struct MyTaskAwaiter : ICriticalNotifyCompletion
    {
        internal MyTask _task;
        public bool IsCompleted => _task._completed;
        public void OnCompleted(Action continuation) => _task.ContinueWith(_ => continuation());
        public void UnsafeOnCompleted(Action continuation) => _task.ContinueWith(_ => continuation());
        public void GetResult() => _task.Wait();
    }
}

如果一個(gè)類型公開(kāi)了 getwaiter() 方法，就可以等待它，Task 就是這樣做的。這個(gè)方法需要返回一些內(nèi)容，而這些內(nèi)容又公開(kāi)了幾個(gè)成員，包括一個(gè) IsCompleted 屬性，用于在調(diào)用 IsCompleted 時(shí)檢查操作是否已經(jīng)完成。你可以看到正在發(fā)生的事情：在 IL_008b，從 ReadAsync 返回的任務(wù)已經(jīng)調(diào)用了 getwaiter，然后在 struct awaiter 實(shí)例上完成訪問(wèn)。如果 IsCompleted 返回 true，那么最終會(huì)執(zhí)行到 IL_00f0，在這里代碼會(huì)調(diào)用 awaiter 的另一個(gè)成員：GetResult()。如果操作失敗，GetResult() 負(fù)責(zé)拋出異常，以便將其傳播到 async 方法中的 await 之外；否則，GetResult() 負(fù)責(zé)返回操作的結(jié)果。在 ReadAsync 的例子中，如果結(jié)果為0，那么我們跳出讀寫(xiě)循環(huán)，到方法的末尾調(diào)用 SetResult，就完成了。

不過(guò)，回過(guò)頭來(lái)看一下，真正有趣的部分是，如果 IsCompleted 檢查實(shí)際上返回 false，會(huì)發(fā)生什么。如果它返回 true，我們就繼續(xù)處理循環(huán)，類似于在 APM 模式中 completedsynchronized 返回 true，Begin 方法的調(diào)用者負(fù)責(zé)繼續(xù)執(zhí)行，而不是回調(diào)函數(shù)。但是如果 IsCompleted 返回 false，我們需要暫停 async 方法的執(zhí)行，直到 await 操作完成。這意味著從 MoveNext 中返回，因?yàn)檫@是 Start 的一部分，我們?nèi)匀辉谌肟邳c(diǎn)方法中，這意味著將任務(wù)返回給調(diào)用者。但在發(fā)生任何事情之前，我們需要將 continuation 連接到正在等待的任務(wù)(注意，為了避免像在 APM 情況中那樣的 stack dives，如果異步操作在 IsCompleted 返回 false 后完成，但在我們連接 continuation 之前，continuation 仍然需要從調(diào)用線程異步調(diào)用，因此它將進(jìn)入隊(duì)列)。由于我們可以等待任何東西，我們不能直接與任務(wù)實(shí)例對(duì)話；相反，我們需要通過(guò)一些基于模式的方法來(lái)執(zhí)行此操作。

Awaiter 公開(kāi)了一個(gè)方法來(lái)連接 continuation。編譯器可以直接使用它，除了一個(gè)非常關(guān)鍵的問(wèn)題：continuation 到底應(yīng)該是什么?更重要的是，它應(yīng)該與什么對(duì)象相關(guān)聯(lián)?請(qǐng)記住，狀態(tài)機(jī)結(jié)構(gòu)體在棧上，我們當(dāng)前運(yùn)行的 MoveNext 調(diào)用是對(duì)該實(shí)例的方法調(diào)用。我們需要保存狀態(tài)機(jī)，以便在恢復(fù)時(shí)我們擁有所有正確的狀態(tài)，這意味著狀態(tài)機(jī)不能一直存在于棧中；它需要被復(fù)制到堆上的某個(gè)地方，因?yàn)闂Ｗ罱K將被用于該線程執(zhí)行的其他后續(xù)的、無(wú)關(guān)的工作。然后，延續(xù)需要在堆上的狀態(tài)機(jī)副本上調(diào)用 MoveNext 方法。

此外，ExecutionContext 也與此相關(guān)。狀態(tài)機(jī)需要確保存儲(chǔ)在 ExecutionContext 中的任何環(huán)境數(shù)據(jù)在暫停時(shí)被捕獲，然后在恢復(fù)時(shí)被應(yīng)用，這意味著延續(xù)也需要合并該 ExecutionContext。因此，僅僅在狀態(tài)機(jī)上創(chuàng)建一個(gè)指向 MoveNext 的委托是不夠的。這也是我們不想要的開(kāi)銷。如果當(dāng)我們掛起時(shí)，我們?cè)跔顟B(tài)機(jī)上創(chuàng)建了一個(gè)指向 MoveNext 的委托，那么每次這樣做我們都要對(duì)狀態(tài)機(jī)結(jié)構(gòu)進(jìn)行裝箱(即使它已經(jīng)作為其他對(duì)象的一部分在堆上)并分配一個(gè)額外的委托(委托的這個(gè)對(duì)象引用將是該結(jié)構(gòu)體的一個(gè)新裝箱的副本)。因此，我們需要做一個(gè)復(fù)雜的動(dòng)作，即確保我們只在方法第一次暫停執(zhí)行時(shí)將該結(jié)構(gòu)從堆棧中提升到堆中，而在其他時(shí)候都使用相同的堆對(duì)象作為 MoveNext 的目標(biāo)，并在這個(gè)過(guò)程中確保我們捕獲了正確的上下文，并在恢復(fù)時(shí)確保我們使用捕獲的上下文來(lái)調(diào)用該操作。

你可以在 C# 編譯器生成的代碼中看到，當(dāng)我們需要掛起時(shí)就會(huì)發(fā)生:

if (!awaiter.IsCompleted) // we need to suspend when IsCompleted is false
{
    <>1__state = 1;
    <>u__2 = awaiter;
    <>t__builder.AwaitUnsafeOnCompleted(ref awaiter, ref this);
    return;
}

我們將狀態(tài) id 存儲(chǔ)到 state 字段中，該 id 表示當(dāng)方法恢復(fù)時(shí)應(yīng)該跳轉(zhuǎn)到的位置。然后，我們將 awaiter 本身持久化到一個(gè)字段中，以便在恢復(fù)后可以使用它來(lái)調(diào)用 GetResult。然后在返回 MoveNext 調(diào)用之前，我們要做的最后一件事是調(diào)用 <>t__builder.AwaitUnsafeOnCompleted(ref awaiter, ref this)，要求構(gòu)建器為這個(gè)狀態(tài)機(jī)連接一個(gè) continuation 到 awaiter。

(注意，它調(diào)用構(gòu)建器的 AwaitUnsafeOnCompleted 而不是構(gòu)建器的 AwaitOnCompleted，因?yàn)?awaiter 實(shí)現(xiàn)了 iccriticalnotifycompletion；狀態(tài)機(jī)處理流動(dòng)的 ExecutionContext，所以我們不需要 awaiter，正如前面提到的，這樣做只會(huì)帶來(lái)重復(fù)和不必要的開(kāi)銷。)

AwaitUnsafeOnCompleted 方法的實(shí)現(xiàn)太復(fù)雜了，不能在這里詳述，所以我將總結(jié)它在 .NET Framework 上的作用:

1.它使用 ExecutionContext.Capture() 來(lái)獲取當(dāng)前上下文。

2.然后它分配一個(gè) MoveNextRunner 對(duì)象來(lái)包裝捕獲的上下文和裝箱的狀態(tài)機(jī)(如果這是該方法第一次掛起，我們還沒(méi)有狀態(tài)機(jī)，所以我們只使用 null 作為占位符)。

3.然后，它創(chuàng)建一個(gè)操作委托給該 MoveNextRunner 上的 Run 方法；這就是它如何能夠獲得一個(gè)委托，該委托將在捕獲的 ExecutionContext 的上下文中調(diào)用狀態(tài)機(jī)的 MoveNext。

4.如果這是該方法第一次掛起，我們還沒(méi)有裝箱的狀態(tài)機(jī)，所以此時(shí)它會(huì)將其裝箱，通過(guò)將實(shí)例存儲(chǔ)到本地類型的 IAsyncStateMachine 接口中，在堆上創(chuàng)建一個(gè)副本。然后，這個(gè)盒子會(huì)被存儲(chǔ)到已分配的 MoveNextRunner 中。

5.現(xiàn)在到了一個(gè)有些令人費(fèi)解的步驟。如果您查看狀態(tài)機(jī)結(jié)構(gòu)體的定義，它包含構(gòu)建器，public AsyncTaskMethodBuilder <>t__builder;，如果你查看構(gòu)建器的定義，它包含內(nèi)部的 IAsyncStateMachine m_stateMachine;。

構(gòu)建器需要引用裝箱的狀態(tài)機(jī)，以便在后續(xù)的掛起中它可以看到它已經(jīng)裝箱了狀態(tài)機(jī)，并且不需要再次這樣做。但是我們只是裝箱了狀態(tài)機(jī)，并且該狀態(tài)機(jī)包含一個(gè) m_stateMachine 字段為 null 的構(gòu)建器。我們需要改變裝箱狀態(tài)機(jī)的構(gòu)建器的 m_stateMachine 指向它的父容器。

為了實(shí)現(xiàn)這一點(diǎn)，編譯器生成的狀態(tài)機(jī)結(jié)構(gòu)體實(shí)現(xiàn)了 IAsyncStateMachine 接口，其中包括一個(gè) void SetStateMachine(IAsyncStateMachine stateMachine) ;方法，該狀態(tài)機(jī)結(jié)構(gòu)體包含了該接口方法的實(shí)現(xiàn):

private void SetStateMachine(IAsyncStateMachine stateMachine) =>
<>t__builder.SetStateMachine(stateMachine);

因此，構(gòu)建器對(duì)狀態(tài)機(jī)進(jìn)行裝箱，然后將裝箱傳遞給裝箱的 SetStateMachine 方法，該方法會(huì)調(diào)用構(gòu)建器的 SetStateMachine 方法，將裝箱存儲(chǔ)到字段中。

6.最后，我們有一個(gè)表示 continuation 的 Action，它被傳遞給 awaiter 的 UnsafeOnCompleted 方法。在 TaskAwaiter 的情況下，任務(wù)將將該操作存儲(chǔ)到任務(wù)的 continuation 列表中，這樣當(dāng)任務(wù)完成時(shí)，它將調(diào)用該操作，通過(guò) MoveNextRunner.Run 回調(diào)，通過(guò) ExecutionContext.Run 回調(diào)，最后調(diào)用狀態(tài)機(jī)的 MoveNext 方法重新進(jìn)入狀態(tài)機(jī)，并從它停止的地方繼續(xù)運(yùn)行。

這就是在 .NET Framework 中發(fā)生的事情，你可以在分析器中看到結(jié)果，例如通過(guò)運(yùn)行分配分析器來(lái)查看每個(gè) await 上的分配情況。讓我們看看這個(gè)愚蠢的程序，我寫(xiě)這個(gè)程序只是為了強(qiáng)調(diào)其中涉及的分配成本:

using System.Threading;
using System.Threading.Tasks;
class Program
{
    static async Task Main()
    {
        var al = new AsyncLocal<int>() { Value = 42 };
        for (int i = 0; i < 1000; i++)
        {
            await SomeMethodAsync();
        }
    }
    static async Task SomeMethodAsync()
    {
        for (int i = 0; i < 1000; i++)
        {
            await Task.Yield();
        }
    }
}

這個(gè)程序創(chuàng)建了一個(gè) AsyncLocal<int>，讓值42通過(guò)所有后續(xù)的異步操作。然后它調(diào)用 SomeMethodAsync 1000次，每次暫停/恢復(fù)1000次。在 Visual Studio 中，我使用  .NET Object Allocation Tracking profiler 運(yùn)行它，結(jié)果如下:

那是很多的分配！讓我們來(lái)研究一下它們的來(lái)源。

ExecutionContext。有超過(guò)一百萬(wàn)個(gè)這樣的內(nèi)容被分配。為什么?因?yàn)樵?.NET Framework 中，ExecutionContext 是一個(gè)可變的數(shù)據(jù)結(jié)構(gòu)。由于我們希望流轉(zhuǎn)一個(gè)異步操作被 fork 時(shí)的數(shù)據(jù)，并且我們不希望它在 fork 之后看到執(zhí)行的變更，我們需要復(fù)制 ExecutionContext。每個(gè)單獨(dú)的 fork 操作都需要這樣的副本，因此有1000次對(duì) SomeMethodAsync 的調(diào)用，每個(gè)調(diào)用都會(huì)暫停/恢復(fù)1000次，我們有100萬(wàn)個(gè) ExecutionContext 實(shí)例。

Action。類似地，每次我們等待尚未完成的任務(wù)時(shí)(我們的百萬(wàn)個(gè) await Task.Yield()s就是這種情況)，我們最終分配一個(gè)新的操作委托來(lái)傳遞給 awaiter 的 UnsafeOnCompleted 方法。

MoveNextRunner。同樣的，有一百萬(wàn)個(gè)這樣的例子，因?yàn)樵谇懊娴牟襟E大綱中，每次我們暫停時(shí)，我們都要分配一個(gè)新的 MoveNextRunner 來(lái)存儲(chǔ) Action和 ExecutionContext，以便使用后者來(lái)執(zhí)行前者。

LogicalCallContext。這些是 .NET Framework 上 AsyncLocal<T> 的實(shí)現(xiàn)細(xì)節(jié)；AsyncLocal<T> 將其數(shù)據(jù)存儲(chǔ)到 ExecutionContext 的“邏輯調(diào)用上下文”中，這是表示與 ExecutionContext 一起流動(dòng)的一般狀態(tài)的一種奇特方式。如果我們要復(fù)制一百萬(wàn)個(gè) ExecutionContext，我們也會(huì)復(fù)制一百萬(wàn)個(gè) LogicalCallContext。

QueueUserWorkItemCallback。每個(gè) Task.Yield() 都將一個(gè)工作項(xiàng)排隊(duì)到線程池中，導(dǎo)致分配了100萬(wàn)個(gè)工作項(xiàng)對(duì)象用于表示這100萬(wàn)個(gè)操作。

Task< VoidResult >。這里有一千個(gè)這樣的，所以至少我們脫離了"百萬(wàn)"俱樂(lè)部。每個(gè)異步完成的異步任務(wù)調(diào)用都需要分配一個(gè)新的 Task 實(shí)例來(lái)表示該調(diào)用的最終完成。

< SomeMethodAsync > d__1。這是編譯器生成的狀態(tài)機(jī)結(jié)構(gòu)的盒子。1000個(gè)方法掛起，1000個(gè)盒子出現(xiàn)。

QueueSegment / IThreadPoolWorkItem[]。有幾千個(gè)這樣的方法，從技術(shù)上講，它們與具體的異步方法無(wú)關(guān)，而是與線程池中的隊(duì)列工作有關(guān)。在 .NET 框架中，線程池的隊(duì)列是一個(gè)非循環(huán)段的鏈表。這些段不會(huì)被重用；對(duì)于長(zhǎng)度為 N 的段，一旦 N 個(gè)工作項(xiàng)被加入到該段的隊(duì)列中并從該段中退出，該段就會(huì)被丟棄并當(dāng)作垃圾回收。

這就是 .NET Framework。這是 .NET Core:

對(duì)于 .NET Framework 上的這個(gè)示例，有超過(guò)500萬(wàn)次分配，總共分配了大約145MB的內(nèi)存。對(duì)于 .NET Core 上的相同示例，只有大約1000個(gè)內(nèi)存分配，總共只有大約109KB。為什么這么少?

ExecutionContext。在 .NET Core 中，ExecutionContext 現(xiàn)在是不可變的。這樣做的缺點(diǎn)是，對(duì)上下文的每次更改，例如將值設(shè)置為 AsyncLocal<T>，都需要分配一個(gè)新的 ExecutionContext。然而，好處是，流動(dòng)的上下文比改變它更常見(jiàn)，而且由于 ExecutionContext 現(xiàn)在是不可變的，我們不再需要作為流動(dòng)的一部分進(jìn)行克隆。“捕獲”上下文實(shí)際上就是從字段中讀取它，而不是讀取它并復(fù)制其內(nèi)容。因此，流動(dòng)不僅比變化更常見(jiàn)，而且更便宜。

LogicalCallContext。這在 .NET Core 中已經(jīng)不存在了。在 .NET Core 中，ExecutionContext 唯一存在的東西是 AsyncLocal<T> 的存儲(chǔ)。其他在 ExecutionContext 中有自己特殊位置的東西都是以 AsyncLocal<T> 為模型的。例如，在 .NET Framework 中，模擬將作為 SecurityContext 的一部分流動(dòng)，而SecurityContext 是 ExecutionContext 的一部分；在 .NET Core 中，模擬通過(guò) AsyncLocal<SafeAccessTokenHandle> 流動(dòng)，它使用 valueChangedHandler 來(lái)對(duì)當(dāng)前線程進(jìn)行適當(dāng)?shù)母摹?/p>

QueueSegment / IThreadPoolWorkItem[]。在 .NET Core 中，ThreadPool 的全局隊(duì)列現(xiàn)在被實(shí)現(xiàn)為 ConcurrentQueue<T>，而 ConcurrentQueue<T> 已經(jīng)被重寫(xiě)為一個(gè)由非固定大小的循環(huán)段組成的鏈表。一旦段的長(zhǎng)度大到永遠(yuǎn)不會(huì)被填滿因?yàn)榉€(wěn)態(tài)的出隊(duì)列能夠跟上穩(wěn)態(tài)的入隊(duì)列，就不需要再分配額外的段，相同的足夠大的段就會(huì)被無(wú)休止地使用。

那么其他的分配呢，比如 Action、MoveNextRunner 和 <SomeMethodAsync>d__1? 要理解剩余的分配是如何被移除的，需要深入了解它在 .NET Core 上是如何工作的。

讓我們回到討論掛起時(shí)發(fā)生的事情:

if (!awaiter.IsCompleted) // we need to suspend when IsCompleted is false
{
    <>1__state = 1;
    <>u__2 = awaiter;
    <>t__builder.AwaitUnsafeOnCompleted(ref awaiter, ref this);
    return;
}

不管目標(biāo)是哪個(gè)平臺(tái)，這里發(fā)出的代碼都是相同的，所以不管是 .NET Framework 還是，為這個(gè)掛起生成的 IL 都是相同的。但是，改變的是 AwaitUnsafeOnCompleted 方法的實(shí)現(xiàn)，在 .NET Core 中有很大的不同:

• 1.事情的開(kāi)始是一樣的：該方法調(diào)用 ExecutionContext.Capture() 來(lái)獲取當(dāng)前執(zhí)行上下文。
• 2.然后，事情偏離了 .NET Framework。.NET Core 中的 builder 只有一個(gè)字段:

public struct AsyncTaskMethodBuilder
{
    private Task<VoidTaskResult>? m_task;
    ...
}

在捕獲 ExecutionContext 之后，它檢查 m_task 字段是否包含一個(gè) AsyncStateMachineBox<TStateMachine> 的實(shí)例，其中 TStateMachine 是編譯器生成的狀態(tài)機(jī)結(jié)構(gòu)體的類型。AsyncStateMachineBox<TStateMachine> 類型定義如下:

private class AsyncStateMachineBox<TStateMachine> :
    Task<TResult>, IAsyncStateMachineBox
    where TStateMachine : IAsyncStateMachine
{
    private Action? _moveNextAction;
    public TStateMachine? StateMachine;
    public ExecutionContext? Context;
    ...
}

與其說(shuō)這是一個(gè)單獨(dú)的 Task，不如說(shuō)這是一個(gè)任務(wù)（注意其基本類型）。該結(jié)構(gòu)并沒(méi)有對(duì)狀態(tài)機(jī)進(jìn)行裝箱，而是作為該任務(wù)的強(qiáng)類型字段存在。我們不需要用單獨(dú)的 MoveNextRunner 來(lái)存儲(chǔ) Action 和 ExecutionContext，它們只是這個(gè)類型的字段，而且由于這是存儲(chǔ)在構(gòu)建器的 m_task 字段中的實(shí)例，我們可以直接訪問(wèn)它，不需要在每次暫停時(shí)重新分配。如果 ExecutionContext 發(fā)生變化，我們可以用新的上下文覆蓋該字段，而不需要分配其他東西；我們的任何 Action 仍然指向正確的地方。所以，在捕獲了 ExecutionContext 之后，如果我們已經(jīng)有了這個(gè) AsyncStateMachineBox<TStateMachine> 的實(shí)例，這就不是這個(gè)方法第一次掛起了，我們可以直接把新捕獲的 ExecutionContext 存儲(chǔ)到其中。如果我們還沒(méi)有一個(gè)AsyncStateMachineBox<TStateMachine> 的實(shí)例，那么我們需要分配它：

var box = new AsyncStateMachineBox<TStateMachine>();
taskField = box; // important: this must be done before storing stateMachine into box.StateMachine!
box.StateMachine = stateMachine;
box.Context = currentContext;

請(qǐng)注意源注釋為“重要”的那一行。這取代了 .NET Framework 中復(fù)雜的 SetStateMachine，使得 SetStateMachine 在 .NET Core 中根本沒(méi)有使用。你看到的 taskField 有一個(gè)指向 AsyncTaskMethodBuilder 的 m_task 字段的 ref。我們分配 AsyncStateMachineBox< tstatemachinebox >，然后通過(guò) taskField 將對(duì)象存儲(chǔ)到構(gòu)建器的 m_task 中(這是在棧上的狀態(tài)機(jī)結(jié)構(gòu)中的構(gòu)建器)，然后將基于堆棧的狀態(tài)機(jī)(現(xiàn)在已經(jīng)包含對(duì)盒子的引用)復(fù)制到基于堆的 AsyncStateMachineBox< tstatemachinebox > 中，這樣 AsyncStateMachineBox<TStateMachine> 適當(dāng)?shù)夭⑦f歸地結(jié)束引用自己。這仍然是令人費(fèi)解的，但卻是一種更有效的費(fèi)解。

• 3.然后，我們可以對(duì)這個(gè) Action 上的一個(gè)方法進(jìn)行操作，該方法將調(diào)用其 MoveNext 方法，該方法將在調(diào)用 StateMachine 的 MoveNext 之前執(zhí)行適當(dāng)?shù)?ExecutionContext 恢復(fù)。該 Action 可以緩存到 _moveNextAction 字段中，以便任何后續(xù)使用都可以重用相同的 Action。然后，該 Action 被傳遞給 awaiter 的 UnsafeOnCompleted 來(lái)連接 continuation。

它解釋了為什么剩下的大部分分配都沒(méi)有了:<SomeMethodAsync>d__1 沒(méi)有被裝箱，而是作為任務(wù)本身的一個(gè)字段存在，MoveNextRunner 不再需要，因?yàn)樗拇嬖谥皇菫榱舜鎯?chǔ) Action 和 ExecutionContext。但是，根據(jù)這個(gè)解釋，我們?nèi)匀粦?yīng)該看到1000個(gè)操作分配，每個(gè)方法調(diào)用一個(gè)，但我們沒(méi)有。為什么?還有那些 QueueUserWorkItemCallback 對(duì)象呢?我們?nèi)匀辉?Task.Yield() 中進(jìn)行排隊(duì)，為什么它們沒(méi)有出現(xiàn)呢?

正如我所提到的，將實(shí)現(xiàn)細(xì)節(jié)推入核心庫(kù)的好處之一是，它可以隨著時(shí)間的推移改進(jìn)實(shí)現(xiàn)，我們已經(jīng)看到了它是如何從 .NET Framework 發(fā)展到 .NET Core 的。它在最初為 .NET Core 重寫(xiě)的基礎(chǔ)上進(jìn)一步發(fā)展，增加了額外的優(yōu)化，這得益于對(duì)系統(tǒng)關(guān)鍵組件的內(nèi)部訪問(wèn)。特別是，異步基礎(chǔ)設(shè)施知道 Task 和 TaskAwaiter 等核心類型。而且因?yàn)樗浪鼈儾⒕哂袃?nèi)部訪問(wèn)權(quán)限，所以它不必遵循公開(kāi)定義的規(guī)則。C# 語(yǔ)言遵循的 awaiter 模式要求 awaiter 具有 AwaitOnCompleted 或 AwaitUnsafeOnCompleted 方法，這兩個(gè)方法都將 continuation 作為一個(gè)操作，這意味著基礎(chǔ)結(jié)構(gòu)需要能夠創(chuàng)建一個(gè)操作來(lái)表示 continuation，以便與基礎(chǔ)結(jié)構(gòu)不知道的任意 awaiter 一起工作。但是，如果基礎(chǔ)設(shè)施遇到它知道的 awaiter，它沒(méi)有義務(wù)采取相同的代碼路徑。對(duì)于 System.Private 中定義的所有核心 awaiter。因此，CoreLib 的基礎(chǔ)設(shè)施可以遵循更簡(jiǎn)潔的路徑，完全不需要操作。這些 awaiter 都知道 IAsyncStateMachineBoxes，并且能夠?qū)?box 對(duì)象本身作為 continuation。例如，Task 返回的 YieldAwaitable.Yield 能夠?qū)?IAsyncStateMachineBox 本身作為工作項(xiàng)直接放入 ThreadPool 中，而等待任務(wù)時(shí)使用的 TaskAwaiter 能夠?qū)?IAsyncStateMachineBox 本身直接存儲(chǔ)到任務(wù)的延續(xù)列表中。不需要操作，也不需要 QueueUserWorkItemCallback。

因此，在非常常見(jiàn)的情況下，async 方法只等待 System.Private.CoreLib (Task, Task<TResult>， ValueTask, ValueTask<TResult>，YieldAwaitable，以及它們的ConfigureAwait 變體)，最壞的情況下，只有一次開(kāi)銷分配與 async 方法的整個(gè)生命周期相關(guān)：如果這個(gè)方法掛起了，它會(huì)分配一個(gè)單一的 Task-derived 類型來(lái)存儲(chǔ)所有其他需要的狀態(tài)，如果這個(gè)方法從來(lái)沒(méi)有掛起，就不會(huì)產(chǎn)生額外的分配。

如果愿意，我們也可以去掉最后一個(gè)分配，至少以平攤的方式。如所示，有一個(gè)默認(rèn)構(gòu)建器與 Task(AsyncTaskMethodBuilder) 相關(guān)聯(lián)，類似地，有一個(gè)默認(rèn)構(gòu)建器與任務(wù) <TResult> (AsyncTaskMethodBuilder<TResult>) 和 ValueTask 和ValueTask<TResult> (AsyncValueTaskMethodBuilder 和 AsyncValueTaskMethodBuilder<TResult>，分別)相關(guān)聯(lián)。對(duì)于 ValueTask/ValueTask<TResult>，構(gòu)造器實(shí)際上相當(dāng)簡(jiǎn)單，因?yàn)樗鼈儽旧碇惶幚硗角页晒ν瓿傻那闆r，在這種情況下，異步方法完成而不掛起，構(gòu)建器可以只返回一個(gè) ValueTask.Completed 或者一個(gè)包含結(jié)果值的 ValueTask<TResult>。對(duì)于其他所有事情，它們只是委托給 AsyncTaskMethodBuilder/AsyncTaskMethodBuilder<TResult>，因?yàn)?ValueTask/ValueTask<TResult> 會(huì)被返回包裝一個(gè) Task，它可以共享所有相同的邏輯。但是 .NET 6 and C# 10 引入了一個(gè)方法可以覆蓋逐個(gè)方法使用的構(gòu)建器的能力，并為 ValueTask/ValueTask<TResult> 引入了幾個(gè)專門(mén)的構(gòu)建器，它們能夠池化 IValueTaskSource/IValueTaskSource<TResult> 對(duì)象來(lái)表示最終的完成，而不是使用 Tasks。

我們可以在我們的樣本中看到這一點(diǎn)的影響。稍微調(diào)整一下之前分析的 SomeMethodAsync 函數(shù)，讓它返回 ValueTask 而不是 Task:

static async ValueTask SomeMethodAsync()
{
    for (int i = 0; i < 1000; i++)
    {
        await Task.Yield();
    }
}

這將生成以下入口點(diǎn):

[AsyncStateMachine(typeof(<SomeMethodAsync>d__1))]
private static ValueTask SomeMethodAsync()
{
    <SomeMethodAsync>d__1 stateMachine = default;
    stateMachine.<>t__builder = AsyncValueTaskMethodBuilder.Create();
    stateMachine.<>1__state = -1;
    stateMachine.<>t__builder.Start(ref stateMachine);
    return stateMachine.<>t__builder.Task;
}

現(xiàn)在，我們添加 [AsyncMethodBuilder(typeof(PoolingAsyncValueTaskMethodBuilder))] 到 SomeMethodAsync 的聲明中:

[AsyncMethodBuilder(typeof(PoolingAsyncValueTaskMethodBuilder))]
static async ValueTask SomeMethodAsync()
{
    for (int i = 0; i < 1000; i++)
    {
        await Task.Yield();
    }
}

編譯器輸出如下:

[AsyncStateMachine(typeof(<SomeMethodAsync>d__1))]
[AsyncMethodBuilder(typeof(PoolingAsyncValueTaskMethodBuilder))]
private static ValueTask SomeMethodAsync()
{
    <SomeMethodAsync>d__1 stateMachine = default;
    stateMachine.<>t__builder = PoolingAsyncValueTaskMethodBuilder.Create();
    stateMachine.<>1__state = -1;
    stateMachine.<>t__builder.Start(ref stateMachine);
    return stateMachine.<>t__builder.Task;
}

整個(gè)實(shí)現(xiàn)的實(shí)際 C# 代碼生成，包括整個(gè)狀態(tài)機(jī)(沒(méi)有顯示)，幾乎是相同的；唯一的區(qū)別是創(chuàng)建和存儲(chǔ)的構(gòu)建器的類型，因此在我們之前看到的任何引用構(gòu)建器的地方都可以使用。如果你看一下 PoolingAsyncValueTaskMethodBuilder 的代碼，你會(huì)看到它的結(jié)構(gòu)幾乎與 AsyncTaskMethodBuilder 相同，包括使用一些完全相同的共享例程來(lái)做一些事情，如特殊套管已知的 awaiter 類型。

關(guān)鍵的區(qū)別是，當(dāng)方法第一次掛起時(shí)，它不是執(zhí)行新的 AsyncStateMachineBox<TStateMachine>()，而是執(zhí)行 StateMachineBox<TStateMachine>. rentfromcache()，并且在 async 方法 (SomeMethodAsync) 完成并等待返回的 ValueTask 完成時(shí)，租用的盒子會(huì)被返回到緩存中。這意味著(平攤)零分配:

這個(gè)緩存本身有點(diǎn)意思。對(duì)象池可能是一個(gè)好主意，也可能是一個(gè)壞主意。創(chuàng)建一個(gè)對(duì)象的成本越高，共享它們的價(jià)值就越大；因此，例如，對(duì)非常大的數(shù)組進(jìn)行池化比對(duì)非常小的數(shù)組進(jìn)行池化更有價(jià)值，因?yàn)楦蟮臄?shù)組不僅需要更多的 CPU 周期和內(nèi)存訪問(wèn)為零，它們還會(huì)給垃圾收集器帶來(lái)更大的壓力，使其更頻繁地收集垃圾。然而，對(duì)于非常小的對(duì)象，將它們池化可能會(huì)帶來(lái)負(fù)面影響。池只是內(nèi)存分配器，GC 也是，所以當(dāng)您使用池時(shí)，您是在權(quán)衡與一個(gè)分配器相關(guān)的成本與另一個(gè)分配器相關(guān)的成本，并且 GC 在處理大量微小的、生存期短的對(duì)象方面非常高效。如果你在對(duì)象的構(gòu)造函數(shù)中做了很多工作，避免這些工作可以使分配器本身的開(kāi)銷相形見(jiàn)絀，從而使池變得有價(jià)值。但是，如果您在對(duì)象的構(gòu)造函數(shù)中幾乎沒(méi)有做任何工作，并且將其進(jìn)行池化，則您將打賭您的分配器(您的池)就所采用的訪問(wèn)模式而言比 GC 更有效，而這通常是一個(gè)糟糕的賭注。還涉及其他成本，在某些情況下，您可能最終會(huì)有效地對(duì)抗 GC 的啟發(fā)式方法；例如，垃圾回收是基于一個(gè)前提進(jìn)行優(yōu)化的，即從較高代(如gen2)對(duì)象到較低代(如gen0)對(duì)象的引用相對(duì)較少，但池化對(duì)象可以使這些前提失效。

我們今天為大家介紹了 C# 迭代器和 async/await under the covers，下期文章，我們將繼續(xù)介紹 SynchronizationContext 和 ConfigureAwait，更多關(guān)于C# async await迭代器的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章！

最新評(píng)論