多程序、多執行緒的問題
多執行緒/程序的壁壘
執行緒占用記憶體：約為4mb
高cpu排程消耗
1:1
n:m
排程器的優化
早期go排程器
弊端
全域性佇列
p的本地佇列
p列表
m列表
p和m的數量
m數量問題
hand off 機制
利用並行
搶占 全域性g佇列
通過go func()建立乙個g
有兩個儲存g的佇列，，乙個是區域性排程器的本地佇列p，乙個是全域性g佇列，新建立的g會先儲存在本地佇列p，若p滿了就會儲存到全域性g佇列
g只能執行在m中，乙個m必須持有乙個p，m會從p的本地佇列彈出乙個可以執行的g執行，若p的本地隊列為空，就會從全域性g佇列或其他mp組合偷取乙個可執行的g來執行
乙個m排程g執行的過程是乙個迴圈機制
當m執行某乙個g時若發生了，syscall或者其他阻塞操作，m會阻塞，若當前有一些g在執行，runtime就會把這個執行緒m從p中摘除（detach），然後建立乙個新的執行緒（若有空閒執行緒則復用）服務於這個p
、當m系統呼叫結束時，這個g會嘗試獲取乙個空閒的p執行，並放入到這個p的本地佇列，若獲取不到p，次執行緒m就會進入休眠狀態，加入到空閒執行緒中，然後這個g會被放入全域性佇列
g0
開啟trace
關閉trace
go build且執行後會得到trace.out檔案
通過go tool trace工具開啟trace檔案
通過debug trace檢視gmp資訊，godebug=schedtrace=1000 ./可執行程式
Golang GMP排程模型
processor的數量是在啟動時被設定為環境變數gomaxprocs的值，或者通過執行時排程函式gomaxprocs 進行設定。processor數量固定意味著任意時刻只有gomaxprocs個執行緒在執行著go 我們分別用三角形，矩形和圓形表示machine processor和goroutin...
排程佇列模型
排程佇列模型及準則 1 僅有程序排程的排程佇列模型 每個程序在執行時都可能出現以下三種情況 1 任務在給定的時間片內已經完成，該程序便在釋放處理機後進入完成狀態 2 任務在本次分得的時間片內尚未完成，os便將該任務再放入就緒佇列的末尾 3 在執行期間，程序因為某事件而被阻塞後，被os放入阻塞佇列。2...
Goroutine的排程模型
當前有兩個p，各自繫結了乙個m，每個p上掛了乙個本地goroutine佇列，也有乙個全域性goroutine佇列。流程 每次使用go關鍵字宣告時，乙個g物件被建立並加入到本地g佇列或者全域性g佇列。檢查是否有空閒的p 處理器 若有那麼建立乙個m 若有正在sleep的m那麼直接喚醒它 與其繫結，然後這...