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.MapStore 新 key 平均比它慢 2–3 倍
Load 真的无锁吗？哪些情况会 fallback 加锁？
Load 只在「key 存在于 read.m 且 entry.p 是有效指针」时真正无锁；其余情况都会 fallback 到加锁路径：
立即学习“go语言免费学习笔记（深入）”；
- 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得真实值 —— 这时候就加锁了
所以“无锁读”是有前提的，不是所有 Load 都免锁；高 miss 率或频繁 Delete 后又 Load，很容易让性能掉回加锁水平。
