C# 迭代器

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

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

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

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} ");}

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

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

或者我可以直接通過 IEnumerator<T> 來手動枚舉它：

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

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

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

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

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

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

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

這就是 C# 和 .NET 中 async/await 的開始。

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

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

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

async/await under the covers

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

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 對應(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，這兩個操作都帶 await 前綴。編譯器和核心庫接管了其余部分，從根本上改變了代碼實際執(zhí)行的方式。讓我們深入了解一下是如何做到的。

編譯器轉(zhuǎn)換

我們已經(jīng)看到，和迭代器一樣，編譯器基于狀態(tài)機(jī)重寫了 async 方法。我們?nèi)匀挥幸粋€與開發(fā)人員寫的簽名相同的方法(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;
    ...}

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

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

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

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

[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)建該類型的實例(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)是通過應(yīng)用在類型上的 [AsyncMethodBuilder(…)] 屬性提供的，但在 C# 中，Task 是已知的，因此實際上沒有該屬性。因此，編譯器已經(jīng)讓構(gòu)建器使用這個異步方法，并使用模式中的 Create 方法構(gòu)建它的實例。請注意，與狀態(tài)機(jī)一樣，AsyncTaskMethodBuilder 也是一個結(jié)構(gòu)體，因此這里也沒有內(nèi)存分配。

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

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

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

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

? ExecutionContext

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

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

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

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

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

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

? Back To Start

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

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

然后建議我簡化一下。這種簡化忽略了一個事實，即該方法實際上需要將 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()，而是在這里做了一個動作：獲取當(dāng)前的 ExecutionContext，再調(diào)用 MoveNext，然后在它完成時將當(dāng)前上下文重置為調(diào)用 MoveNext 之前的狀態(tài)。

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

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

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

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

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

? MoveNext

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

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

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

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

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

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

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

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

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

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

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

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

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

你可以在 C# 編譯器生成的代碼中看到，當(dāng)我們需要掛起時就會發(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 存儲到 state 字段中，該 id 表示當(dāng)方法恢復(fù)時應(yīng)該跳轉(zhuǎn)到的位置。然后，我們將 awaiter 本身持久化到一個字段中，以便在恢復(fù)后可以使用它來調(diào)用 GetResult。然后在返回 MoveNext 調(diào)用之前，我們要做的最后一件事是調(diào)用 <>t__builder.AwaitUnsafeOnCompleted(ref awaiter, ref this)，要求構(gòu)建器為這個狀態(tài)機(jī)連接一個 continuation 到 awaiter。

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

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

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

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

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

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

5.現(xiàn)在到了一個有些令人費(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ī)包含一個 m_stateMachine 字段為 null 的構(gòu)建器。我們需要改變裝箱狀態(tài)機(jī)的構(gòu)建器的 m_stateMachine 指向它的父容器。

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

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

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

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

這就是在 .NET Framework 中發(fā)生的事情，你可以在分析器中看到結(jié)果，例如通過運(yùn)行分配分析器來查看每個 await 上的分配情況。讓我們看看這個愚蠢的程序，我寫這個程序只是為了強(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();
        }
    }
}

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

那是很多的分配！讓我們來研究一下它們的來源。

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

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

MoveNextRunner。同樣的，有一百萬個這樣的例子，因為在前面的步驟大綱中，每次我們暫停時，我們都要分配一個新的 MoveNextRunner 來存儲 Action和 ExecutionContext，以便使用后者來執(zhí)行前者。

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

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

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

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

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

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

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

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

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

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

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

讓我們回到討論掛起時發(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)是哪個平臺，這里發(fā)出的代碼都是相同的，所以不管是 .NET Framework 還是，為這個掛起生成的 IL 都是相同的。但是，改變的是 AwaitUnsafeOnCompleted 方法的實現(xiàn)，在 .NET Core 中有很大的不同:

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

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

在捕獲 ExecutionContext 之后，它檢查 m_task 字段是否包含一個 AsyncStateMachineBox<TStateMachine> 的實例，其中 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;
    ...
}

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

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

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

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

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

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

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

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

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

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

這將生成以下入口點:

[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;
}

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

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

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

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