有關 協程 原理， 見 《協程 和 async await》 https://www.cnblogs.com/KSongKing/p/10799875.html ，

協程 切換 的時間很快， 就是 保存 3 個 寄存器 的 值， 再 修改 3 個 寄存器 的 值，

這 3 個 寄存器 分別 保存的 是 協程 的 棧頂 棧底 指令計數器，

切換 協程 就是 保存 上一個 協程 的 棧頂 棧底 指令計數器 ， 再 把 寄存器 的 值 修改 為 下一個 協程 的 棧頂 棧底 指令計數器 。

所以， 協程 切換 相當於 是 調用一個 很短 的 方法， 時間復雜度 可以認為是 O(1) 。

我在 《協程 和 async await》 中 提到， 協程 避免 閉包 共享變量 帶來的 二次尋址 的 性能消耗，

但是，實際上， 有了 協程 的 話， 已經不需要 異步回調 來 減少 線程數量 和 線程切換時間， 當然 也不需要 async await 。

我們可以 正常 的 編寫 同步調用 的 方法，比如， 讀取文件， 可以調用 FileStream 的 Read() 方法， 而 不需要 調用 ReadAsync() 或者 BeginRead() 方法 。

當然，這個 Read() 方法 需要用 協程 重新實現， Read() 方法 的 同步等待 要用 協程 的 同步等待 來實現，而不是 線程 的 同步等待 。

協程 的 同步等待 和 線程 一樣， 在 Read() 方法 裏， 當 調用 操作系統 的 異步 IO API 時， 當前 協程 掛起， 當前 線程 轉而 執行其它 協程 ，

當 異步 IO 完成時，會把 調用這個 IO 的 掛起 的 協程 喚醒（放入 就緒隊列），這樣 接下來 很快就會 執行到 這個 協程 了 。

再見 異步回調， 再見 Async Await， 10 萬 個 協程 的 時代 來 了