Golang 中 sync.Map 的 read 与 dirty 转换机制-Golang-PHP中文网

sync.Map 的 read 是 atomic.Pointer[readOnly]，指向含 map[any]entry 和 amended 布尔值的不可变结构；dirty 是受 mu 保护的普通 map[any]entry；两者均存 *entry，其 p 字段为 atomic.Pointer，状态包括 nil（逻辑删除）、expunged（已从 dirty 物理移除）和有效指针（可用值）。

sync.Map 的 read 和 dirty 是什么结构？

read 是 atomic.pointer[readonly]，指向一个不可变的 readonly 结构体，里面是 map[any]*entry 和一个 amended 布尔标记；dirty 是普通 map[any]*entry，受 mu sync.mutex 保护。两者都存 *entry，而 entry.p 是 atomic.pointer[any]，状态有三种：nil（逻辑删除）、expunged（已从 dirty 物理移除）、有效指针（可用值）。

dirty 什么时候被复制到 read？

不是每次写就同步，而是靠 misses 计数器触发：每次 Load 在 read.m 找不到 key、转去查 dirty 时，misses++；当 misses >= len(dirty)，就执行全量提升——把当前 dirty 拷贝为新的 readOnly.m，清空 dirty，重置 misses = 0，并设 read.amended = false。

这个阈值设计很实际：

太小（比如固定为 1）→ 频繁拷贝，dirty 刚写几条就升，失去缓冲意义，反而放大锁竞争
太大（比如设成 10000）→ read 长期 stale，大量 Load 被迫进锁查 dirty，读性能断崖下跌
Go 当前硬编码用 len(dirty)，不暴露调节接口，你没法改

Store 新 key 为什么有时慢得离谱？

Store 写新 key 一定走 dirty，但具体路径取决于 amended 状态：

Alibabacloud Sdk Client Initialization For Golang

初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。

下载

若 amended == false（即 dirty 已空或刚被提升过），必须先加 mu 锁，再把整个 read.m 复制进 dirty，再插入新 key —— 这是 O(N) 操作，N 是当前 read 中有效 key 数
若 amended == true，可直接写入 dirty，但后续第一次 Load 该 key 仍需加锁查 dirty，直到下次提升才进 read
对比 sync.RWMutex + map：Store 就是简单写锁 + 插入，开销稳定；而 sync.Map Store 新 key 平均比它慢 2–3 倍

Load 真的无锁吗？哪些情况会 fallback 加锁？

Load 只在「key 存在于 read.m 且 entry.p 是有效指针」时真正无锁；其余情况都会 fallback 到加锁路径：

key 不在 read.m 里 → 查 dirty，需加 mu 锁
key 在 read.m 里但 entry.p == expunged → 表示该 entry 已被物理删出 dirty，Load 返回 false，不加锁
key 在 read.m 里但 entry.p == nil（被 Delete 过）→ Load 返回 false，也不加锁
但注意：如果 key 同时存在于 read（标为 nil）和 dirty（还存着），Load 会先读 read 得 false，再加锁查 dirty 得真实值 —— 这时候就加锁了