本文目录一览：
存储过程
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)先来判断剩余空间是否满足需求。若是可以的话则以此计算并返回内存地址；若是空间不足，则提取新的内存块，直接返回起始地址便可； 最后在对比新旧两块内存，空间大的那块则会被保留。