深入理解.NET中的異步
一、前言
網上有很多關於 .NET async/await 的介紹，但是很遺憾，很少有正確的，甚至說大多都是“從現象編原理”都不過分。
最典型的比如通過前後線程 ID 來推斷其工作方式、在 async 方法中用 Thread.Sleep 來解釋 Task 機制而導出多線程模型的結論、在 Task.Run 中包含 IO bound 任務來推出這是開瞭一個多線程在執行任務的結論等等。
看上去似乎可以解釋的通，可是很遺憾，無論是從原理還是結論上看都是錯誤的。
要瞭解 .NET 中的 async/await 機制，首先需要有操作系統原理的基礎，否則的話是很難理解清楚的，如果沒有這些基礎而試圖向他人解釋，大多也隻是基於現象得到的錯誤猜想。
二、初看異步
說到異步大傢應該都很熟悉瞭，2012 年 C# 5 引入瞭新的異步機制：Task，並且還有兩個新的關鍵字 await 和 async，這已經不是什麼新鮮事瞭，而且如今這個異步機制已經被各大語言借鑒，如 JavaScript、TypeScript、Rust、C++ 等等。
下面給出一個簡單的對照：
| 語言 | 調度單位 | 關鍵字/方法 |
|---|---|---|
| C# | Task<>、ValueTask<> | async、await |
| C++ | std::future<> | co_await |
| Rust | std::future::Future<> | .await |
| JavaScript、TypeScript | Promise<> | async、await |
當然，這裡這並不是本文的重點，隻是提一下，方便大傢在有其他語言經驗的情況下（如果有），可以認識到 C# 中 Task 和 async/await 究竟是一個和什麼可以相提並論的東西。
三、多線程編程
在該異步編程模型誕生之前，多線程編程模型是很多人所熟知的。一般來說，開發者會使用 Thread、std::thread 之類的東西作為線程的調度單位來進行多線程開發，每一個這樣的結構表示一個對等線程，線程之間采用互斥或者信號量等方式進行同步。
多線程對於科學計算速度提升等方面效果顯著，但是對於 IO 負荷的任務，例如從讀取文件或者 TCP 流，大多數方案隻是分配一個線程進行讀取，讀取過程中阻塞該線程：
void Main()
{
while (true)
{
var client = socket.Accept();
new Thread(() => ClientThread(client)).Start();
}
}
void ClientThread(Socket client)
{
var buffer = new byte[1024];
while (...)
{
// read and block
client.Read(buffer, 0, 1024);
}
}
上述代碼中，Main 函數在接收客戶端之後即分配瞭一個新的用戶線程用於處理該客戶端，從客戶端接收數據。client.Read() 執行後，該線程即被阻塞，即使阻塞期間該線程沒有任何的操作，該用戶線程也不會被釋放，並被操作系統不斷輪轉調度，這顯然浪費瞭資源。
另外，如果線程數量多起來，頻繁在不同線程之間輪轉切換上下文，線程的上下文也不小，會浪費掉大量的性能。
四、異步編程
因此對於此工作內容（IO），我們在 Linux 上有瞭 epoll/io_uring 技術，在 Windows 上有瞭 IOCP 技術用以實現異步 IO 操作。
（這裡插句題外話，吐槽一句，Linux 終於知道從 Windows 抄作業瞭。先前的 epoll 對比 IOCP 簡直不能打，被 IOCP 全面打壓，io_uring 出來瞭才好不容易能追上 IOCP，不過 IOCP 從 Windows Vista 時代開始每一代都有很大的優化，io_uring 能不能追得上還有待商榷）
這類 API 有一個共同的特性就是，在操作 IO 的時候，調用方控制權被讓出，等待 IO 操作完成之後恢復先前的上下文，重新被調度繼續運行。
所以表現就是這樣的：
假設我現在需要從某設備中讀取 1024 個字節長度的數據，於是我們將緩沖區的地址和內容長度等信息封裝好傳遞給操作系統之後我們就不管瞭，讀取什麼的讓操作系統去做就好瞭。
操作系統在內核態下利用 DMA 等方式將數據讀取瞭 1024 個字節並寫入到我們先前的 buffer 地址下，然後切換到用戶態將從我們先前讓出控制權的位置，對其進行調度使其繼續執行。
你可以發現這麼一來，在讀取數據期間就沒有任何的線程被阻塞，也不存在被頻繁調度和切換上下文的情況，隻有當 IO 操作完成之後才會被重新調度並恢復先前讓出控制權時的上下文，使得後面的代碼繼續執行。
當然，這裡說的是操作系統的異步 IO 實現方式，以便於讀者對異步這個行為本身進行理解，和 .NET 中的異步還是有區別，Task 本身和操作系統也沒什麼關系。
五、Task (ValueTask)
說瞭這麼久還是沒有解釋 Task 到底是個什麼東西，從上面的分析就可以得出，Task 其實就是一個所謂的調度單位，每個異步任務被封裝為一個 Task 在 CLR 中被調度，而 Task 本身會運行在 CLR 中的預先分配好的線程池中。
總有很多人因為 Task 借助線程池執行而把 Task 歸結為多線程模型，這是完全錯誤的。
這個時候有人跳出來瞭，說：你看下面這個代碼
static async Task Main()
{
while (true)
{
Console.WriteLine(Environment.CurrentManagedThreadId);
await Task.Delay(1000);
}
}
輸出的線程 ID 不一樣欸，你騙人，這明明就是多線程！對於這種言論，我也隻能說這些人從原理上理解的就是錯誤的。
當代碼執行到 await 的時候，此時當前的控制權就已經被讓出瞭，當前線程並沒有在阻塞地等待延時結束；待 Task.Delay() 完畢後，CLR 從線程池當中挑起瞭一個先前分配好的已有的但是空閑的線程，將讓出控制權前的上下文信息恢復，使得該線程恰好可以從先前讓出的位置繼續執行下去。這個時候，可能挑到瞭先前讓出前所在的那個線程，導致前後線程 ID 一致；也有可能挑到瞭另外一個和之前不一樣的線程執行下面的代碼，使得前後的線程 ID 不一致。在此過程中並沒有任何的新線程被分配瞭出去。
當然，在 WPF 等地方，因為利用瞭 SynchronizationContext 對調度行為進行瞭控制，所以可以得到和上述不同的結論，和這個相關的還有 .ConfigureAwait() 的用法，但是這裡不是本文重點，因此就不做展開。
在 .NET 中由於采用 stackless 的做法，這裡需要用到 CPS 變換，大概是這麼個流程：
using System;
using System.Threading.Tasks;
public class C
{
public async Task M()
{
var a = 1;
await Task.Delay(1000);
Console.WriteLine(a);
}
}
編譯後：
public class C
{
[StructLayout(LayoutKind.Auto)]
[CompilerGenerated]
private struct <M>d__0 : IAsyncStateMachine
{
public int <>1__state;
public AsyncTaskMethodBuilder <>t__builder;
private int <a>5__2;
private TaskAwaiter <>u__1;
private void MoveNext()
{
int num = <>1__state;
try
{
TaskAwaiter awaiter;
if (num != 0)
{
<a>5__2 = 1;
awaiter = Task.Delay(1000).GetAwaiter();
if (!awaiter.IsCompleted)
{
num = (<>1__state = 0);
<>u__1 = awaiter;
<>t__builder.AwaitUnsafeOnCompleted(ref awaiter, ref this);
return;
}
}
else
{
awaiter = <>u__1;
<>u__1 = default(TaskAwaiter);
num = (<>1__state = -1);
}
awaiter.GetResult();
Console.WriteLine(<a>5__2);
}
catch (Exception exception)
{
<>1__state = -2;
<>t__builder.SetException(exception);
return;
}
<>1__state = -2;
<>t__builder.SetResult();
}
void IAsyncStateMachine.MoveNext()
{
//ILSpy generated this explicit interface implementation from .override directive in MoveNext
this.MoveNext();
}
[DebuggerHidden]
private void SetStateMachine(IAsyncStateMachine stateMachine)
{
<>t__builder.SetStateMachine(stateMachine);
}
void IAsyncStateMachine.SetStateMachine(IAsyncStateMachine stateMachine)
{
//ILSpy generated this explicit interface implementation from .override directive in SetStateMachine
this.SetStateMachine(stateMachine);
}
}
[AsyncStateMachine(typeof(<M>d__0))]
public Task M()
{
<M>d__0 stateMachine = default(<M>d__0);
stateMachine.<>t__builder = AsyncTaskMethodBuilder.Create();
stateMachine.<>1__state = -1;
stateMachine.<>t__builder.Start(ref stateMachine);
return stateMachine.<>t__builder.Task;
}
}
可以看到，原來的變量 a 被塞到瞭 <a>5__2 裡面去（相當於備份上下文），Task 狀態的轉換後也是靠著調用 MoveNext（相當於狀態轉換後被重新調度）來接著驅動代碼執行的，裡面的 num 就表示當前的狀態，num 如果為 0 表示 Task 完成瞭，於是接著執行下面的代碼 Console.WriteLine(<a>5__2);。
但是上面和經典的多線程編程的那一套一樣嗎?不一樣。
至於 ValueTask 是個什麼玩意，官方發現，Task 由於本身是一個 class，在運行時如果頻繁反復的分配和回收會給 GC 造成不小的壓力，因此出瞭一個 ValueTask，這個東西是 struct，分配在棧上，這樣的話就不會給 GC 造成壓力瞭，減輕瞭開銷。不過也正因為 ValueTask 是會在棧上分配的值類型結構，因此提供的功能也不如 Task 全面。
六、Task.Run
由於 .NET 是允許有多個線程的，因此也提供瞭 Task.Run 這個方法，允許我們將 CPU bound 的任務放在上述的線程池之中的某個線程上執行，並且允許我們將該負載作為一個 Task 進行管理，僅在這一點才和多線程的采用線程池的編程比較像。
對於瀏覽器環境（v8），這個時候是完全沒有多線程這一說的，因此你開的新的 Promise 其實是後面利用事件循環機制，將該微任務以異步的方式執行。
想一想在 JavaScript 中，Promise 是怎麼用的：
let p = new Promise((resolve, reject) => {
// do something
let success = true;
let result = 123456;
if (success) {
resolve(result);
}
else {
reject("failed");
}
})
然後調用：
let r = await p; console.log(r); // 輸出 123456
你隻需要把這一套背後的驅動器：事件循環隊列，替換成 CLR 的線程池，就差不多是 .NET 的 Task 相對 JavaScript 的 Promise 的工作方式瞭。
如果你把 CLR 線程池線程數量設置為 1，那就和 JavaScript 這套幾乎差不多瞭（雖然實現上還是有差異）。
這時有人要問瞭：“我在 Task.Run 裡面套瞭好幾層 Task.Run，可是為什麼層數深瞭之後裡面的不執行瞭呢?” 這是因為上面所說的線程池被耗盡瞭，後面的 Task 還在排著隊等待被調度。
七、自己封裝異步邏輯
瞭解瞭上面的東西之後，相信對 .NET 中的異步機制應該理解得差不多瞭，可以看出來這一套是名副其實的 coroutine，並且在實現上是 stackless 的。至於有的人說的什麼狀態機什麼的，隻是實現過程中利用的手段而已，並不是什麼重要的東西。
那我們要怎麼樣使用 Task 來編寫我們自己的異步代碼呢?
事件驅動其實也可以算是一種異步模型，例如以下情景：
A 函數調用 B 函數，調用發起後就直接返回不管瞭（BeginInvoke），B 函數執行完成後觸發事件執行 C 函數。
private event Action CompletedEvent;
void A()
{
CompletedEvent += C;
Console.WriteLine("begin");
((Action)B).BeginInvoke();
}
void B()
{
Console.WriteLine("running");
CompletedEvent?.Invoke();
}
void C()
{
Console.WriteLine("end");
}
那麼我們現在想要做一件事，就是把上面的事件驅動改造為利用 async/await 的異步編程模型，改造後的代碼就是簡單的：
async Task A()
{
Console.WriteLine("begin");
await B();
Console.WriteLine("end");
}
Task B()
{
Console.WriteLine("running");
return Task.CompletedTask;
}
你可以看到，原本 C 函數的內容被放到瞭 A 調用 B 的下面，為什麼呢?其實很簡單，因為這裡 await B(); 這一行以後的內容，本身就可以理解為 B 函數的回調瞭，隻不過在內部實現上，不是直接從 B 進行調用的回調，而是 A 先讓出控制權，B 執行完成後，CLR 切換上下文，將 A 調度回來繼續執行剩下的代碼。
如果事件相關的代碼已經確定不可改動（即不能改動 B 函數），我們想將其封裝為異步調用的模式，那隻需要利用 TaskCompletionSource 即可：
private event Action CompletedEvent;
async Task A()
{
// 因為 TaskCompletionSource 要求必須有一個泛型參數
// 因此就隨便指定瞭一個 bool
// 本例中其實是不需要這樣的一個結果的
// 需要註意的是從 .NET 5 開始
// TaskCompletionSource 不再強制需要泛型參數
var tsc = new TaskCompletionSource<bool>();
// 隨便寫一個結果作為 Task 的結果
CompletedEvent += () => tsc.SetResult(false);
Console.WriteLine("begin");
((Action)B).BeginInvoke();
await tsc.Task;
Console.WriteLine("end");
}
void B()
{
Console.WriteLine("running");
CompletedEvent?.Invoke();
}
順便提一句，這個 TaskCompletionSource<T> 其實和 JavaScript 中的 Promise<T> 更像。SetResult() 方法對應 resolve()，SetException() 方法對應 reject()。.NET 比 JavaScript 還多瞭一個取消狀態，因此還可以 SetCancelled() 表示任務被取消瞭。
八、同步方式調用異步代碼
說句真的，一般能有這個需求，都說明你的代碼寫的有問題，但是如果你無論如何都想以阻塞的方式去等待一個異步任務完成的話：
Task t = ... t.GetAwaiter().GetResult();
祝你好運，這相當於，t 中的異步任務開始執行後，你將當前線程阻塞，然後等到 t 完成之後再喚醒，可以說是：毫無意義，而且很有可能因為代碼編寫不當而導致死鎖的發生。
九、void async 是什麼?
最後有人會問瞭，函數可以寫 async Task Foo()，還可以寫 async void Bar()，這有什麼區別呢?
對於上述代碼，我們一般調用的時候，分別這麼寫：
await Foo(); Bar();
可以發現，誒這個 Bar 函數不需要 await 誒。為什麼呢?
其實這和用以下方式調用 Foo 是一樣的：
_ = Foo();
換句話說就是調用後瞬間就直接拋掉不管瞭，不過這樣你也就沒法知道這個異步任務的狀態和結果瞭。
十、await 必須配合 Task/ValueTask 才能用嗎?
當然不是。
在 C# 中隻要你的類中包含 GetAwaiter() 方法和 bool IsCompleted 屬性，並且 GetAwaiter() 返回的東西包含一個 GetResult() 方法、一個 bool IsCompleted 屬性和實現瞭 INotifyCompletion，那麼這個類的對象就是可以 await 的。
public class MyTask<T>
{
public MyAwaiter<T> GetAwaiter()
{
return new MyAwaiter<T>();
}
}
public class MyAwaiter<T> : INotifyCompletion
{
public bool IsCompleted { get; private set; }
public T GetResult()
{
throw new NotImplementedException();
}
public void OnCompleted(Action continuation)
{
throw new NotImplementedException();
}
}
public class Program
{
static async Task Main(string[] args)
{
var obj = new MyTask<int>();
await obj;
}
}
十一、結語
本文至此就結束瞭，感興趣的小夥伴可以多多學習一下操作系統原理，對 CLR 感興趣也可以去研究其源代碼：https://github.com/dotnet/runtime 。
.NET 的異步和線程密不可分，但是和多線程編程方式和思想是有本質不同的，也希望大傢不要將異步和多線程混淆瞭，而這有聯系也有區別。
從現象猜測本質是大忌，可能解釋的通但是終究隻是偶然現象，而且從原理上看也是完全錯誤的，甚至官方的實現代碼稍微變一下可能立馬就無法解釋的通瞭。
總之，通過本文希望大傢能對異步和 .NET 中的異步有一個更清晰的理解。
以上就是深入理解.NET中的異步的詳細內容，更多關於.NET 異步的資料請關註WalkonNet其它相關文章！