Go语言中除Channels外goroutine间有哪些其他通信方式？

Go 设计上虽然推崇「通过通信共享内存」的 Channel 用法，但完全存在多类成熟的 Goroutine 消息收发替代方案，覆盖不同场景需求，具体实现和原理如下：

1. sync 同步原语配合共享内存 #

这是最通用的替代方案，本质是回归传统并发模型的「通过共享内存通信」思路，用 sync 包提供的同步原语解决共享变量的并发竞态问题：

• 互斥锁 sync.Mutex/sync.RWMutex：底层依赖原子操作标记内存访问权限，同一时刻仅允许持有锁的 Goroutine 操作共享内存区域（全局变量、结构体字段、共享切片/Map 都可以作为消息载体）。发送方加锁后写入消息再解锁，接收方加锁后读取消息即可完成收发，示例代码：

var (
    lock sync.Mutex
    data string // 作为消息载体的共享变量
)
// 发送方Goroutine
go func() {
    lock.Lock()
    data = "message from sender"
    lock.Unlock()
}()

// 接收方Goroutine
go func() {
    lock.Lock()
    defer lock.Unlock()
    fmt.Println(data) // 读取到发送方写入的消息
}()

• 等待组 sync.WaitGroup：内部维护一个原子计数器，发送方完成消息写入后调用 Done() 扣减计数，接收方通过 Wait() 阻塞直到计数器归零后再读取共享内存内容，适合一次性的任务完成类通知场景。
• 条件变量 sync.Cond：基于互斥锁实现，内部维护阻塞等待的 Goroutine 队列。发送方写入消息后调用 Signal()/Broadcast() 唤醒等待的接收方，接收方被唤醒后直接读取消息，省去了循环轮询加锁的CPU开销，适合多生产者多消费者的消息流场景。

2. sync/atomic 原子操作 #

底层直接调用CPU提供的原子指令（X86 架构下为 XCHG、CMPXCHG 等），不需要加锁就能保证基础类型变量操作的原子性和跨 Goroutine 内存可见性，性能远高于互斥锁，适合传递简单的状态类消息：

• 基础类型原子读写：可以直接对 int32/int64/uintptr 类型的共享变量做原子Load/Store，传递停止信号、状态标记这类简单消息，示例：

var stopFlag int32
// 工作Goroutine（接收停止信号）
go func() {
    for atomic.LoadInt32(&stopFlag) == 0 {
        // 执行业务逻辑
    }
    fmt.Println("received stop message, exit")
}()
// 控制Goroutine（发送停止信号）
atomic.StoreInt32(&stopFlag, 1)

• atomic.Value：支持原子读写任意Go类型值，不需要做unsafe指针转换，就可以传递结构体、切片等复杂类型的消息，适用范围更广。

3. 操作系统IPC能力 #

可以直接借助操作系统提供的进程内/跨进程通信能力传递消息，不依赖Go runtime的Channel实现：

• 本地套接字/网络套接字：Goroutine分别持有套接字的读写端，发送方将消息序列化为字节流写入套接字，接收方读取字节流反序列化得到消息，这类方案支持跨进程通信，只是序列化、系统调用的开销比内存级方案高。
• os.Pipe 管道：内核维护的内存字节缓冲区，返回一对绑定的读写文件句柄，Goroutine分别持有读写端即可传递字节流消息，行为和Channel非常接近，只是底层完全通过系统调用实现。

4. 标准库并发安全容器 #

• sync.Map：官方实现的并发安全Map，内部通过读写分离、原子操作、锁优化降低竞态开销，多个Goroutine可以直接调用 Store() 写入消息、Load() 读取消息，适合键值对形式的消息路由场景。

注意：所有基于共享内存的通信方案都必须严格校验同步逻辑，否则会出现难以排查的数据竞争问题，开发阶段可以用 go run -race 指令自动检测竞态。

内容的提问来源于stack exchange，提问作者satish kumar rayavarapu