本教程深入探讨go语言中基于channel的并发控制流，重点分析了在使用无缓冲channel进行事件监听和状态管理时可能发生的死锁问题。通过具体代码示例，文章详细解释了死锁的成因，并提供了三种有效的解决方案：将channel发送操作移至独立goroutine、采用布尔标志进行状态管理，以及利用有缓冲channel来解耦发送与接收操作，旨在帮助开发者构建健壮的并发程序。
Go语言以其内置的并发原语——Goroutine和Channel——极大地简化了并发编程。Channel作为Goroutine之间通信的桥梁，其设计哲学是“不要通过共享内存来通信，而通过通信来共享内存”。然而，如果不正确地使用Channel，尤其是无缓冲Channel，很容易导致程序陷入死锁状态。本文将通过一个具体的案例，深入剖析Go Channel控制流中的常见陷阱，并提供多种避免死锁的策略。
理解无缓冲Channel与死锁成因
在Go语言中，Channel可以分为无缓冲（unbuffered）和有缓冲（buffered）两种。无缓冲Channel要求发送者和接收者必须同时就绪才能完成通信。这意味着，当一个Goroutine尝试向无缓冲Channel发送数据时，如果此时没有另一个Goroutine准备好从该Channel接收数据，发送Goroutine将会被阻塞，直到有接收者出现。反之亦然，如果一个Goroutine尝试从无缓冲Channel接收数据，而没有发送者，它也会被阻塞。
考虑以下代码示例，它尝试在一个Goroutine内部通过无缓冲Channel进行状态控制，但最终导致了死锁：
package main
import (
"fmt"
"time"
)
type A struct {
count int
ch chan bool
exit chan bool // 无缓冲退出Channel
}
func (this *A) Run() {
for {
select {
case <-this.ch: // 接收事件
this.handler()
case <-this.exit: // 接收退出信号
return
default:
time.Sleep(20 * time.Millisecond)
}
}
}
func (this *A) handler() {
println("hit me")
if this.count > 2 {
// 在Run Goroutine内部，尝试向exit Channel发送数据
this.exit <- true
}
fmt.Println(this.count)
this.count += 1
}
func (this *A) Hit() {
this.ch <- true
}
func main() {
a := &A{}
a.ch = make(chan bool)
a.exit = make(chan bool) // 创建无缓冲Channel
go a.Hit()
go a.Hit()
go a.Hit()
go a.Hit()
// main Goroutine调用a.Run()，该方法会阻塞main Goroutine
a.Run()
fmt.Println("s")
}运行上述代码，会观察到如下错误信息：
hit me 0 hit me 1 hit me 2 hit me fatal error: all goroutines are asleep - deadlock! goroutine 1 [chan send]: main.(*A).handler(0x2101bf000) /Users/yeer/go/src/github.com/athom/practice/channel-controll.go:31 +0x60 main.(*A).Run(0x2101bf000) /Users/yeer/go/src/github.com/athom/practice/channel-controll.go:19 +0x66 main.main() /Users/yeer/go/src/github.com/athom/practice/channel-controll.go:50 +0xed exit status 2
死锁分析：main Goroutine（通过调用a.Run()）进入了Run方法中的无限循环。当this.count达到3时，handler方法被Run Goroutine同步调用，并尝试执行 this.exit
解决方案一：将Channel发送操作移至独立Goroutine
解决上述死锁问题的一种直接方法是确保Channel的发送和接收操作发生在不同的Goroutine中，或者至少确保发送Goroutine不会因为等待接收而阻塞。
一个有效的策略是将handler函数中触发exit信号的逻辑，或者整个handler的执行，放入一个新的Goroutine中。
方案1.1：将handler的执行放入独立Goroutine
如果将`handler
