最近有人問起我關於Go語言中協程的設計初衷問題，正好說一下我對這個玩意的想法，同時這個也算是面試中可能會問起的問題。

從操作系統的層面上來在，線程是由內核創建和管理，運行在內核態的一種數據結構。協程是由用戶創建和管理，運行在用戶態的一種數據結構。

知道這點就基本瞭解了線程和協程的區別，那麼問題來了，為什麼要創建協程，用線程不好麼，用線程的資源創建協程，資源使用率不就更加地下了麼？

上面這個疑問，我最開始瞭解到協程這個概念的時候也有，不過隨著接觸的內容變多後就漸漸釋懷了~

有一個IO模型的設計其實和協程的設計非常類似，這個東西叫做epoll，它的出現目的主要是解決了傳統IO硬件利用率低下的問題。網絡IO的特性，經常需要等待外部鏈路的傳輸延遲，這個延遲可能會有上百毫秒以上，甚至更高。而在計算機中，幾百毫秒的時間片已經足夠讓CPU做很多事情了，所以才有了epoll：將大量的IO集中在一個線程上，讓線程來輪詢處理這些IO。

實際上協程也是類似，將多任務也就是協程集中在一個線程上，來達到節省資源的目的。

除此之外還有一個目的，那就是CPU基於每個線程的資源也就是時間片是不固定的，在用戶態是無法控制這玩意的。

正好協程就實現在用戶態，可以在用戶態內進行資源的分配。

其實你可能已經見過協程類似的設計了，沒錯，Nginx當時也是這麼設計的。

其實結論就比較明顯了，協程在類似Web服務這種，IO併發數高，並且有延遲的這種環境，表現會非常出色。在桌面UI事件處理上我認為協程也會有不錯的表現。

就這樣吧，完。