类型转换、类型断言、动态派发。iface，eface。

反射对象具有的方法：

编译优化：

内部实现：

实现 Context 接口有以下几个类型（空实现就忽略了）：

互斥锁的控制逻辑：

设计思路：

（以上为写被读阻塞，下面是读被写阻塞）

总结，读写锁的设计还是非常巧妙的：

设计思路：

WaitGroup 有三个暴露的函数:

部件：

设计思路：

结构：

Once 只暴露了一个方法：

实现：

三个关键点：

细节：

让多协程任务的开始执行时间可控（按顺序或归一）。（Context 是控制结束时间）

设计思路： 通过一个锁和内置的 notifyList 队列实现，Wait() 会生成票据，并将等待协程信息加入链表中，等待控制协程中发送信号通知一个（Signal()）或所有（Boardcast()）等待者（内部实现是通过票据通知的）来控制协程解除阻塞。

暴露四个函数：

实现细节：

部件：

包： golang.org/x/sync/errgroup

作用：开启 func() error 函数签名的协程，在同 Group 下协程并发执行过程并收集首次 err 错误。通过 Context 的传入，还可以控制在首次 err 出现时就终止组内各协程。

设计思路：

结构：

暴露的方法：

实现细节：

注意问题：

包： "golang.org/x/sync/semaphore"

作用：排队借资源（如钱，有借有还）的一种场景。此包相当于对底层信号量的一种暴露。

设计思路：有一定数量的资源 Weight，每一个 waiter 携带一个 channel 和要借的数量 n。通过队列排队执行借贷。

结构：

暴露方法：

细节：

部件：

细节：

包： "golang.org/x/sync/singleflight"

作用：防击穿。瞬时的相同请求只调用一次，response 被所有相同请求共享。

设计思路：按请求的 key 分组（一个 *call 是一个组，用 map 映射存储组），每个组只进行一次访问，组内每个协程会获得对应结果的一个拷贝。

结构：

逻辑：

细节：

部件：

如有错误，请批评指正。

https://golang.org/ref/mem

Go内存模型指定了在何种条件下可以保证在一个 goroutine 中读取变量时观察到不同 goroutine 中写入该变量的值。

通过多个协程并发修改数据的程序必须将操作序列化。为了序列化访问，通过channel操作或者其他同步原语（ sync 、 sync/atomic ）来保护数据。

如果你必须要阅读本文的其他部分才能理解你程序的行为，请尽量不要这样...

在单个 goroutine 中，读取和写入的行为必须像按照程序指定的顺序执行一样。 也就是说，只有当重新排序不会改变语言规范定义的 goroutine 中的行为时，编译器和处理器才可以重新排序在单个 goroutine 中执行的读取和写入。 由于这种重新排序，一个 goroutine 观察到的执行顺序可能与另一个 goroutine 感知的顺序不同。 例如，如果一个 goroutine 执行 a = 1b = 2，另一个可能会在 a 的更新值之前观察到 b 的更新值。

为了满足读写的需求，我们定义了 happens before ，Go程序中内存操作的局部顺序。如果事件 e1 在 e2 之前发生，我们说 e2 在 e1 之后发生。还有，如果 e1 不在 e2 之前发生、 e2 也不在 e1 之前发生，那么我们说 e1 和 e2 并发happen。

在单个 goroutine 中， happens-before 顺序由程序指定。

当下面两个条件满足时，变量 v 的阅读操作 r 就 可能 观察到写入操作 w

为了保证 r 一定能阅读到 v ，保证 w 是 r 能观测到的唯一的写操作。当下面两个条件满足时， r 保证可以读取到 w

这一对条件比上一对条件更强；这要求无论是 w 还是 r ，都没有相应的并发操作。

在单个 goroutine 中，没有并发。所以这两个定义等价：读操作 r 能读到最近一次 w 写入 v 的值。但是当多个 goroutine 访问共享变量时，它们必须使用同步事件来建立 happens-before 关系。

使用变量 v 类型的0值初始化变量 v 的行为类似于内存模型中的写入。

对于大于单个机器字长的值的读取和写入表现为未指定顺序的对多个机器字长的操作。

程序初始化在单个 goroutine 中运行，但该 goroutine 可能会创建其他并发运行的 goroutine。

如果包 p 导入包 q，则 q 的 init 函数的完成发生在任何 p 的操作开始之前。

main.main 函数的启动发生在所有 init 函数完成之后。

go 语句启动新的协程发生在新协程启动开始之前。

举个例子

调用 hello 将会打印 hello, world 。当然，这个时候 hello 可能已经返回了。

go 协程的退出并不保证发生在任何事件之前

对 a 的赋值之后没有任何同步事件，因此不能保证任何其他 goroutine 都会观察到它。 事实上，激进的编译器可能会删除整个 go 语句。

如果一个 goroutine 的效果必须被另一个 goroutine 观察到，请使用同步机制，例如锁或通道通信来建立相对顺序。

通道通信是在go协程之间传输数据的主要手段。在特定通道上的发送总有一个对应的channel的接收，通常是在另外一个协程。

channel 上的发送发生在对应 channel 接收之前

程序能保证输出 hello, world 。对a的写入发生在往 c 发送数据之前，往 c 发送数据又发生在从 c 接收数据之前，它又发生在 print 之前。

channel 的关闭发生在从 channel 中获取到0值之前

在之前的例子中，将 c<-0 替换为 close(c) ，程序还是能保证输出 hello, world

无buffer channel 的接收发生在发送操作完成之前

这个程序，和之前一样，但是调换发送和接收操作，并且使用无buffer的channel

也保证能够输出 hello, world 。对a的写入发生在c的接收之前，继而发生在c的写入操作完成之前，继而发生在print之前。

如果该 channel 是buffer channel （例如： c=make(chan int, 1) ），那么程序就不能保证输出 hello, world 。可能会打印空字符串、崩溃等等。从而，我们得到一个相对通用的推论：

对于容量为C的buffer channel来说，第k次从channel中接收，发生在第 k + C 次发送完成之前。

此规则将先前的规则推广到缓冲通道。 它允许通过buffer channel 来模拟信号量：通道中的条数对应活跃的数量，通道的容量对应于最大并发数。向channel发送数据相当于获取信号量，从channel中接收数据相当于释放信号量。 这是限制并发的常用习惯用法。

该程序为工作列表中的每个条目启动一个 goroutine，但是 goroutine 使用 limit channel进行协调，以确保一次最多三个work函数正在运行。

sync 包中实现了两种锁类型： sync.Mutex 和 sync.RWMutex

对于任何的 sync.Mutex 或者 sync.RWMutex 变量 ，且有 n<m ，第 n 个调用 UnLock 一定发生在 m 个 Lock`之前。

这个程序也保证输出 hello,world 。第一次调用 unLock 一定发生在第二次 Lock 调用之前

对于任何 sync.RWMutex 的 RLock 方法调用，存在变量n，满足 RLock 方法发生在第 n 个 UnLock 调用之后，并且对应的 RUnlock 发生在第 n+1 个 Lock 方法之前。

在存在多个 goroutine 时， sync 包通过 once 提供了一种安全的初始化机制。对于特定的 f ，多个线程可以执行 once.Do(f) ，但是只有一个会运行 f() ，另一个调用会阻塞，直到 f() 返回

从 once.Do(f) 对 f() 的单个调用返回在任何一个 once.Do(f) 返回之前。

调用 twoprint 将只调用一次 setup。 setup 函数将在任一打印调用之前完成。 结果将是 hello, world 打印两次。

注意，读取 r 有可能观察到了由写入 w 并发写入的值。尽管观察到了这个值，也并不意味着 r 后续的读取可以读取到 w 之前的写入。

有可能 g 会接连打印2和0两个值。

双检查锁是为了降低同步造成的开销。举个例子， twoprint 方法可能会被误写成

因为没有任何机制保证，协程观察到done为true的同时可以观测到a为 hello, world ,其中有一个 doprint 可能会输出空字符。

另外一个例子

和以前一样，不能保证在 main 中，观察对 done 的写入意味着观察对 a 的写入，因此该程序也可以打印一个空字符串。 更糟糕的情况下，由于两个线程之间没有同步事件，因此无法保证 main 会观察到对 done 的写入。 main 中的循环会一直死循环。

下面是该例子的一个更微妙的变体

尽管 main 观测到g不为nil，但是也没有任何机制保证可以读取到t.msg。

在上述例子中，解决方案都是相同的：请使用显式的同步机制。