Go中sync.RWMutex表现异常：本地与Playground行为差异排查

嘿，这个问题挺典型的——不同运行环境下的并发行为差异确实容易让人摸不着头脑。咱们一步步拆解来看：

一、代码大概率存在的潜在问题：缺失双重检查锁定 #

虽然最终缓存的结果是正确的，但同一SessionData多次触发写入日志，核心原因很可能是你在使用sync.RWMutex时，没有在获取写锁后二次检查缓存状态，导致多个goroutine都进入了写入分支。

举个常见的错误实现例子：

rwmu.RLock()
_, exists := sessionCache[sessionID]
rwmu.RUnlock()
if !exists {
    rwmu.Lock()
    // 这里没有二次检查！
    sessionCache[sessionID] = newSessionData
    fmt.Printf("写入Session: %s\n", sessionID)
    rwmu.Unlock()
}

这个逻辑的问题在于：

• 多个goroutine可以同时通过读锁的检查（都看到sessionID不存在）
• 之后它们会排队等待获取写锁，虽然写锁是互斥的，但每个goroutine抢到锁后都会执行写入和日志打印——哪怕此时缓存里已经有值了，最终缓存结果是对的（因为最后一次写入会覆盖，但前面的写入其实是无效的），但日志会重复输出。

二、为什么Go Playground和Windows本地运行表现不同？ #

这是两个环境的GOMAXPROCS设置和调度逻辑差异导致的：

• Go Playground：默认限制了GOMAXPROCS=1（单核心执行），goroutine是串行调度的。一个goroutine从读锁判断到写锁写入的整个流程会完整执行完，其他goroutine才会被调度，所以不会出现多个goroutine同时进入写入分支的情况，日志自然只会打印一次。
• Windows本地环境：默认GOMAXPROCS等于你的CPU核心数（多核），多个goroutine可以并行执行读锁检查步骤，都触发“需要写入”的判断，进而排队抢写锁，最终导致日志重复输出。

三、修复方案：添加双重检查锁定 #

在获取写锁之后，必须再次检查缓存中是否已经存在目标值，这样只有第一个抢到写锁的goroutine会执行写入和日志，后续的goroutine拿到锁后发现值已存在，就会跳过操作。

正确的实现示例：

rwmu.RLock()
_, exists := sessionCache[sessionID]
rwmu.RUnlock()
if !exists {
    rwmu.Lock()
    // 二次检查，避免竞态条件
    _, exists = sessionCache[sessionID]
    if !exists {
        sessionCache[sessionID] = newSessionData
        fmt.Printf("写入Session: %s\n", sessionID)
    }
    rwmu.Unlock()
}

如果你的场景写操作并不频繁，也可以直接用写锁完成判断（牺牲一点读性能，但逻辑更简单）：

rwmu.Lock()
_, exists := sessionCache[sessionID]
if !exists {
    sessionCache[sessionID] = newSessionData
    fmt.Printf("写入Session: %s\n", sessionID)
}
rwmu.Unlock()

额外排查建议 #

• 检查代码中是否有其他地方重复调用了写入逻辑，但根据你说的最终缓存结果正确，这个可能性较低。
• 可以在本地运行时手动设置GOMAXPROCS=1（比如通过runtime.GOMAXPROCS(1)），看看是否和Playground表现一致，这也能验证调度差异的猜想。

内容的提问来源于stack exchange，提问作者Deepak Kumar