go 语言中的map并非并发安全的,在Go 1.6以前,并发读写map会致使读取到脏数据,在1.6以后则程序直接panic. 所以以前的解决方案通常都是经过引入RWMutex(读写锁)进行处理, 关于go为何不支持map的原子操做,概况来讲,对map原子操做必定程度上下降了只有并发读,或不存在并发读写等场景的性能. 但做为服务端来讲,使用go编写服务,大部分状况下都会存在gorutine并发访问map的状况,所以,1.9以后,go 在sync包下引入了并发安全的map. 这里将从源码对其进行解读.git
func (m *Map) Store(key, value interface{})
复制代码
func (m *Map) Delete(key interface{})
复制代码
func (m *Map) Load(key interface{}) (value interface{}, ok bool)
复制代码
func (m *Map) LoadOrStore(key, value interface{}) (actual interface{}, loaded bool)
复制代码
func (m *Map) Range(f func(key, value interface{}) bool)
复制代码
经过引入两个map,将读写分离到不一样的map,其中read map只提供读,而dirty map则负责写. 这样read map就能够在不加锁的状况下进行并发读取,当read map中没有读取到值时,再加锁进行后续读取,并累加未命中数,当未命中数到达必定数量后,将dirty map上升为read map.github
另外,虽然引入了两个map,可是底层数据存储的是指针,指向的是同一份值.golang
具体流程: 如插入key 1,2,3时均插入了dirty map中,此时read map没有key值,读取时从dirty map中读取,并记录miss数安全
当miss数大于等于dirty map的长度时,将dirty map直接升级为read map,这里直接 对dirty map进行地址拷贝.bash
当有新的key 4插入时,将read map中的key值拷贝到dirty map中,这样dirty map就含有全部的值,下次升级为read map时直接进行地址拷贝.并发
entry结构,用于保存value的interface指针,经过atomic进行原子操做.app
type entry struct {
p unsafe.Pointer // *interface{}
}
复制代码
Map结构, 主结构,提供对外的方法,以及数据存储.函数
type Map struct {
mu Mutex
//存储readOnly,不加锁的状况下,对其进行并发读取
read atomic.Value // readOnly
//dirty map用于存储写入的数据,能直接升级成read map.
dirty map[interface{}]*entry
//misses 主要记录read读取不到数据加锁读取read map以及dirty map的次数.
misses int
}
复制代码
readOnly 结构, 主要用于存储源码分析
// readOnly 经过原子操做存储在Map.read中,
type readOnly struct {
m map[interface{}]*entry
amended bool // true if the dirty map contains some key not in m.
}
复制代码
func (m *Map) Load(key interface{}) (value interface{}, ok bool) {
read, _ := m.read.Load().(readOnly)
e, ok := read.m[key]
if !ok && read.amended {
m.mu.Lock()
//加锁,而后再读取一遍read map中内容,主要防止在加锁的过程当中,dirty map转换成read map,从而致使读取不到数据.
read, _ = m.read.Load().(readOnly)
e, ok = read.m[key]
if !ok && read.amended {
e, ok = m.dirty[key]
//记录miss数, 在dirty map提高为read map以前,
//这个key值都必须在加锁的状况下在dirty map中读取到.
m.missLocked()
}
m.mu.Unlock()
}
if !ok {
return nil, false
}
return e.load()
}
复制代码
// Store sets the value for a key.
func (m *Map) Store(key, value interface{}) {
//若是在read map读取到值,则尝试使用原子操做直接对值进行更新,更新成功则返回
read, _ := m.read.Load().(readOnly)
if e, ok := read.m[key]; ok && e.tryStore(&value) {
return
}
//若是未在read map中读取到值或读取到值进行更新时更新失败,则加锁进行后续处理
m.mu.Lock()
read, _ = m.read.Load().(readOnly)
if e, ok := read.m[key]; ok {
//在检查一遍read,若是读取到的值处于删除状态,将值写入dirty map中
if e.unexpungeLocked() {
m.dirty[key] = e
}
//使用原子操做更新key对应的值
e.storeLocked(&value)
} else if e, ok := m.dirty[key]; ok {
//若是在dirty map中读取到值,则直接使用原子操做更新值
e.storeLocked(&value)
} else {
//若是dirty map中不含有值,则说明dirty map已经升级为read map,或者第一次进入
//须要初始化dirty map,并将read map的key添加到新建立的dirty map中.
if !read.amended {
m.dirtyLocked()
m.read.Store(readOnly{m: read.m, amended: true})
}
m.dirty[key] = newEntry(value)
}
m.mu.Unlock()
}
复制代码
代码逻辑和Store相似性能
func (m *Map) LoadOrStore(key, value interface{}) (actual interface{}, loaded bool) {
// 不加锁的状况下读取read map
read, _ := m.read.Load().(readOnly)
if e, ok := read.m[key]; ok {
//若是读取到值则尝试对值进行更新或读取
actual, loaded, ok := e.tryLoadOrStore(value)
if ok {
return actual, loaded
}
}
m.mu.Lock()
read, _ = m.read.Load().(readOnly)
// 在加锁的请求下在肯定一次read map
if e, ok := read.m[key]; ok {
if e.unexpungeLocked() {
m.dirty[key] = e
}
actual, loaded, _ = e.tryLoadOrStore(value)
} else if e, ok := m.dirty[key]; ok {
actual, loaded, _ = e.tryLoadOrStore(value)
m.missLocked()
} else {
if !read.amended {
m.dirtyLocked()
m.read.Store(readOnly{m: read.m, amended: true})
}
m.dirty[key] = newEntry(value)
actual, loaded = value, false
}
m.mu.Unlock()
return actual, loaded
}
复制代码
func (m *Map) Range(f func(key, value interface{}) bool) {
//先获取read map中值
read, _ := m.read.Load().(readOnly)
//若是dirty map中还有值,则进行加锁检测
if read.amended {
m.mu.Lock()
read, _ = m.read.Load().(readOnly)
if read.amended {
//将dirty map中赋给read,由于dirty map包含了全部的值
read = readOnly{m: m.dirty}
m.read.Store(read)
m.dirty = nil
m.misses = 0
}
m.mu.Unlock()
}
//进行遍历
for k, e := range read.m {
v, ok := e.load()
if !ok {
continue
}
if !f(k, v) {
break
}
}
}
复制代码
func (m *Map) Delete(key interface{}) {
//首先获取read map
read, _ := m.read.Load().(readOnly)
e, ok := read.m[key]
if !ok && read.amended {
m.mu.Lock()
//加锁二次检测
read, _ = m.read.Load().(readOnly)
e, ok = read.m[key]
//没有在read map中获取到值,到dirty map中删除
if !ok && read.amended {
delete(m.dirty, key)
}
m.mu.Unlock()
}
if ok {
e.delete()
}
}
复制代码
从以上的源码可知,sync.map并不适合同时存在大量读写的场景,大量的写会致使read map读取不到数据从而加锁进行进一步读取,同时dirty map不断升级为read map. 从而致使总体性能较低,特别是针对cache场景.针对append-only以及大量读,少许写场景使用sync.map则相对比较合适.
对于map,还有一种基于hash的实现思路,具体就是对map加读写锁,可是分配n个map,根据对key作hash运算肯定是分配到哪一个map中. 这样锁的消耗就降到了1/n(理论值).具体实现可见:concurrent-map
相比之下, 基于hash的方式更容易理解,总体性能较稳定. sync.map在某些场景性能可能差一些,但某些场景却能取得更好的效果. 因此仍是要根据具体的业务场景进行取舍.