Go語言下的線程模型

閱讀Go併發編程對go語言線程模型的筆記，解釋的很是到，好記性不如爛筆頭，忘記的時候回來翻一番，在此作下筆記。

Go語言的線程實現模型,又3個必知的核心元素，他們支撐起了這個線程實現模型的主要框架:
1>M:Machine的縮寫。一個M表明一個內核線程。
2>P:Procecssor的縮寫。一個P表明了M所在的上下文環境。
3>G:Goroutine的縮寫。一個G表明了對一段須要被併發執行的Go語言代碼的封裝。

簡單的來講，一個G的執行文件須要M和P的支持。一個M在與一個P關聯造成一個有效的G運行環境(內核線程+上下文環境)。
每一個P都會包含一個可運行的G的隊列(runq)。該隊列的G會被依次傳給與本地P關聯的M並得到運行時機。在這裏，
咱們把運行當前程序的那個M稱爲當前M，而把與當前M關聯的那個P稱爲本地P。

M(Machine)與KSE(Kernel Schedule Entity)之間總一對一的。一個M能且僅表明一個內核線程。Go語言的運行
時系統(runtime system)用它來表明一個內核調度系統。

1.M(Machine)

一個M表明了一個內核線程。大多數狀況下,建立一個M的緣由都是因爲沒有足夠的M來關聯P(Process)
並運行其中的可運行的G。不過，在運行時系統執行系統監控或垃圾回收等任務的時候也會
致使新的M的建立。M（Machine）的數據結構包括(curg p mstartfn nextp)。

M（Machine）結構中的字段衆多。咱們在這裏只是挑選了對於咱們的初步認識M(Machine)最重要的4個字段。其中字段
curg會存放當前M正在運行的那個G（goroutine）的指針，字段p會指向與當前M相關聯的那個P,而字段mstartfm則表明
咱們立刻會講到的M(Machine)的起始函數。在M被調度的過程當中，這三個字段最能體現他的即便狀況。而另外的字段nextp則
會被用於暫存與當前M(Machine)又潛在關係的P。咱們能夠把調度器將某個P(Process)賦值給某個M的nextp字段的操做稱爲
M和P的預聯。在有些時候，運行時系統給會把剛剛被重啓新啓用的M(Machine)和它預聯的那個P關聯在一塊兒，這就是nextp字段的所起到的做用。

M被建立之初會被加入全局的M(Machine)列表(runtie.allm)中。緊接着，它的起始函數和準備關聯的P(Process)(大多數
狀況下致使次M(Machine)建立操做的那個P(Process))會被設置。最後，運行時系統會爲它專門建立一個新的內核線程並與之
關聯。這樣,這個新的M(Machine)就爲執行G(Goroutine)作好了準備。而這裏的全局M(Machine)列表其實並無什麼特殊的意義。
運行時系統在須要的時候會經過它獲取全部M的信息。同時它也防止M被看成垃圾回收。

在新的M被建立完成以後的會先進行一番初始化工做。其中包括了對自身所持的棧空間以及信號處理方面的初始化。
在這些初始化工做都完成以後。該M將會被執行(若是存在的話)。注意,若是在這個起始函數表明的是系統監控的任務
的話，那麼該M會一直在那裏執行而不會繼續後面的流程。不然，在初始函數被執行完畢後。當前M將會與那個準備與
它關聯的P完成關聯。至此，一個併發執行環境才真正的造成。在這以後，M開始尋找可運行的G並運行它，這一過程
能夠被看作是調度的一部分。

運行時系統所管轄的M（或者說runtime.allm中的M）有時候會被中止，好比在運行時系統準備開始執行垃圾回收任務時候。
運行時系統中止在M的時候，會對它的屬性進行必要的重置以後，把它放進調度器的空閒M列表(runtime.sched.midle)。
由於在須要一個未被使用的M的時候，運行時系統會嘗試從該列表中。

注意，M自己是無狀態的。M是否空閒僅僅覺得它是否存在於調度器的空閒M列表中爲依據。雖然運行時系統能夠經過M列表
獲取全部的M，可是卻沒法得知它們的狀態（由於它們沒有狀態)。

單個Go程序所使用的M最大數據是能夠被設置的。在咱們使用命令運行Go程序的時候，一個引導程序先會被啓動。
這個引導程序先會被啓動，這個初始值是1w。也就是說，一個Go程序最多可使用1w個M。
這就覺得着。在最理想的狀況下，同時能夠有1w個內核線程同時被執行。請注意，這裏說的是最理想的i狀況下的。
因爲操做系統的內核對進程的虛擬內存的佈局的控制以及大小的限制，如此量級的線程很難共存。從這個角度看。
Go語言自己對線程的線程數量幾乎能夠被忽略。

出了上述設置外，咱們也能夠在Go程序中對該限制進行設置。爲了達到此目的，咱們須要調用標準庫的代碼包runtime/debug包
中的SetMaxThreads函數而且對提供新的M最大數量。runtime/debug.SetMaxThreads函數在執行後，會把舊的M最大數量做爲結果
值返回。很是重要的一點是，若是我嫩在調用runtime/debug.seMaxThreads函數時給定的新值比當時M的實際數量還要小的話，
運行時系統就會發起一個運行時恐慌。因此，咱們要當心使用這個函數。請記住，若是咱們真的須要設置M的最大數量。
那麼也早調用runtime/debug.SetMaxThreads函數就也好，對於它的設定值，咱們也要仔細斟酌。

2.P(Process)

P(Process)是使G可以在M中運行的關鍵。Golang的運行時系統會實時地讓P與不一樣的M創建或斷開關聯，以使P中的那些可運行的
G可以在須要的時候及時得到運行時機。這與操做系統內核在CPU之上切換不一樣的進程或者線程相似。

經過調用函數runtime.GOMAXPROCS，咱們能夠改變單個Go程序能夠間接擁有的P的最大數量。初除此自外，咱們還能夠在運行Go程序
以前設置環境變量GOMAXPROCS的值對Go程序的能夠用的P最大的數量作出預先設定。P的最大數量至關因而對能夠被併發運行的用戶
級別的G的數量作出限制。咱們已經知道，每一個P都須要關聯一個M(Machine)才能使其中的可運行的G獲得執行。可是這卻不意味着
環境變量GOMAXPROCS的值會被限制住M的總數量。當M因系統調用的進行而被阻塞(更切確的說，是它運行的G進入了系統的調用)的
時候，運行時系統會將該M和與之關聯的P分離出來。這時，若是這個P的可運行G隊列中還未被運行的G，那麼運行時系統
就會找到一個空閒M，或建立出一個新的M，並與該P關聯以知足這些G運行須要。若是咱們在Go程序中建立大部分Goroutine中
都包含了不少須要的間接地進行各類系統調用(好比各類I/O操做)代碼的話，那麼即便環境變量GOMAXPROCS的值被設定未1，也
極可能被建立不少個M被建立出來。因此，實際的M總數量極可能比環境變量GOMAXPROCS所指代的數量多。因而可知，Go程序
真正使用的內核線程的數量並不會所以而受到限制。

在Go程序開始被運行的時候，咱們在前面提到的引導程序也會對P的最大數量進行設置。P的最大數量的默認值是1。所以。
在默認的狀況下，不管咱們在程序中用go語句啓用多個Goroutine。它們都只會被塞入同一個P的可運行G的隊列中，當
環境變量GOMAXPROCS的值的有效就會被這個硬性限制取代，也就是說，最終的P最大數量值絕對不會比引導程序中的這個硬性
上線值打。該硬性上限值是2的8次方。即256.這個硬性上限值爲256的緣由是Go語言目前還不能保證在數量比256更多的P同時存在的
狀況下Go程序仍能保持高效。也就是說，這個硬行上線並非永久的，它在之後可能會被改變
[https://stackoverflow.com/questions/40943065/golang-why-runtime-gomaxprocs-is-limited-to-256]如今是1024了。

注意,雖然咱們能夠在程序中隨意地調用runtime.GOMAXPROCS函數，可是它的執行會暫時使全部的P都相繼進入中止狀態並試圖
阻止任何用戶級別的G的運行。只有在新的P最大數量被設定完成後，運行時系統纔會開始陸續恢復它們。對於程序的性能是
很是大的損耗。因此，咱們只好在Go程序的main函數的開始處調用runtime.GOMAXPROCS函數。固然，在Go程序中不對它進行
調用而只預先設置環境變量GOMAXPROCS是最好不過的了

在肯定P的最大數量以後，運行時系統會根據這個數值初始化全局的P列表(runtime.allp)與全局M列表相似，該列表包含了當前
運行時的系統建立的全部P。隨後，運行時系統會把調度器的可運行G隊列(runtime.sched.runq)中的全部G均勻的放入到全局
列表中。至此，運行時系統須要用到的全部P都已就緒

與空閒M列表相似，所運行時系統中也存在一個調度器的空閒P列表(runtime.sched.pidle)。當一個P再也不與任何M關聯的時候，
運行時系統就會把它放入到該列表，當前運行時系統須要一個空閒的P關聯某個M的話，會從次列表取一個出來，由此咱們也可知道
空閒P列表的准入條件，注意，即便P進入到了空閒P列表中，它的運行G列表也不必定是空的，二者之間沒有必然的聯繫。

與M不一樣，P自己是有狀態的，一個P可能具備的狀態以下：
1>Pidle: 此狀態代表當前P未與任何M存在關聯。
2>Prunning:此狀態代表當前P與某個M關聯。
3>Psyscall:此狀態代表當前P中的被運行的那個G正在進行系統調用。
4>Pgcstop:此狀態代表運行系統正在驚醒垃圾回收，在運行時系統驚醒垃圾回收的時候，會試圖把全局列表中的都置於此狀態。
5>Pdead:此狀態代表當前P已經不會再被調用。當咱們Go程序運行的過程當中經過調用。

runtime.GOMAXPROCS函數減小P最大數量的時候，其他的P就會被運行時系統置於此狀態。P的初始狀態是Pgcstop，
雖然運行時系統並不會再這時進行垃圾回收。不過，P處於這一初始狀態的時間會很是短暫。緊接着的初始化和填充P中的可
運行G隊列以後，運行時系統會被其狀態設置未Pidle並放入到調度器的空閒列表中。此空閒P列表中的全部P都有調度器根據實際
狀況經進行取用。

3.G(Goroutine)

一個G就至關於一個Goroutine(或稱Go程)，也與咱們使用go語句欲併發執行的一個匿名或命名的函數相對應。咱們
做爲編程人員只使用go語句向Go語言的運行時系統告知了(或提交了)一個個併發任務，而Go語言的運行時系統則會
按照咱們的要求併發地執行完成這一任務。

Go語言的編譯器會把咱們編寫的go語句(go 關鍵字和其後的函數統稱)變成對一個運行時系統中的函數調用，並把go
語句中的那個函數以及其參數都做爲參數傳遞給這個運行時系統中的函數。這也是咱們應該瞭解的第一件與go語句相關
的事。其實它並不神奇，只是表明了咱們向運行時系統遞交了一個任務而已。

運行時系統在接到這樣一個調用以後，會先檢查一下go函數及其參數的合法性，緊接着會試圖從本地P的自由G列表和調度器
的自由G列表獲取可用的G。若是沒有獲取到則只好新建一個G了。與M和P相同，運行時系統也持有一個G的全局列表(runtime.allg)。
新創建的G會在第一時間被加入該列表中。相似地，該列表的主要做用也就是集中存放當前運行時系統中的全部G指針。不管
將會封裝當前的這個go函數的G是不是最新的，運行時系統都會對它進行一次初始化。其中包裹了關聯的go函數以及設置G的
狀態和ID等步驟。在初始化完成後，這個G會被放入到本地P的可運行G隊列中。若是實際成熟，調度會當即進行以使這個G儘快
運行。不過爲了及時運行各個可運行的忙碌着。

每一個G都會由運行時系統根絕其實際狀態狀況設置不一樣的狀態，其可能的狀態以下。
1>Gidle: 在當前G被建立但尚未徹底未被初始化的時候會處於此狀態。
2>Grunnable:表示當前G是可運行時的，而且正在等待被與運行。
3>Grunning:表示當前G正在被運行。
4>Gsyscall:表示當前G正在進行系統調用。
5>Gwaiting:表示當前G正在因某個緣由而等待。
6>Gdead:表示當前G已經被運行完成

在運行時系統想用一個G封咱們經過go語句遞交的go函數的時候，會對這個G進行初始化。其中的一步就是初始化這個G的
狀態，而這個狀態總會是Grunnable。也就是說，一個G真正的開始被使用是在其狀態被設置Grunnable以後。

一個G在被運行的過程當中，時候會等待某個事件以及會等待什麼樣的事件，徹底由其封裝的go函數決定的。例如，
若是這個函數中包含了對通道類型值的操做，那麼在執行到對應的代碼的時候這個G就有可能進入Gwaiting狀態。
這可能在等待從通道類型值中接受值，也多是在等待向通道類型發送值。又例如，設計網絡I/O的時候也會致使
相應的G進入Gwaiting狀態。此外，操做定時器(time.Timer)和調用time.Sleep函數一樣會形成相應的G的等待。在事件到來
以後，G會被"喚醒"並被轉移到Grunnable狀態。待時機來時，它會在此執行。

G在退出系統調用的時候的狀態轉換要比上述狀況發雜一些，運行時系統會先嚐試直接運行這個G，僅當沒法直接運行的時候，才
會把它轉換成Grunnable狀態並放入到調度器放入自由G列表中，顯然，對這樣的一個G來講，在其退出系統之時就被當即繼續運行
是再好不過的了。運行時系統固然會爲此作出一些努力，不過，即便努力失敗了，該G也仍是在實時的調度過程當中被發現並運行。

最後，值得一提的是，進入死亡狀態(Gdead)的G是能夠被從新初始化並使用的。相比之下，P在進入狀態（Pdead）以後則
只能面臨銷燬的結局。由此能夠說明Gdead狀態與Pdead狀態所表達的含義是大相徑庭的。初一Gdead狀態的G會被放入本地P或
調度器的自由G列表，這爲它們的重要條件。

至此，咱們瞭解到一個G在運行時系統中的流轉方式和時機，着也展示了一條go語句的背後所蘊含的玄機。

核心元素容器

在這些容器中，全局的那個3個列表存在的主要目的都分別是爲了統計運行時系統中的全部M,P或G。
相比之下。最應該值得咱們關注的是那些非全局的容器，尤爲是與G相關的那4個容器。

與G有關的非全局容器有可運行G隊列，調度器的自由G列表，本地P的可運行G隊列以及本地P的自由G列表。
運行時系統建立出的任何G都回存在於全局G列表中，而其他的4個列表則只存放在當前做用域的全部特定
的狀態的G。注意，這裏的兩個可運行G列表中的G都擁有幾乎平等的運行機會。因爲這種平等性的存在，因此
咱們無需關心哪類可運行的G會進入到哪個隊列中，不過。能夠順便提一下，從Gsyscall狀態和Ggstop狀態轉出
的G，都會被放入調度器的可運行G隊列，而被運行時系統初始化的G，都會被放入本地P的可運行G隊列。至於
從Gwaiting狀態轉出的G，除了因進行網絡I/O而陷入等待的G以外，都會被存放到本地P的可運行G隊列。此外，
咱們以前說過，對runtine.GOMAXPROCS函數的調用，可能會致使運行時系統清空調度器的可運行G隊列。其中的
全部G都會被均勻地放入到全局P列表這種的各個P的可運行G對了當中。另外一方面在G轉入Gdead狀態後，首先會被
放入本地P的自由G列表，而在運行時系統須要用自由G封裝go函數的時候，也會嘗試從本地P的自由G列表中獲取。
調度器的自由G列表只是起到了一個暫存自由G的做用。

與M和P相關的非全局容器分別是調度器的空閒M列表和調度器的空閒P列表。這兩個列表都被用於存放暫時不被 使用的元素的實例。在運行時系統有須要的時候，會從中獲取i相應的元素的實例從新啓動該它。