sync.Map仅适用于低频写、高频读且键数量少的场景;频繁增删或大数据量会导致内存上涨和GC压力,应改用gcache等支持TTL和淘汰策略的库。用 sync.Map 做简单键值缓存,但别当主力sync.Map 看起来顺手:不用显式加锁、支持并发读写、标准库自带。但它只适合低频写 + 高频读、键数量稳定且不大的场景。比如缓存几十个配置项或连接池元信息。常见错误是把它当 map 的线程安全替代品,往里塞上万条数据,结果内存持续上涨、GC 压力变大------sync.Map 内部用了 read map + dirty map 双结构,写操作会不断复制 dirty map,且不自动清理已删除的 key。使用建议:只存生命周期明确、数量可控的数据(如 userCache 按 ID 缓存几百个用户)写入后不再更新的场景更合适;频繁 Store + Delete 会放大性能损耗不要依赖它做 TTL 过期,它本身不支持过期逻辑需要自动过期?直接上 github.com/bluele/gcache这个包轻量(不到 300 行)、无依赖、API 干净,比自己手写带 LRU + 定时清理的逻辑靠谱得多。它默认用 map + sync.RWMutex,支持 LRU、LFU、ARC 多种淘汰策略,还能设 expire 和 maxSize。立即学习"go语言免费学习笔记(深入)";容易踩的坑:初始化时没调 Build() 就直接 Get(),会 panic:"cache is not built"Set() 传了负数 expire,导致 key 永远不被清理(它把负数当"不过期",不是报错)在 HTTP handler 里反复 gcache.New(100).LRU().Build(),每次新建实例,缓存完全失效示例用法: 文心快码 文心快码(Comate)是百度推出的一款AI辅助编程工具
相关推荐
XZ-07000119 分钟前
week4-1-figure画布冰暮流星34 分钟前
mysql之表子查询Escalating_xu1 小时前
【System V 信号量】从 P/V 原语到 Builder 封装:写出可控、可清理的进程互斥组件Full Stack Developme1 小时前
CRM相关库表设计步行cgn1 小时前
Spring 注入 Map 集合详解今儿敲了吗1 小时前
03停用词过滤李可以量化2 小时前
Tornado 部署公域网络安全与防护(上)风跟我说过她2 小时前
SQL 一键转经典 Chen 风格 ER 图:开源 CLI + 在线工具 + Agent Skill这个DBA有点耶2 小时前
MySQL大表DDL锁表锁到崩溃?Online DDL的3个关键参数和实战避坑Ulyanov2 小时前
AudioVision Pro:基于 PySide6 + sounddevice 的实时音频可视化播放器设计