golang存儲過程,golang 共享內存

本文目錄一覽：

• 1、存儲過程
• 2、徹底理解Golang Map
• 3、【golang詳解】go語言GMP(GPM)原理和調度
• 4、簡單說明下存儲過程go的作用，謝謝！
• 5、golang map array 是怎麼存儲的
• 6、golang內存擴容

存儲過程

sql server存儲過程語法

存儲過程就是作為可執行對象存放在資料庫中的一個或多個SQL命令。

定義總是很抽象。存儲過程其實就是能完成一定操作的一組SQL語句，只不過這組語句是放在資料庫中的(這裡我們只談SQL Server)。如果我們通過創建存儲過程以及在ASP中調用存儲過程，就可以避免將SQL語句同ASP代碼混雜在一起。這樣做的好處至少有三個：

第一、大大提高效率。存儲過程本身的執行速度非常快，而且，調用存儲過程可以大大減少同資料庫的交互次數。

第二、提高安全性。假如將SQL語句混合在ASP代碼中，一旦代碼失密，同時也就意味著庫結構失密。

第三、有利於SQL語句的重用。

在ASP中，一般通過command對象調用存儲過程，根據不同情況，本文也介紹其它調用方法。為了方便說明，根據存儲過程的輸入輸出，作以下簡單分類：

1. 只返回單一記錄集的存儲過程

假設有以下存儲過程(本文的目的不在於講述T-SQL語法，所以存儲過程只給出代碼，不作說明)：

/*SP1*/

CREATE PROCEDURE dbo.getUserList

as

set nocount on

begin

select * from dbo.[userinfo]

end

go

以上存儲過程取得userinfo表中的所有記錄，返回一個記錄集。通過command對象調用該存儲過程的ASP代碼如下:

‘**通過Command對象調用存儲過程**

DIM MyComm,MyRst

Set MyComm = Server.CreateObject(“ADODB.Command”)

MyComm.ActiveConnection = MyConStr ‘MyConStr是資料庫連接字串

MyComm.CommandText = “getUserList” ‘指定存儲過程名

MyComm.CommandType = 4 ‘表明這是一個存儲過程

MyComm.Prepared = true ‘要求將SQL命令先行編譯

Set MyRst = MyComm.Execute

Set MyComm = Nothing

存儲過程取得的記錄集賦給MyRst，接下來，可以對MyRst進行操作。

在以上代碼中，CommandType屬性表明請求的類型，取值及說明如下：

-1 表明CommandText參數的類型無法確定

1 表明CommandText是一般的命令類型

2 表明CommandText參數是一個存在的表名稱

4 表明CommandText參數是一個存儲過程的名稱

還可以通過Connection對象或Recordset對象調用存儲過程，方法分別如下：

‘**通過Connection對象調用存儲過程**

DIM MyConn,MyRst

Set MyConn = Server.CreateObject(“ADODB.Connection”)

MyConn.open MyConStr ‘MyConStr是資料庫連接字串

Set MyRst = MyConn.Execute(“getUserList”,0,4) ‘最後一個參斷含義同CommandType

Set MyConn = Nothing

‘**通過Recordset對象調用存儲過程**

DIM MyRst

Set MyRst = Server.CreateObject(“ADODB.Recordset”)

MyRst.open “getUserList”,MyConStr,0,1,4

‘MyConStr是資料庫連接字串,最後一個參斷含義與CommandType相同

2. 沒有輸入輸出的存儲過程

請看以下存儲過程：

/*SP2*/

CREATE PROCEDURE dbo.delUserAll

as

set nocount on

begin

delete from dbo.[userinfo]

end

go

該存儲過程刪去userinfo表中的所有記錄，沒有任何輸入及輸出，調用方法與上面講過的基本相同，只是不用取得記錄集：

‘**通過Command對象調用存儲過程**

DIM MyComm

Set MyComm = Server.CreateObject(“ADODB.Command”)

MyComm.ActiveConnection = MyConStr ‘MyConStr是資料庫連接字串

MyComm.CommandText = “delUserAll” ‘指定存儲過程名

MyComm.CommandType = 4 ‘表明這是一個存儲過程

MyComm.Prepared = true ‘要求將SQL命令先行編譯

MyComm.Execute ‘此處不必再取得記錄集

Set MyComm = Nothing

當然也可通過Connection對象或Recordset對象調用此類存儲過程，不過建立Recordset對象是為了取得記錄集，在沒有返回記錄集的情況下，還是利用Command對象吧。

3. 有返回值的存儲過程

在進行類似SP2的操作時，應充分利用SQL Server強大的事務處理功能，以維護數據的一致性。並且，我們可能需要存儲過程返回執行情況，為此，將SP2修改如下：

/*SP3*/

CREATE PROCEDURE dbo.delUserAll

as

set nocount on

begin

BEGIN TRANSACTION

delete from dbo.[userinfo]

IF @@error=0

begin

COMMIT TRANSACTION

return 1

end

ELSE

begin

ROLLBACK TRANSACTION

return 0

end

return

end

go

以上存儲過程，在delete順利執行時，返回1，否則返回0，並進行回滾操作。為了在ASP中取得返回值，需要利用Parameters集合來聲明參數：

‘**調用帶有返回值的存儲過程並取得返回值**

DIM MyComm,MyPara

Set MyComm = Server.CreateObject(“ADODB.Command”)

MyComm.ActiveConnection = MyConStr ‘MyConStr是資料庫連接字串

MyComm.CommandText = “delUserAll” ‘指定存儲過程名

MyComm.CommandType = 4 ‘表明這是一個存儲過程

MyComm.Prepared = true ‘要求將SQL命令先行編譯

‘聲明返回值

Set Mypara = MyComm.CreateParameter(“RETURN”,2,4)

MyComm.Parameters.Append MyPara

MyComm.Execute

‘取得返回值

DIM retValue

retValue = MyComm(0) ‘或retValue = MyComm.Parameters(0)

Set MyComm = Nothing

在MyComm.CreateParameter(“RETURN”,2,4)中，各參數的含義如下：

第一個參數(“RETURE”)為參數名。參數名可以任意設定，但一般應與存儲過程中聲明的參數名相同。此處是返回值，我習慣上設為”RETURE”；

第二個參數(2)，表明該參數的數據類型，具體的類型代碼請參閱ADO參考，以下給出常用的類型代碼：

adBigInt: 20 ;

adBinary : 128 ;

adBoolean: 11 ;

adChar: 129 ;

adDBTimeStamp: 135 ;

adEmpty: 0 ;

adInteger: 3 ;

adSmallInt: 2 ;

adTinyInt: 16 ;

adVarChar: 200 ;

對於返回值，只能取整形，且-1到-99為保留值；

第三個參數(4)，表明參數的性質，此處4表明這是一個返回值。此參數取值的說明如下：

0 : 類型無法確定； 1: 輸入參數；2: 輸入參數；3：輸入或輸出參數；4: 返回值

以上給出的ASP代碼，應該說是完整的代碼，也即最複雜的代碼，其實

Set Mypara = MyComm.CreateParameter(“RETURN”,2,4)

MyComm.Parameters.Append MyPara

可以簡化為

MyComm.Parameters.Append MyComm.CreateParameter(“RETURN”,2,4)

甚至還可以繼續簡化，稍後會做說明。

對於帶參數的存儲過程，只能使用Command對象調用(也有資料說可通過Connection對象或Recordset對象調用，但我沒有試成過)。

4. 有輸入參數和輸出參數的存儲過程

返回值其實是一種特殊的輸出參數。在大多數情況下，我們用到的是同時有輸入及輸出參數的存儲過程，比如我們想取得用戶信息表中，某ID用戶的用戶名，這時候，有一個輸入參數—-用戶ID，和一個輸出參數—-用戶名。實現這一功能的存儲過程如下：

/*SP4*/

CREATE PROCEDURE dbo.getUserName

@UserID int,

@UserName varchar(40) output

as

set nocount on

begin

if @UserID is null return

select @UserName=username

from dbo.[userinfo]

這樣可以么？

徹底理解Golang Map

本文目錄如下，閱讀本文後，將一網打盡下面Golang Map相關面試題

Go中的map是一個指針，佔用8個位元組，指向hmap結構體; 源碼 src/runtime/map.go 中可以看到map的底層結構

每個map的底層結構是hmap，hmap包含若干個結構為bmap的bucket數組。每個bucket底層都採用鏈表結構。接下來，我們來詳細看下map的結構

bmap 就是我們常說的「桶」，一個桶裡面會最多裝 8 個 key，這些 key 之所以會落入同一個桶，是因為它們經過哈希計算後，哈希結果是「一類」的，關於key的定位我們在map的查詢和插入中詳細說明。在桶內，又會根據 key 計算出來的 hash 值的高 8 位來決定 key 到底落入桶內的哪個位置（一個桶內最多有8個位置)。

bucket內存數據結構可視化如下：

注意到 key 和 value 是各自放在一起的，並不是 key/value/key/value/… 這樣的形式。源碼里說明這樣的好處是在某些情況下可以省略掉 padding欄位，節省內存空間。

當 map 的 key 和 value 都不是指針，並且 size 都小於 128 位元組的情況下，會把 bmap 標記為不含指針，這樣可以避免 gc 時掃描整個 hmap。但是，我們看 bmap 其實有一個 overflow 的欄位，是指針類型的，破壞了 bmap 不含指針的設想，這時會把 overflow 移動到 extra 欄位來。

map是個指針，底層指向hmap，所以是個引用類型

golang 有三個常用的高級類型 slice 、map、channel, 它們都是 引用類型 ，當引用類型作為函數參數時，可能會修改原內容數據。

golang 中沒有引用傳遞，只有值和指針傳遞。所以 map 作為函數實參傳遞時本質上也是值傳遞，只不過因為 map 底層數據結構是通過指針指向實際的元素存儲空間，在被調函數中修改 map，對調用者同樣可見，所以 map 作為函數實參傳遞時表現出了引用傳遞的效果。

因此，傳遞 map 時，如果想修改map的內容而不是map本身，函數形參無需使用指針

map 底層數據結構是通過指針指向實際的元素 存儲空間 ，這種情況下，對其中一個map的更改，會影響到其他map

map 在沒有被修改的情況下，使用 range 多次遍歷 map 時輸出的 key 和 value 的順序可能不同。這是 Go 語言的設計者們有意為之，在每次 range 時的順序被隨機化，旨在提示開發者們，Go 底層實現並不保證 map 遍歷順序穩定，請大家不要依賴 range 遍歷結果順序。

map 本身是無序的，且遍歷時順序還會被隨機化，如果想順序遍歷 map，需要對 map key 先排序，再按照 key 的順序遍歷 map。

map默認是並發不安全的，原因如下：

Go 官方在經過了長時間的討論後，認為 Go map 更應適配典型使用場景（不需要從多個 goroutine 中進行安全訪問），而不是為了小部分情況（並發訪問），導致大部分程序付出加鎖代價（性能），決定了不支持。

場景: 2個協程同時讀和寫，以下程序會出現致命錯誤：fatal error: concurrent map writes

如果想實現map線程安全，有兩種方式：

方式一：使用讀寫鎖 map + sync.RWMutex

方式二：使用golang提供的 sync.Map

sync.map是用讀寫分離實現的，其思想是空間換時間。和map+RWLock的實現方式相比，它做了一些優化：可以無鎖訪問read map，而且會優先操作read map，倘若只操作read map就可以滿足要求(增刪改查遍歷)，那就不用去操作write map(它的讀寫都要加鎖)，所以在某些特定場景中它發生鎖競爭的頻率會遠遠小於map+RWLock的實現方式。

golang中map是一個kv對集合。底層使用hash table，用鏈表來解決衝突 ，出現衝突時，不是每一個key都申請一個結構通過鏈表串起來，而是以bmap為最小粒度掛載，一個bmap可以放8個kv。在哈希函數的選擇上，會在程序啟動時，檢測 cpu 是否支持 aes，如果支持，則使用 aes hash，否則使用 memhash。

map有3鍾初始化方式，一般通過make方式創建

map的創建通過生成彙編碼可以知道，make創建map時調用的底層函數是 runtime.makemap 。如果你的map初始容量小於等於8會發現走的是 runtime.fastrand 是因為容量小於8時不需要生成多個桶，一個桶的容量就可以滿足

makemap函數會通過 fastrand 創建一個隨機的哈希種子，然後根據傳入的 hint 計算出需要的最小需要的桶的數量，最後再使用 makeBucketArray 創建用於保存桶的數組，這個方法其實就是根據傳入的 B 計算出的需要創建的桶數量在內存中分配一片連續的空間用於存儲數據，在創建桶的過程中還會額外創建一些用於保存溢出數據的桶，數量是 2^(B-4) 個。初始化完成返回hmap指針。

找到一個 B，使得 map 的裝載因子在正常範圍內

Go 語言中讀取 map 有兩種語法：帶 comma 和 不帶 comma。當要查詢的 key 不在 map 里，帶 comma 的用法會返回一個 bool 型變數提示 key 是否在 map 中；而不帶 comma 的語句則會返回一個 value 類型的零值。如果 value 是 int 型就會返回 0，如果 value 是 string 類型，就會返回空字元串。

map的查找通過生成彙編碼可以知道，根據 key 的不同類型，編譯器會將查找函數用更具體的函數替換，以優化效率：

函數首先會檢查 map 的標誌位 flags。如果 flags 的寫標誌位此時被置 1 了，說明有其他協程在執行「寫」操作，進而導致程序 panic。這也說明了 map 對協程是不安全的。

key經過哈希函數計算後，得到的哈希值如下（主流64位機下共 64 個 bit 位）：

m: 桶的個數

從buckets 通過 hash m 得到對應的bucket，如果bucket正在擴容，並且沒有擴容完成，則從oldbuckets得到對應的bucket

計算hash所在桶編號：

用上一步哈希值最後的 5 個 bit 位，也就是 01010 ，值為 10，也就是 10 號桶（範圍是0~31號桶）

計算hash所在的槽位:

用上一步哈希值哈希值的高8個bit 位，也就是 10010111 ，轉化為十進位，也就是151，在 10 號 bucket 中尋找** tophash 值（HOB hash）為 151* 的 槽位**，即為key所在位置，找到了 2 號槽位，這樣整個查找過程就結束了。

如果在 bucket 中沒找到，並且 overflow 不為空，還要繼續去 overflow bucket 中尋找，直到找到或是所有的 key 槽位都找遍了，包括所有的 overflow bucket。

通過上面找到了對應的槽位，這裡我們再詳細分析下key/value值是如何獲取的：

bucket 里 key 的起始地址就是 unsafe.Pointer(b)+dataOffset。第 i 個 key 的地址就要在此基礎上跨過 i 個 key 的大小；而我們又知道，value 的地址是在所有 key 之後，因此第 i 個 value 的地址還需要加上所有 key 的偏移。

通過彙編語言可以看到，向 map 中插入或者修改 key，最終調用的是 mapassign 函數。

實際上插入或修改 key 的語法是一樣的，只不過前者操作的 key 在 map 中不存在，而後者操作的 key 存在 map 中。

mapassign 有一個系列的函數，根據 key 類型的不同，編譯器會將其優化為相應的「快速函數」。

我們只用研究最一般的賦值函數 mapassign 。

map的賦值會附帶著map的擴容和遷移，map的擴容只是將底層數組擴大了一倍，並沒有進行數據的轉移，數據的轉移是在擴容後逐步進行的，在遷移的過程中每進行一次賦值（access或者delete）會至少做一次遷移工作。

1.判斷map是否為nil

每一次進行賦值/刪除操作時，只要oldbuckets != nil 則認為正在擴容，會做一次遷移工作，下面會詳細說下遷移過程

根據上面查找過程，查找key所在位置，如果找到則更新，沒找到則找空位插入即可

經過前面迭代尋找動作，若沒有找到可插入的位置，意味著需要擴容進行插入，下面會詳細說下擴容過程

通過彙編語言可以看到，向 map 中刪除 key，最終調用的是 mapdelete 函數

刪除的邏輯相對比較簡單，大多函數在賦值操作中已經用到過，核心還是找到 key 的具體位置。尋找過程都是類似的，在 bucket 中挨個 cell 尋找。找到對應位置後，對 key 或者 value 進行「清零」操作，將 count 值減 1，將對應位置的 tophash 值置成 Empty

再來說觸發 map 擴容的時機：在向 map 插入新 key 的時候，會進行條件檢測，符合下面這 2 個條件，就會觸發擴容：

1、裝載因子超過閾值

源碼里定義的閾值是 6.5 (loadFactorNum/loadFactorDen)，是經過測試後取出的一個比較合理的因子

我們知道，每個 bucket 有 8 個空位，在沒有溢出，且所有的桶都裝滿了的情況下，裝載因子算出來的結果是 8。因此當裝載因子超過 6.5 時，表明很多 bucket 都快要裝滿了，查找效率和插入效率都變低了。在這個時候進行擴容是有必要的。

對於條件 1，元素太多，而 bucket 數量太少，很簡單：將 B 加 1，bucket 最大數量( 2^B )直接變成原來 bucket 數量的 2 倍。於是，就有新老 bucket 了。注意，這時候元素都在老 bucket 里，還沒遷移到新的 bucket 來。新 bucket 只是最大數量變為原來最大數量的 2 倍( 2^B * 2 ) 。

2、overflow 的 bucket 數量過多

在裝載因子比較小的情況下，這時候 map 的查找和插入效率也很低，而第 1 點識別不出來這種情況。表面現象就是計算裝載因子的分子比較小，即 map 里元素總數少，但是 bucket 數量多（真實分配的 bucket 數量多，包括大量的 overflow bucket）

不難想像造成這種情況的原因：不停地插入、刪除元素。先插入很多元素，導致創建了很多 bucket，但是裝載因子達不到第 1 點的臨界值，未觸發擴容來緩解這種情況。之後，刪除元素降低元素總數量，再插入很多元素，導致創建很多的 overflow bucket，但就是不會觸發第 1 點的規定，你能拿我怎麼辦？overflow bucket 數量太多，導致 key 會很分散，查找插入效率低得嚇人，因此出台第 2 點規定。這就像是一座空城，房子很多，但是住戶很少，都分散了，找起人來很困難

對於條件 2，其實元素沒那麼多，但是 overflow bucket 數特別多，說明很多 bucket 都沒裝滿。解決辦法就是開闢一個新 bucket 空間，將老 bucket 中的元素移動到新 bucket，使得同一個 bucket 中的 key 排列地更緊密。這樣，原來，在 overflow bucket 中的 key 可以移動到 bucket 中來。結果是節省空間，提高 bucket 利用率，map 的查找和插入效率自然就會提升。

由於 map 擴容需要將原有的 key/value 重新搬遷到新的內存地址，如果有大量的 key/value 需要搬遷，會非常影響性能。因此 Go map 的擴容採取了一種稱為「漸進式」的方式，原有的 key 並不會一次性搬遷完畢，每次最多只會搬遷 2 個 bucket。

上面說的 hashGrow() 函數實際上並沒有真正地「搬遷」，它只是分配好了新的 buckets，並將老的 buckets 掛到了 oldbuckets 欄位上。真正搬遷 buckets 的動作在 growWork() 函數中，而調用 growWork() 函數的動作是在 mapassign 和 mapdelete 函數中。也就是插入或修改、刪除 key 的時候，都會嘗試進行搬遷 buckets 的工作。先檢查 oldbuckets 是否搬遷完畢，具體來說就是檢查 oldbuckets 是否為 nil。

如果未遷移完畢，賦值/刪除的時候，擴容完畢後（預分配內存），不會馬上就進行遷移。而是採取 增量擴容 的方式，當有訪問到具體 bukcet 時，才會逐漸的進行遷移（將 oldbucket 遷移到 bucket）

nevacuate 標識的是當前的進度，如果都搬遷完，應該和2^B的長度是一樣的

在evacuate 方法實現是把這個位置對應的bucket，以及其衝突鏈上的數據都轉移到新的buckets上。

轉移的判斷直接通過tophash 就可以，判斷tophash中第一個hash值即可

遍歷的過程，就是按順序遍歷 bucket，同時按順序遍歷 bucket 中的 key。

map遍歷是無序的，如果想實現有序遍歷，可以先對key進行排序

為什麼遍歷 map 是無序的？

如果發生過遷移，key 的位置發生了重大的變化，有些 key 飛上高枝，有些 key 則原地不動。這樣，遍歷 map 的結果就不可能按原來的順序了。

如果就一個寫死的 map，不會向 map 進行插入刪除的操作，按理說每次遍歷這樣的 map 都會返回一個固定順序的 key/value 序列吧。但是 Go 杜絕了這種做法，因為這樣會給新手程序員帶來誤解，以為這是一定會發生的事情，在某些情況下，可能會釀成大錯。

Go 做得更絕，當我們在遍歷 map 時，並不是固定地從 0 號 bucket 開始遍歷，每次都是從一個**隨機值序號的 bucket 開始遍歷，並且是從這個 bucket 的一個 隨機序號的 cell **開始遍歷。這樣，即使你是一個寫死的 map，僅僅只是遍歷它，也不太可能會返回一個固定序列的 key/value 對了。

【golang詳解】go語言GMP(GPM)原理和調度

Goroutine調度是一個很複雜的機制，下面嘗試用簡單的語言描述一下Goroutine調度機制，想要對其有更深入的了解可以去研讀一下源碼。

首先介紹一下GMP什麼意思：

G ———– goroutine: 即Go協程，每個go關鍵字都會創建一個協程。

M ———- thread內核級線程，所有的G都要放在M上才能運行。

P ———– processor處理器，調度G到M上，其維護了一個隊列，存儲了所有需要它來調度的G。

Goroutine 調度器P和 OS 調度器是通過 M 結合起來的，每個 M 都代表了 1 個內核線程，OS 調度器負責把內核線程分配到 CPU 的核上執行

模型圖：

避免頻繁的創建、銷毀線程，而是對線程的復用。

1）work stealing機制

  當本線程無可運行的G時，嘗試從其他線程綁定的P偷取G，而不是銷毀線程。

2）hand off機制

  當本線程M0因為G0進行系統調用阻塞時，線程釋放綁定的P，把P轉移給其他空閑的線程執行。進而某個空閑的M1獲取P，繼續執行P隊列中剩下的G。而M0由於陷入系統調用而進被阻塞，M1接替M0的工作，只要P不空閑，就可以保證充分利用CPU。M1的來源有可能是M的緩存池，也可能是新建的。當G0系統調用結束後，根據M0是否能獲取到P，將會將G0做不同的處理：

如果有空閑的P，則獲取一個P，繼續執行G0。

如果沒有空閑的P，則將G0放入全局隊列，等待被其他的P調度。然後M0將進入緩存池睡眠。

如下圖

GOMAXPROCS設置P的數量，最多有GOMAXPROCS個線程分布在多個CPU上同時運行

在Go中一個goroutine最多佔用CPU 10ms，防止其他goroutine被餓死。

具體可以去看另一篇文章

【Golang詳解】go語言調度機制 搶佔式調度

當創建一個新的G之後優先加入本地隊列，如果本地隊列滿了，會將本地隊列的G移動到全局隊列裡面，當M執行work stealing從其他P偷不到G時，它可以從全局G隊列獲取G。

協程經歷過程

我們創建一個協程 go func()經歷過程如下圖：

說明：

這裡有兩個存儲G的隊列，一個是局部調度器P的本地隊列、一個是全局G隊列。新創建的G會先保存在P的本地隊列中，如果P的本地隊列已經滿了就會保存在全局的隊列中；處理器本地隊列是一個使用數組構成的環形鏈表，它最多可以存儲 256 個待執行任務。

G只能運行在M中，一個M必須持有一個P，M與P是1：1的關係。M會從P的本地隊列彈出一個可執行狀態的G來執行，如果P的本地隊列為空，就會想其他的MP組合偷取一個可執行的G來執行；

一個M調度G執行的過程是一個循環機制；會一直從本地隊列或全局隊列中獲取G

上面說到P的個數默認等於CPU核數，每個M必須持有一個P才可以執行G，一般情況下M的個數會略大於P的個數，這多出來的M將會在G產生系統調用時發揮作用。類似線程池，Go也提供一個M的池子，需要時從池子中獲取，用完放回池子，不夠用時就再創建一個。

work-stealing調度演算法：當M執行完了當前P的本地隊列隊列里的所有G後，P也不會就這麼在那躺屍啥都不幹，它會先嘗試從全局隊列隊列尋找G來執行，如果全局隊列為空，它會隨機挑選另外一個P，從它的隊列里中拿走一半的G到自己的隊列中執行。

如果一切正常，調度器會以上述的那種方式順暢地運行，但這個世界沒這麼美好，總有意外發生，以下分析goroutine在兩種例外情況下的行為。

Go runtime會在下面的goroutine被阻塞的情況下運行另外一個goroutine：

用戶態阻塞/喚醒

當goroutine因為channel操作或者network I/O而阻塞時（實際上golang已經用netpoller實現了goroutine網路I/O阻塞不會導致M被阻塞，僅阻塞G，這裡僅僅是舉個栗子），對應的G會被放置到某個wait隊列(如channel的waitq)，該G的狀態由_Gruning變為_Gwaitting，而M會跳過該G嘗試獲取並執行下一個G，如果此時沒有可運行的G供M運行，那麼M將解綁P，並進入sleep狀態；當阻塞的G被另一端的G2喚醒時（比如channel的可讀/寫通知），G被標記為，嘗試加入G2所在P的runnext（runnext是線程下一個需要執行的 Goroutine。）， 然後再是P的本地隊列和全局隊列。

系統調用阻塞

當M執行某一個G時候如果發生了阻塞操作，M會阻塞，如果當前有一些G在執行，調度器會把這個線程M從P中摘除，然後再創建一個新的操作系統的線程(如果有空閑的線程可用就復用空閑線程)來服務於這個P。當M系統調用結束時候，這個G會嘗試獲取一個空閑的P執行，並放入到這個P的本地隊列。如果獲取不到P，那麼這個線程M變成休眠狀態， 加入到空閑線程中，然後這個G會被放入全局隊列中。

隊列輪轉

可見每個P維護著一個包含G的隊列，不考慮G進入系統調用或IO操作的情況下，P周期性的將G調度到M中執行，執行一小段時間，將上下文保存下來，然後將G放到隊列尾部，然後從隊列中重新取出一個G進行調度。

除了每個P維護的G隊列以外，還有一個全局的隊列，每個P會周期性地查看全局隊列中是否有G待運行並將其調度到M中執行，全局隊列中G的來源，主要有從系統調用中恢復的G。之所以P會周期性地查看全局隊列，也是為了防止全局隊列中的G被餓死。

除了每個P維護的G隊列以外，還有一個全局的隊列，每個P會周期性地查看全局隊列中是否有G待運行並將其調度到M中執行，全局隊列中G的來源，主要有從系統調用中恢復的G。之所以P會周期性地查看全局隊列，也是為了防止全局隊列中的G被餓死。

M0

M0是啟動程序後的編號為0的主線程，這個M對應的實例會在全局變數rutime.m0中，不需要在heap上分配，M0負責執行初始化操作和啟動第一個G，在之後M0就和其他的M一樣了

G0

G0是每次啟動一個M都會第一個創建的goroutine，G0僅用於負責調度G，G0不指向任何可執行的函數，每個M都會有一個自己的G0，在調度或系統調用時會使用G0的棧空間，全局變數的G0是M0的G0

一個G由於調度被中斷，此後如何恢復？

中斷的時候將寄存器里的棧信息，保存到自己的G對象裡面。當再次輪到自己執行時，將自己保存的棧信息複製到寄存器裡面，這樣就接著上次之後運行了。

我這裡只是根據自己的理解進行了簡單的介紹，想要詳細了解有關GMP的底層原理可以去看Go調度器 G-P-M 模型的設計者的文檔或直接看源碼

參考： ()

()

簡單說明下存儲過程go的作用，謝謝！

結束，終止上面語句

詳細解釋如下

GO

用信號通知 Microsoft® SQL Server™ 實用工具一批 Transact-SQL 語句的結束。

語法

GO

注釋

GO 不是 Transact-SQL 語句；而是可為 osql 和 isql 實用工具及 SQL Server 查詢分析器識別的命令。

SQL Server 實用工具將 GO 解釋為應將當前的 Transact-SQL 批處理語句發送給 SQL Server 的信號。當前批處理語句是自上一 GO 命令後輸入的所有語句，若是第一條 GO 命令，則是從特殊會話或腳本的開始處到這條 GO 命令之間的所有語句。SQL 查詢分析器和 osql 及 isql 命令提示實用工具執行 GO 命令的方式不同。有關更多信息，請參見 osql 實用工具、isql 實用工具和 SQL 查詢分析器。

GO 命令和Transact-SQL 語句不可在同一行上。但在 GO 命令行中可包含注釋。

用戶必須遵照使用批處理的規則。例如，在批處理中的第一條語句後執行任何存儲過程必須包含 EXECUTE 關鍵字。局部（用戶定義）變數的作用域限制在一個批處理中，不可在 GO 命令後引用。

USE pubs

GO

DECLARE @MyMsg VARCHAR(50)

SELECT @MyMsg = ‘Hello, World.’

GO — @MyMsg is not valid after this GO ends the batch.

— Yields an error because @MyMsg not declared in this batch.

PRINT @MyMsg

GO

SELECT @@VERSION;

— Yields an error: Must be EXEC sp_who if not first statement in

— batch.

sp_who

GO

SQL Server 應用程序可將多條 Transact-SQL 語句作為一個批處理髮給 SQL Server 去執行。在此批處理中的語句編譯成一個執行計劃。程序員在 SQL Server 實用工具中執行特定語句，或生成 Transact-SQL 語句腳本在 SQL Server 實用工具中運行，用 GO 來標識批處理的結束。

如果基於 DB-Library、ODBC 或 OLE DB APIs 的應用程序試圖執行 GO 命令時會收到語法錯誤。SQL Server 實用工具永遠不會向伺服器發送 GO 命令。

許可權

GO 是一個不需許可權的實用工具命令。可以由任何用戶執行。

示例

下面的示例創建兩個批處理。第一個批處理只包含一條 USE pubs 語句，用於設置資料庫上下文。剩下的語句使用了一個局部變數，因此所有的局部變數聲明必須在一個批處理中。這一點可通過在最後一條引用此變數的語句之後才使用 GO 命令來做到。

USE pubs

GO

DECLARE @NmbrAuthors int

SELECT @NmbrAuthors = COUNT(*)

FROM authors

PRINT ‘The number of authors as of ‘ +

CAST(GETDATE() AS char(20)) + ‘ is ‘ +

CAST(@NmbrAuthors AS char (10))

golang map array 是怎麼存儲的

map 的 hash 表包含了一個桶集合(collection of buckets)。當我們存儲，移除或者查找鍵值對(key/value pair)時，都會從選擇一個桶開始。在映射(map)操作過程中，我們會把指定的鍵值(key)傳遞給 hash 函數(又稱散列函數)。hash 函數的作用是生成索引，索引均勻的分布在所有可用的桶上。hash 表演算法詳見：July的博客—從頭到尾徹底解析 hash 表演算法

golang內存擴容

一般來說當內存空間span不足時，需要進行擴容。而在擴容前需要將當前沒有剩餘空間的內存塊相關狀態解除，以便後續的垃圾回收期能夠進行掃描和回收，接著在從中間部件(central)提取新的內存塊放回數組中。

需要注意由於中間部件有scan和noscan兩種類型，則申請的內存空間最終獲取的可能是其兩倍，並由heap堆進行統一管理。中間部件central是通過兩個鏈表來管理其分配的所有內存塊：

1、empty代表「無法使用」狀態，沒有剩餘的空間或被移交給緩存的內存塊

2、noempty代表剩餘的空間，並這些內存塊能夠提供服務

由於golang垃圾回收器使用的累增計數器(heap.sweepgen)來表達代齡的：

從上面內容可以看到每次進行清理操作時 該計數器 +2

再來看下mcentral的構成

當通過mcentral進行空間span獲取時，第一步需要到noempty列表檢查剩餘空間的內存塊，這裡面有一點需要說明主要是垃圾回收器的掃描過程和清理過程是同時進行的，那麼為了獲取更多的可用空間，則會在將分配的內存塊移交給cache部件前，先完成清理的操作。第二步當noempty沒有返回時，則需要檢查下empty列表(由於empty里的內存塊有可能已被標記為垃圾，這樣可以直接清理，對應的空間則可直接使用了)。第三步若是noempty和empty都沒有申請到，這時需要堆進行申請內存的

通過上面的源碼也可以看到中間部件central自身擴容操作與大對象內存分配差不多類似。

在golang中將長度小於16bytes的對象稱為微小對象(tiny)，最常見的就是小字元串，一般會將這些微小對象組合起來，並用單塊內存存儲，這樣能夠有效的減少內存浪費。

當微小對象需要分配空間span，首先緩存部件會按指定的規格(tiny size class)取出一塊內存，若容量不足，則重新提取一塊；前面也提到會將微小對象進行組合，而這些組合的微小對象是不能包含指針的，因為垃圾回收的原因，一般都是當前存儲單元里所有的微小對象都不可達時，才會將該塊內存進行回收。

而當從緩衝部件cache中獲取空間span時， 是通過偏移位置(tinyoffset)先來判斷剩餘空間是否滿足需求。若是可以的話則以此計算並返回內存地址；若是空間不足，則提取新的內存塊，直接返回起始地址便可； 最後在對比新舊兩塊內存，空間大的那塊則會被保留。