協程是一個很早的概念了，早些年的遊戲行業中已經大規模地在使用，像lua、go這些語言中的協程原語已經相對比較完善了，一般來說直接使用就好，但是在系統後臺開發上，出現的時間並不長。
我是做C++方向的後臺開發，目前國內一些公司也開源了一些C++協程庫，但目前來說，還是在逐步完善的階段。最早接觸的C++協程庫是騰訊微信的 libco，可以說是相當輕量級的協程，網上關於libco的實現的文章也是相對較多，這裏的話不會去過多地敘述。

在網上查找關於 libgo 的資料，關於代碼實現的文章並沒有多少，因此，打算自己看代碼總結，之後的文章中，可能會針libgo和libco的部分功能進行簡單對比，不足之處，希望讀者指出。

背景

因為工作需要，以前系統的異步框架已經顯得不再那麽地具有擴展性，異步使得原本很簡單的邏輯（讀->處理->寫），要拆分開來成多個階段，通過回調來響應各個事件，因此有計劃地使用協程來代替。

為什麽最後選擇了libgo，而沒有選擇更加輕量級的libco ？網上有人給出過兩者的性能對比，從自旋鎖、協程的數量以及棧空間、線程支持等各個角度考慮，貌似libgo完勝。

圖片來源於網絡

性能對比數據來源於網絡，並不是說libco不好，也許各自應用的場景略有不同，libco幾千行的代碼可以實現一個相對較完備的協程，而且經得住微信後臺龐大的數據流量，自有它的優勢。由於對 libgo 的代碼正在研究當中，因此，暫不對兩者評價。

協程

不管是什麽樣的協程，最核心的內容，都是在系統發生阻塞的時候上層主動讓出CPU，切換就緒協程的上下文，簡要總結，有如下幾個方面：

1. 上下文切換的實現
2. 系統函數的hook；
3. 協程調度；
4. 時間管理；

libgo 源碼

https://github.com/yyzybb537/libgo

libgo 目錄結構說明

muhui@ASIAYANG-MB0:~/code/libgo/libgo-master$ ll
total 64
-rw-r--r--@  1 muhui  staff  5913 11  7 11:20 CMakeLists.txt
-rw-r--r--@  1 muhui  staff  1084 11  7 11:20 LICENSE
-rw-r--r--@  1 muhui  staff  8758 11  7 11:20 README.md
-rw-r--r--@  1 muhui  staff  4230 11  7 11:20 TODO
drwxr-xr-x@  4 muhui  staff   128 11  7 11:20 imgs
drwxr-xr-x@ 15 muhui  staff   480 11  7 11:20 libgo
drwxr-xr-x@  8 muhui  staff   256 11  7 11:20 test
drwxr-xr-x@  6 muhui  staff   192 11  7 11:20 third_party
drwxr-xr-x@ 20 muhui  staff   640 11  7 11:20 tutorial
drwxr-xr-x@  4 muhui  staff   128 11  7 11:20 vs_proj
muhui@ASIAYANG-MB0:~/code/libgo/libgo-master$ cd libgo/
muhui@ASIAYANG-MB0:~/code/libgo/libgo-master/libgo$ ll
total 16
drwxr-xr-x@  4 muhui  staff   128 11  7 11:20 cls
drwxr-xr-x@ 19 muhui  staff   608 11  7 11:20 common
drwxr-xr-x@  6 muhui  staff   192 11  7 11:20 context
-rw-r--r--@  1 muhui  staff  1848 11  7 11:20 coroutine.h
drwxr-xr-x@  5 muhui  staff   160 11  7 11:20 debug
drwxr-xr-x@  4 muhui  staff   128 11  7 11:20 defer
-rw-r--r--@  1 muhui  staff    36 11  7 11:20 libgo.h
drwxr-xr-x@  4 muhui  staff   128 11  7 11:20 netio
drwxr-xr-x@  5 muhui  staff   160 11  7 11:20 pool
drwxr-xr-x@  8 muhui  staff   256 11  7 11:20 scheduler
drwxr-xr-x@  7 muhui  staff   224 11  7 11:20 sync
drwxr-xr-x@  4 muhui  staff   128 11  7 11:20 task
drwxr-xr-x@  4 muhui  staff   128 11  7 11:20 timer
 

libgo 做的較好的一點是增加了對windows 環境的支持等，我們只針對 Linux 環境做研究。

• TODO：libgo 後續會逐步完善或增加的功能；
• libgo：源碼實現的主目錄，關於協程和調度策略的實現都在該目錄下；
• test：測試代碼；
• tutorial：libgo 使用教程代碼；

• vs_proj：VS 環境下如何使用libgo。

  在libgo目錄下

  • task：協程的相關實現；
  • scheduler：協程調度的實現；
  • debug：libgo 自帶的調試功能（用於協程狀態的定位等）；
  • coroutine.h：對一些常用對方法進行了重定義。
• netio：hook的系統調用；
• context：上下文的切換；
• pool：libgo 實現的連接池

libgo調度原理概述

我們知道，協程是用戶態線程，因此libco的話是不支持線程的。但在libgo中，線程同樣是支持的，這於它的調度方式有關。

首先我們要說的一點是，在libgo中，每個協程是一個task，libgo 的調度並不是直接作用於協程，是通過間接調度實現的。

libgo中有調度器（scheduler）和執行器（processer）的概念：

1. 直接負責協程調度的是執行器，它會在協程阻塞的時候切出上下文，並切入一個就緒協程的上下文去繼續處理，當沒有可執行的協程時，執行器就會阻塞等待，當有新到來的任務時，會繼續處理；

2. 負責管理執行器的是調度器，對調度器而言，每個執行器是一個單獨的線程，調度器做的最主要的工作，就是平衡各個執行器中的協程數量，防止饑餓效應，部分執行器過忙，部分執行器卻沒有task可執行，另外，如果某個執行器卡住，調度器也會將執行器中的可運行協程取出，放到負載最低的執行器上。

3. 當然，調度器的個數的話是支持動態擴展的。

如下圖：

關於代碼實現會在下一篇中敘述。

libgo 源碼剖析（1. libgo簡介與調度淺談）