Labs 導讀

隨著異步編程的發展以及各種并發框架的普及，協程作為一種異步編程規范在各類語言中地位逐步提高。我們不單單會在自己的程序中使用協程，各類框架如fastapi，aiohttp等也都是基于異步以及協程進行實現。

數字化轉型時代

用戶對計算機

處理效率的要求越來越高

為保證高并發，高性能

在網絡請求和程序執行的過程中

大量應用會采用[異步編程]

那作為異步編程范式的一種

協程是怎么做的呢？

它有什么優缺點？

各類語言又是怎么實現協程的?

本期Labs帶大家認識下

協程的那些事兒

Part 01、進程，線程到協程 

眾所周知，計算機操作系統中有兩個常見的概念：進程和線程。要講協程，我們先從這兩個基本概念入手。

? 進程：操作系統中每一個獨立允許的程序，都會占有操作系統分配的資源，是資源分配的基本單位。進程之間互不干涉，都只負責運行自己的指令，這就是進程。

? 線程：進程中的一個實體，是被系統獨立調度和CPU分派資源的基本單位，線程自己不擁有系統資源，只擁有一些運行時必不可少的資源，如自己的堆棧，程序計數器，寄存器數據等。一個進程可以有多個線程，各個線程共享進程所擁有的全部資源。

? 協程：協作的線程，也可以被稱作微線程，是一種用戶態的線程，協程的調度是由用戶主動完成的。代表了一種非搶占式的多任務并發的調度思想：協作式調度，即沒有優先級高低的區分。

- 對比

1、從內存占用，上下文切換內容，上下文切換過程等角度進行詳細對比。

圖片

2、從包容關系上來說，一個進程至少包含一個線程，一個線程里面有0個或者多個協程，因此可歸納為如下圖：

Part 02、  從異步編程說起  

異步編程，也可以叫做并發編程，并發不同于并行：并行是物理上并行，至少要有2個CPU，兩個線程同時運行；而并發可以是單核，通過時間調度算法實現多任務調度，給人感覺是同時運行，實際上某一時刻只有一個線程在運行。異步編程能有效避免主線程被阻塞，特別是對于前端來說，如果主線程被阻塞，會導致APP無響應。常見的異步編程有：多線程，回調，Promise，響應式編程以及協程。

- 多線程

以發微博來舉例，發布操作可以簡單歸結為如下三個操作：

1、獲取用戶簽名數據prepareSubmit

2、攜帶簽名數據進行微博發布內容提交請求postSubmit

3、處理請求，響應結果processPost

最開始我們可能只有10個用戶，只需要啟動10個線程去操作，但是隨著用戶數增加到1000個，10000個，這個時候如果啟動10000個線程，由于每個線程至少會占用4M，10000個線程會占用39G的內存，對服務器的性能要求太高了，并且線程之間的切換也會占用大量的系統時間。因此這種方式只適用于線程之間沒有競爭關系，占用內存資源少，切對時延不敏感的情況。

圖片

- 回調

如果用異步回調的等方式解決上面發微博的問題，我們可以用如下代碼來解決，這種方式簡單易懂，使用范圍也很廣，幾乎所有的異步框架都用到了回調。但是也有很明顯的問題：

1、如果步驟很多就會出現嵌套地獄

2、對于異常的情況很難處理和傳遞

3、如果某一個步驟要等多個回調完成之后再進行收口操作，也很困難

圖片

- Promise

Promise是說對于一個耗時比較久的操作，程序給你一個承諾，保證不久之后會把結果告知你。它采用了鏈式編程模型，簡化了回調的異步操作，解決了嵌套地獄的問題，Promise有以下幾種狀態：

• 待定（pending）: 初始狀態，既沒有被兌現，也沒有被拒絕。
• 兌現（fulfilled）: 操作成功完成。
• 拒絕（rejected）: 操作失敗。

發微博問題使用promise來解決如圖，必須等前置條件兌現之后才往后。

圖片

Promise存在如下問題：

1、每一步的返回值類型都必須是 Promise，不能是實際的數據類型

2、錯誤處理變得復雜，不同階段產生的錯誤很難一路傳遞下去

3、不同階段之間共享數據困難

- 響應式編程

響應式編程（Reactive Extension簡稱Rx）的核心是將一切當作數據流，關注數據流的變換和流轉，描述數據輸入與輸出之間的關系，會實現數量眾多的擴展函數，這些函數只對輸入和輸出負責，因此可以很輕松的將函數分發到其他線程上實現異步調用。但Rx調試比較困難，學習成本較高，維護也不易。

- 協程

考慮到大部分互聯網請求都是IO密集型而不是CPU密集型，基本的流程都是：請求-少量計算-調用公共服務-大量讀寫數據庫-返回數據。因此IO密集型很容易發生讀寫阻塞，此時會進行線程切換，執行其他線程。但線程是寶貴的計算資源，因此我們希望線程不要阻塞，一直跑，不要切換上下文。針對這種需求，協程的優勢就出來了。協程執行如圖：

圖片

★ 優點

1）協程的創建，銷毀和調度都發生在用戶態，避免CPU頻繁切換帶來的資源浪費

2）內存占用小，可以輕松創建幾十萬的協程

3）可讀性高，易維護，代碼基本等同于同步

4）通過結構化并發限制控制域，減少內存泄漏

Part 03、  種類劃分 

- 按照調用棧分類

協程最關鍵的步驟就是暫停代碼和恢復代碼執行，實現方法主要基于棧和狀態機&閉包兩種。通過區分執行協程的時候是否可以在任意嵌套函數中被掛起，可以分為有棧協程和無棧協程，有棧協程可以被掛起，無棧協程不能被掛起。先看正常的函數棧操作：

圖片

• 有棧協程

協程實現的關鍵點就是如何保存、恢復和切換上下文，如果將一個函數當作協程，當有棧協程對函數的上下文進行保存，恢復和切換操作時，會對這個函數及其嵌套函數，棧針存儲的值，寄存器存儲的值進行快照操作，之后只需要對快照做，恢復和切換。

• 無棧協程

相比于有棧協程，無棧協程在不改變調用棧的情況下采用了類似狀態機和閉包的方式來存儲暫停點的代碼信息。在不改變函數調用棧的情況下，我們也不可能在任意一個嵌套函數中掛起協程，這也是無棧協程的特點，同時由于不需要切換棧幀，無棧協程的性能比有棧協程還要高一點。

- 按照調度方式分類

協程的暫停和恢復涉及到控制權的轉移，可以分為非對稱協程和對稱協程。

• 非對稱協程

非對稱協程通過暫停和繼續兩個指令進行控制權轉移，暫停之后控制權就會轉移給繼續指令所在的協程，因此控制權的轉移存在較弱的調用方和被調用方的關系。

• 對稱協程

對稱協程只有一個繼續指令，各協程之間地位是平等的，繼續指令執行之后，控制權就會在多個協程之間流轉。

Part 04、 總結 

在高并發、高請求當道的今天，合理利用協程勢必會提升我們的系統性能和用戶體驗。當我們的業務操作或者網絡請求面臨大量IO時，我們可以考慮采用協程替換線程，能夠幫助我們的應用降低系統內存占用，同時也減少了系統切換開銷，提升系統性能。然而協程雖然很強大，但是也不要過度使用，協程只有和異步IO結合起來才能發揮出最大的威力。