golang中channel的Q&A
channel Q&A
什么是CSP?
不要通过共享内存来实现通信，而要通过通信实现共享内存
CSP通常被认为go在并发上成功的关键因素
go一开始就把CSP的思想融入到语言的核心里，所以并发编程称为go的一个独特的优势
大多数编程语言的并发模式是基于线程和内存同步访问控制实现的，Go的并发编程模型通过goroutine和channel来代替
goroutine和线程类似，channel和mutex(内存同步访问控制)类似
goroutine解放了程序员，让我们更贴近业务去思考问题，而不用考虑各种像线程库、线程开销、线程调度这些繁琐的底层问题了，
goroutine天生替你解决好了
channel则天生可以和其它channel组成，我们可以把收集各种子系统结果的channel输入到同一个channel
channel还可以和select,cancel,timeout组合，而mutex没有这些功能
go的并发原则非常优秀，目标就是简单，尽量使用channel，把goroutine当做免费的资源，随便用
channel和select和timeout组合案例：
// channel 和 select timeout组合
chan1 := make(chan int, 1)
//out := make(chan int, 1)
//timer := time.NewTimer(time.Second * 3)
go func() {
time.Sleep(time.Second * 3)
chan1 <- 88
}()
select {
case v := <-chan1:
fmt.Println("chan1接收到数据", v)
//case <-timer.C:
case <-time.After(time.Second * 2):
fmt.Println("超时了")
}
// channel 和 select timeout组合
chan1 := make(chan int, 1)
out := make(chan int, 1)
timer := time.NewTimer(time.Second * 2)
go func() {
go func() {
time.Sleep(time.Second * 3)
chan1 <- 88
}()
select {
case v := <-chan1:
fmt.Println("chan1接收到数据", v)
//case <-timer.C:
case <-timer.C:
fmt.Println("超时了")
}
out <- 88
}()
<-out
channel底层的数据结构是什么
type hchan struct {
// chan 里元素数量
qcount uint
// chan 底层循环数组的长度
dataqsiz uint
// 指向底层循环数组的指针
// 只针对有缓冲的 channel
buf unsafe.Pointer
// chan 中元素大小
elemsize uint16
// chan 是否被关闭的标志
closed uint32
// chan 中元素类型
elemtype *_type // element type
// 已发送元素在循环数组中的索引
sendx uint // send index
// 已接收元素在循环数组中的索引
recvx uint // receive index
// 等待接收的 goroutine 队列
recvq waitq // list of recv waiters
// 等待发送的 goroutine 队列
sendq waitq // list of send waiters
// 保护 hchan 中所有字段
lock mutex
}
关于字段的含义都写在注释里了，再来重点说几个字段：
buf 指向底层循环数组，只有缓冲型的 channel 才有。
sendx，recvx 均指向底层循环数组，表示当前可以发送和接收的元素位置索引值（相对于底层数组）。
sendq，recvq 分别表示被阻塞的 goroutine，这些 goroutine 由于尝试读取 channel 或向 channel 发送数据而被阻塞。
waitq 是 sudog 的一个双向链表，而 sudog 实际上是对 goroutine 的一个封装：
lock 用来保证每个读 channel 或写 channel 的操作都是原子的。
- 创建
func makechan(t *chantype, size int64) *hchan
从函数原型来看，创建的channel是一个指针，所以我们在函数之间直接传递channel，而不需要传递channel的指针
channel发送和接收元素的本质是什么？
* 就是说channel的发送和接收本质上都是"值拷贝",无论是从sender goroutine的栈道chan buf
还是从chan buf到receiver goroutine，或者直接从sender goroutine到receiver goroutine
案例：
package main
import (
"fmt"
"time"
)
type user struct {
name string
age int8
}
var u = user{name: "马亚南", age: 29}
var g = &u
func printUser(c <-chan *user) {
time.Sleep(time.Second * 2)
fmt.Println("printUser输出的是：", <-c)
}
func modifyUser(u *user) {
fmt.Println("modifyUser输出的是：", u)
u.name = "香香"
}
func main() {
// 非常重要的一点：goroutine发送到channel，从channel接收到goroutine
// 还是goroutine发送到另一个goroutine，全部都是"值拷贝"
ch := make(chan *user, 5)
ch <- g // g发送到channel，是值拷贝，拷贝的是g中的内容，也就是u的指针
g = &user{name: "彤宝贝", age: 5}
go printUser(ch)
go modifyUser(g)
time.Sleep(time.Second * 3)
fmt.Println(g)
}
/* 输出结果
modifyUser输出的是: &[彤宝贝 5]
printUser输出的是 &[马亚南 29]
&[香香 5]
*/
// 结论: goroutine发送到channel，channel读取到goroutine全部是值传递
从channel接收数据的过程是怎样的
* goroutine是用户态的协程，由go runtime进行管理，相比线程由os进行管理
goroutine更轻量，所以我们可以轻松创建数万goroutine
一个内核线程可以管理多个goroutine，当其中的一个goroutine阻塞时，内核线程可以调度其它的goroutine来运行，
内核线程本身不会阻塞，这就是我们常说的M:N模型
channel发送接收报错的场景
错误1：当向无缓冲通道且无接收者发送数据时，会报panic错误
错误2：当从无发送者(无论有无缓冲)通道接收数据时，都会报panic错误
零值3：当从已关闭的（无论有无缓冲）通道接收数据时，都会返回通道对应类型的零值
4： 当向有缓冲且通道未满发送数据时，无论有无接收者，都不会报错
5. 当向有缓冲通道且通道已满，而且无接收者是，会报panic错误
channel在什么情况下会引起资源泄漏
* channel可能会引发goroutine泄漏
泄漏的原因是，当goroutine操作channel时，处于发送或接收阻塞状态，而channel处于满或空的状态，
一直得不到改变，同时垃圾回收器也不会回收此类资源，进而导致goroutine一直处于等待队列中，不见天日
另外在程序运行中，对于一个channel，如果没有任何goroutine对其引用了，gc就会对其回收，不会引起内存泄漏
channel有哪些应用
* channel和goroutine的结合是go并发编程的大杀器
* 而channel和select、cancel、timer的结合能实现各种各样的功能
* 1. 停止信号：关闭channel或向channel发送一个元素，使接收方通过channel获得信息后做相应的操作
* 2. 任务定时：
（1）超时控制
func main() {
c := make(chan int)
out := make(chan bool)
go func() {
go func() {
time.Sleep(time.Second)
c <- 2
}()
select {
case <-time.After(time.Second * 1):
fmt.Println("超时了")
case v := <-c:
fmt.Println("c中读取出的数据：", v)
}
out <- true
}()
<-out
}
（2）定期执行某个任务
func main() {
timer := time.NewTicker(time.Second)
for {
select {
case <-timer.C:
fmt.Println("执行了") // 每隔1秒执行一次
}
}
}
3. 解耦生产方和消费方
服务启动时，启动n个worker，作为工作协程池，这些协程工作在一个for无限循环里, 从某个channel消费工作任务并执行
案例：
func main() {
tasksChan := make(chan int, 100) // 任务队列
go workerTask(tasksChan) // 开启处理任务的协程池
// 发起任务
for i := 0; i < 10; i++ {
tasksChan <- i
}
select {
case <-time.After(time.Second * 3):
}
}
func workerTask(tasksChan chan int) {
// 开启5个协程去处理任务队列中的数据
GOS := 5
for i := 0; i < GOS; i++ {
// 局部变量在堆栈上存储，也是变量逃逸的一种场景(解决方法：使用闭包)
go func(i int) {
for {
value := <-tasksChan
fmt.Printf("finish task: %d by worker %d\n", value, i)
time.Sleep(time.Second)
}
}(i)
}
}
输出结果：
finish task: 1 by worker 4
finish task: 2 by worker 1
finish task: 3 by worker 2
finish task: 4 by worker 3
finish task: 0 by worker 0
finish task: 5 by worker 0
finish task: 6 by worker 1
finish task: 7 by worker 3
finish task: 8 by worker 2
finish task: 9 by worker 4
4. 控制并发数
有时需要定时执行几百个任务，例如每天定时按城市来执行一些离线计算的任务。但是并发数又不能太高，
因为任务执行过程依赖第三方的一些资源，对请求的速率有限制。这时就可以通过 channel 来控制并发数。
案例：
var limit = make(chan int, 3)
func main() {
// 通过channel控制最大并发数量
tasks := [...]int{11, 22, 33, 44, 55, 66, 77, 88, 99, 100}
for i, v := range tasks {
// 为每一个任务开启一个goroutine
go func(i, v int) {
// 通过channel控制goroutine最大并发数量
limit <- -1
fmt.Println(i, v)
time.Sleep(time.Second)
<-limit
}(i, v)
}
time.Sleep(time.Second * 4)
}
从一个关闭的channel中仍能读出数据吗？
从一个有缓冲的channel里读取数据，当channel关闭后，依然能读出有效值，
只有当ok返回的值为false时，读取出的值是channel中默认类型的零值
案例：
func main() {
ch := make(chan int, 3)
ch <- 55
close(ch)
v, ok := <-ch
if ok {
fmt.Println("first read value: ", v)
}
v = <-ch
fmt.Println(v) // 0
v, ok = <-ch // 从通道中读取数据，既可以直接接收值， 也可以接收值和接收状态
if !ok {
fmt.Println("second read value:", v)
}
}
关于channel的happened-before有哪些
1. 第 n 个 send 一定 happened before 第 n 个 receive finished，无论是缓冲型还是非缓冲型的 channel。
2. 对于容量为 m 的缓冲型 channel，第 n 个 receive 一定 happened before 第 n+m 个 send finished。
3. 对于非缓冲型的 channel，第 n 个 receive 一定 happened before 第 n 个 send finished。
4. channel close 一定 happened before receiver 得到通知。
解释：
1. send不一定发生在recv之前，因为也可以先receive,然后goroutine被挂起，之后被sender唤醒,
无论如何，send一定发生在receive finished之前
2. 缓冲型channel，容量为m，第n+m个send发送之后的情形：
如果第n个receive还没发生，这时候channel填满了，send就会被阻塞，
当第n个receive接收完成后，sender goroutine会被唤醒，之后在继续发送过程
也就是说第n个receive happened-before 第n+m个send finished
3. 第n个send如果被阻塞了，sender goroutine被挂起，第n个receive到来时，先与第n个send finished
如果第n个send未被阻塞，说明第n个receive已经在那等着了，它不仅happened-before send finished
而且还happened-before send
4. 先设置closed = 1，在唤醒等待的receiver, 并将零值拷贝给receiver
案例：
// 顺序一致性的内存模型，这是并发编程的基础
var ch = make(chan bool)
var msg string
func AGoroutine() {
time.Sleep(time.Second)
msg = "哈哈"
<-ch
}
func main() {
go AGoroutine()
ch <- true
fmt.Println(msg) // 一定打印哈哈，为什么？
// 因为 对于无缓冲型通道，第n个receive一定发生在第n个send finished之前
}
// 这里依赖的就是前面讲的happened-before 第一条，send一定发生在receive finished之前，
// 即 ch <- true 在 <-ch 之前
关闭一个channel的过程是怎么样的？
1. 关闭一个nil channel会报错panic
2. close逻辑比较简单，对于一个channel，recvq和sendq分别保存了阻塞的发送者和接受者
关闭channel后，对于等接收者而言，会收到一个相应类型的零值，对于发送者，会直接panic,
所以，在不了解channel还有没有接收者的时候，不能贸然关闭channel
3. close函数先上一把大锁，然后把所有挂载channel上的receiver和sender连成一个sudog链表
在解锁，最后在将所有的sudog全部唤醒
4. 唤醒之后，该干嘛干嘛，sender继续向channel发送就会报panic错误，
receiver继续接收，如果channel为空了，返回对应类型的零值
向channel发送数据的过程是怎样的
1. 如果检测到channel已经关闭，直接panic
2. 如果能从等待接收队列recvq里出队一个sudog(代表一个goroutine)，说明此时channel是空的，
没有元素，所以才会有等待接收者，这时会调用send函数将元素从发送者的栈拷贝到接受者的栈中去
3. 向一个非缓冲型的channel发送数据，从一个无元素的channel(非缓冲型或缓冲型但空)接收数据，
都会导致一个goroutine直接操作另一个goroutine的栈
如何优雅的关闭channel
关于channel的使用有几点不方便的地方
1. 在不改变channel自身状况的情况下，无法获知一个channel是否关闭
2. 关闭一个closed channel就会导致panic, 如果关闭channel的一方不知道channel是否处于关闭状态时就去贸然关闭，是件很危险的事情
3. 向一个closed channel发送数据就会导致panic, 如果想channel发送数据的一方不知道是否处于关闭状态时就去贸然发送数据，是件很危险的事情
4. 有一条广泛流传的关闭channel的原则：
不要从一个receiver侧关闭channel，也不要在有多个sender时关闭channel(本质：不要关闭或者发送数据到以关闭的channel)
5. 有两个不那么优雅的关闭channel的方法
* 使用defer-recover机制，大胆放心的向channel发送数据或关闭channel，报错了有defer-recover在兜底
func main() {
ch := make(chan int, 10)
go goroutineA(ch)
go goroutineB(ch)
time.Sleep(time.Second * 4)
}
func goroutineA(ch chan int) {
defer func() {
if err := recover(); err != nil {
fmt.Println(err)
}
}()
ch <- 10
time.Sleep(time.Second)
close(ch)
}
func goroutineB(ch chan int) {
defer func() {
if err := recover(); err != nil {
fmt.Println(err)
}
}()
ch <- 20
time.Sleep(time.Second * 2)
close(ch)
}
* 使用sync.Once来保证只关闭一次
案例：
var (
once *sync.Once = &sync.Once{}
)
func main() {
ch := make(chan int, 10)
go goroutineA(ch)
go goroutineB(ch)
time.Sleep(time.Second * 4)
}
func goroutineA(ch chan int) {
ch <- 10
time.Sleep(time.Second)
close(ch) // 错误
//once.Do(func() {
// close(ch)
//})
}
func goroutineB(ch chan int) {
ch <- 20
time.Sleep(time.Second * 2)
close(ch) // 错误
//once.Do(func() {
// close(ch)
//})
}
// 上面两处错误的原因：关闭已经关闭的channel就会报panic
6. 如何优雅的关闭channel（四种情况）
1. 如何只有一个sender而且只有一个receiver，那么直接在sender中关闭就好了
2. 如果只有一个sender而且有多个receiver,也是直接在sender中关闭就好了
3. 如果有多个sender, 只有一个receiver的情况下，解决方案就是增加一个传递关闭信号的channel
receiver通过关闭channel指令，sender监听到关闭信号后，停止发送数据
func main() {
rand.Seed(time.Now().UnixNano()) // 真随机
const Max = 100000
const NumSenders = 1000
var wg sync.WaitGroup
wg.Add(NumSenders + 1)
dataCh := make(chan int, 100)
stopCh := make(chan struct{})
// senders
for i := 0; i < NumSenders; i++{
go func() {
defer wg.Done()
for {
select {
case <-stopCh:
return
case dataCh <- rand.Intn(Max):
}
}
}()
}
// 开启一个receiver goroutine
go func() {
defer wg.Done()
for value := range dataCh{
if value == Max - 1{
fmt.Println("send close signal to senders", value)
close(stopCh)
// 此处必须得return,因为如果不return的话, 由于dataCh并没有关闭，for循环会一直等待，进入死锁
// 但是有一点，return之后，dataCh中由于是100的容量，所以最后的100条数据不会读取出来
return
}
fmt.Println(value)
}
wg.Done()
}()
wg.Wait()
//select{
//case <-time.After(time.Second * 5): // 1小时超时控制
//}
}
上面程序中dataCh并没有显示的关闭通道，因为在go语言中，对于一个channel,
如果没有任何goroutine引用它，不管该channel有没有关闭，都会被GC回收
所以在这种情况下，所谓的优雅的关闭channel就是不关闭channel，让GC代劳
4. 切记两点：
1. 不要从接收方关闭channel
2. 如果channel有多个发送方，也不要关闭channel(可以通过另外一个信号通道告诉发送方停止发送)
5. 本质：不要关闭已经关闭的channel，不要向已关闭的channel发送数据
6. 如果有多个sender和多个receiver的时候跟第三种情况就又不太一样了，如果由receiver关闭stopCh的话
由于有多个receiver，就会包panic,此时我们需要一个中间人，多个receiver都向该中间人发送关闭通道的指令
中间人接收到第一个请求后就会直接关闭,这里将 toStop 声明成了一个 缓冲型的 channel。
假设 toStop 声明的是一个非缓冲型的 channel，那么第一个发送的关闭 dataCh 请求可能会丢失。
因为无论是 sender 还是 receiver 都是通过 select 语句来发送请求，如果中间人所在的 goroutine 没有准备好，
那 select 语句就不会选中，直接走 default 选项，什么也不做。这样，第一个关闭 dataCh 的请求就会丢失。
func main() {
rand.Seed(time.Now().UnixNano()) // 真随机
const Max = 100000
const NumSenders = 1000
const NumReceivers = 10
var wg sync.WaitGroup
wg.Add(NumSenders + NumReceivers)
dataCh := make(chan int, 100)
stopCh := make(chan struct{})
toStop := make(chan string, 1)
var stoppedBy string
// 中间人监听toStop，一旦有数据关闭stopCh
go func() {
stoppedBy = <-toStop
close(stopCh)
}()
// senders
for i := 0; i < NumSenders; i++{
go func(id string) {
defer wg.Done()
for {
value := rand.Intn(Max)
if value == 0 {
select {
case toStop <- "sender#" + id:
default:
}
fmt.Println("value=====================================:", value)
return
}
select {
case <-stopCh:
return
case dataCh <- rand.Intn(Max):
}
}
}(strconv.Itoa(i))
}
// receivers
for i := 0; i < NumReceivers; i++{
go func(id string) {
defer wg.Done()
for{
select {
case <-stopCh:
return
case value := <-dataCh:
if value == Max - 1{
select {
case toStop <- "receiver#" + id:
default:
}
fmt.Println("value==============================:", value)
return
}
fmt.Println(value)
}
}
}(strconv.Itoa(i))
}
wg.Wait()
//select{
//case <-time.After(time.Second * 5): // 1小时超时控制
//}
}
操作channel的情况总结
总结一下操作channel的结果
操作 nil channel closed channel not nil, not closed channel
close panic panic 正常关闭
读<- ch 阻塞 读到对应类型的零值 阻塞或正常读取数据。缓冲型 channel 为空或非缓冲型 channel 没有等待发送者时会阻塞
写ch <- 阻塞 panic 阻塞或正常写入数据。非缓冲型 channel 没有等待接收者或缓冲型 channel buf 满时会被阻塞
总结一下：发生panic有三种情况：
1. 向一个已经关闭的channel发送数据
2. 重复关闭channel
3. 关闭一个nil channel
阻塞的两种情况：
1. 向一个nil channel发送数据
2. 从一个nil channel读取数据
