源码

你以为 sync.Map 无锁？它的锁藏在三个地方

这套对话，我在 code review 里见过很多次。

A 说：这个 map 读多写少，并发安全得处理一下。 B 说：那把 map + RWMutex 换成 sync.Map 吧，无锁的，更快。

第一句不完全错，第二句基本错了。 …

读多写少就用 sync.Map？先问这 5 个问题

线上有一张设备状态表，用 sync.Map 存着。

读很多，写很少。平时接口很稳，一到定时刷新那几秒，读 p99 就会抖一下。你看代码，第一反应可能不是怀疑 sync.Map，而是怀疑刷新逻辑：是不是批量太大？是不是网络抖了？是不是 GC …

线上锁竞争别急着换 RWMutex：Go 同步原语背后的三笔账

接口 p99 突然抖起来，pprof 里 mutex wait 很显眼。

会议上最容易出现的三个动作是：锁太粗，换成 RWMutex；分配太多，把 buffer 放进 sync.Pool；再不行，把临界区附近的代码拆一拆。

听起来都像优化。 …

context.WithValue 不是 map，是一条链

函数签名很干净，代码却越来越难查。

你打开一个 Go 函数，只看到一个 ctx context.Context。再往里翻，发现 user id 从 ctx.Value 里取，tenant 从 ctx.Value 里取，trace id 从 …

Go context 最容易被误用的地方：以为 cancel 会替你收拾现场

线上接口开始超时，goroutine 数一路往上涨。

你第一反应可能是：不是已经传了 context.WithTimeout 吗？超时到了，goroutine 不就该停了吗？

这就是 Go context 最容易被误用的地方。 …