協程是一種用戶態的輕量級線程。
server的發展如下：
IO密集型應用: 多進程->多線程->事件驅動->協程
CPU密集型應用:多進程-->多線程
如果說多進程對於多CPU，多線程對應多核CPU，那么事件驅動和協程則是在充分挖掘不斷提高性能的單核CPU的潛力。
異步事件驅動模型中，把會導致阻塞的操作轉化為一個異步操作，主線程負責發起這個異步操作，並處理這個異步操作的結果。由於所有阻塞的操作都轉化為異步操作，理論上主線程的大部分時間都是在處理實際的計算任務，少了多線程的調度時間，所以這種模型的性能通常會比較好。總的說來，當單核cpu性能提升，cpu不在成為性能瓶頸時，采用異步server能夠簡化編程模型，也能提高IO密集型應用的性能。
協程擁有自己的寄存器上下文和棧。協程調度切換時，將寄存器上下文和棧保存到其他地方，在切回來的時候，恢復先前保存的寄存器上下文和棧。因此：
協程能保留上一次調用時的狀態（即所有局部狀態的一個特定組合），每次過程重入時，就相當於進入上一次調用的狀態，換種說法：進入上一次離開時所處邏輯流的位置。
在並發編程中，協程與線程類似，每個協程表示一個執行單元，有自己的本地數據，與其它協程共享全局數據和其它資源。目前主流語言基本上都選擇了多線程作為並發設施，與線程相關的概念是搶占式多任務（Preemptive multitasking），而與協程相關的是協作式多任務。
不管是進程還是線程，每次阻塞、切換都需要陷入系統調用(system call)，先讓CPU跑操作系統的調度程序，然后再由調度程序決定該跑哪一個進程(線程)。
而且由於搶占式調度執行順序無法確定的特點，使用線程時需要非常小心地處理同步問題，而協程完全不存在這個問題（事件驅動和異步程序也有同樣的優點）。
我們在自己在進程里面完成邏輯流調度，碰着i\o我就用非阻塞式的。那么我們即可以利用到異步優勢，又可以避免反復系統調用，還有進程切換造成的開銷，分分鍾給你上幾千個邏輯流不費力。這就是協程。
協程 vs 事件驅動
以nginx為代表的事件驅動的異步server正在橫掃天下，那么事件驅動模型會是server端模型的終點嗎？
事件驅動編程的架構是預先設計一個事件循環，這個事件循環程序不斷地檢查目前要處理的信息，根據要處理的信息運行一個觸發函數。其中這個外部信息可能來自一個目錄夾中的文件，可能來自鍵盤或鼠標的動作，或者是一個時間事件。這個觸發函數，可以是系統默認的也可以是用戶注冊的回調函數。
事件驅動程序設計着重於彈性以及異步化上面。許多GUI框架（如windows的MFC，Android的GUI框架），Zookeeper的Watcher等都使用了事件驅動機制。
基於事件驅動的編程是單線程思維，其特點是異步+回調。
協程也是單線程，但是它能讓原來要使用異步+回調方式寫的非人類代碼,可以用看似同步的方式寫出來。它是實現推拉互動的所謂非搶占式協作的關鍵。
總結
協程的好處：
- 跨平台
- 跨體系架構
- 無需線程上下文切換的開銷
- 無需原子操作鎖定及同步的開銷
- 方便切換控制流，簡化編程模型
- 高並發+高擴展性+低成本：一個CPU支持上萬的協程都不是問題。所以很適合用於高並發處理。
缺點：
- 無法利用多核資源：協程的本質是個單線程,它不能同時將單個CPU 的多個核用上,協程需要和進程配合才能運行在多CPU上.當然我們日常所編寫的絕大部分應用都沒有這個必要，除非是cpu密集型應用。
- 進行阻塞（Blocking）操作（如IO時）會阻塞掉整個程序：這一點和事件驅動一樣，可以使用異步IO操作來解決
https://www.liaoxuefeng.com/wiki/001374738125095c955c1e6d8bb493182103fac9270762a000/0013868328689835ecd883d910145dfa8227b539725e5ed000
http://www.infoq.com/cn/articles/CplusStyleCorourtine-At-Wechat
https://www.zhihu.com/question/32218874