在 Go 并发编程里，锁竞争是吞吐量下降的主要原因之一。sync.Mutex 的底层实现已经足够高效，但真正的问题往往不在锁本身，而在使用方式：临界区太长、锁粒度太粗、读写不区分、共享数据设计不合理。想减少锁竞争，不能只盯着一行加锁代码，需要从数据结构和访问模式入手。下面按常见优化路径展开，每类方案都给出可直接运行的示例。
先明确一个概念：锁竞争不是锁被持有时间长就一定会发生，而是多个 goroutine 在同一时间窗口内试图获取同一把锁。一旦竞争出现，操作系统会挂起等待者，产生上下文切换，CPU 高速缓存中的行也可能频繁失效。因此优化的核心只有两条：降低锁被同时请求的概率，或者减少锁持有的时间。
一、先定位锁竞争从哪来
竞争出现时，最先要观察的是临界区里到底放了什么。一个典型的错误是加锁后执行与共享变量无关的操作，例如打印日志、解析 JSON、发起网络调用。这些操作会让锁的持有时间从纳秒级膨胀到毫秒级，等待的 goroutine 数量迅速上升。
下面是一个最基础的互斥锁计数器，它本身没有大问题，但如果把耗时操作放进 Inc 方法，就会放大竞争。
type Counter struct {
mu sync.Mutex
n int64
}
func (c *Counter) Inc() {
c.mu.Lock()
defer c.mu.Unlock()
c.n++
}
func (c *Counter) Value() int64 {
c.mu.Lock()
defer c.mu.Unlock()
return c.n
}
这个例子中锁的持有时间极短，即便并发量较高，竞争开销也相对可控。但如果改成下面这样，就不是锁本身的问题，而是临界区设计的问题。
func (c *Counter) Inc() {
time.Sleep(time.Millisecond) // 模拟耗时操作
c.mu.Lock()
defer c.mu.Unlock()
c.n++
}
耗时操作和锁是串行关系，多个 goroutine 同时进入后只能排队。正确的做法是先在锁外完成耗时计算，只在最后更新共享变量时加锁。定位竞争来源，实际上就是在审查每一段锁内代码是否真的需要被保护。
二、缩小临界区与分片锁
缩小临界区是最直接的优化。如果共享变量只是一个整数，锁内只保留一次自增即可；如果共享变量是一个 map，锁内不要遍历整个 map，除非遍历结果本身需要一致性快照。可以把复杂计算移出锁外，再用局部变量保存结果，最后一次性写回。
当单个锁保护的资源量太大时，分片锁能显著降低竞争概率。分片锁的思路是把一个大资源拆成多个独立的小资源，每个小资源有自己独立的锁。以 map 为例，可以按 key 的哈希值路由到不同分片。这样两个 goroutine 操作不同的 key 时，大多数情况下不会争抢同一把锁。
const shardCount = 32
type ShardMap struct {
shards [shardCount]mapShard
}
type mapShard struct {
mu sync.Mutex
m map[string]int
}
func NewShardMap() *ShardMap {
sm := &ShardMap{}
for i := 0; i < shardCount; i++ {
sm.shards[i].m = make(map[string]int)
}
return sm
}
func (sm *ShardMap) Get(key string) (int, bool) {
idx := fnv32(key) % shardCount
shard := &sm.shards[idx]
shard.mu.Lock()
defer shard.mu.Unlock()
v, ok := shard.m[key]
return v, ok
}
func fnv32(key string) uint32 {
hash := uint32(2166136261)
for i := 0; i < len(key); i++ {
hash *= 16777619
hash ^= uint32(key[i])
}
return hash
}
分片数量不是越多越好。分片过多会占用更多内存，也会增加缓存行冲突的可能；分片太少则竞争仍然集中。一般可以按 CPU 核心数的 4 倍左右起步，再通过基准测试调整。另外要注意，如果业务中经常需要遍历全部 key，分片锁并不会减少跨分片遍历的成本，反而需要在每个分片上加锁，优化效果可能不明显。
三、用读写锁和原子操作替换互斥锁
如果共享数据读多写少，sync.RWMutex 是比 sync.Mutex 更合适的选择。读锁之间可以并行，只有写锁才互斥。缓存、配置中心、字典查询这类场景通常都满足读多写少的条件。
type Config struct {
mu sync.RWMutex
m map[string]string
}
func (c *Config) Get(key string) string {
c.mu.RLock()
defer c.mu.RUnlock()
return c.m[key]
}
func (c *Config) Set(key, value string) {
c.mu.Lock()
defer c.mu.Unlock()
c.m[key] = value
}
读写锁并非银弹。写操作频繁时，RWMutex 的写锁会持续等待所有读锁释放，读操作也可能被不断到期的写锁阻塞，整体吞吐未必好于普通互斥锁。更麻烦的是，如果代码里出现递归调用 Lock，就会死锁。选择读写锁前，最好用压测确认读写比例。
对于单个数值型变量，sync/atomic 包提供的原子操作可以在不加锁的情况下完成读写。原子操作直接利用 CPU 指令保证原子性，避免了上下文切换。
type AtomicCounter struct {
n int64
}
func (c *AtomicCounter) Inc() {
atomic.AddInt64(&c.n, 1)
}
func (c *AtomicCounter) Value() int64 {
return atomic.LoadInt64(&c.n)
}
原子操作的局限也很明显：只能保护单个变量，无法保护多个变量之间的不变关系。比如账户转账需要同时修改余额和流水，这时用多个原子操作无法保证一致性，仍然需要锁或事务。另外，atomic.Value 可以存任意类型的快照，但要求每次写入的值类型一致，适合配置热更新这种读多写少场景。
四、使用 sync.Map 与 channel 分流
sync.Map 是 Go 标准库提供的并发安全 map，内部用读写分离和原子操作减少竞争。它适合两类场景：一是 key 只会被写入一次但会被多次读取；二是不同 goroutine 操作的 key 集合基本不重叠。如果写入非常频繁，或者需要遍历整个 map，sync.Map 的性能不一定比普通 map 加锁更好。
var sm sync.Map
func Store(k, v interface{}) {
sm.Store(k, v)
}
func Load(k interface{}) (interface{}, bool) {
return sm.Load(k)
}
channel 是另一种思路。它不直接减少锁竞争，而是把共享状态的所有修改都交给一个专属 goroutine 串行处理，其他 goroutine 只通过 channel 发送更新请求。这种方式把“锁”换成了“消息队列”，适合状态变更不频繁但需要严格一致性的场景。
type State struct {
value int
}
var updates = make(chan func(*State))
func Update(fn func(*State)) {
updates <- fn
}
func manager() {
state := &State{}
for fn := range updates {
fn(state)
}
}
channel 方案要小心背压。如果生产者速度超过管理 goroutine 的处理速度，channel 缓冲区会满，生产者会阻塞。这个阻塞本质上也是一种“锁竞争”的变形。因此要确保状态变更逻辑足够轻量，或者为 channel 配置合理的缓冲和丢弃策略。
五、测量与常见反模式
优化锁竞争最忌讳凭感觉改代码。Go 提供了 mutex profile，可以统计哪些互斥锁的等待时间最长。在程序启动时调用 runtime.SetMutexProfileFraction(1)，之后通过 go tool pprof 就能看到锁竞争的热点。
import _ "net/http/pprof"
func init() {
runtime.SetMutexProfileFraction(1)
}
除了 profile，基准测试也很重要。可以分别对 Mutex、RWMutex 和 atomic 版本做并发基准，观察不同核心数下的 ns/op 和分配次数。不要只看单次运行时间，要结合 CPU 利用率判断竞争是否真的下降。
func BenchmarkMutex(b *testing.B) {
c := &Counter{}
b.RunParallel(func(pb *testing.PB) {
for pb.Next() {
c.Inc()
}
})
}
常见反模式包括：锁内做 I/O 或系统调用、用 defer 解锁时在循环内加锁导致临界区膨胀、复制包含 Mutex 的结构体、在持有读锁时执行写操作、以及无视读写比例而一律使用 RWMutex。另一个隐蔽的问题是伪共享：多个分片锁放在同一个缓存行里，不同 goroutine 修改相邻字段也会触发缓存行失效。Go 里可以通过 padding 字段把热点锁隔开，但多数业务场景不一定需要这么底层。
减少锁竞争是一个从数据结构到访问模式的综合工程。先测量、找热点，再选择缩小临界区、分片、读写分离、原子操作或 channel 分流中的一种或多种组合，通常能获得比单纯换锁更明显的收益。