dirty 提升为 read 的触发条件是 misses >= len(dirty)，该阈值由 go 运行时硬编码，非经验值；每次 load 未命中 read 时 misses 加 1，满足条件后在下一个加锁写操作中执行提升：赋值 dirty 给 read、清空 dirty、重置 misses 为 0、设 amended = false。
dirty 提升为 read 的触发条件是 misses >= len(dirty)
这个等式不是经验值，而是 go 运行时硬编码的阈值逻辑。每次 load 在 read.m 中未命中、转而查 dirty 时，misses 就加 1；一旦满足 misses >= len(dirty)，下一次加锁写操作（比如 store 或 delete）就会触发提升：把整个 dirty 赋给新的 readonly，清空 dirty，重置 misses = 0，并设 read.amended = false。
- 这个提升动作是 O(N) 的，N 是当前
dirty的键数量 - 它不发生在
Load过程中，而是在后续首个需要加锁的写操作里完成（避免读路径阻塞） -
dirty为空时（如刚提升完），首次写会先拷贝read.m中所有未被expunged的 entry 到新dirty，这步也是 O(N)
为什么 len(dirty) 是临界点？它平衡了什么
这个设计本质是在「避免频繁锁竞争」和「防止 read 长期 stale」之间做折中：
- 如果阈值太小（比如
misses >= 1）：每次 miss 都可能触发提升 → 拷贝开销大，dirty写几条就升，失去缓冲意义，反而比直接用sync.RWMutex + map更慢 - 如果阈值太大（比如
misses >= 10000）：read 长期不更新，大量Load强制进锁查dirty，并发读性能崩塌，锁争抢加剧
Go 选择 len(dirty) 是因为：它天然随写入量增长，能自适应负载；在读多写少场景下，misses 增长慢，提升稀疏；在写变多时，len(dirty) 变大，阈值自动拉高，避免过早刷脏。
实际压测中容易被忽略的三个性能拐点
-
dirty刚提升后首次写：要拷贝所有未删除的read.mentry → 若此时read很大（比如 10w 键），单次写延迟可能突增数十毫秒 -
misses即将触达阈值时：多个 goroutine 并发Load同时 miss，会集中触发后续写操作的提升，造成“提升风暴”，表现为短时 CPU 尖峰和延迟毛刺 - 高频
Delete后未触发提升：被Delete的 key 在read中仅标记为nil，仍占内存；只有等下次dirty提升为read时才会真正过滤掉 —— 所以长期只删不写的场景，read.m会缓慢膨胀
真正的临界不是某个固定 QPS 或键数，而是 misses 累积速度与 len(dirty) 的比值持续接近 1.0 的状态。这时候你看到的不是错误，而是 Load 延迟开始上扬、P99 毛刺增多、GC 压力微升——这些信号比阈值公式更值得盯紧。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
