Go语言中实现简易的字符串缓存：基于LRU算法的常驻字符串检索优化-Golang-PHP中文网

直接用 map[string]string 做缓存会因无淘汰机制导致内存只增不减，runtime.gc 无法回收，而 github.com/hashicorp/golang-lru/v2 提供线程安全、o(1) 复杂度的 lru 实现，配合明确容量与合理分片可稳住内存水位并提升高并发性能。

go语言中实现简易的字符串缓存：基于lru算法的常驻字符串检索优化

为什么直接用 map[string]string 做缓存会出问题

因为没淘汰机制，内存只增不减。业务里反复拼接或解析的字符串（比如 URL path、JSON key 路径、SQL 模板）一旦缓存无上限，runtime.GC 都救不回来。LRU 不是银弹，但对“最近频繁用、历史很少用”的字符串场景，它能稳住内存水位。

用 github.com/hashicorp/golang-lru 实现最小可行缓存

别自己重造轮子——这个库轻量、线程安全、API 干净。它内部用双向链表 + map，Get 和 Put 都是 O(1)。

实操建议：

初始化时明确容量，比如 lru.New(1024)，别用 lru.New2Q 或其他变种——2Q 对字符串这种小对象没收益，还多一层哈希判断
键必须是 string，值也建议是 string；如果存结构体指针，得确保不会被外部修改，否则缓存语义就乱了
注意 OnEvicted 回调：如果字符串背后关联了资源（比如临时文件名），这里才是释放时机，不是 Get 时

示例：

cache, _ := lru.New(512)
cache.Add("user:123:profile", `{"name":"alice","age":30}`)
if val, ok := cache.Get("user:123:profile"); ok {
    // val 是 interface{}，需类型断言
    s := val.(string)
}

字符串比较开销大？用 unsafe.String 转换要小心

Go 1.20+ 支持 unsafe.String 快速把 []byte 转成 string 零拷贝，但缓存键若来自 unsafe.String，得确认底层字节切片生命周期比缓存长——否则缓存里存的是悬垂指针，读出来是脏数据或 panic。

Go语言（Golang）1.26.0

Go语言（Golang）1.26.0版本官方下载，版本号 1.26.0，适合旧项目维护、兼容性测试和指定版本开发环境搭建。

下载

常见错误现象：fatal error: unexpected signal during runtime execution 或返回空字符串。

安全做法：

只对静态字面量或明确持有所有权的 []byte（比如从 io.ReadFull 读满的缓冲区）用 unsafe.String
从 HTTP body、数据库字段等来的字节，先 copy 再转，别图快直接 unsafe.String
缓存键尽量用原始 string 构造，而不是反复转来转去

并发读写下性能掉得厉害？加读写锁反而更慢

github.com/hashicorp/golang-lru 默认用 sync.RWMutex，但高并发 Get 场景下，读锁竞争仍明显。实测 QPS 过 5k 后，锁成为瓶颈。

替代方案：

用 lru.NewWithARC（ARC 变种），它把访问频次和时间双维度建模，热点字符串更难被淘汰，间接减少 Get miss 导致的锁争抢
或者拆分缓存：按前缀哈希分片，比如 shard[key[0]%4].Get(key)，每个分片独立锁，吞吐翻倍
别用 sync.Map 替代——它对字符串键的 hash 计算开销比原生 map 高，且不支持 LRU 淘汰

分片示例：

type ShardedCache struct {
    shards [4]*lru.Cache
}
func (c *ShardedCache) Get(key string) (interface{}, bool) {
    idx := int(key[0]) % 4
    return c.shards[idx].Get(key)
}

缓存键的散列分布是否均匀，比算法本身更容易决定实际效果。一个长字符串前缀全一样（比如都以 /api/v1/ 开头），分片或哈希就失效了——这时候得提前截断或加盐。