golang的協程原理

這是一個建立於 的文章，其中的資訊可能已經有所發展或是發生改變。

協程是應用程式層的線程。

 

應用程式層是相對於核心層而言，是作業系統的概念，對應的是cpu的運行層級。作業系統的核心代碼啟動並執行ring0層級，應用程式的代碼運行在ring3層級。核心與應用程式層的層級設定保證了一些高許可權的操作只有核心代碼能做，應用程式要使用這些功能必須通過叫用作業系統的API（linux上稱為系統調用）來調用核心的代碼。這個調用會導致cpu從ring3到ring0的環境切換，這個切換是耗費一些cpu時間的。

 

線程是作業系統的核心對象，多線程編程時，如果線程數過多，就會導致頻繁的環境切換，這些cpu時間是一個額外的耗費。所以在一些高並發的網路伺服器編程中，使用一個線程服務一個socket串連是很不明智的。於是作業系統提供了基於事件模式的非同步編程模型。用少量的線程來服務大量的網路連接和I/O操作。但是採用非同步和基於事件的編程模型，複雜化了程式碼的編寫，非常容易出錯。因為線程穿插，也提高排查錯誤的難度。

 

協程，是在應用程式層類比的線程，他避免了環境切換的額外耗費，兼顧了多線程的優點。簡化了高並發程式的複雜度。舉個例子，一個高並發的網路伺服器，每一個socket串連進來，伺服器用一個協程來對他進行服務。代碼非常清晰。而且兼顧了效能。

 

那麼，協程是怎麼實現的呢？

他和線程的原理是一樣的，當a線程切換到b線程的時候，需要將a線程的相關執行進度壓入棧，然後將b線程的執行進度出棧，進入b的執行序列。協程只不過是在應用成實現這一點。

但是，協程並不是有作業系統調度的，而且應用程式也沒有能力和許可權執行cpu調度。怎麼解決這個問題？

答案是，協程是基於線程的。內部實現上，維護了一組資料結構和n個線程，真正的執行還是線程，協程執行的代碼被扔進一個待執行隊列中，有這n個線程從隊列中拉出來執行。這就解決了協程的執行問題。那麼協程是怎麼切換的呢？答案是:golang對各種io函數進行了封裝，這些封裝的函數提供給應用程式使用，而其內部調用了作業系統的非同步io函數，當這些非同步函數返回busy或bloking時，golang利用這個時機將現有的執行序列壓棧，讓線程去拉另外一個協程的代碼來執行，基本原理就是這樣，利用並封裝了作業系統的非同步函數。包括linux的epoll，select和windows的iocp,event等。

 

由於golang是從編譯器和語言基礎庫多個層面對協程做了實現，所以，golang的協程是目前各類有協程概念的語言中實現的最完整和成熟的。

十萬個協程同時運行也毫無壓力。關鍵我們不會這麼寫代碼。但是總體而言，程式員可以在編寫golang的代碼是，可以更多的關注商務邏輯的實現，更少的在這些關鍵的基礎構件上耗費太多精力。