Hello，大家好，又见面了！上一遍我们将 channel 相关基础以及使用场景。这一篇，还需要再次进阶理解channel 阻塞问题。以下创建一个chan类型为int，cap 为3。
channel 内部其实是一个环形buf数据结构 ，是一种滑动窗口机制，当make完后，就分配在 Heap 上。
上面，向 chan 发送一条“hello”数据：
如果 G1 发送数据超过指定cap时，会出现什么情况？
看下面实例：
以上会出现什么，chan 缓冲区允许大小为1，如果再往chan仍数据，满了就会被阻塞，那么是如何实现阻塞的呢？当 chan 满时，会进入 gopark，此时 G1 进入一个 waiting 状态，然后会创建一个 sudog 对象，其实就sendq队列，把 200放进去。等 buf 不满的时候，再唤醒放入buf里面。
通过如下源码，你会更加清晰：
上面，从 chan 获取数据：
Go 语言核心思想：“Do not communicate by sharing memoryinstead, share memory by communicating.” 你可以看看这本书名叫：Effective Go
如果接收者，接收一个空对象，也会发生什么情况？
代码示例 ：
也会报错如下：
上面，从 chan 取出数据，可是没有数据了。此时，它会把 接收者 G2 阻塞掉，也是和G1发送者一样，也会执行 gopark 将状态改为 waiting，不一样的点就是。
正常情况下，接收者G2作为取出数据是去 buf 读取数据的，但现在，buf 为空了，此时，接收者G2会将sudog导出来，因为现在G2已经被阻塞了嘛，会把G2给G，然后将 t := <-ch 中变量t是在栈上的地址，放进去 elem ，也就是说，只存它的地址指针在sudog里面。
最后， ch <- 200当G1往 chan 添加200这个数据，正常情况是将数据添加到buf里面，然后唤醒 G2 是吧，而现在是将 G1 的添加200数据直接干到刚才G2阻塞的t这里变量里面。
你会认为，这样真的可以吗？想一想，G2 本来就是已经阻塞了，然后我们直接这么干肯定没有什么毛病，而且效率提高了，不需要再次放入buf再取出，这个过程也是需要时间。不然，不得往chan添加数据需要加锁、拷贝、解锁一序列操作，那肯定就慢了，我想Go语言是为了高效及内存使用率的考虑这样设计的。（注意，一般都是在runtime里面完成，不然会出现象安全问题。）
总结 ：
chan 类型的特点：chan 如果为空，receiver 接收数据的时候就会阻塞等待，直到 chan 被关闭或者有新的数据到来。有这种个机制，就可以实现 wait/notify 的设计模式。
相关面试题：
个人看法：
对于C++来说，go补充了一个快速开发多线程程序的方案，在c++中使用指针，必须小心的包装智能指针进行和弱引用来保证线程与指针析构之间的先后顺序
go显然更灵活的做到这一点，并且将异步，通知的方案直接嵌入到了I/O层，与他自己的goroutine调度器进行了结合，非常方便开发i/o相关的程序。
另外在文本处理方面也有线程的优良库，方便的结合github的安装第三方库方案，这些现代的新方案确实要比c++老迈的发展步伐更让人眼前一亮。
最后go语言能做到什么，我个人觉得多线程、重度i/o，快速开发是他的标签。
另外，新语言提供的新思路，肯定会提高包括C++/python在内各种语言发展的步伐。
本文是对 Gopher 2017 中一个非常好的 Talk�: [Understanding Channel](GopherCon 2017: Kavya Joshi - Understanding Channels) 的学习笔记，希望能够通过对 channel 的关键特性的理解，进一步掌握其用法细节以及 Golang 语言设计哲学的管窥蠡测。
channel 是可以让一个 goroutine 发送特定值到另一个 gouroutine 的通信机制。
原生的 channel 是没有缓存的(unbuffered channel)，可以用于 goroutine 之间实现同步。
关闭后不能再写入，可以读取直到 channel 中再没有数据，并返回元素类型的零值。
gopl/ch3/netcat3
首先从 channel 是怎么被创建的开始:
在 heap 上分配一个 hchan 类型的对象，并将其初始化，然后返回一个指向这个 hchan 对象的指针。
理解了 channel 的数据结构实现，现在转到 channel 的两个最基本方法: sends 和 receivces ，看一下以上的特性是如何体现在 sends 和 receives 中的:
假设发送方先启动，执行 ch <- task0 :
如此为 channel 带来了 goroutine-safe 的特性。
在这样的模型里， sender goroutine ->channel ->receiver goroutine 之间， hchan 是唯一的共享内存，而这个唯一的共享内存又通过 mutex 来确保 goroutine-safe ，所有在队列中的内容都只是副本。
这便是著名的 golang 并发原则的体现:
发送方 goroutine 会阻塞，暂停，并在收到 receive 后才恢复。
goroutine 是一种 用户态线程 , 由 Go runtime 创建并管理，而不是操作系统，比起操作系统线程来说，goroutine更加轻量。
Go runtime scheduler 负责将 goroutine 调度到操作系统线程上。
runtime scheduler 怎么将 goroutine 调度到操作系统线程上？
当阻塞发生时，一次 goroutine 上下文切换的全过程:
然而，被阻塞的 goroutine 怎么恢复过来？
阻塞发生时，调用 runtime sheduler 执行 gopark 之前，G1 会创建一个 sudog ，并将它存放在 hchan 的 sendq 中。 sudog 中便记录了即将被阻塞的 goroutine G1 ，以及它要发送的数据元素 task4 等等。
接收方 将通过这个 sudog 来恢复 G1
接收方 G2 接收数据, 并发出一个 receivce ，将 G1 置为 runnable :
同样的, 接收方 G2 会被阻塞，G2 会创建 sudoq ，存放在 recvq ，基本过程和发送方阻塞一样。
不同的是，发送方 G1如何恢复接收方 G2，这是一个非常神奇的实现。
理论上可以将 task 入队，然后恢复 G2, 但恢复 G2后，G2会做什么呢？
G2会将队列中的 task 复制出来，放到自己的 memory 中，基于这个思路，G1在这个时候，直接将 task 写到 G2的 stack memory 中！
这是违反常规的操作，理论上 goroutine 之间的 stack 是相互独立的，只有在运行时可以执行这样的操作。
这么做纯粹是出于性能优化的考虑，原来的步骤是：
优化后，相当于减少了 G2 获取锁并且执行 memcopy 的性能消耗。
channel 设计背后的思想可以理解为 simplicity 和 performance 之间权衡抉择，具体如下：
queue with a lock prefered to lock-free implementation:
比起完全 lock-free 的实现，使用锁的队列实现更简单，容易实现
