-
我给一个带 sync.Mutex 的 Go 结构体写了用值接收者的方法又到处用值传递把它传来传去、自以为加了锁就线程安全了,结果高并发下那份本该被锁保护的数据还是被改乱了计数器还是丢更新,排查很久才搞懂我每次值拷贝这个结构体时把里面的锁也一起复制成了另一把副本锁的根本不是同一把锁的深度复盘
我写了个带计数功能的结构体 Counter 里有个 sync.Mutex 保护并发、方法用了值接收者 func (c Counter) Inc() 里面 c.mu.Lock() defer Unlock() c.count++,然后多个 goroutine 并发调 Inc() 还经常把 Counter 当参数值传递。上线后:开 1000 个 goroutine 各 Inc() 一次最后 Value…- 0
- 0
-
一个被多个 goroutine 同时读写的普通 map,把整个 Go 服务以 fatal error 直接干崩、连 recover 都拦不住:一次 map 并发不安全的深度复盘
高并发 Go 服务平时稳如磐石,一到高峰就毫无征兆整个进程挂掉,日志只留一行 fatal error: concurrent map read and map write,而且入口的 recover 居然拦不住。根因是用普通 map 做内存缓存、多个 goroutine 无同步地并发读写它——Go 内置 map 为性能不做并发同步,并发写会破坏其哈希结构,运行时检测到就抛不可 recover 的 …- 2
- 0
-
Go 并发踩坑实录:一个共享 map 如何让整个服务瞬间崩溃
这次事故没有任何前兆:一个跑了大半年、从没出过岔子的 Go 服务,突然整个进程没了。登上机器翻日志,最后一行让我后背一凉——fatal error: concurrent map writes。不是 panic,是 fatal error,recover 写再多都拦不住一个字。根因朴素得讽刺:一个做本地缓存的普通 map,被好几个 goroutine 同时读写,平时并发不高一直没事,流量一冲高,两…- 2
- 0
sync.Mutex
-
￥优惠劵使用时效：无法使用使用时效：
之前
使用时效：永久有效优惠劵ID：×