Go並發原理

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

Go語言是為並發而生的語言，Go語言是為數不多的在語言層面實現並發的語言；也正是Go語言的並發特性，吸引了全球無數的開發人員。

並發(concurrency)和並行(parallellism)

並發(concurrency)：兩個或兩個以上的任務在一段時間內被執行。我們不必care這些任務在某一個時間點是否是同時執行，可能同時執行，也可能不是，我們只關心在一段時間內，哪怕是很短的時間（一秒或者兩秒）是否執行解決了兩個或兩個以上任務。

並行(parallellism)：兩個或兩個以上的任務在同一時刻被同時執行。

並發說的是邏輯上的概念，而並行，強調的是物理運行狀態。並發“包含”並行。

（詳情請見：Rob Pike 的PPT）

Go的CSP並行存取模型

Go實現了兩種並發形式。第一種是大家普遍認知的：多線程共用記憶體。其實就是Java或者C++等語言中的多線程開發。另外一種是Go語言特有的，也是Go語言推薦的：CSP（communicating sequential processes）並行存取模型。

CSP並行存取模型是在1970年左右提出的概念，屬於比較新的概念，不同於傳統的多線程通過共用記憶體來通訊，CSP講究的是“以通訊的方式來共用記憶體”。

請記住下面這句話：
Do not communicate by sharing memory; instead, share memory by communicating.
“不要以共用記憶體的方式來通訊，相反，要通過通訊來共用記憶體。”

普通的線程並行存取模型，就是像Java、C++、或者Python，他們線程間通訊都是通過共用記憶體的方式來進行的。非常典型的方式就是，在訪問共用資料（例如數組、Map、或者某個結構體或對象）的時候，通過鎖來訪問，因此，在很多時候，衍生出一種方便操作的資料結構，叫做“安全執行緒的資料結構”。例如Java提供的包”java.util.concurrent”中的資料結構。Go中也實現了傳統的線程並行存取模型。

Go的CSP並行存取模型，是通過goroutine和channel來實現的。

• goroutine 是Go語言中並發的執行單位。有點抽象，其實就是和傳統概念上的”線程“類似，可以理解為”線程“。
• channel是Go語言中各個並髮結構體(goroutine)之前的通訊機制。 通俗的講，就是各個goroutine之間通訊的”管道“，有點類似於Linux中的管道。

產生一個goroutine的方式非常的簡單：Go一下，就產生了。

1

go f();

通訊機制channel也很方便，傳資料用channel <- data，取資料用<-channel。

在通訊過程中，傳資料channel <- data和取資料<-channel必然會成對出現，因為這邊傳，那邊取，兩個goroutine之間才會實現通訊。

而且不管傳還是取，必阻塞，直到另外的goroutine傳或者取為止。

有兩個goroutine，其中一個發起了向channel中發起了傳值操作。（goroutine為矩形，channel為箭頭）

左邊的goroutine開始阻塞，等待有人接收。

這時候，右邊的goroutine發起了接收操作。

右邊的goroutine也開始阻塞，等待別人傳送。

這時候，兩邊goroutine都發現了對方，於是兩個goroutine開始一傳，一收。

這便是Golang CSP並行存取模型最基本的形式。

Go並行存取模型的實現原理

我們先從線程講起，無論語言層面何種並行存取模型，到了作業系統層面，一定是以線程的形態存在的。而作業系統根據資源存取權限的不同，體系架構可分為使用者空間和核心空間；核心空間主要操作訪問CPU資源、I/O資源、記憶體資源等硬體資源，為上層應用程式提供最基本的基礎資源，使用者空間呢就是上層應用程式的固定活動空間，使用者空間不可以直接存取資源，必須通過“系統調用”、“庫函數”或“Shell指令碼”來調用核心空間提供的資源。

我們現在的電腦語言，可以狹義的認為是一種“軟體”，它們中所謂的“線程”，往往是使用者態的線程，和作業系統本身核心態的線程（簡稱KSE），還是有區別的。

執行緒模式的實現，可以分為以下幾種方式：

使用者級執行緒模式

，多個使用者態的線程對應著一個核心線程，程式線程的建立、終止、切換或者同步等線程工作必須自身來完成。

核心級執行緒模式

這種模型直接叫用作業系統的核心線程，所有線程的建立、終止、切換、同步等操作，都由核心來完成。C++就是這種。

兩級執行緒模式

這種模型是介於使用者級執行緒模式和核心級執行緒模式之間的一種執行緒模式。這種模型的實現非常複雜，和核心級執行緒模式類似，一個進程中可以對應多個核心級線程，但是進程中的線程不和核心線程一一對應；這種執行緒模式會先建立多個核心級線程，然後用自身的使用者級線程去對應建立的多個核心級線程，自身的使用者級線程需要本身程式去調度，核心級的線程交給作業系統核心去調度。

Go語言的執行緒模式就是一種特殊的兩級執行緒模式。暫且叫它“MPG”模型吧。

Go線程實現模型MPG

M指的是Machine，一個M直接關聯了一個核心線程。
P指的是”processor”，代表了M所需的上下文環境，也是處理使用者級代碼邏輯的處理器。
G指的是Goroutine，其實本質上也是一種輕量級的線程。

三者關係如所示：

以上這個圖講的是兩個線程(核心線程)的情況。一個M會對應一個核心線程，一個M也會串連一個上下文P，一個上下文P相當於一個“處理器”，一個上下文串連一個或者多個Goroutine。P(Processor)的數量是在啟動時被設定為環境變數GOMAXPROCS的值，或者通過運行時調用函數runtime.GOMAXPROCS()進行設定。Processor數量固定意味著任意時刻只有固定數量的線程在運行go代碼。Goroutine中就是我們要執行並發的代碼。圖中P正在執行的Goroutine為藍色的；處於待執行狀態的Goroutine為灰色的，灰色的Goroutine形成了一個隊列runqueues

三者關係的宏觀的圖為：

拋棄P(Processor)

你可能會想，為什麼一定需要一個上下文，我們能不能直接除去上下文，讓Goroutine的runqueues掛到M上呢？答案是不行，需要內容相關的目的，是讓我們可以直接放開其他線程，當遇到核心線程阻塞的時候。

一個很簡單的例子就是系統調用sysall，一個線程肯定不能同時執行代碼和系統調用被阻塞，這個時候，此線程M需要放棄當前的上下文環境P，以便可以讓其他的Goroutine被調度執行。

如左圖所示，M0中的G0執行了syscall，然後就建立了一個M1(也有可能本身就存在，沒建立)，（轉向右圖）然後M0丟棄了P，等待syscall的傳回值，M1接受了P，將·繼續執行Goroutine隊列中的其他Goroutine。

當系統調用syscall結束後，M0會“偷”一個上下文，如果不成功，M0就把它的Gouroutine G0放到一個全域的runqueue中，然後自己放到線程池或者轉入休眠狀態。全域runqueue是各個P在運行完自己的本地的Goroutine runqueue後用來拉取新goroutine的地方。P也會周期性的檢查這個全域runqueue上的goroutine，否則，全域runqueue上的goroutines可能得不到執行而餓死。

均衡的分配工作

按照以上的說法，上下文P會週期性檢查全域的goroutine 隊列中的goroutine，以便自己在消費掉自身Goroutine隊列的時候有事可做。假如全域goroutine隊列中的goroutine也沒了呢？就從其他啟動並執行中的P的runqueue裡偷。

每個P中的Goroutine不同導致他們啟動並執行效率和時間也不同，在一個有很多P和M的環境中，不能讓一個P跑完自身的Goroutine就沒事可做了，因為或許其他的P有很長的goroutine隊列要跑，得需要均衡。
該如何解決呢？

Go的做法倒也直接，從其他P中偷一半！

參考文獻：
The Go scheduler
《Go並發編程第一版》