文章目录
前言
最近在学习Golang的时候，注意到channel的传输存在很多种情况，因此在本篇文章中通过实践的方式，整理各种情况的结果，方便自己和大家今后的学习。
channel可以分为3种类型：
//只读 channel，单向 channel
readOlnyChan := make(<-chan int)
只写 channel，单向 channel
writeOlnyChan := make(chan<- int)
可读可写 channel
ch := make(chan)
三个类型种，业务最频繁使用的是可读可写的无限制channel，所以接下来将主要介绍可读可写的channel场景。
各种情况预览
总结下来，异常主要有三个部分。
- 超量读写 和 nil读写： 出现了阻塞
- close的channel写入： 触发
panic - close的读：读出0
Channel的两种使用
Golang中channel的存在使得整个语言在处理异步式或密集IO的问题有着显著的提升，因为Golang的设计，近来的JAVA在jdk21版本设计上也参照Golang的协程理念。
Channel在英文中即管道的意思，在Golang中channel就像管道一样，承担着在多个程序之间传输的任务。针对不同情况，可以创建两种Channel：无缓冲Channel、有缓冲Channel。
无缓冲Channel
创建一种int类型的无缓冲channel，其结果代表协程中处理的最终结果。最终被主线程接受
package main
import (
"fmt"
"time"
)
func main() {
ch := make(chan int)
go func() {
// 执行任务
fmt.Println("执行协程任务开始")
time.Sleep(1 * time.Second)
fmt.Println("执行协程任务结束")
// 假设得到结果 为1
// 传1到channel中
ch <- 1
}()
// 主线程异步执行其他任务
fmt.Println("执行主线程任务开始")
time.Sleep(2 * time.Second) //假设执行需要2s
fmt.Println("执行主线程任务结束")
select {
case x := <-ch:
fmt.Println("接受Channel", x)
case <-time.After(time.Second):
fmt.Println("timeout")
}
}
可以看到主线程任务和协程任务，两者同时开始，并且在最后将channel中的值传给了主线程。这两者在执行任务的过程是同步。当然还有更多中关于无缓冲Channel的使用，这里就不多介绍。
有缓冲Channel的使用
package main
import (
"fmt"
"time"
)
func main() {
ch := make(chan int, 3)
// 1. 正常使用buffer
// 结果制造程序
go func() {
// 程序需执行三次计算，每次计算耗时1s
for i := 0; i < 3; i++ {
time.Sleep(1 * time.Second)
fmt.Println("任务结束，传输的值为：", i)
ch <- i
fmt.Println("传输结果：", i)
}
}()
// 结果接受程序
for i := 0; i < 3; i++ {
select {
case v := <-ch:
fmt.Println("获取结果：", v)
case <-time.After(3 * time.Second):
fmt.Println("正常读写出现阻塞")
}
}
}
通过make(chan int 3)来创建一个int类型的有缓冲buffer，其中3表示缓冲的长度。上述代码运行结果如下。
上述就简单的演示一下有缓冲channel的一种使用情况。
无缓冲Channel的所有情况
无缓冲Channel在使用中主要可能出现5种读写场景。
正常读写
package main
import (
"fmt"
"time"
)
func main() {
ch := make(chan string)
// 1. 正常channel读写
fmt.Println("----------正常channel读写-----------------")
go func() {
ch <- "1. 正常读写"
}()
select {
case data := <-ch:
fmt.Println(data, "读写成功")
case <-time.After(time.Second):
fmt.Println("1. 正常读写：1s后读写阻塞了。。。")
}
}
标准的无缓冲channel读写
连续写入
// 2.连续写
ch = make(chan string)
flag := make(chan bool)
fmt.Println("----------连续写-----------------")
go func() {
for i := 0; i < 3; i++ {
fmt.Printf("第%d次写入\n", i+1)
ch <- "这是第" + string(rune(i)) + "次"
}
flag <- true
// 循环是否出来
fmt.Println("循环结束")
}()
select {
case <-flag:
fmt.Println("没有阻塞")
case <-time.After(time.Second):
fmt.Println("2.连续写：阻塞了")
}
如果无缓冲channel中不是空的，那么下次写入就会阻塞，直到有程序将其读出
package main
import (
"fmt"
"time"
)
func main() {
// 3. 连续读
fmt.Println("----------连续读-----------------")
// 创建一个空channel
ch := make(chan string)
flag := make(chan bool)
go func() {
// 持续读
for i := 0; i < 3; i++ {
fmt.Printf("第%d次读\n", i+1)
x := <-ch
fmt.Println("ch的值为：", x)
}
flag <- true
}()
select {
case <-flag:
fmt.Println("没有阻塞")
case <-time.After(time.Second):
fmt.Println("3. 连续读：阻塞了")
}
}
类似的，如果无缓冲buffer中没有数据，那么读也会被阻塞，直到channel中出现写入。
nil的channel
写入情况
package main
import (
"fmt"
"time"
)
func main() {
var ch chan string = nil
// 4. nil的channel读写
fmt.Println("----------nil的channel读写-----------------")
go func() {
ch <- "4. nil的channel读写"
fmt.Println("写入完成")
}()
select {
case data := <-ch:
fmt.Println(data, "读写成功")
case <-time.After(time.Second):
fmt.Println("4. 正常读写：1s后读写阻塞了。。。")
}
}
可以看到，协程中的写入操作 = 没有写入。并且fmt.Println("写入完成")部分也没有执行，说明写入部分出现了阻塞，主线程在通过select的操作时并没有检查到ch中的输入信号，所以最终倒计时结束执行退出操作。
读取状况
package main
import (
"fmt"
"time"
)
func main() {
var ch chan int = nil
go func() {
fmt.Println(<-ch)
fmt.Println("读取成功")
}()
time.Sleep(1 * time.Second)
}
运行结果也并没出现读取成功的字样，所以协程中也出现了阻塞的情况。
已关闭的channel
写入情况
package main
import (
"fmt"
"time"
)
func main() {
ch := make(chan string)
close(ch)
// 5. channel关闭情况下读写
fmt.Println("----------channel关闭情况下读写-----------------")
go func() {
ch <- "5. close的channel读写"
}()
time.Sleep(1 * time.Second)
}
可以看到在向关闭的channel写入时，会触发panic，从而终止程序。
读取情况
import "fmt"
func main() {
ch := make(chan int)
close(ch)
fmt.Println("读取channel")
x := <-ch
fmt.Println(x)
}
代码结果表明，在读取close的channel时，会返回一个0作为结果，而不会像无值的时候那样出现阻塞。
总结
将上述的情况进行总结，可以得到有缓冲channel在多种情况下，在每个程序中会带来的影响。
主要有两个特殊情况，即close读写的两个特殊情况。
- close的channel写会造成
panic - close的channel读在int类型下会读到0。
有缓冲Channel的所有情况
Channel中还有有缓冲的设计模式，通过在创建时，对channel设定一定的大小的长度，来表示channel最大能缓冲的数据量。
正常读写
package main
import (
"fmt"
"time"
)
func main() {
ch := make(chan int, 3)
fmt.Println("-----------正常读写---------------")
// 1. 正常使用buffer
// 结果制造程序
go func() {
// 程序需执行三次计算，每次计算耗时1s
for i := 0; i < 3; i++ {
time.Sleep(1 * time.Second)
fmt.Println("任务结束，传输的值为：", i)
ch <- i
fmt.Println("传输结果：", i)
}
}()
// 结果接受程序
for i := 0; i < 3; i++ {
select {
case v := <-ch:
fmt.Println("获取结果：", v)
case <-time.After(3 * time.Second):
fmt.Println("正常读写出现阻塞")
}
}
}
代码中一个协程进行数据的筛入，主线程进行获取。最终很好的实现三次传输和接受的同步。并且整个程序也没有出现阻塞的现象。
超量写不读
package main
import (
"fmt"
"time"
)
func main() {
// 2. 超量写
fmt.Println("----------超量写-----------")
ch := make(chan int, 3)
flag := make(chan bool)
go func() {
for i := 0; i < 5; i++ {
time.Sleep(100 * time.Millisecond)
fmt.Println("程序结束，传输数据", i)
ch <- i
fmt.Println("传输成功，", i)
}
fmt.Println("数据传输完毕")
// 没有阻塞
flag <- true
}()
select {
case <-flag:
fmt.Println("没有阻塞")
case <-time.After(6 * time.Second):
fmt.Println("6s 后发现阻塞")
}
}
可以看到只写不读的情况下，当传入channel循环到第三个数据时，就不会传输了，此协程中就出现了阻塞。最终在主线程中结束了等待。
超量读不写
package main
import (
"fmt"
"time"
)
func main() {
// 3. 超量读
fmt.Println("----------超量读-----------")
// 重新创建新的
ch := make(chan int, 3)
flag := make(chan bool)
go func() {
for i := 0; i < 5; i++ {
fmt.Println("程序计算完毕，准备获取channel内部的值")
v := <-ch
fmt.Println("此时无值，但要超量读，v的值为：", v)
}
fmt.Println("channel数据获取完毕")
flag <- true
}()
select {
case <-flag:
fmt.Println("没有阻塞")
case <-time.After(6 * time.Second):
fmt.Println("6s 后发现阻塞")
}
}
可以看到，在协程中channel根本就没有数据，所以自然而然就发生了阻塞，进而协程中的程序将不再执行，直到主线程等待6s后结束程序。
nil 的有缓冲channel的情况
写
package main
import (
"fmt"
"time"
)
func main() {
var ch chan []int = nil
flag := make(chan bool)
go func() {
ch <- []int{1, 2, 3}
flag <- true
fmt.Println("数据写入成功")
}()
select {
case <-flag:
fmt.Println("channel数据写入成功")
case <-time.After(time.Second):
fmt.Println("1s后出现阻塞")
}
}
可以看到在新建的协程中，执行ch <- []int{1, 2, 3}时出现了阻塞，协程无法继续向后执行，flag无法接受到结束信号，使的整个协程出现了阻塞。直到主线程中select将整个进程按阻塞情况处理了。
读
package main
import (
"fmt"
"time"
)
func main() {
var ch chan []int = nil
flag := make(chan bool)
go func() {
x := <-ch
fmt.Println("x:", x)
flag <- true
fmt.Println("数据写入成功")
}()
select {
case <-flag:
fmt.Println("程序结束")
case <-time.After(1 * time.Second):
fmt.Println("程序阻塞")
}
}
结果也是出现了阻塞，当然这也是符合预期的。
关闭缓冲Channel的所有情况
正常读写
package main
import (
"fmt"
"time"
)
func main() {
ch := make(chan int, 3)
close(ch)
go func() {
for i := 0; i < 3; i++ {
ch <- i
}
fmt.Println("数据传输成功")
}()
for i := 0; i < 3; i++ {
select {
case v := <-ch:
fmt.Println("收到数据，", v)
case <-time.After(time.Second):
fmt.Println("阻塞")
}
}
}
当执行上述的关闭程序时，发现出现了收到了数据和send on closed channel的错误，猜测写入关闭channel会出现panic，读的时候会读到0。也就是说有缓冲和无缓冲的channel的关闭情况是相同的。
总结
结果可以看到，有缓冲的channel的各种情况的和无缓冲的channel相类似。
最后总结
可以看到，不管是无缓冲和有缓冲channel，两者的机理相类似，这必然是golang中内部源码提前设计好的，如果大家喜欢的话，之后可以再深入探讨一下^-^
总结下来，异常主要有三个部分。
- 超量读写 和 nil读写： 出现了阻塞
- close的channel写入： 触发
panic - close的读：读出0
本文是经过个人查阅相关资料后理解的提炼，可能存在理论上理解偏差的问题，如果您在阅读过程中发现任何问题或有任何疑问，请不吝指出，我将非常感激并乐意与您讨论。谢谢您的阅读！
1955
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
