Go goroutine理解

Go語言最大的特點就是從語言層面支持併發(Goroutine),Goroutine是Go中最基本的執行單元。事實上每個Go程序至少有一個Goroutine:主Goroutine。當程序啓動時,它會自動建立。java

爲了更好理解Goroutine,現講一下線程和協程的概念git

線程(Thread):有時被稱爲輕量級進程(Lightweight Process,LWP),是程序執行流的最小單元。一個標準的線程由線程ID,當前指令指針(PC),寄存器集合和堆棧組成。另外,線程是進程中的一個實體,是被系統獨立調度和分派的基本單位,線程本身不擁有系統資源,只擁有一點兒在運行中必不可少的資源,但它可與同屬一個進程的其它線程共享進程所擁有的所有資源。程序員

線程擁有本身獨立的棧和共享的堆,共享堆,不共享棧,線程的切換通常也由操做系統調度。github

協程(coroutine):又稱微線程與子例程(或者稱爲函數)同樣,協程(coroutine)也是一種程序組件。相對子例程而言,協程更爲通常和靈活,但在實踐中使用沒有子例程那樣普遍。golang

和線程相似,共享堆,不共享棧,協程的切換通常由程序員在代碼中顯式控制。它避免了上下文切換的額外耗費,兼顧了多線程的優勢,簡化了高併發程序的複雜。數組

Goroutine和其餘語言的協程(coroutine)在使用方式上相似,但從字面意義上來看不一樣(一個是Goroutine,一個是coroutine),再就是協程是一種協做任務控制機制,在最簡單的意義上,協程不是併發的,而Goroutine支持併發的。所以Goroutine能夠理解爲一種Go語言的協程。同時它能夠運行在一個或多個線程上。緩存

先給個簡單實例安全

func loop() {
    for i := 0; i < ; i++ {
        fmt.Printf("%d ", i)
    }
}

func main() {
   go loop() // 啓動一個goroutine
    loop()
}

GO併發的實現原理

1、Go併發模型服務器

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併發模型,是經過goroutinechannel來實現的。

  • goroutine 是Go語言中併發的執行單位。有點抽象,其實就是和傳統概念上的」線程「相似,能夠理解爲」線程「。
  • channel是Go語言中各個併發結構體(goroutine)以前的通訊機制。 通俗的講,就是各個goroutine之間通訊的」管道「,有點相似於Linux中的管道。

生成一個goroutine的方式很是的簡單:Go一下,就生成了。

go f();

通訊機制channel也很方便,傳數據用channel <- data,取數據用<-channel

在通訊過程當中,傳數據channel <- data和取數據<-channel必然會成對出現,由於這邊傳,那邊取,兩個goroutine之間纔會實現通訊。

並且無論傳仍是取,必阻塞,直到另外的goroutine傳或者取爲止。

示例以下:

package main

import "fmt"

func main() {
   
   messages := make(chan string)

   go func() { messages <- "ping" }()

   msg := <-messages
   fmt.Println(msg)
}

注意 main()自己也是運行了一個goroutine。

messages:= make(chan int) 這樣就聲明瞭一個阻塞式的無緩衝的通道

chan 是關鍵字 表明我要建立一個通道

GO併發模型的實現原理

咱們先從線程講起,不管語言層面何種併發模型,到了操做系統層面,必定是以線程的形態存在的。而操做系統根據資源訪問權限的不一樣,體系架構可分爲用戶空間和內核空間;內核空間主要操做訪問CPU資源、I/O資源、內存資源等硬件資源,爲上層應用程序提供最基本的基礎資源,用戶空間呢就是上層應用程序的固定活動空間,用戶空間不能夠直接訪問資源,必須經過「系統調用」、「庫函數」或「Shell腳本」來調用內核空間提供的資源。

咱們如今的計算機語言,能夠狹義的認爲是一種「軟件」,它們中所謂的「線程」,每每是用戶態的線程,和操做系統自己內核態的線程(簡稱KSE),仍是有區別的。

線程模型的實現,能夠分爲如下幾種方式:

用戶級線程模型

如圖所示,多個用戶態的線程對應着一個內核線程,程序線程的建立、終止、切換或者同步等線程工做必須自身來完成。它能夠作快速的上下文切換。缺點是不能有效利用多核CPU。

內核級線程模型

這種模型直接調用操做系統的內核線程,全部線程的建立、終止、切換、同步等操做,都由內核來完成。一個用戶態的線程對應一個系統線程,它能夠利用多核機制,但上下文切換須要消耗額外的資源。C++就是這種。

兩級線程模型

這種模型是介於用戶級線程模型和內核級線程模型之間的一種線程模型。這種模型的實現很是複雜,和內核級線程模型相似,一個進程中能夠對應多個內核級線程,可是進程中的線程不和內核線程一一對應;這種線程模型會先建立多個內核級線程,而後用自身的用戶級線程去對應建立的多個內核級線程,自身的用戶級線程須要自己程序去調度,內核級的線程交給操做系統內核去調度。

M個用戶線程對應N個系統線程,缺點增長了調度器的實現難度。

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

Go線程實現模型MPG

M指的是Machine,一個M直接關聯了一個內核線程。由操做系統管理。
P指的是」processor」,表明了M所需的上下文環境,也是處理用戶級代碼邏輯的處理器。它負責銜接M和G的調度上下文,將等待執行的G與M對接。
G指的是Goroutine,其實本質上也是一種輕量級的線程。包括了調用棧,重要的調度信息,例如channel等。

P的數量由環境變量中的GOMAXPROCS決定,一般來講它是和核心數對應,例如在4Core的服務器上回啓動4個線程。G會有不少個,每一個P會將Goroutine從一個就緒的隊列中作Pop操做,爲了減少鎖的競爭,一般狀況下每一個P會負責一個隊列。

三者關係以下圖所示:

以上這個圖講的是兩個線程(內核線程)的狀況。一個M會對應一個內核線程,一個M也會鏈接一個上下文P,一個上下文P至關於一個「處理器」,一個上下文鏈接一個或者多個Goroutine。爲了運行goroutine,線程必須保存上下文。

上下文P(Processor)的數量在啓動時設置爲GOMAXPROCS環境變量的值或經過運行時函數GOMAXPROCS()。一般狀況下,在程序執行期間不會更改。上下文數量固定意味着只有固定數量的線程在任什麼時候候運行Go代碼。咱們可使用它來調整Go進程到我的計算機的調用,例如4核PC在4個線程上運行Go代碼。

圖中P正在執行的Goroutine爲藍色的;處於待執行狀態的Goroutine爲灰色的,灰色的Goroutine造成了一個隊列runqueues

Go語言裏,啓動一個goroutine很容易:go function 就行,因此每有一個go語句被執行,runqueue隊列就在其末尾加入一個goroutine,一旦上下文運行goroutine直到調度點,它會從其runqueue中彈出goroutine,設置堆棧和指令指針並開始運行goroutine。

拋棄P(Processor)

你可能會想,爲何必定須要一個上下文,咱們能不能直接除去上下文,讓Goroutinerunqueues掛到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中偷一半!

Goroutine 小結

優勢:

一、開銷小

POSIX的thread API雖然可以提供豐富的API,例如配置本身的CPU親和性,申請資源等等,線程在獲得了不少與進程相同的控制權的同時,開銷也很是的大,在Goroutine中則不需這些額外的開銷,因此一個Golang的程序中能夠支持10w級別的Goroutine。

每一個 goroutine (協程) 默認佔用內存遠比 Java 、C 的線程少(goroutine:2KB ,線程:8MB)

二、調度性能好

在Golang的程序中,操做系統級別的線程調度,一般不會作出合適的調度決策。例如在GC時,內存必需要達到一個一致的狀態。在Goroutine機制裏,Golang能夠控制Goroutine的調度,從而在一個合適的時間進行GC。

在應用層模擬的線程,它避免了上下文切換的額外耗費,兼顧了多線程的優勢。簡化了高併發程序的複雜度。

缺點:

協程調度機制沒法實現公平調度。

參考:

links

相關文章
相關標籤/搜索