源码包中src/runtime/chan.go定义了hchan的数据结构如下：
hchan结构体的主要组成部分有四个：
用来保存goroutine之间传递数据的循环数组：buf
用来记录此循环数组当前发送或接收数据的下标值：sendx和recvx
用于保存向该chan发送和从该chan接收数据被阻塞的goroutine队列： sendq 和 recvq
保证channel写入和读取数据时线程安全的锁：lock
环形数组作为channel 的缓冲区 数组的长度就是定义channnel 时channel 的缓冲大小
在hchan 中包括了读/写 等待队列， waitq是一个双向队列，包括了一个头结点和尾节点。 每个节点是一个sudog结构体变量
channel有2种类型：无缓冲、有缓冲， 在创建时 make(chan type cap) 通过cap 设定缓冲大小
channel有3种模式：写操作模式（单向通道）、读操作模式（单向通道）、读写操作模式（双向通道）
channel有3种状态：未初始化、正常、关闭
如下几种状态会引发panic
channel 是线程安全的，channel的底层实现中，hchan结构体中采用Mutex锁来保证数据读写安全。在对循环数组buf中的数据进行入队和出队操作时，必须先获取互斥锁，才能操作channel数据
在 Golang 游戏leaf系列(一) 概述与示例 (下文简称系列一)中，提到过Go模块用于创建能够被 Leaf 管理的 goroutine。Go模块是对golang中go提供一些额外功能。Go提供回调功能，LinearContext提供顺序调用功能。善用 goroutine 能够充分利用多核资源，Leaf 提供的 Go 机制解决了原生 goroutine 存在的一些问题：
我们来看一个例子（可以在 LeafServer 的模块的 OnInit 方法中测试）：
这里的 Go 方法接收 2 个函数作为参数，第一个函数会被放置在一个新创建的 goroutine 中执行，在其执行完成之后，第二个函数会在当前 goroutine 中被执行。由此，我们可以看到变量 res 同一时刻总是只被一个 goroutine 访问，这就避免了同步机制的使用。Go 的设计使得 CPU 得到充分利用，避免操作阻塞当前 goroutine，同时又无需为共享资源同步而忧心。
这里主动调用了 d.Cb(<-d.ChanCb) ，把这个回调取出来了。实际上，在skeleton.Run里会自己取这个通道
看一下源码：
New方法，会生成指定缓冲长度的ChanCb。然后调用Go方法就是先执行第一个func,然后把第二个放到Cb里。现在手动造一个例子：
这里解释一下，d.Go根据源码来看，实际也是调用了一个协程。然后上面两次d.Go并不能保证先后顺序。目前的输出结果是1+2那个先执行了，把3写入d.ChanCb，然后把3读出来，继续读时，d.ChanCb里没有东西，阻塞了。然后1+1那个协程启动了，最后又读到了2。
现在把time.Sleep(time.Second)的注释解开，会是啥结果呢
这里执行到time.Sleep睡着了，上面两个d.Go仍然是不确定顺序的，但是会各自的function先执行掉，然后陆续把cb写入d.ChanCb。看这次输出，1+2先写进去的。所以最后执行d.Cb时，就把3先读出来了。然后d.ChanCb的长度为1，说明还有一个，就是输出2了。
另外，就是close时会判断g.pendingGo
这个例子的意思很明显，NewLinearContext这种方式，即使先调用的慢了半秒，它还是会先执行完。
这里先是用了一个list，加入的时候用mutexLinearGo锁了，都加到最后。然后新开协程去处理，读的时候从最前面开始读，也要用mutexLinearGo锁。执行的时候，也要上锁mutexExecution，确保f()执行完并且写入g.ChanCb回调，这个mutexExecution锁才会解除。现在可以改造一个带回调的例子：
结果说明，确实是2先被写入了d.ChanCb。
