用 RWMutex 保护读多写少的内存索引并缩短锁区间

读多写少的内存索引可以用 sync.RWMutex 保护，但真正决定并发体验的并不是把 Mutex 换成 RWMutex，而是把锁区间缩到只覆盖共享 map 的读取、赋值和整体替换。字符串规范化、切片复制、过滤、排序与新索引构建都应尽量放在锁外。

一个可维护的边界是：存入索引的 Entry 发布后保持不可变；读锁内只取值或复制结构体快照；写锁内只做 map 赋值或 map 指针替换。若业务需要“读取旧值后再决定新值”，则必须把整个读改写不变量放进同一个写锁，不能先读锁再尝试升级。

RWMutex 改变的是访问边界

RWMutex 可以同时被任意数量的读者持有，也可以被一个写者独占持有。它的零值可直接使用，但首次使用后不能复制。官方文档还强调：当写者已经在等待时，新的 RLock 会阻塞，让写者最终获得锁；因此递归读锁并不安全。

它也不支持锁升级和降级。不能先持有 RLock，读取旧值后再调用 Lock 完成更新；同样不能在持有写锁时直接切换成读锁。遇到“检查后写入”这类复合不变量，直接从一开始持有写锁。

把索引和锁封装在同一个类型里

下面的索引以字符串 ID 为键。关键约定是：写入前复制 Tags，写入后不再修改已发布条目的内部切片。这样 Search 可以在读锁内快速复制 Entry 结构体，再在锁外做匹配；Get 返回时再深复制，避免调用方改到索引持有的底层数组。

package memindex

import (
    "sort"
    "strings"
    "sync"
)

type Entry struct {
    ID   string
    Name string
    Tags []string
}

type Index struct {
    mu    sync.RWMutex
    items map[string]Entry
}

func NewIndex() *Index {
    // map 在构造时初始化，锁使用可直接工作的零值。
    return &Index{items: make(map[string]Entry)}
}

func cloneEntry(e Entry) Entry {
    // 深复制切片，隔离调用方与索引内部的底层数组。
    e.Tags = append([]string(nil), e.Tags...)
    return e
}

func normalize(e Entry) Entry {
    // 规范化属于纯计算，不应占用写锁。
    e.ID = strings.TrimSpace(e.ID)
    e.Name = strings.TrimSpace(e.Name)
    for i := range e.Tags {
        e.Tags[i] = strings.ToLower(strings.TrimSpace(e.Tags[i]))
    }
    return e
}

func (x *Index) Upsert(e Entry) {
    // 先在锁外得到完整且独立的不可变值。
    prepared := normalize(cloneEntry(e))

    x.mu.Lock()
    x.items[prepared.ID] = prepared // 临界区只保留 map 赋值。
    x.mu.Unlock()
}

func (x *Index) Get(id string) (Entry, bool) {
    x.mu.RLock()
    e, ok := x.items[id] // 读锁内只取出稳定值。
    x.mu.RUnlock()
    if !ok {
        return Entry{}, false
    }

    // 返回副本，避免外部代码修改已发布 Entry 的 Tags。
    return cloneEntry(e), true
}

func (x *Index) Search(query string) []Entry {
    x.mu.RLock()
    snapshot := make([]Entry, 0, len(x.items))
    for _, e := range x.items {
        // Entry 发布后保持不可变，因此这里复制结构体即可形成稳定快照。
        snapshot = append(snapshot, e)
    }
    x.mu.RUnlock()

    // 过滤和排序都在锁外完成，避免长时间挡住写者。
    q := strings.ToLower(strings.TrimSpace(query))
    result := make([]Entry, 0)
    for _, e := range snapshot {
        if strings.Contains(strings.ToLower(e.Name), q) {
            result = append(result, cloneEntry(e))
        }
    }
    sort.Slice(result, func(i, j int) bool {
        return result[i].Name 

这个实现没有在锁内调用外部函数，也没有在锁内进行排序或大批量分配。锁与 map 都是 Index 的私有字段，调用方不能绕过方法直接访问共享状态，因而更容易维持“所有读写都经过同一把锁”的规则。

把准备工作和计算移出锁区间

缩短锁区间要区分两类成本。写入侧的字符串清洗、标签复制和新 map 构建只依赖入参，可以先完成，再持有写锁提交。读取侧必须在读锁内访问 map，但拿到稳定快照后，过滤、排序和结果深复制都不再需要占用读锁。

不能简单地在读锁内取出 []*Entry 指针，然后让写者继续修改同一对象。上面的方案把写入条目视为不可变值：更新时创建新副本并整体替换 map 中的值，旧快照引用的切片不会被写者原地改变。这是把计算移到锁外仍能保持正确性的前提。

批量刷新优先构建新 map 再整体替换

配置重载、路由表刷新或词典更新经常一次替换大量条目。如果在写锁内循环解析和插入，所有读请求会等待整个构建过程。更合适的做法是先构建 next，确认它已完整可用后，再在写锁内把 x.items 替换为新 map。

这种方式带来的语义也更清楚：读者要么看到旧索引，要么看到新索引，不会看到只更新了一半的中间状态。若批量更新需要和其他共享字段保持一致，则把这些字段一起放进受锁保护的状态对象，在同一个写锁内整体替换。

哪些逻辑不能擅自移到锁外

特别注意“先 RLock 查询，再 Unlock，最后 Lock 更新”的写法。两次加锁之间状态可能已经变化，这不是锁升级，而是存在竞争窗口。如果新值依赖旧值，就在写锁内重新读取并完成判断与写入。

用竞态检测和基准测试做最小验证

先用竞态检测器确认并发测试没有无同步访问，再比较普通 Mutex 与 RWMutex。不要只看“读多写少”四个字就认定 RWMutex 一定更快：临界区极短、并发度不高或写入频繁时，普通 Mutex 可能更简单，实际结果应由当前负载下的基准测试决定。

# 先运行并发测试并启用竞态检测器
go test -race ./...

# 再重复基准测试，比较不同锁实现和读写比例
go test -run '^$' -bench 'Index' -benchmem -count=5 ./...

基准场景至少分开记录纯读、读多写少、批量替换三种负载，并让数据规模接近生产索引。比较时关注吞吐、每次操作耗时和分配次数，同时确认两种实现的业务语义完全相同。

迁移现有大锁代码的检查清单

• 锁和 map 是否封装在同一个不可复制的结构体中。
• 每一处 map 读取是否都持有读锁或写锁。
• 每一处 map 修改是否都持有写锁。
• 写入对象中的 map、slice、pointer 是否会在发布后被原地修改。
• 排序、序列化、日志、网络调用和用户回调是否仍位于锁内。
• 是否存在试图从 RLock 升级为 Lock 的代码。
• 是否同时运行了竞态检测与符合真实读写比例的基准测试。

相关问题

RWMutex 适合所有缓存吗？ 不适合。读操作并发度低、临界区很短时，普通 Mutex 可能更直接；只有测量才能确认收益。

可以在持有 RLock 时再次 RLock 吗？ 不应依赖递归读锁。等待中的写者会阻止新读锁，递归获取可能让程序无法继续。

为什么 Get 返回值还要复制 Tags？ 因为切片是包含底层数组指针的描述符。返回深复制可以防止调用方修改索引内部已发布的数组。

什么时候考虑 sync.Map？ 当键通常只写一次后反复读取，或不同 goroutine 操作互不重叠的键集合时可以评估；普通 map 配合锁通常类型更安全，也更容易维护跨字段不变量。