前言

http://www.dbjr.com.cn/article/228730.htm

請記住下面這句話：

DO NOT COMMUNICATE BY SHARING MEMORY; INSTEAD, SHARE MEMORY BY COMMUNICATING.

“不要以共享內(nèi)存的方式來通信，相反，要通過通信來共享內(nèi)存。”

普通的線程并發(fā)模型，就是像Java、C++、或者Python，他們線程間通信都是通過共享內(nèi)存的方式來進(jìn)行的。非常典型的方式就是，在訪問共享數(shù)據(jù)（例如數(shù)組、Map、或者某個(gè)結(jié)構(gòu)體或?qū)ο螅┑臅r(shí)候，通過鎖來訪問，因此，在很多時(shí)候，衍生出一種方便操作的數(shù)據(jù)結(jié)構(gòu)，叫做“線程安全的數(shù)據(jù)結(jié)構(gòu)”。例如Java提供的包”java.util.concurrent”中的數(shù)據(jù)結(jié)構(gòu)。Go中也實(shí)現(xiàn)了傳統(tǒng)的線程并發(fā)模型。

Go的CSP并發(fā)模型，是通過goroutine和channel來實(shí)現(xiàn)的。

goroutine 是Go語言中并發(fā)的執(zhí)行單位。有點(diǎn)抽象，其實(shí)就是和傳統(tǒng)概念上的”線程“類似，可以理解為”線程“。

channel是Go語言中各個(gè)并發(fā)結(jié)構(gòu)體(goroutine)之前的通信機(jī)制。 通俗的講，就是各個(gè)goroutine之間通信的”管道“，有點(diǎn)類似于Linux中的管道。

生成一個(gè)goroutine的方式非常的簡單：Go一下，就生成了。

go f();

通信機(jī)制channel也很方便，傳數(shù)據(jù)用channel <- data，取數(shù)據(jù)用<-channel。

在通信過程中，傳數(shù)據(jù)channel <- data和取數(shù)據(jù)<-channel必然會成對出現(xiàn)，因?yàn)檫@邊傳，那邊取，兩個(gè)goroutine之間才會實(shí)現(xiàn)通信。

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

示例如下：

package main
import "fmt"
func main() {
   messages := make(chan string)
   go func() { messages <- "ping" }()
   msg := <-messages
   fmt.Println(msg)
}

注意 main()本身也是運(yùn)行了一個(gè)goroutine。

messages:= make(chan int) 這樣就聲明了一個(gè)阻塞式的無緩沖的通道

chan 是關(guān)鍵字 代表我要創(chuàng)建一個(gè)通道

GO并發(fā)模型的實(shí)現(xiàn)原理

我們先從線程講起，無論語言層面何種并發(fā)模型，到了操作系統(tǒng)層面，一定是以線程的形態(tài)存在的。而操作系統(tǒng)根據(jù)資源訪問權(quán)限的不同，體系架構(gòu)可分為用戶空間和內(nèi)核空間；內(nèi)核空間主要操作訪問CPU資源、I/O資源、內(nèi)存資源等硬件資源，為上層應(yīng)用程序提供最基本的基礎(chǔ)資源，用戶空間呢就是上層應(yīng)用程序的固定活動空間，用戶空間不可以直接訪問資源，必須通過“系統(tǒng)調(diào)用”、“庫函數(shù)”或“Shell腳本”來調(diào)用內(nèi)核空間提供的資源。

我們現(xiàn)在的計(jì)算機(jī)語言，可以狹義的認(rèn)為是一種“軟件”，它們中所謂的“線程”，往往是用戶態(tài)的線程，和操作系統(tǒng)本身內(nèi)核態(tài)的線程（簡稱KSE），還是有區(qū)別的。

線程模型的實(shí)現(xiàn)，可以分為以下幾種方式：

用戶級線程模型

如圖所示，多個(gè)用戶態(tài)的線程對應(yīng)著一個(gè)內(nèi)核線程，程序線程的創(chuàng)建、終止、切換或者同步等線程工作必須自身來完成。它可以做快速的上下文切換。缺點(diǎn)是不能有效利用多核CPU。

內(nèi)核級線程模型

這種模型直接調(diào)用操作系統(tǒng)的內(nèi)核線程，所有線程的創(chuàng)建、終止、切換、同步等操作，都由內(nèi)核來完成。一個(gè)用戶態(tài)的線程對應(yīng)一個(gè)系統(tǒng)線程，它可以利用多核機(jī)制，但上下文切換需要消耗額外的資源。C++就是這種。

兩級線程模型

這種模型是介于用戶級線程模型和內(nèi)核級線程模型之間的一種線程模型。這種模型的實(shí)現(xiàn)非常復(fù)雜，和內(nèi)核級線程模型類似，一個(gè)進(jìn)程中可以對應(yīng)多個(gè)內(nèi)核級線程，但是進(jìn)程中的線程不和內(nèi)核線程一一對應(yīng)；這種線程模型會先創(chuàng)建多個(gè)內(nèi)核級線程，然后用自身的用戶級線程去對應(yīng)創(chuàng)建的多個(gè)內(nèi)核級線程，自身的用戶級線程需要本身程序去調(diào)度，內(nèi)核級的線程交給操作系統(tǒng)內(nèi)核去調(diào)度。

M個(gè)用戶線程對應(yīng)N個(gè)系統(tǒng)線程，缺點(diǎn)增加了調(diào)度器的實(shí)現(xiàn)難度。

Go語言的線程模型就是一種特殊的兩級線程模型（GPM調(diào)度模型）。

Go線程實(shí)現(xiàn)模型MPG

M指的是Machine，一個(gè)M直接關(guān)聯(lián)了一個(gè)內(nèi)核線程。由操作系統(tǒng)管理。

P指的是”processor”，代表了M所需的上下文環(huán)境，也是處理用戶級代碼邏輯的處理器。它負(fù)責(zé)銜接M和G的調(diào)度上下文，將等待執(zhí)行的G與M對接。

G指的是Goroutine，其實(shí)本質(zhì)上也是一種輕量級的線程。包括了調(diào)用棧，重要的調(diào)度信息，例如channel等。

P的數(shù)量由環(huán)境變量中的GOMAXPROCS決定，通常來說它是和核心數(shù)對應(yīng)，例如在4Core的服務(wù)器上回啟動4個(gè)線程。G會有很多個(gè)，每個(gè)P會將Goroutine從一個(gè)就緒的隊(duì)列中做Pop操作，為了減小鎖的競爭，通常情況下每個(gè)P會負(fù)責(zé)一個(gè)隊(duì)列。

三者關(guān)系如下圖所示：

以上這個(gè)圖講的是兩個(gè)線程(內(nèi)核線程)的情況。一個(gè)M會對應(yīng)一個(gè)內(nèi)核線程，一個(gè)M也會連接一個(gè)上下文P，一個(gè)上下文P相當(dāng)于一個(gè)“處理器”，一個(gè)上下文連接一個(gè)或者多個(gè)Goroutine。為了運(yùn)行g(shù)oroutine，線程必須保存上下文。

上下文P(Processor)的數(shù)量在啟動時(shí)設(shè)置為GOMAXPROCS環(huán)境變量的值或通過運(yùn)行時(shí)函數(shù)GOMAXPROCS()。通常情況下，在程序執(zhí)行期間不會更改。上下文數(shù)量固定意味著只有固定數(shù)量的線程在任何時(shí)候運(yùn)行Go代碼。我們可以使用它來調(diào)整Go進(jìn)程到個(gè)人計(jì)算機(jī)的調(diào)用，例如4核PC在4個(gè)線程上運(yùn)行Go代碼。

圖中P正在執(zhí)行的Goroutine為藍(lán)色的；處于待執(zhí)行狀態(tài)的Goroutine為灰色的，灰色的Goroutine形成了一個(gè)隊(duì)列runqueues。

Go語言里，啟動一個(gè)goroutine很容易：go function 就行，所以每有一個(gè)go語句被執(zhí)行，runqueue隊(duì)列就在其末尾加入一個(gè)goroutine，一旦上下文運(yùn)行g(shù)oroutine直到調(diào)度點(diǎn)，它會從其runqueue中彈出goroutine，設(shè)置堆棧和指令指針并開始運(yùn)行g(shù)oroutine。

拋棄P(Processor)

你可能會想，為什么一定需要一個(gè)上下文，我們能不能直接除去上下文，讓Goroutine的runqueues掛到M上呢？答案是不行，需要上下文的目的，是讓我們可以直接放開其他線程，當(dāng)遇到內(nèi)核線程阻塞的時(shí)候。

一個(gè)很簡單的例子就是系統(tǒng)調(diào)用sysall，一個(gè)線程肯定不能同時(shí)執(zhí)行代碼和系統(tǒng)調(diào)用被阻塞，這個(gè)時(shí)候，此線程M需要放棄當(dāng)前的上下文環(huán)境P，以便可以讓其他的Goroutine被調(diào)度執(zhí)行。

如上圖左圖所示，M0中的G0執(zhí)行了syscall，然后就創(chuàng)建了一個(gè)M1(也有可能來自線程緩存)，（轉(zhuǎn)向右圖）然后M0丟棄了P，等待syscall的返回值，M1接受了P，將·繼續(xù)執(zhí)行Goroutine隊(duì)列中的其他Goroutine。

當(dāng)系統(tǒng)調(diào)用syscall結(jié)束后，M0會“偷”一個(gè)上下文，如果不成功，M0就把它的Gouroutine G0放到一個(gè)全局的runqueue中，將自己置于線程緩存中并進(jìn)入休眠狀態(tài)。全局runqueue是各個(gè)P在運(yùn)行完自己的本地的Goroutine runqueue后用來拉取新goroutine的地方。P也會周期性的檢查這個(gè)全局runqueue上的goroutine，否則，全局runqueue上的goroutines可能得不到執(zhí)行而餓死。

均衡的分配工作

按照以上的說法，上下文P會定期的檢查全局的goroutine 隊(duì)列中的goroutine，以便自己在消費(fèi)掉自身Goroutine隊(duì)列的時(shí)候有事可做。假如全局goroutine隊(duì)列中的goroutine也沒了呢？就從其他運(yùn)行的中的P的runqueue里偷。

每個(gè)P中的Goroutine不同導(dǎo)致他們運(yùn)行的效率和時(shí)間也不同，在一個(gè)有很多P和M的環(huán)境中，不能讓一個(gè)P跑完自身的Goroutine就沒事可做了，因?yàn)榛蛟S其他的P有很長的goroutine隊(duì)列要跑，得需要均衡。
該如何解決呢？

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

Goroutine 小結(jié)

優(yōu)點(diǎn)：

1、開銷小

POSIX的thread API雖然能夠提供豐富的API，例如配置自己的CPU親和性，申請資源等等，線程在得到了很多與進(jìn)程相同的控制權(quán)的同時(shí)，開銷也非常的大，在Goroutine中則不需這些額外的開銷，所以一個(gè)Golang的程序中可以支持10w級別的Goroutine。

每個(gè) goroutine (協(xié)程) 默認(rèn)占用內(nèi)存遠(yuǎn)比 Java 、C 的線程少（goroutine：2KB ，線程：8MB）

2、調(diào)度性能好

在Golang的程序中，操作系統(tǒng)級別的線程調(diào)度，通常不會做出合適的調(diào)度決策。例如在GC時(shí)，內(nèi)存必須要達(dá)到一個(gè)一致的狀態(tài)。在Goroutine機(jī)制里，Golang可以控制Goroutine的調(diào)度，從而在一個(gè)合適的時(shí)間進(jìn)行GC。

在應(yīng)用層模擬的線程，它避免了上下文切換的額外耗費(fèi)，兼顧了多線程的優(yōu)點(diǎn)。簡化了高并發(fā)程序的復(fù)雜度。

缺點(diǎn)：

協(xié)程調(diào)度機(jī)制無法實(shí)現(xiàn)公平調(diào)度。

以上就是CSP communicating sequential processes并發(fā)模型的詳細(xì)內(nèi)容，更多關(guān)于CSP并發(fā)模型的資料請關(guān)注腳本之家其它相關(guān)文章！

最新評論