Golang使用sync.Cond实现条件变量通知

Golang中sync.Cond需与sync.Mutex结合使用，因Cond仅负责通知，而Mutex保护共享状态。Wait()在条件不满足时释放锁并挂起，被唤醒后重新获取锁，确保安全检查条件。典型应用场景如生产者-消费者模型，通过Signal()唤醒一个等待者或Broadcast()唤醒所有等待者。常见陷阱包括未在循环中检查条件导致虚假唤醒问题，最佳实践是始终用for循环检查条件、封装Cond与锁、按需选择Signal或Broadcast，避免竞态和性能损耗。

Golang中的

sync.Cond

sync.Mutex

解决方案

要使用

sync.Cond

sync.Mutex

sync.RWMutex

Cond.Wait()

Wait()

Signal()

Broadcast()

Cond.Signal()

Cond.Broadcast()

一个典型的例子是实现一个有限容量的缓冲区：

package main

import (
    "fmt"
    "sync"
    "time"
)

// Buffer 是一个简单的有限容量缓冲区
type Buffer struct {
    mu       sync.Mutex
    cond     *sync.Cond
    items    []int
    capacity int
}

// NewBuffer 创建一个新的缓冲区
func NewBuffer(capacity int) *Buffer {
    b := &Buffer{
        items:    make([]int, 0, capacity),
        capacity: capacity,
    }
    b.cond = sync.NewCond(&b.mu) // 将互斥锁传递给条件变量
    return b
}

// Put 将一个元素放入缓冲区
func (b *Buffer) Put(item int) {
    b.cond.L.Lock() // 获取互斥锁保护共享状态
    defer b.cond.L.Unlock()

    // 如果缓冲区满了，就等待
    for len(b.items) == b.capacity {
        fmt.Printf("生产者 %d: 缓冲区已满，等待...\n", item)
        b.cond.Wait() // 释放锁并等待，被唤醒后重新获取锁
    }

    b.items = append(b.items, item)
    fmt.Printf("生产者 %d: 放入 %d，当前缓冲区: %v\n", item, item, b.items)
    b.cond.Signal() // 通知一个等待的消费者
}

// Get 从缓冲区取出一个元素
func (b *Buffer) Get() int {
    b.cond.L.Lock() // 获取互斥锁保护共享状态
    defer b.cond.L.Unlock()

    // 如果缓冲区为空，就等待
    for len(b.items) == 0 {
        fmt.Println("消费者: 缓冲区为空，等待...")
        b.cond.Wait() // 释放锁并等待，被唤醒后重新获取锁
    }

    item := b.items[0]
    b.items = b.items[1:]
    fmt.Printf("消费者: 取出 %d，当前缓冲区: %v\n", item, b.items)
    b.cond.Signal() // 通知一个等待的生产者（如果有的话）
    return item
}

func main() {
    buf := NewBuffer(3) // 容量为3的缓冲区

    // 启动多个生产者
    for i := 0; i < 5; i++ {
        go func(id int) {
            time.Sleep(time.Duration(id) * 100 * time.Millisecond) // 错开生产时间
            buf.Put(id)
        }(i)
    }

    // 启动多个消费者
    for i := 0; i < 5; i++ {
        go func() {
            time.Sleep(50 * time.Millisecond) // 消费者稍微晚点启动
            buf.Get()
        }()
    }

    // 等待一段时间，观察输出
    time.Sleep(2 * time.Second)
    fmt.Println("主程序退出。")
}

在这个例子中，

Put

Get

Signal()

立即学习“go语言免费学习笔记（深入）”；

为什么Golang的sync.Cond需要与sync.Mutex结合使用？

这是个非常核心的问题，我刚开始接触

sync.Cond

sync.Cond

sync.Mutex

sync.Cond

Wait()

sync.Cond

Wait()

1. 解锁互斥锁并挂起goroutine。 这允许其他goroutine获取锁并修改共享状态。
2. 当被唤醒时，重新获取互斥锁。 这确保了被唤醒的goroutine在检查条件时，能够在一个受保护的环境下进行，避免了在检查条件和被唤醒之间，共享状态再次被修改而导致不一致。

所以，

sync.Mutex

sync.Cond

Golang中sync.Cond.Signal()与sync.Cond.Broadcast()有什么区别，何时选用？

sync.Cond

Signal()

Broadcast()

• Cond.Signal()

  登录后复制
  : 这个方法只会唤醒至多一个正在等待的goroutine。如果当前有多个goroutine在

  Cond.Wait()

  登录后复制
  上等待，

  Signal()

  登录后复制
  会选择其中一个（具体是哪一个通常是随机的，或由调度器决定）将其唤醒。
  • 何时选用？ 当你的场景中，只需要一个等待者来处理事件时，

    Signal()

    登录后复制
    是更高效的选择。例如，在一个任务队列中，当有新任务到来时，你只需要唤醒一个空闲的工作goroutine来处理它，而不是所有工作goroutine。如果唤醒了多个，它们可能会“争抢”同一个任务，导致额外的开销，甚至可能出现“惊群效应”（thundering herd problem），即所有goroutine都被唤醒，然后大部分发现条件仍然不满足，又重新进入等待状态。

• Cond.Broadcast()

  登录后复制
  : 这个方法会唤醒所有正在等待的goroutine。
  • 何时选用？ 当你的条件变化需要所有等待者都做出响应时，

    Broadcast()

    登录后复制
    是必需的。例如，一个全局配置更新的通知，或者一个程序即将关闭的信号，所有依赖这些条件的goroutine都需要被告知并采取相应行动。

我的经验是，在不确定的时候，很多人会倾向于使用

Broadcast()

Signal()

使用Golang sync.Cond时常见的陷阱与最佳实践是什么？

在使用

sync.Cond

知我AI

一款多端AI知识助理，通过一键生成播客/视频/文档/网页文章摘要、思维导图，提高个人知识获取效率；自动存储知识，通过与知识库聊天，提高知识利用效率。

26

查看详情

常见陷阱：

1. 未在循环中检查条件： 这是最常见的错误之一。

   Wait()

   登录后复制
   被唤醒并不意味着条件就一定满足了。可能存在“虚假唤醒”（spurious wakeups），或者在

   Signal()

   登录后复制
   发出到你的goroutine重新获得锁并检查条件之间，条件又被其他goroutine改变了。
   • 错误示例：

     if !condition { cond.Wait() }

     登录后复制
   • 正确做法： 始终在

     for

     登录后复制
     循环中检查条件：

     for !condition { cond.Wait() }

     登录后复制
     。这样即使被虚假唤醒或条件再次不满足，goroutine也会再次进入等待。

2. 在不持有互斥锁的情况下调用

   Wait()

   登录后复制
   ：

   Cond.Wait()

   登录后复制
   要求在调用时必须持有

   cond.L

   登录后复制
   关联的互斥锁。如果你没有持有锁就调用，程序会panic。这是因为

   Wait()

   登录后复制
   需要原子性地解锁和挂起，没有锁，这个原子操作就无法完成。

3. 在不持有互斥锁的情况下修改条件变量所依赖的共享状态：

   sync.Cond

   登录后复制
   只负责通知，不负责数据保护。任何对共享状态的读写，都必须在持有

   cond.L

   登录后复制
   互斥锁的情况下进行，否则会引入数据竞争。

4. 在不持有互斥锁的情况下调用

   Signal()

   登录后复制
   或

   Broadcast()

   登录后复制
   ： 尽管Go语言允许你在不持有互斥锁的情况下调用

   Signal()

   登录后复制
   或

   Broadcast()

   登录后复制
   ，但这通常不是一个好习惯。如果条件改变了，但你没有持有锁就发出了信号，那么在信号发出之后、互斥锁被释放之前，可能有另一个goroutine恰好检查条件发现不满足并进入等待。这样它就错过了信号，可能导致死锁。最佳实践是，在修改了共享状态并准备通知时，始终持有互斥锁，然后发出信号，最后释放互斥锁。

最佳实践：

1. 始终在

   for

   登录后复制
   循环中检查条件： 这一点再怎么强调都不为过。这是保证程序正确性的基石。

2. 明确条件变量的职责：

   sync.Cond

   登录后复制
   是用来等待一个布尔条件的。如果你的等待逻辑非常复杂，涉及到多个变量、复杂的逻辑判断，或者需要超时、取消等高级功能，那么可能需要考虑使用

   context.Context

   登录后复制
   结合channel，或者更高级的并发原语。

   sync.Cond

   登录后复制
   是低层级的原语，简单而强大，但不是万能的。

3. 理解

   Signal()

   登录后复制
   与

   Broadcast()

   登录后复制
   的性能差异： 如前所述，根据实际需求选择合适的唤醒方式。避免不必要的

   Broadcast()

   登录后复制
   ，以减少潜在的“惊群效应”和上下文切换开销。

4. 将条件变量及其关联的互斥锁封装起来： 就像我上面提供的

   Buffer

   登录后复制
   结构体一样，将

   sync.Mutex

   登录后复制
   和

   sync.Cond

   登录后复制
   以及它们保护的共享状态封装在一个结构体中，并通过方法来暴露操作，这能极大地提高代码的可读性、可维护性和安全性，避免外部直接操作导致错误。

5. 考虑超时和取消：

   sync.Cond.Wait()

   登录后复制
   本身没有超时或取消机制。在需要这些功能的场景下，你可能需要结合

   select

   登录后复制
   语句和

   time.After

   登录后复制
   或者

   context.WithTimeout

   登录后复制
   来构建更健壮的等待逻辑。例如，一个goroutine可以在等待

   Cond

   登录后复制
   的同时，监听一个超时channel或

   context.Done()

   登录后复制
   channel。

总之，

sync.Cond

以上就是Golang使用sync.Cond实现条件变量通知的详细内容，更多请关注php中文网其它相关文章！