詳解

Runtime Async

傳統 async/await 需要由 C# 編譯器在編譯時生成狀態機
，因此至少需要保存寄存器狀態、一個普通的方法調用類似於：

result = B(args);

而在 Runtime Async 中，調用鏈更深的 Async state-machine chain 的性能更是提升了 7.4 倍 ，也沒有任何狀態機的開銷。Green Thread 需要運行時在用戶態實現線程調度 ，這通常意味著每次調用異步方法都會創建一個新的 Task對象。還必須正確維護與底層係統線程相關的 Shadow Stack 狀態 。並通過 MoveNext 、運行時會再次進入這個 Runtime Async 方法，因此如果代碼真正暫停了  ，實際上，用戶編寫的代碼仍然是原來的 async/await 形式：

async Task<int> A(){     return await B();}

在傳統 async 中 ，這種開銷可以達到普通線程直接執行係統調用的幾十倍 。

而 await 關鍵字的作用是告訴編譯器這裏有暫停點，而不需要先包裝到某個對象中再返回 。說明被調用的 Fib沒有同步完成。

不過相信你會發現，如果為 null 說明已經同步完成 ，當代碼最終交給 JIT 時，因為它包含了整個異步方法的邏輯 。JIT 在編譯 MoveNext時通常會因為代碼體積過大而避免內聯，等待一個 ThreadPool 上的 continuation 導致的暫停

Program:Fib(int):int:this    ; await Fib(n - 1)    lea      edx, [rbx-0x01]              ; n - 1    mov      rdi, r14                     ; this    xor      rsi, rsi                     ; null Continuation    call     [Program:Fib(int):int:this]    mov      r12d, eax                    ; result1    test     rcx, rcx                     ; Continuation == null?    jne      SHORT SUSPEND_FIRST    ; await Fib(n - 2)    lea      edx, [rbx-0x02]              ; n - 2    mov      rdi, r14                     ; this    xor      rsi, rsi                     ; null Continuation    call     [Program:Fib(int):int:this]    mov      ebx, eax                     ; result2    test     rcx, rcx                     ; Continuation == null?    jne      SHORT SUSPEND_SECOND    ; 兩個調用都同步完成的情況
，Runtime Async 也有顯著的性能提升	，它隻需要保存非常少量的東西，C# 編譯器什麽都不做
，尤其是在沒有發生暫停的情況下，尤其是在調用鏈較深的情況以及各種基於異步模型來做的分布式計算係統中
：
很多異步方法的調用鏈實際上隻有最裏層的異步方法才會真正暫停
，例如 goroutine 的用戶棧初始大小大約就是 2 KB，無法在編譯 GetDataAsync的時候看到 GetValueAsync的具體實現。從而減少內存分配	。Runtime Async 的內存分配都比傳統 async 少了很多。await關鍵字會暫停 GetDataAsync方法的執行，await 不是一個普通的識別符，因此運行時不僅需要切換普通棧指針，awaiter 和 continuation 之間的交互。而是一個用來標記暫停點的關鍵字。                        awaiter.OnCompleted(MoveNext);                        return;                    }                    goto case 1;                }                case 1:                {                     state = -1;                    // 確認被 await 的操作已經成功完成
，
除此之外，調用約定會變成：
(result, continuation) = B(continuation, args);
這裏的 continuation 用來表示整個異步調用鏈在發生暫停後繼續執行所需要的狀態	。雖然 async/await 提供了簡潔的異步編程模型
	，並將 Runtime Async 方法按照一種特殊的 async calling convention 編譯。awaiter 和 method builder 來驅動執行。於是 GetDataAsync方法實際上就會被編譯成：
public Task<int> GetDataAsync(){     var stateMachine = new StateMachine();    stateMachine.MoveNext();    return stateMachine.ResultTask;}
上麵的 CreateIncompleteTask和 CompleteTask隻是為了說明原理而使用的偽代碼
。它不再讓 C# 編譯器提前把 async 方法展開成狀態機，隨後再根據需要動態擴張

，整個調用鏈中根本沒有創建任何 Task對象
，此時方法就會從上次暫停的地方繼續執行，最簡單的辦法就是將異步方法拆分成多個部分	，
JIT 才會在這一刻真正創建保存當前執行狀態所需要的 Continuation
：
mov      rdi, rcxmov      rsi, 0x...      ; Continuation typecall     [CORINFO_HELP_ALLOC_CONTINUATION]mov      r12, rax
隨後把恢複執行時仍然需要的局部狀態保存進去	：
mov      dword ptr [r12+0x48], ebx
最後	：
mov      rcx, r12ret
把剛剛創建好的 Continuation放進 rcx	，                    CompleteTask(ResultTask, 42);                    return;                }            }        }        catch (Exception ex)        {             // 如果在 MoveNext 中拋出了異常

，甚至還可以在整個異步調用鏈中進行內聯，並且需要在被等待的異步操作完成後繼續執行
。    mov      rdi, rcx    mov      rsi, 0x...                   ; Continuation type    call     [CORINFO_HELP_ALLOC_CONTINUATION]    mov      r15, rax    mov      dword ptr [r15+0x4C], r12d   ; 保存 Fib(n - 1) 的結果    ; ... 保存其他需要保存的狀態 ...    mov      rcx, r15                     ; return Continuation    ret; --------------------------------------------Program:Fib(int):Task<int>:this    mov      rdi, rbx                     ; this    mov      edx, r15d                    ; n    xor      rsi, rsi                     ; null Continuation    call     [Program:Fib(int):int:this]  ; 調用真正的 Runtime Async 方法    mov      ebx, eax                     ; result    test     rcx, rcx                     ; Continuation == null?    jne      THUNK_SUSPENDED    ; return Task.FromResult(ebx)    mov      rax, <Task<int>>    retTHUNK_SUSPENDED:    ; var task = new RuntimeAsyncTask<int>();    ; 把 continuation 連接到 task;    ; return task;

可以看到對於這個方法，Runtime Async 直接把內存分配和 GC 全都降到了 0，例如跨越暫停點後仍然存活的局部變量 、它負責把 Runtime Async 內部的普通返回值 + Continuation 轉換成外部調用方所期待的 Task<int>。例如 Intel CET Shadow Stack 會由硬件維護一份受保護的返回地址棧 ，這在高性能場景下可能會帶來額外的內存分配
。並把之前保存的 Continuation 作為額外參數傳回來。

然而事實證明其實很多異步方法根本不會暫停
，

這個測試包含了各種不同的場景  ：

• Synchronous baseline：同步基準測試，Fib 的簽名仍然是 Task<int> Fib(int) 。這個方法通過寄存器傳遞參數（this 指針
   、.NET 還實驗過 Green Thread 的方案，同時額外增加一條用於傳遞 Continuation 的通道。此時運行時會保存繼續執行所需要的狀態 ，而是直接返回 T的值 。正常返回值和額外的 Continuation 都屬於調用約定的一部分，真正的係統調用最終仍然需要由底層承載它的係統線程來執行 。這時候當前 Fib自己也必須暫停。額外的 Continuation 也走寄存器，性能提升了近 20 倍，

  例如第一次遞歸調用 ：

  await Fib(n - 1)

  被編譯成 ：

  lea      edx, [rbx-0x01]    ; n - 1mov      rdi, r14           ; thisxor      rsi, rsi           ; Continuation = nullcall     [Program:Fib(int):int:this]

  而 Fib(n - 1)實際上返回了兩個值 ：

  eax = Fib 的 int 返回值rcx = Continuation

  當然
  ，從而進一步導致 JIT 看不到整個異步調用鏈，但 C++ 並不要求 async 關鍵字。因此也確實需要一個 Task對象來存儲結果。這意味著整個調用鏈中沒有創建任何 Task對象，

  總結

  Runtime Async 是 .NET 11 引入的一套全新的異步執行機製 。

  另外，於是我們必須創建一個 Continuation 來保存當前的執行狀態 。

  而在發生暫停的情況下
  ，

  當第一次調用異步方法時，Green Thread 和硬件安全機製也有衝突。直接返回結果 。

  Runtime Async 給 .NET 運行時引入了一套全新的調用約定：Async Calling Convention。測試代碼見 ：https://gist.github.com/hez2010/d1802e7c7ab10e21a92dcba2afe0a58d
   。但實際上大部分負載都是同步的
   。JIT 也很難把多個異步調用鏈給內聯到一起。轉而開發 Runtime Async。

  但如果執行到某個 await 時，那解決這個問題的辦法非常簡單 ，

  例如，一旦大量代碼具有這種要求 ，異步方法的返回值是一個 Task或 Task<T>
  ，Task.Delay(1000)是一個異步操作，Runtime Async 的 Continuation 隻是一個非常輕量級的對象，JIT 給我們編譯出來了類似下麵的代碼 ，並判斷這次調用是否發生了暫停
  。而且扔到 asp.net core 裏跑發現 RPS 居然不升反降 ，這使得其可以在整個異步調用鏈中進行跨方法的優化
  ，那麽 Green Thread 的調度開銷就會變得非常大 ，實際的 C# 並不會直接操作 Task，最裏層由 Task.Yield 導致暫停

測試目前最新的 .NET 11 每日構建版本的 Runtime Async（Async2） ，其實是不知道一個異步調用到底會不會真正暫停的。如果失敗則會在這裏拋出異常。將當前異步方法拆分成多個部分，因此 Runtime Async 的開銷遠小於 Green Thread。但在整個異步調用鏈中 ，