channelgo语言 channel for

提示：扫一扫查出行
【扫一扫了解最新限行尾号】
复制提示

go语言无缓冲的channel

无缓冲的通道（unbuffered channel）是指在接收前没有能力保存任何值的通道。

这种类型的通道要求发送goroutine和接收goroutine同时准备好channelgo语言，才能完成发送和接收操作。否则，通道会导致先执行发送或接收操作的 goroutine 阻塞等待。

这种对通道进行发送和接收的交互行为本身就是同步的。其中任意一个操作都无法离开另一个操作单独存在。

阻塞：由于某种原因数据没有到达，当前协程（线程）持续处于等待状态，直到条件满足，才接触阻塞。

同步：在两个或多个协程（线程）间，保持数据内容一致性的机制。

下图展示两个 goroutine 如何利用无缓冲的通道来共享一个值：

在第 1 步，两个 goroutine 都到达通道，但哪个都没有开始执行发送或者接收。

在第 2 步，左侧的 goroutine 将它的手伸进channelgo语言了通道，这模拟了向通道发送数据的行为。这时，这个 goroutine 会在通道中被锁住，直到交换完成。

在第 3 步，右侧的 goroutine 将它的手放入通道，这模拟了从通道里接收数据。这个 goroutine 一样也会在通道中被锁住，直到交换完成。

在第 4 步和第 5 步，进行交换，并最终，在第 6 步，两个 goroutine 都将它们的手从通道里拿出来，这模拟了被锁住的 goroutine 得到释放。两个 goroutine 现在都可以去做别的事情了。

如果没有指定缓冲区容量，那么该通道就是同步的，因此会阻塞到发送者准备好发送和接收者准备好接收。

无缓冲channel： —— 同步通信

相关问答

Q1: Golang 语言深入理解：channel

本文是对 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 的实现，使用锁的队列实现更简单，容易实现

Q2: Go 语言 channel 的阻塞问题

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 memory; instead, 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 的设计模式。