在 Go 的并发编程中，通道负责在多个 goroutine 之间传递数据，但通道的阻塞特性也容易引发死锁。最常见的情形是：主 goroutine 向一个无缓冲通道发送数据，却没有第二个 goroutine 接收，程序会直接抛出 fatal error: all goroutines are asleep - deadlock。这类错误不会等到运行时才出现，它会在所有 goroutine 都阻塞时立即触发。理解通道的发送与接收配对关系，是避免死锁的第一步。
通道死锁的本质：发送与接收必须配对
Go 的通道分为无缓冲通道和缓冲通道。无缓冲通道的发送操作 ch <- 1 只有在另一个 goroutine 执行了 <-ch 接收操作时才会返回；反过来，接收操作也会阻塞到有发送者出现。这意味着无缓冲通道天然要求发送和接收在两个不同的 goroutine 中同步进行。如果发送和接收出现在同一个 goroutine 中，就会形成死锁。
下面这段代码是一个典型的错误示例：
package main
import "fmt"
func main() {
ch := make(chan int)
ch <- 1
fmt.Println(<-ch)
}
程序执行到 ch <- 1 时，主 goroutine 被阻塞，等待接收方；而接收操作在后面，永远没有机会执行。运行时检测到所有 goroutine 都在休眠，于是抛出死锁错误。解决方式很简单：让发送和接收分别运行在不同的 goroutine 中，或者使用带缓冲的通道。
缓冲通道在缓冲区未满时，发送操作不会阻塞；缓冲区为空时，接收操作才会阻塞。比如把上面的代码改成 make(chan int, 1)，发送操作就可以在缓冲区写入数据并立即返回，后续接收也能正常读到数据。但这只是缓解了同步问题，如果缓冲区大小固定而生产速度长期高于消费速度，仍然可能在某些时刻阻塞。
避免死锁的实战模式：非阻塞、超时与取消
实际项目中，goroutine 的数量和数据流向往往比较复杂，不能只依赖配对。一个常用的办法是使用 select 语句配合 default 分支，实现非阻塞的通道操作。这样即使没有接收方或发送方，当前 goroutine 也不会永久阻塞。
package main
import "fmt"
func main() {
ch := make(chan int)
select {
case v := <-ch:
fmt.Println("received", v)
default:
fmt.Println("no data, continue")
}
}
上面的代码在 <-ch 没有数据可读时，会直接执行 default 分支，而不是挂起等待。这种方式适合轮询或需要快速响应的场景。不过，单纯的非阻塞操作并不能解决所有问题，有时业务上需要等待一段时间再放弃，这时可以引入 time.After 超时。
package main
import (
"fmt"
"time"
)
func main() {
ch := make(chan int)
select {
case v := <-ch:
fmt.Println("received", v)
case <-time.After(2 * time.Second):
fmt.Println("timeout")
}
}
当通道在 2 秒内没有数据到达时，程序会打印 timeout 并继续向下执行，从而避免无限等待。如果等待逻辑还涉及上游请求取消、服务优雅退出等场景，使用 context.Context 会更加规范。通过 context.WithTimeout 或 context.WithCancel 创建一个可取消的上下文，再把 ctx.Done() 作为 select 的一个分支，就能在外部主动终止阻塞。
package main
import (
"context"
"fmt"
"time"
)
func main() {
ch := make(chan int)
ctx, cancel := context.WithTimeout(context.Background(), 3*time.Second)
defer cancel()
select {
case v := <-ch:
fmt.Println("received", v)
case <-ctx.Done():
fmt.Println("canceled or timed out")
}
}
使用 context 的好处是取消信号可以跨多个 goroutine 传播，只要每个 goroutine 都在 select 中监听 ctx.Done()，就能实现统一的超时控制和资源回收。对于需要长期运行的消费者协程，关闭通道也是一种广播停止信号的手段。
package main
import "fmt"
func worker(done <-chan struct{}) {
<-done
fmt.Println("worker exit")
}
func main() {
done := make(chan struct{})
go worker(done)
close(done)
}
关闭通道后，所有从该通道接收的 goroutine 都会立即收到零值，不需要为每个 goroutine 单独发送停止信号。但要注意，关闭通道本身不能重复调用，否则会 panic。通常由发送方或专门的管理者负责关闭，接收方只负责读取。
共享数据的并发安全：互斥锁、原子操作与竞态检测
通道适合在 goroutine 之间传递数据所有权，但并非所有共享数据都适合用通道来同步。如果多个 goroutine 需要并发读写同一个变量，直接操作会引发数据竞争。Go 提供了 sync.Mutex 来保护临界区，确保同一时刻只有一个 goroutine 能访问共享资源。
package main
import (
"fmt"
"sync"
)
var (
mu sync.Mutex
counter int
)
func increment() {
mu.Lock()
defer mu.Unlock()
counter++
}
func main() {
var wg sync.WaitGroup
for i := 0; i < 1000; i++ {
wg.Add(1)
go func() {
defer wg.Done()
increment()
}()
}
wg.Wait()
fmt.Println(counter)
}
互斥锁的代价是加锁和释放锁会带来一定的性能开销，并且如果锁的顺序设计不当，还可能引入新的死锁问题。对于简单的计数、状态标志等场景，使用 sync/atomic 包提供的原子操作往往更高效。原子操作在硬件层面保证单个操作的不可分割性，不需要显式加锁。
package main
import (
"fmt"
"sync"
"sync/atomic"
)
var counter int64
func increment() {
atomic.AddInt64(&counter, 1)
}
func main() {
var wg sync.WaitGroup
for i := 0; i < 1000; i++ {
wg.Add(1)
go func() {
defer wg.Done()
increment()
}()
}
wg.Wait()
fmt.Println(atomic.LoadInt64(&counter))
}
虽然原子操作只能支持有限的几种类型和操作，但在高并发计数、标志位切换等场景下，它的性能明显优于互斥锁。无论使用锁还是原子操作，都无法替代实际的并发测试。Go 自带的竞态检测器 go run -race main.go 可以在运行时发现数据竞争，建议在测试阶段始终开启。
从一次线上故障看死锁排查思路
假设线上某个服务突然出现所有请求超时，但 CPU 和内存并不高。通过 pprof 查看 goroutine 堆栈，发现大量 goroutine 都停留在某个通道的发送或接收操作上。这种表象几乎可以锁定为死锁或通道阻塞。排查时可以先确认是否有 goroutine 因为 panic 提前退出，导致原本应该接收数据的协程消失。
另一个常见原因是循环等待：A goroutine 持有资源并等待 B goroutine 释放资源，而 B 也在等待 A。虽然 Go 的通道不完全等同于锁资源，但用通道传递权限或信号时同样会出现类似的相互等待。解决办法是明确资源的所有权，保证通道的一方只是发送方，另一方只是接收方，避免双向依赖。
还有一种隐蔽的情况是：向一个从未被关闭但也不会再产生数据的通道持续读取。消费者会一直阻塞，而生产者可能已经因为错误提前退出。遇到这种情况，除了依赖 context 取消外，还可以给生产者增加 defer 关闭通道的逻辑，或者让消费者在读取时同时监听关闭信号。最终，使用竞态检测器和合理的超时策略，能把大多数通道问题扼杀在开发阶段。