goroutine學習筆記

進程、線程、協(xié)程

進程：系統(tǒng)進行資源分配的基本單位，由獨立的內(nèi)存空間

線程：CPU調(diào)度和分配資源的基本單位，線程依附于進程，每個線程會共享父進程的資源

協(xié)程：一種用戶態(tài)的輕量級線程，協(xié)程完全由用戶控制，協(xié)程間的切換只需要保存任務(wù)的上下文，沒有內(nèi)核開銷

優(yōu)勢

1. 內(nèi)存消耗更小
   1. 一個線程可以包含多個協(xié)程
   2. 線程大約申請8MB內(nèi)存（線程?？臻g通常是 2M）
   3. 協(xié)程大約4kb（Goroutine ?？臻g最小 2K）
2. 上線文切換更快
   1. 協(xié)程少一道手續(xù)，協(xié)程只涉及到3個寄存器值的修改；而線程需要涉及到模式切換（用戶態(tài)切換到內(nèi)核態(tài)），以及16個寄存器、PC、SP...等寄存器的修改
   2. 線程申請內(nèi)存，需要走內(nèi)核；協(xié)程申請內(nèi)存，不需要走內(nèi)核

線程上下文切換，由于中斷處理、多任務(wù)處理、用戶態(tài)切換等原因CPU從一個線程切換到另一個線程，需要保存當前線程的狀態(tài)并恢復到另一個線程的狀態(tài)。上下文切換的代價是高昂的。上下文切換的延遲取決于不同的因素，大概在在 50 到 100 納秒之間，考慮到硬件在內(nèi)核上平均每納秒大約執(zhí)行12條指令，那么一次上下文切換花費600到1200條指令的執(zhí)行時間。如果存在跨核上下文切換，可能導致CPU緩存失效（CPU從緩存訪問數(shù)據(jù)的成本約3 - 40個時鐘周期，從主存訪問則是100到300個時鐘周期），這中場景的切換成本更高

G-P-M模型

Go 調(diào)度器模型我們通常叫做G-P-M 模型，他包括 4 個重要結(jié)構(gòu)，分別是G、P、M、Sched

G: Goroutine，每個Goroutine對應(yīng)一個 G 結(jié)構(gòu)體，G 存儲Goroutine的運行堆棧、狀態(tài)以及任務(wù)函數(shù)，可重用。G并非執(zhí)行體，每個G需要綁定到P才能被調(diào)度執(zhí)行

P：Processor，表示邏輯處理器，對G來說，P相當于CPU核，G只有綁定P才能被調(diào)度執(zhí)行。對于M來說，P執(zhí)行了相應(yīng)的執(zhí)行環(huán)境（context），如內(nèi)存分配狀態(tài)（mcache）任務(wù)隊列（G）等。P的數(shù)量決定了系統(tǒng)內(nèi)最大可執(zhí)行G的數(shù)量（前提CPU核數(shù) >= P數(shù)量）。P的數(shù)量由用戶設(shè)置的GOMAXPROCS決定，最大為256。

M: Machine, OS內(nèi)核線程抽象，代表真正執(zhí)行計算的資源，在綁定有效P后，進入 schedule 循環(huán)；而P的循環(huán)機制大致是從gobal隊列、P的local隊列以及wait隊列獲取。M的數(shù)量不是固定的，由go runtime調(diào)整。為了防止過度創(chuàng)建OS線程導致系統(tǒng)調(diào)度不過來，目前最大限制為10000個。M不保留G狀態(tài)，這是G可以跨M調(diào)度的基礎(chǔ)。

注意: 設(shè)置 GOMAXPROCS 高于真正可使用的核心數(shù)后會導致Go調(diào)度器不停地進行OS線程切換，從而給調(diào)度器增加很多不必要的工作。go會獲取CPU核心數(shù)作為GOMAXPROCS，docker會隔離CPU，導致無法獲取到正確的CPU核數(shù)，目前 Go 官方并無好的方式來規(guī)避在容器里獲取不到真正可使用的核心數(shù)這一問題，而 Uber 提出了一種 Workaround 方法，利用 uber-go/automaxprocs 這一個包，可以在運行時根據(jù) cgroup 為容器分配的CPU資源限制數(shù)來修改 GOMAXPROCS。

Go學習總結(jié)的GPM模型