Go語言是爲併發而生的語言，是爲數不多的在語言層面實現併發的語言。瞭解Go併發機制並熟悉其併發特性有助於我們更好的編寫併發程序。本文將按順序分別介紹Go的CSP併發模型及其併發模型的實現原理。
1.併發和並行
提到併發，就不得不提並行，這裏我們先回顧下併發和並行的區別與聯繫：
- 併發（concurrency）：兩個或兩個以上的任務在一段時間內被執行，我們不必關注這些任務在某一個時間點是否同時執行，可能同時執行，也可能不是，我們只關心在一段時間內，哪怕是很短的時間（一秒或者兩秒）是否執行解決了兩個或兩個以上的任務
- 並行（parallellism）：兩個或兩個以上的任務在同一時刻被同時執行
簡而言之，併發說的是邏輯上的概念，而並行，強調的是物理運行狀態。併發“包含”並行。
2.Go的CSP併發模型
2.1.CSP簡介
在計算機科學中，通信順序過程（communicating sequential processes，CSP）是一種描述併發系統中交互模式的正式語言，它是併發數學理論家族中的一個成員，被稱爲過程算法（process algebras），或者說過程計算（process calculate），是基於消息的通道傳遞的數學理論。
CSP模型是上個世紀70年代提出的，不同於傳統的多線程通過共享內存來通信，CSP講究的是“以通信的方式來共享內存”。CSP是用於描述兩個獨立的併發實體通過共享的通訊即channel（管道）進行通信的併發模型。在CSP中channel是第一類對象，CSP並不關注發送消息的實體，它只關注實體之間發送消息時使用的channel。
Go中的channel是被單獨創建並且可以在進程之間進行消息傳遞的結構體，它的通信模式類似於boss-worker模式，一個實體將消息發送到channel中，然後由另一個實體監聽並接收channel的消息，在這一過程中，兩個實體之間是匿名的，這個就實現了實體之間的解耦。
2.2.Go的CSP併發模型
Go實現了兩種併發方式。第一種是大家大家普遍認知的：多線程共享內存。其實就是Java或者C++等語言中的多線程開發。另外一種是Go語言特有的，也是Go語言推薦的：CSP併發模型。
普通的線程併發模型，就是像Java、C++、或者Python，他們線程間通信都是通過共享內存的方式來進行的。
非常典型的方式就是，在訪問共享數據（例如數組、Map、或者某個結構體或對象）的時候，通過鎖來訪問。
因此，在很多時候，衍生出一種方便操作的數據結構，叫做“線程安全的數據結構”。例如Java提供的包”java.util.concurrent”中的數據結構。
Go中也實現了傳統的線程併發模型，如爲了在併發場景中安全使用map，Go提供了sync.Map。
Go的CSP併發模型，是通過goroutine和channel來實現的。
- goroutine 是Go語言中併發的執行單位。有點抽象，其實就是和傳統概念上的”線程“類似，可以理解爲”線程“
- channel是Go語言中各個併發結構體(goroutine)之前的通信機制。 通俗的講，就是各個goroutine之間通信的”管道“，有點類似於Linux中的管道
goroutine底層使用協程（coroutine）實現併發，coroutine是一種運行在用戶態的用戶線程，類似於greenthread。
go選擇使用coroutine的出發點是因爲：
- 用戶空間，避免了內核態和用戶態的切換導致的成本
- 可以由語言和框架層進行調度
- 更小的棧空間允許創建大量實例
生成一個goroutine的方式非常的簡單：
go f()
通信機制channel也很方便，傳數據用channel <- data，取數據用<-channel。
在通信過程中，傳數據channel <- data和取數據<-channel必然會成對出現，因爲這邊傳，那邊取，兩個goroutine之間纔會實現通信。
而且不管傳還是取，必阻塞，直到另外的goroutine傳或者取爲止。
以流程圖形式展示這一過程如下：
假設有兩個goroutine，其中一個首先向channel發送了數據：（goroutine爲矩形，channel爲箭頭）
左邊的goroutine開始阻塞，等待有人從channel接收數據。
然後右邊的goroutine發起了接收操作。
右邊的goroutine也開始阻塞，等待有人向cahnnel發送數據。
這時候，兩邊goroutine都發現了對方，於是兩個goroutine就通過channel實現了數據的傳輸。
3.Go併發模型的實現原理
我們先從線程講起，無論語言層面是何種併發模型，到了操作系統層面，一定是以線程的形態存在的。而操作系統根據資源訪問權限的不同，體系架構可分爲用戶空間和內核空間；內核空間主要操作訪問CPU資源、I/O資源、內存資源等硬件資源，爲上層應用程序提供最基本的基礎資源，用戶空間則就是上層應用程序的固定活動空間，用戶空間不可以直接訪問資源，必須通過“系統調用”、“庫函數”或“Shell腳本”來調用內核空間提供的資源。
我們現在的計算機語言，可以狹義的認爲是一種“軟件”，它們中所謂的“線程”，往往是用戶態的線程，和操作系統本身內核態的線程（簡稱KSE），還是有區別的。
3.1.線程模型
線程模型的實現，可以分爲以下幾種方式：
- 用戶級線程模型
如圖所示，多個用戶態的線程對應着一個內核線程，程序線程的創建、終止、切換或者同步等線程工作必須自身來完成。
- 內核級線程模型
這種模型直接調用操作系統的內核線程，所有線程的創建、終止、切換、同步等操作，都由內核來完成。C++就是這種。
- 兩級線程模型
這種模型是介於用戶級線程模型和內核級線程模型之間的一種線程模型。
這種模型的實現非常複雜：
- 和內核級線程模型類似，一個進程中可以對應多個內核級線程，但是進程中的線程不和內核線程一一對應；
- 這種線程模型會先創建多個內核級線程，然後用自身的用戶級線程去對應創建的多個內核級線程；
- 自身的用戶級線程需要本身程序去調度，內核級的線程交給操作系統內核去調度。
Go語言的線程模型就是一種特殊的兩級線程模型。暫且叫它“GPM”模型吧。
3.2.GPM模型
- GPM簡介
- G指的是Goroutine，其實本質上也是一種輕量級的線程。
- P指的是”processor”，代表了M所需的上下文環境，也是處理用戶級代碼邏輯的處理器。
- M指的是Machine，一個M直接關聯了一個內核線程。
三者關係如下圖所示：
上圖講的是兩個線程(內核線程)的情況。一個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中偷一半。
因此，GPM的簡要概括即爲：事件循環、線程池、工作隊列
綜上，我們簡要介紹了go併發機制及它所使用的CSP併發模型，瞭解這些可以幫助我們更好的進行併發程序的開發，實現性能的優化。