go 编译器不会自动做锁消除，gc 不支持锁消除和锁粗化，同步语义由程序员确定；锁操作严格按代码执行，无运行时优化。
Go 编译器会不会自动做锁消除？
不会。Go 的编译器（gc）目前不支持锁消除（lock elision），也不做锁粗化（lock coarsening）。这是和 JVM 完全不同的设计选择——Go 把同步语义的确定性交给程序员，而不是运行时或编译器去猜。
你写一个 sync.Mutex，它就真加锁；你在循环里反复 mu.Lock()/mu.Unlock()，它就真锁 N 次。没有“这段代码没共享写，我帮你省了”的优化。
- Go 1.22 仍无锁消除支持，官方 issue（如 golang/go#56407）明确标记为 “Unlikely”
- 所谓“逃逸分析后发现变量未逃逸，所以锁可省”是常见误解：逃逸分析管内存分配，不管同步行为
- 如果你依赖“编译器会优化掉无竞争锁”，那上线后高并发一压，
mutex contention就会直接打脸
什么时候该手动合并临界区？
当你在同一个 goroutine 中、对同一把锁反复加解锁，且中间操作不依赖外部状态（比如不调用可能阻塞或调度的函数），就可以考虑合并——这不是为了“让编译器高兴”，而是减少系统调用开销和调度干扰。
典型场景：遍历 slice 做纯内存更新，或批量写入 map。
立即学习“go语言免费学习笔记（深入）”；
- ✅ 安全合并：
for i := range data { mu.Lock(); m[i] = i*2; mu.Unlock() }→ 改成mu.Lock(); for i := range data { m[i] = i*2 }; mu.Unlock() - ❌ 危险合并：循环里调用了
http.Get、time.Sleep、甚至fmt.Println（可能触发写锁）——这些会让 goroutine 让出时间片，延长临界区，放大锁竞争 - ⚠️ 注意
range本身不阻塞，但若被 range 的对象是 channel 或带方法的自定义类型，需确认其Next()是否含同步逻辑
用 sync.RWMutex 替代 sync.Mutex 真能提速？
只在读多写少、且读操作确实能并行时才有效。否则反而因额外字段和路径分支拖慢性能。
关键不是“用了 RWMutex 就更快”，而是“读操作是否真的可以并发执行而不互相干扰”。
- 读操作含写：比如
map的len()是 O(1)，但如果你在RWMutex.RLock()下调用json.Marshal(m)，而m正在被其他 goroutine 修改，那就不是安全读——RWMutex 不防数据竞争，只防你乱加锁 - 写操作频繁：哪怕每秒只有 1 次写，只要读请求量大，
RWMutex的写饥饿问题（Linux futex 实现下尤其明显）会让平均延迟飙升 - 实测建议：用
go test -bench=. -benchmem -count=5对比，别凭感觉。有时sync.Mutex在低争用下比RWMutex快 10%+
哪些看似“无害”的操作会意外延长临界区？
临界区长度不取决于代码行数，而取决于执行时间。很多标准库调用表面轻量，实际可能隐式调度或系统调用。
-
log.Printf：默认输出到os.Stderr，底层是带锁的file.write，一旦 stderr 被重定向到管道或文件，就可能阻塞 -
fmt.Sprintf：通常安全，但若格式串含%v且参数是大 struct 或嵌套 map，GC 扫描和内存分配会拉长时间 -
time.Now()：在大多数 Linux 上是 vDSO 调用，很快；但在容器中若内核未启用 vDSO，就会退化为真实系统调用 - 最隐蔽的是：在临界区内启动新 goroutine，比如
go doWork()—— 这本身不阻塞，但若doWork里又去抢同一把锁，就制造了间接竞争
真正难调的性能毛刺，往往来自这些“我以为它很快”的调用混在锁里。与其猜，不如用 pprof 看 sync.Mutex.Lock 的调用栈，再顺藤摸瓜。
