.NET 異步詳解

2020 年 8 月 5 日
筆記
.NET, .NET Core, .NET Framework, c#, CLR

前言

博客園中有很多關於 .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() 執行後，該線程即被阻塞，即使阻塞期間該線程沒有任何的操作，該用戶線程也不會被釋放，並被操作系統不斷輪轉調度，這顯然浪費了資源。

另外，如果線程數量多起來，頻繁在不同線程之間輪轉切換上下文，線程的上下文也不小，會浪費掉大量的性能。

異步編程

因此我們在 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 操作完成之後才會被重新調度並恢復先前讓出控制權時的上下文，使得後面的代碼繼續執行。

`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 不一致。在此過程中並沒有任何的新線程被分配了出去。

但是上面和經典的多線程編程的那一套有任何的關係嗎?完全沒有。

至於 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 這套幾乎差不多了（雖然實現上還是有差異）。

有效利用 .NET 中的異步

了解了上面的東西之後，相信對 .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");
    await tsc.Task;
    Console.WriteLine("end");
}

void B()
{
    Console.WriteLine("running");
    CompletedEvent?.Invoke();
}

順便提一句，這個 TaskCompletionSource<T> 其實和 JavaScript 中的 Promise<T> 更像。SetResult() 方法對應 resove()，SetException() 方法對應 reject()。.NET 比 JavaScript 還多了一個取消狀態，因此還可以 SetCancel() 表示任務被取消了。

同步方式調用異步代碼

說句真的，一般能有這個需求，都說明你的代碼寫的有問題，但是如果你無論如何都想以阻塞的方式去等待一個異步任務完成的話：

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 感興趣也可以去研究其源代碼：//github.com/dotnet/runtime 。

從現象猜測本質是大忌，可能解釋的通但是終究只是偶然現象，而且從原理上看也是完全錯誤的，甚至官方的實現代碼稍微變一下可能立馬就無法解釋的通了。

總之，通過本文希望大家能對異步和 .NET 中的異步有一個更清晰的理解。

感謝閱讀。

Tags: .NET .NET Core .NET Framework c# CLR