Go 竞态修复后吞吐下降如何确认是锁竞争

竞态修复后吞吐反而下降，先别急着把锅甩给 Go 的锁实现。最可靠的判断是：用同一组压测条件采集 mutex profile，再用 block profile 和 CPU profile 对照。如果 mutex profile 的主要样本集中在新加保护的临界区，且缩小这段临界区后吞吐恢复，才可以把“锁竞争”当作主要原因。

先确认吞吐下降确实来自同一组负载

竞态修复前后的 benchmark 必须固定输入数据、并发数、请求比例、GOMAXPROCS、预热时间和采样时长。尤其要避免一次使用缓存命中、一次使用随机数据；也不要只比较某一秒的峰值。建议至少跑多轮，记录每轮吞吐、延迟和 CPU 使用率。

如果吞吐下降但 CPU 从 80% 降到 35%，同步等待值得优先调查；如果 CPU 仍接近满载，锁只是可能因素，还要看新代码是否增加了复制、序列化或分配。这个判断只是筛选方向，不能替代 profile。

打开 mutex profile，先拿到可比较的样本

测试场景可以直接用 Go 的 profiling flag：

go test -run '^$' -bench 'BenchmarkServe' -benchtime=30s \
  -mutexprofile=mutex.prof -mutexprofilefraction=1
# -run '^$' 不跑普通测试，只保留 benchmark 场景
# -mutexprofile 写出互斥锁竞争 profile
# fraction=1 便于短压测先收集完整样本，长时间生产采样应评估开销

-mutexprofilefraction n 表示大约采样每 n 个持有竞争互斥锁的栈；1 适合短实验，不能把它当成生产默认值。服务进程则需要在采集前调用 runtime.SetMutexProfileFraction，并通过受保护的 net/http/pprof 端点取 profile。

import "runtime"

func enableMutexProfile() func() {
	// 保存旧采样率，实验结束后恢复，避免长期增加运行成本。
	old := runtime.SetMutexProfileFraction(1)
	return func() {
		// 恢复调用方原来的 profiling 设置。
		runtime.SetMutexProfileFraction(old)
	}
}

pprof 里要看的是竞争归属，不是只看 Lock 一行

拿到 profile 后，先看累计等待成本最高的节点：

go tool pprof -top mutex.prof
go tool pprof -list '(*Counter).Add' mutex.prof
# -top 先找累计 contention 高的调用栈
# -list 回到具体函数，检查临界区是否在修复后变长
# profile 名称和函数名按项目实际路径替换

Go 官方对 mutex profile 的定义很关键：它跟踪互斥锁竞争，栈通常对应“造成竞争的临界区结束处”，常见表现是 Unlock 附近。样本值是其他 goroutine 等待该锁的累计时间近似值。因此看到 Counter.Add 的退出路径很高，含义可能是它持锁期间做了更多工作，不是 Unlock 本身变慢。

用 block profile 和复测把“相关”变成“可确认”

mutex profile 只能说明采样到互斥锁竞争，不能单独证明它导致了吞吐下降。若怀疑还有通道或条件同步，开启 block profile 后比较：

go test -run '^$' -bench 'BenchmarkServe' -benchtime=30s \
  -mutexprofile=mutex.prof -mutexprofilefraction=1 \
  -blockprofile=block.prof -blockprofilerate=1
# 两类 profile 使用同一 benchmark 条件，便于横向比较
# block profile 还会覆盖 channel、WaitGroup、Cond 等同步阻塞

最后做一次最小改动实验：只把锁内的格式化、复制、回调或 I/O 移到锁外，仍保留共享字段的读写保护。若吞吐提高、mutex 热点下降，而结果一致性没有回归，因果链才比较完整。不能为了让 profile 变好而直接删锁；竞态检测通过也不代表锁的业务边界正确。

常见问题

mutex profile 为什么默认看不到内容？

它默认未开启，需要设置 runtime.SetMutexProfileFraction，或在测试中使用 -mutexprofilefraction。

看见 Unlock 热点是不是 Unlock 太慢？

通常不是。它更常表示该临界区结束时记录了等待者的累计竞争成本，应回看整个持锁区。

mutex profile 和 block profile 该选哪个？

怀疑互斥锁时先看 mutex；若同步类型不确定，两个 profile 用相同负载一起采集，再结合 CPU profile 判断。

真正有效的结论应同时满足三点：基线可比、profile 热点落在新增保护范围、缩小临界区后复测改善。缺少最后一步时，最多只能说“发现了竞争”，还不能说“已经确认它是吞吐下降的主因”。