sync.Map 内存不自动释放，因其 read map 删除仅标记 nil、dirty 升级后旧 read 不立即丢弃、interface{} 类型擦除阻碍 GC，且无 rehash 机制；需通过 RWMutex 保护下定期重建新实例并迁移有效数据来收缩内存。
sync.map 长期运行时确实会内存增长，但不是“无限”，而是因旧数据延迟清理 + 类型擦除导致 gc 回收不及时；必须主动干预，不能靠它自动收缩。
为什么 sync.Map 内存不自动释放
sync.Map 内部维护 read（只读）和 dirty（可写）两层结构。写入新 key 时，若 key 不在 read 中，会先复制一份到 dirty；read 中的 entry 被删除后，只是标记为 nil，不会立即从底层哈希桶中移除。GC 只能回收整个 map 结构，但那些被标记为 nil 的 entry 仍占据哈希槽位，且因 interface{} 类型擦除，value 指针可能隐式延长对象生命周期。
常见错误现象：runtime.ReadMemStats 显示 HeapInuse 持续上涨，Range 遍历出的键数远少于实际内存占用；用 pprof 查 heap 会看到大量 sync.mapRead 和 sync.entry 占据空间。
- dirty map 升级为 read 后，旧 read 不会被立刻丢弃，而是等下次写入再逐步替换
- Store 过
nil值的 key 依然保留在结构中，且Delete后 entry 也不清空槽位 - 没有类似
map的 rehash 机制，桶数组大小固定，无法压缩稀疏空间
定期重建是唯一可控的收缩方式
别依赖 Range + Delete 清理——它无法回收 read map 的桶内存，且遍历时新增的 key 会被跳过。真正有效的做法是：在业务低峰期，用新 sync.Map 替换旧实例，并迁移有效键值对。
示例逻辑：
var (
mu sync.RWMutex
cache = new(sync.Map)
)
func rebuildCache() {
newCache := new(sync.Map)
cache.Range(func(k, v interface{}) bool {
// 这里加业务判断：是否过期、是否有效
if isValid(v) {
newCache.Store(k, v)
}
return true
})
mu.Lock()
cache = newCache
mu.Unlock()
}
- 必须用
sync.RWMutex包一层，避免重建期间读写冲突 - 迁移过程不保证原子性，但比原地
Delete更彻底：新 map 从零开始分配桶数组 - 重建频率取决于 key 增长速度，建议结合监控（如每小时一次或内存增长超阈值触发）
LoadOrStore 不能替代清理逻辑
有人试图用 LoadOrStore “覆盖”旧值来触发内部清理，这是无效的。该方法只更新 value 指针，entry 结构体本身仍在原位置，且 read map 中的旧引用不会被清除。
更危险的是：如果之前 Store(k, nil) 过，后续 LoadOrStore(k, v) 仍返回 nil 并设 loaded=true，你以为写进去了，其实没生效——这会导致误判 key 状态，让本该清理的 key 一直挂着。
- 想判断 key 是否真存在，必须
Load后检查ok，不能只看 value 是否为 nil -
LoadOrStore的语义是“首次写入”，不是“强制更新”，别把它当SetIfAbsent用 - 清理必须显式调用
Delete或重建，没有捷径
最易被忽略的一点：sync.Map 的内存压力往往在服务运行数天后才暴露，因为 read map 的惰性升级机制会让问题延迟显现。上线前务必压测 + pprof 监控，而不是等 OOM 才发现。
