concurrenthashmap通过渐进式扩容和多线程协作迁移优化性能：扩容时双表共存，由触发线程与后续读写线程共同分摊迁移任务，借助forwardingnode引导访问、synchronized锁桶头节点保证原子性，并用volatile确保内存可见性。
扩容期间 map 的读写性能会明显劣化，不是线性变慢，而是呈现「阶段性卡顿 + 持续开销」特征：每次访问到未迁移的旧桶时触发惰性搬迁，带来额外计算与内存操作；同时新旧桶并存导致 cache 局部性下降、GC 压力上升。
map 扩容时读操作为什么有时变慢？
读操作本身不阻塞，但会参与渐进式迁移——只要访问的 key 还在 oldbuckets 里，runtime 就顺手把它和相邻 bucket 一起搬走。这意味着：
-
mapaccess1或mapaccess2调用可能突然多出 rehash + 内存拷贝开销，尤其当 key 是大结构体或指针密集型 value 时 - 若
nevacuate进度滞后（比如 map 长期只读），首次读某个旧桶会集中触发搬迁，造成毫秒级延迟尖峰 - 遍历
for range m时，每次迭代都可能触发一次或多次搬迁，导致整体耗时不可预测、CPU 使用率毛刺明显
写操作在扩容中会发生什么？
写操作必须写入新 bucket，且会强制推进搬迁进度：
-
mapassign总是定位到新 buckets 数组，不会往 oldbuckets 写 - 写入前检查该 key 对应的旧 bucket 是否已迁移；若未迁，则立即搬运该 bucket 及下一个（
evacuate逻辑） - 高频写入会加速
nevacuate推进，但也意味着更多并发搬迁动作，容易引发 false sharing 和 cache line 争用 - 如果多个 goroutine 同时写入不同 key 却命中同一旧 bucket，它们会串行化执行搬迁，形成隐式锁竞争
如何从 pprof 和运行时指标识别扩容影响？
不能只看 CPU 时间，要结合内存与 GC 行为交叉判断：
- pprof 火焰图中出现高频
runtime.mapassign或runtime.evacuate调用栈，尤其是占比 >10%，基本可确认处于活跃扩容期 -
runtime.ReadMemStats显示HeapSys短期飙升、NumGC异常升高，说明 oldbuckets 滞留加剧堆压力 - 使用
debug.ReadGCStats观察PauseTotalNs是否随写入节奏周期性上涨——这是搬迁触发 GC 的典型信号 - 注意：
map_buckhash_sys（来自runtime/debug）持续增长，往往代表 overflow bucket 泛滥，可能触发 sameSizeGrow 而非翻倍，这种扩容更隐蔽但同样拖慢写入
真正难处理的不是扩容本身，而是它和业务逻辑耦合的方式：一个看似只读的缓存 map，可能因某次后台统计写入而悄悄启动搬迁，随后所有读请求都开始承担搬迁开销。这种延迟传导很难在单元测试里暴露，只能靠压测 + pprof + 实时指标联动观测。
