Go 互斥锁 Mutex：sync.Mutex、RWMutex、atomic 与 sync.Once

保护共享数据

sync.Mutex 同一时刻只允许一个 goroutine 进入 Lock 和 Unlock 之间的代码。把互斥锁放在它所保护的数据旁边，通常就放在同一个 struct 里：

package main

import (
	"fmt"
	"sync"
)

type Counter struct {
	mu     sync.Mutex
	counts map[string]int
}

func (c *Counter) Inc(key string) {
	c.mu.Lock()
	defer c.mu.Unlock()
	c.counts[key]++
}

func (c *Counter) Get(key string) int {
	c.mu.Lock()
	defer c.mu.Unlock()
	return c.counts[key]
}

func main() {
	c := Counter{counts: make(map[string]int)}

	var wg sync.WaitGroup
	for range 100 {
		wg.Add(1)
		go func() {
			defer wg.Done()
			for range 100 {
				c.Inc("hits")
			}
		}()
	}
	wg.Wait()

	fmt.Println("hits:", c.Get("hits"))
}

这段代码总是打印 hits: 10000。如果不加锁，100 个 goroutine 同时写同一个 map，程序通常会以 fatal error: concurrent map writes 崩溃。这个错误来自运行时的一项尽力而为的检查，它无法被 recover，而且程序没有崩溃也不能证明代码是正确的。

需要注意的细节：

• sync.Mutex 的零值就是未加锁、可直接使用的状态，不需要构造函数。
• 方法使用指针接收者（*Counter）。值接收者会锁住互斥锁的一个副本，什么也保护不了。
• 在 Lock 之后紧跟 defer c.mu.Unlock()，意味着每一条返回路径，以及发生 panic 时，都会释放锁。
• 每一次访问都要经过锁，读操作也不例外。在另一个 goroutine 写入时不加锁地读取，仍然是数据竞争。

让临界区尽量小

defer 会在函数结束时解锁。对于上面这样的短方法，这样做没问题。在较长的函数里，一旦不再访问共享数据就立即解锁，这样其他 goroutine 就不必等待那些根本不需要锁的工作：

func (s *Store) Save(key string) error {
	s.mu.Lock()
	data := s.items[key] // copy what you need
	s.mu.Unlock()

	return writeToDisk(key, data) // slow I/O, outside the lock
}

在持有锁的同时进行网络调用、磁盘 I/O 或向 channel 发送数据，是并发程序变慢最常见的原因，而在锁内向 channel 发送数据也是导致死锁的常见原因。

读多写少用 RWMutex

sync.RWMutex 有两种模式。RLock/RUnlock 获取共享读锁，多个 goroutine 可以同时持有。Lock/Unlock 获取独占写锁，它会一直等到所有读者离开。

package main

import (
	"fmt"
	"sync"
)

type Config struct {
	mu     sync.RWMutex
	values map[string]string
}

func (c *Config) Get(key string) (string, bool) {
	c.mu.RLock()
	defer c.mu.RUnlock()
	v, ok := c.values[key]
	return v, ok
}

func (c *Config) Set(key, value string) {
	c.mu.Lock()
	defer c.mu.Unlock()
	c.values[key] = value
}

func main() {
	cfg := &Config{values: map[string]string{"mode": "dev"}}

	var wg sync.WaitGroup
	for range 50 {
		wg.Add(1)
		go func() {
			defer wg.Done()
			cfg.Get("mode") // many readers at the same time
		}()
	}
	wg.Add(1)
	go func() {
		defer wg.Done()
		cfg.Set("mode", "prod") // one writer, exclusive
	}()
	wg.Wait()

	v, _ := cfg.Get("mode")
	fmt.Println("mode:", v)
}

当读操作占绝大多数，并且每次读都要在锁内做实际的工作时，RWMutex 才划算。对于像单次 map 查找这样极小的临界区，普通的 Mutex 往往一样快，因为读锁本身也有额外的簿记开销。选择之前先做基准测试。

读锁不能升级为写锁。在同一个 goroutine 中持有 RLock 时调用 Lock 会导致死锁。应先释放读锁，再获取写锁，然后重新检查条件，因为在这之间可能有别的写者已经修改了数据。

单个值用 sync/atomic

对于单个计数器或标志位，sync/atomic 比互斥锁更简单、开销更小。应该使用带类型的封装（Go 1.19）：

package main

import (
	"fmt"
	"sync"
	"sync/atomic"
)

func main() {
	var requests atomic.Int64
	var ready atomic.Bool

	var wg sync.WaitGroup
	for range 1000 {
		wg.Add(1)
		go func() {
			defer wg.Done()
			requests.Add(1)
		}()
	}
	wg.Wait()
	ready.Store(true)

	fmt.Println("requests:", requests.Load())
	fmt.Println("ready:", ready.Load())

	// CompareAndSwap: set only if the current value is what you expect.
	fmt.Println("swapped:", requests.CompareAndSwap(1000, 0), "now:", requests.Load())
}

原子操作一次只保护一个值。一旦有两个值必须一起改变（余额和交易次数，map 和它的大小），就要用互斥锁。两次独立的原子操作之间，可能穿插着其他 goroutine 的操作。

sync.Once

sync.Once 保证一个函数只执行一次，无论有多少个 goroutine 同时调用它。所有调用 Do 的 goroutine 都会等到第一次调用完成。这是实现延迟初始化的标准方式：

package main

import (
	"fmt"
	"sync"
)

var (
	once   sync.Once
	config map[string]string
)

func loadConfig() map[string]string {
	once.Do(func() {
		fmt.Println("loading config (runs once)")
		config = map[string]string{"env": "prod"}
	})
	return config
}

// Go 1.21: OnceValue wraps a function and caches its result.
var port = sync.OnceValue(func() int {
	fmt.Println("computing port (runs once)")
	return 8080
})

func main() {
	var wg sync.WaitGroup
	for range 5 {
		wg.Add(1)
		go func() {
			defer wg.Done()
			_ = loadConfig()
			_ = port()
		}()
	}
	wg.Wait()
	fmt.Println(loadConfig()["env"], port())
}

每一行 "runs once" 都只出现一次。如果传给 Do 的函数发生 panic，Once 仍会认为它已经执行过，不会再重试。sync.OnceValues 对返回两个值的函数做同样的事，通常是一个值和一个 error。

Mutex、channel 还是 sync.Map

sync.Map 并不能通用地替代加锁的 map。它没有类型参数，所以取出的值都是 any，而且只在表中这两种情况下才更快。先从互斥锁加普通 map 开始。

常见错误

• 复制互斥锁。 按值传递一个包含 sync.Mutex 的 struct，或使用值接收者，都会复制这把锁。go vet 会报告 passes lock by value 或 copies lock value。
• 在同一个 goroutine 中加锁两次。 Go 的互斥锁不可重入。如果 Inc 调用了 Get，而两者都要加锁，Inc 就会永远阻塞。让公开方法负责加锁，私有辅助函数假定锁已被持有。
• 提前返回时忘记解锁。 除非有理由不这么做，否则就用 defer。
• 以不同的顺序加锁。 如果一个 goroutine 先拿锁 A 再拿锁 B，而另一个先拿 B 再拿 A，两者可能永远互相等待。获取多把锁时，始终按同样的顺序。
• 暴露受保护的数据。 从方法里返回内部的 map，调用方就能不加锁地读写它。应返回一份副本（maps.Clone，Go 1.21）或单个值。
• 只保护写操作。 不加锁的读与加锁的写并发执行，仍然是竞争。用 go test -race 运行你的测试。