看过这篇剖析,你还不懂 Go sync.Map 吗?

看过这篇剖析,你还不懂 Go sync.Map 吗?,第1张

看过这篇剖析,你还不懂 Go sync.Map 吗?

hi, 大家好,我是 haohongfan。


本篇文章会从使用方式和原码角度剖析 sync.Map。


不过不管是日常开发还是开源项目中,好像 sync.Map 并没有得到很好的利用,大家还是习惯使用 Mutex + Map 来使用。


下面这段代码,看起来很有道理,其实是用错了(背景:并发场景中获取注册信息)。


instance, ok := instanceMap[name]
if ok {
return instance, nil
} initLock.Lock()
defer initLock.Unlock() // double check
instance, ok = instanceMap[name]
if ok {
return instance, nil
}

这里使用使用 sync.Map 会更合理些,因为 sync.Map 底层完全包含了这个逻辑。


可能写 Java 的同学看着上面这段代码很眼熟,但确实是用错了,关于为什么用错了以及会造成什么影响,请大家关注后续的文章。


我大概分析了下大家宁愿使用 Mutex + Map,也不愿使用 sync.Map 的原因:

  1. sync.Map 本身就很难用,使用起来并不像一个 Map。


    失去了 map 应有的特权语法,如:make, map[1] 等

  2. sync.Map 方法较多。


    让一个简单的 Map 使用起来有了较高的学习成本。


不管什么样的原因吧,当你读过这篇文章后,在某些特定的并发场景下,建议使用 sync.Map 代替 Map + Mutex 的。


用法全解
package main

import (
"fmt"
"sync"
) func main() {
var syncMap sync.Map
syncMap.Store("11", 11)
syncMap.Store("22", 22) fmt.Println(syncMap.Load("11")) // 11
fmt.Println(syncMap.Load("33")) // 空 fmt.Println(syncMap.LoadOrStore("33", 33)) // 33
fmt.Println(syncMap.Load("33")) // 33
fmt.Println(syncMap.LoadAndDelete("33")) // 33
fmt.Println(syncMap.Load("33")) // 空 syncMap.Range(func(key, value interface{}) bool {
fmt.Printf("key:%v value:%v\n", key, value)
return true
})
// key:22 value:22
// key:11 value:11
}

其实 sync.Map 并不复杂,只是将普通 map 的相关 *** 作转成对应函数而已。


普通 map sync.Map map 获取某个 key map[1] sync.Load(1) map 添加元素 map[1] = 10 sync.Store(1, 10) map 删除一个 key delete(map, 1) sync.Delete(1) 遍历 map for...range sync.Range()

sync.Map 两个特有的函数,不过从字面就能理解是什么意思了。




LoadOrStore:sync.Map 存在就返回,不存在就插入

LoadAndDelete:sync.Map 获取某个 key,如果存在的话,同时删除这个 key

源码解析
type Map struct {
mu Mutex
read atomic.Value // readOnly read map
dirty map[interface{}]*entry // dirty map
misses int
}

read map 的值是什么时间更新的 ?
  1. Load/LoadOrStore/LoadAndDelete 时,当 misses 数量大于等于 dirty map 的元素个数时,会整体复制 dirty map 到 read map
  2. Store/LoadOrStore 时,当 read map 中存在这个key,则更新
  3. Delete/LoadAndDelete 时,如果 read map 中存在这个key,则设置这个值为 nil
dirty map 的值是什么时间更新的 ?
  1. 完全是一个新 key, 第一次插入 sync.Map,必先插入 dirty map
  2. Store/LoadOrStore 时,当 read map 中不存在这个key,在 dirty map 存在这个key,则更新
  3. Delete/LoadAndDelete 时,如果 read map 中不存在这个key,在 dirty map 存在这个key,则从 dirty map 中删除这个key
  4. 当 misses 数量大于等于 dirty map 的元素个数时,会整体复制 dirty map 到 read map,同时设置 dirty map 为 nil

疑问:当 dirty map 复制到 read map 后,将 dirty map 设置为 nil,也就是 dirty map 中就不存在这个 key 了。


如果又新插入某个 key,多次访问后达到了 dirty map 往 read map 复制的条件,如果直接用 read map 覆盖 dirty map,那岂不是就丢了之前在 read map 但不在 dirty map 的 key ?

答:其实并不会。


当 dirty map 向 read map 复制后,readOnly.amended 等于了 false。


当新插入了一个值时,会将 read map 中的值,重新给 dirty map 赋值一遍,也就是 read map 也会向 dirty map 中复制。


func (m *Map) dirtyLocked() {
if m.dirty != nil {
return
} read, _ := m.read.Load().(readOnly)
m.dirty = make(map[interface{}]*entry, len(read.m))
for k, e := range read.m {
if !e.tryExpungeLocked() {
m.dirty[k] = e
}
}
}
read map 和 dirty map 是什么时间删除的?
  • 当 read map 中存在某个 key 的时候,这个时候只会删除 read map, 并不会删除 dirty map(因为 dirty map 不存在这个值)
  • 当 read map 中不存在时,才会去删除 dirty map 里面的值

疑问:如果按照这个删除方式,那岂不是 dirty map 中会有残余的 key,导致没删除掉?

答:其实并不会。


当 misses 数量大于等于 dirty map 的元素个数时,会整体复制 dirty map 到 read map。


这个过程中还附带了另外一个 *** 作:将 dirty map 置为 nil。


func (m *Map) missLocked() {
m.misses++
if m.misses < len(m.dirty) {
return
}
m.read.Store(readOnly{m: m.dirty})
m.dirty = nil
m.misses = 0
}
read map 与 dirty map 的关系 ?
  1. 在 read map 中存在的值,在 dirty map 中可能不存在。


  2. 在 dirty map 中存在的值,在 read map 中也可能存在。


  3. 当访问多次,发现 dirty map 中存在,read map 中不存在,导致 misses 数量大于等于 dirty map 的元素个数时,会整体复制 dirty map 到 read map。


  4. 当出现 dirty map 向 read map 复制后,dirty map 会被置成 nil。


  5. 当出现 dirty map 向 read map 复制后,readOnly.amended 等于了 false。


    当新插入了一个值时,会将 read map 中的值,重新给 dirty map 赋值一遍

read/dirty map 中的值一定是有效的吗?

并不一定。


放入到 read/dirty map 中的值总共有 3 种类型:

  • nil:如果获取到的 value 是 nil,那说明这个 key 是已经删除过的。


    既不在 read map,也不在 dirty map

  • expunged:这个 key 在 dirty map 中是不存在的
  • valid:其实就正常的情况,要么这个值存在在 read map 中,要么存在在 dirty map 中
sync.Map 是如何提高性能的?

通过源码解析,我们知道 sync.Map 里面有两个普通 map,read map主要是负责读,dirty map 是负责读和写(加锁)。


在读多写少的场景下,read map 的值基本不发生变化,可以让 read map 做到无锁 *** 作,就减少了使用 Mutex + Map 必须的加锁/解锁环节,因此也就提高了性能。


不过也能够看出来,read map 也是会发生变化的,如果某些 key 写 *** 作特别频繁的话,sync.Map 基本也就退化成了 Mutex + Map(有可能性能还不如 Mutex + Map)。


所以,不是说使用了 sync.Map 就一定能提高程序性能,我们日常使用中尽量注意拆分粒度来使用 sync.Map。


关于如何分析 sync.Map 是否优化了程序性能,同样可以使用 pprof。


具体过程可以参考 《这可能是最容易理解的 Go Mutex 源码剖析》

sync.Map 应用场景
  1. 读多写少
  2. 写 *** 作也多,但是修改的 key 和读取的 key 特别不重合。


关于第二点我觉得挺扯的,毕竟我们很难把控这一点,不过由于是官方的注释还是放在这里。


实际开发中我们要注意使用场景和擅用 pprof 来分析程序性能。


sync.Map 使用注意点

和 Mutex 一样, sync.Map 也同样不能被复制,因为 atomic.Value 是不能被复制的。


参考链接
  1. https://golang.design/under-the-hood/zh-cn/part1basic/ch05sync/map/
  2. https://draveness.me/golang-sync-primitives/
  3. https://github.com/golang/go/blob/master/src/sync/map.go

sync.Map 完整流程图获取链接:链接: https://pan.baidu.com/s/16yEnZFbXwSe3qkvX1zi-Wg 密码: 8w8k。


欢迎分享,转载请注明来源:内存溢出

原文地址: https://outofmemory.cn/zaji/588897.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2022-04-12
下一篇 2022-04-12

发表评论

登录后才能评论

评论列表(0条)

保存