concurrent.Map扩展sync.Map

最新推荐文章于 2024-03-26 16:17:46 发布
最新推荐文章于 2024-03-26 16:17:46 发布
阅读量102 收藏
点赞数
分类专栏： java 文章标签： java 后端
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/m0_67390379/article/details/124505261
版权

前言

笔者最近在写一个开源项目gmap，里面就复用了sync.Map的技术，并不是直接使用sync.Map，而是拷贝sync.Map的代码并做一些适配性的调整和扩展。我想很多人应该会问为什么拷贝而不是直接使用？为什么不用map？这里我列举如下问题：

  1. map加读写锁（sync.RWMutex），问题在于利用读锁遍历map的时候写锁会被阻塞，说白了就是读的时候不能写。一般的应用是无所谓的，但是对于gmap或者sync.Map遍历需要回调用户函数，时间不可控，同时回调函数可能还会访问map形成圈，造成死锁。
  2. map加读写锁搞不定，笔者想到了sync.Map，但是sync.Map不支持CAS(Compare And Swap)，只有LoadOrStore。gmap为用户提供了CAS的功能，可以多协程竞争更新map中的值，而sync.Map只能做到多协程竞争store。

其实sync.Map的设计完全可以实现CAS功能，不知道设计者当初为什么没有开发相应的接口，我想多半是没有需要吧，亦或是有什么细节我没想到？

笔者认为sync.Map支持CAS功能还是比较普遍的需求，于是把sync.Map的代码拷贝一份，再扩展一个Update接口，上传到了https://github.com/jindezgm/concurrent/map.go。在介绍扩展接口之前，笔者先对sync.Map做一次详细介绍，看看它是如何做到遍历map的同时还能写操作，甚至在遍历的回调函数中依然可以访问map而不死锁。

sync.Map详解

为什么sync.Map能够实现并发读写（此处主要指的是在遍历的map的过程中依然可以写入或者更新），应该很容易想到两个独立的map这样的办法：在遍历的时候先拷贝一份（遍历时复制）。这种方法虽然可行，但是存在如下几个问题：

  1. 如果map比较大，拷贝成本比较高；
  2. 如果n个协程同时遍历，需要拷贝n次；
  3. 遍历过程中如果值更新，遍历协程无法获得最新的值；

那sync.Map是如何解决以上问题的呢？遍历时复制或者读时复制笔者是没听过的，反倒是写时复制（copy-on-write）到是比较普遍，包括linux内核都在用这种技术。而sync.Map用的就是写时复制技术，让我们先来看看sync.Map的定义（本文源码源自go1.13/src/sync/map.go）：

type Map struct {
    // 并不是读写锁，因为sync.Map采用写时复制(copy-on-write)，互斥锁足够了
    // 一个只读map，一个读写map，只有访问读写map的时候需要加锁，所以不区分读写锁
    // 后文会有更详细说明，此处只是说明为什么不是读写锁
    mu Mutex
    // 源码注释是只读，这个变量存储的是只用来读map，采用原子的方式获取和设置map对象。
    // 需要重点说明的是，只读是针对map的，不是针对value的，也就是read存储的map不会
    // 有写和删除操作，只能读取，这样对这个map的并发访问就不用在考虑互斥了，因为全是读操作
    read atomic.Value 
    // dirty顾名思义就是脏了，是相对于read而言，如果read中的map是一个纯净的数据，
    // 那么dirty中就是在read的基础上或多或少的加了一点其他数据，这就是脏的来由。
    // 因为read是只读的，当新写入数据时将read拷贝至dirty中并将新数据写入到dirty，
    // 这就是写时复制，而新数据就是脏的那部分。那么问题来了，每次写新数据都要拷贝一次read么？
    // ‘脏’的数据什么时候能够变成‘干净’的？后文会给出详细解释。至于为什么是*entry而不是
    // interface{}，因为entry是一个巧妙的设计，且听下文分解。
    dirty map[interface{}]*entry
    // 前面刚刚提到了脏的数据什么时候能够变干净，misses就是用来触发‘漂白’的。因为dirty比
    // read多一些脏数据，此时调用sync.Map.Load()访问这些脏数据的时候在read中找不到，我们
    // 称之为miss，就像CPU的cache miss。当miss次数达到阈值时，sync.Map就会把整个dirty
    // 赋值给read，达到漂白的效果就。这也解释了read为什么是atomic.Value类型，因为赋值的同事
    // 可能有其他协程在读取，并且也可以推导出read的map类型也是map[interface{}]*entry，
    // 否则光类型转换就非常麻烦的。
    misses int
}

如果从定义上看还是体会不到sync.Map设计巧妙之处，那么先来看看sync.Map的巧妙设计之一entry。在源码注释中对于entry解释是一个value的槽位，也可以理解为一个entry就是一个value。来看看entry的定义：

type entry struct {
    // 是的，你没看错，就是这么简单，用一个指针指向对象的地址，注意是*interface{}。
    // 从dirty的类型map[interface{}]*entry可知sync.Map存储的是key:*entry对，
    // entry.p指向了value。
    p unsafe.Pointer // *interface{}
}

为什么要这么设计？道理很假单，就是避免对map的修改(写/删)，这让我想起了一句名言：“没有什么架构设计不能通过一层抽象解决的，如果有，那就再抽象一层”。多了一层entry让sync.Map对于value的操作更加灵活，既可以直接从map中删除，也可以从entry中删除。这让互斥变成key级别而不是map级别（只针对read而言，dirty还是map级别的互斥），配合原子操作整体性能是非常可观的。举个栗子，产出指定key的value，直接将entry.p=nil即可；此后再写入该key的新值，则将nil再改为新值的指针。具体的细节下文在解析sync.Map的接口的时候会涉及到。

接下来介绍sync.Map的另一个巧妙设计：读写分离，先来看一个类型定义：

// readOnly就是sync.Map.Read存储的类型，一个加了amended标记的map，而这个map的定义和
// sync.Map.dirty是一样的。所以可以sync.Map其实是两个map[interface{}]*entry的map，
// 一个是只读的sync.Map.read.m（后文简称read），一个是读写的sync.Map.dirty。
type readOnly struct {
    m       map[interface{}]*entry
    // true表示sync.Map.dirty中有read没有的数据，为什么需要这个标记？这样就可以避免无效加锁，
    // 因为false表示read与sync.Map.dirty相同，如果指定的key在read中不存在，
    // 也就不用从sync.Map.dirty中再找一遍了
    amended bool 
}

因为read存在，就可以很好理解sync.Map在迭代的时候不会阻塞其他操作，因为遍历的是read，而其他操作要么访问dirty，要么与迭代通过原子的方式互斥访问read中的值，所以不会有阻塞。是时候分析sync.Map的接口实现了，看看和我们的理解是否相同？

func (m *Map) Load(key interface{}) (value interface{}, ok bool) {
    // 现在read中查找，这个比较好理解，不需要多解释了
    read, _ := m.read.Load().(readOnly)
    e, ok := read.m[key]
    // 这里就可以看到amended的价值了，如果read不存在指定的key，只有dirty比read数据多，
    // 才需要查找dirty，否则没必要。
    if !ok && read.amended {
        m.mu.Lock()
        // 再次访问一次read，写过并发的同学都应该明白为什么，笔者将这称之为锁前判断锁后校验。
        // 毕竟是并发访问，当某一个协程获得锁后刚刚的判断条件可能已经被前一个获得锁的协程修改了。
        read, _ = m.read.Load().(readOnly)
        e, ok = read.m[key]
        if !ok && read.amended {
            // 在dirty中查找指定的key
            e, ok = m.dirty[key]
            // missLocked就是累加read查找miss计数，如果miss计数太多就将dirty更新到read中。
            // 就是因为有可能更新read，所以才有加锁后二次查找read。missLocked见下文。
            m.missLocked()
        }
        m.mu.Unlock()
    }
    // 把entry中的value返回
    if !ok {
        return nil, false
    }
    return e.load()
}

func (m *Map) missLocked() {
    // 看来miss的次数的阈值是dirty的中记录的数量，miss计数不仅可以在必要的时候将dirty
    // 更新到read，同时也可以避免频繁插入新值时的拷贝（write-on-copy），只要dirty
    // 还没有被更新read就不需要拷贝，因为dirty才是全集，直接插入新值即可。而miss计数的阈值
    // 设置为常数也不不合理的，因为map中的数据量大小不同阈值也是不同的，所以采用dirty中的
    // 记录的数量是一个与map数据量线性变化的动态阈值，此设计也是非常巧妙的。
    m.misses++
    if m.misses < len(m.dirty) {
        return
    }
    // 因为read是dirty的子集，所以直接将dirty赋值给read即可，为什么dirty和readOnly.m
    // 的类型相同，这样就不用转换了，方便！
    m.read.Store(readOnly{m: m.dirty})
    m.dirty = nil
    m.misses = 0
}

func (e *entry) load() (value interface{}, ok bool) {
    p := atomic.LoadPointer(&e.p)
    // 其他的代码无需解释，这里面关键需要说明的是expunged，这是一个标记变量，表示这个entry被删除，
    // 意思就是这个entry是不可用的。这么设计的目的是为了避免执行map的delete操作，因为read
    // 是不能够执行删除操作的。
    if p == nil || p == expunged {
        return nil, false
    }
    return *(*interface{})(p), true
}

以上就是sync.Map.Load()的代码了，基本没有跑出我们前面的假设，expunged除外。因为read不可修改的特点，在一些情况下必须删除read中的某条记录变得非常困难，expunged就是用来标记key已经被删除。expunged不同于nil，虽然二者都代表value不存在（如entry.load()代码所示），但是expunged代表key也不再，而nil只是代表value不存在。至于什么情况下需要设置expunged，答案在写时复制里，来看看sync.Map.Store()的代码：

func (m *Map) Store(key, value interface{}) {
    // 如果read中有指定的key，则直接写入到read中，entry.tryStore见下文详解
    read, _ := m.read.Load().(readOnly)
    // 此时建议读者现去阅读下面关于entry.tryStore()的解析，这样更有利于理解。
    if e, ok := read.m[key]; ok && e.tryStore(&value) {
        return
    }
    // 因为read里的没有指定的key，expunged也算作key不存在，所以只能写入dirty了
    m.mu.Lock()
    read, _ = m.read.Load().(readOnly)
    if e, ok := read.m[key]; ok {
        // entry.unexpungeLocked()是将expunged的value设置为nil，为什么又把expunged
        // 变为nil？不是说expunged的key相当于被删除了么？这一点笔者需要说明一下，
        // 当read中的数据已经被复制到dirty中，那么read中所有entry.p=nil的记录都会被改为
        // entry.p=expunged以表示从read中删除。但需要注意的是，此时dirty中也没有这个key，
        // 此时再写入的记录的key被标记为expunged，肯定是要写入dirty的，正如下面代码所示。
        // 与此同时，因为read中已经有这个key了，重新激活它岂不是更好？这样再次访问该key的记录
        // 就直接访问read即可，这就是为什么又将expunged的记录改为nil的原因。unexpungeLocked()
        // 很简单：atomic.CompareAndSwapPointer(&e.p, expunged, nil)，通过原子的方式
        // 把expunged变为nil。如果成功了，说明写时复制已经完成，可以直接写入dirty，因为只有
        // 写时复制的过程才能设置expunged；如果失败了，直接赋值entry即可。
        if e.unexpungeLocked() {
            m.dirty[key] = e
        }
        // entry.storeLocked就是调用atomic.StorePointer()，让entry.p指向value。
        // 为什么此处不用atomic.CompareAndSwapPointer()?答案是当前没有一个协程会可能
        // 同时将entry.p设置为expunged就没必要用CAS，具体为什么读者应该能够想明白。因为
        // 将entry.p设置为expunged是在写时复制过程中执行的，而这个过程必须加锁，而此处已经
        // 完成所操作，所以就直接赋值。
        e.storeLocked(&value)
        // 以上代码笔者任务可以做一点点优化，如下所示：
        //  if atomic.CompareAndSwapPointer(&e.p, expunged, unsafe.Pointer(&value)) {
        //      m.dirty[key] = e
        //  } else {
        //      e.storeLocked(&value)
        //  }
        // 以上代码省去了将expunged变为nil后再赋值的过程，而是直接将expunged改为具体的值，
        // 然后写入dirty，如果不是expunged就直接修改值。这种小优化在值为expunged情况下
        // 少一次原子写操作。
    } else if e, ok := m.dirty[key]; ok {
        // 如果dirty中有则更新dirty中的值
        e.storeLocked(&value)
    } else {
        // dirty中没有只能在dirty中插入新的记录，此处需要注意，dirty中没有有两种可能：
        // 1.dirty=nil，此时要做的就是前面说了很多遍的写时复制
        // 2.dirty!=nil，此时直接写入dirty即可
        // golang还是不错的，空指针的map依然可以查找，如果是C++早就不知道崩溃多少回了~
        // 此处用read.amended做判断笔者认为语义上并不通畅，感觉if nil == m.dirty会更好。
        // amended变量的注释是dirty是否包含一些read中没有的记录，因为只有写操作并且read中
        // 的情况下才会复制，所以只要复制amended必然为true，dirty必然非nil。此处用
        // amended逻辑上不会错误，但是笔者认为用dirty指针判断语义更顺畅。
        if !read.amended {
            // dirtyLocked就是实现写时复制的函数，见下文详解
            m.dirtyLocked()
            // 复制与amended=true是强关联，读者在解析LoadOrStore()接口的时候还会看到
            m.read.Store(readOnly{m: read.m, amended: true})
        }
        // dirty中插入新的记录，也是amended=true的原因
        m.dirty[key] = newEntry(value)
    }
    m.mu.Unlock()
}

func (e *entry) tryStore(i *interface{}) bool {
    for {
        p := atomic.LoadPointer(&e.p)
        // 这句足以证明笔者前面对于expunged的解释，他等同于key不存在
        if p == expunged {
            return false
        }
        // 通过CAS的方式多协程竞争写，为什么不是atomic.StorePointer()?因为其他协程写时复制
        // 时会把p改为expunged，一旦p为expunged就不可以在写入了。
        if atomic.CompareAndSwapPointer(&e.p, p, unsafe.Pointer(i)) {
            return true
        }
    }
}

// dirtyLocked实现写时复制
func (m *Map) dirtyLocked() {
    // 这有何必呢？在之前的用dirty指针判断多好？难道说笔者有什么细节没有注意到么？
    // 左思右想还是没有想到，哪位读者知道烦请告知笔者。
    if m.dirty != nil {
        return
    }
    // 下面的代码比较简单就是在复制read的记录，其中entry.tryExpungeLocked()是一个关键函数
    // 他是把的entry.p==nil的记录设置为entry.p=expunged，目的很简单，因为nil不会被拷贝到dirty
    // 那么read此后也不能在对其更新，否则read就不是dirty的子集了。不用再解释了，应该够明白了。
    read, _ := m.read.Load().(readOnly)
    m.dirty = make(map[interface{}]*entry, len(read.m))
    for k, e := range read.m {
        if !e.tryExpungeLocked() {
            // 没有被删除的记录被拷贝到dirty中
            m.dirty[k] = e
        }
    }
}

// tryExpungeLocked把entry.p=nil的entry标记为删除
func (e *entry) tryExpungeLocked() (isExpunged bool) {
    p := atomic.LoadPointer(&e.p)
    for p == nil {
        if atomic.CompareAndSwapPointer(&e.p, nil, expunged) {
            return true
        }
        p = atomic.LoadPointer(&e.p)
    }
    return p == expunged
}

理解sync.Map的Load和Store两个接口的实现，其他接口的实现相信读者基本也能想象得到，甚至可以自己实现，鉴于文章的完整性，笔者对Delete和Range两个接口做简单说明，LoadOrStore留给读者。

func (m *Map) Delete(key interface{}) {
    // 首先在read里查找key是否存在
    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]
        if !ok && read.amended {
            // read里没有，就直接删除dirty即可，因为dirty是读写的，所以直接删除
            delete(m.dirty, key)
        }
        m.mu.Unlock()
    }
    if ok {
        // 如果在read找到了，调用entry.delete()，见下文
        e.delete()
    }
}
func (e *entry) delete() (hadValue bool) {
    for {
        p := atomic.LoadPointer(&e.p)
        // 如果是nil或者expunged说明已经被删除
        if p == nil || p == expunged {
            return false
        }
        // 将value指针设置为nil
        if atomic.CompareAndSwapPointer(&e.p, p, nil) {
            return true
        }
    }
}
func (m *Map) Range(f func(key, value interface{}) bool) {
    // 如果dirty中的数据不比read多，那么直接遍历read即可
    read, _ := m.read.Load().(readOnly)
    if read.amended {
        m.mu.Lock()
        read, _ = m.read.Load().(readOnly)
        if read.amended {
            // dirty数据更多，则将整个dirty更新到read然后清空dirty
            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
        }
    }
}

至此，笔者把sync.Map基本总结如下：

  1. 有两个map，一个只读read，一个读写dirty，访问read无锁操作，访问dirty需要锁操作；
  2. 查询(Load)时先查找read，如果read中没有在查找dirty，如果查找read的miss次数太多，将dirty更新到read并清空dirty；
  3. 删除(Delete)时如果read中有指定key则将value设置为nil，否则直接删除dirty中指定key
  4. 插入(Store)时如果read中指定key存在并且value不是expunged，那么直接将新的值更新到read中；如果value是expunged则修改为nil再次复用；如果read中没有指定key，则执行写时复制并将新的值插入dirty，同时read的amended标记true；
  5. 能够触发dirty更新到read的条件有两个，一个是miss次数，一个就是调用Range，如果使用sync.Map频繁的Range和插入新纪录，会让sync.Map忙于写时复制，性能会有所下降；

sync.Map扩展

concurrent.Map在sync.Map基础上扩展了Update接口，Update接口设计目标是支持并发更新同一个value对象。Update不同于Store，Store最终只有一个协程的value会被写入，其他的都会被覆盖，而Update可以将所有协程的更新都保证跟新到value对象中，除非这些协程有更新了value对象相同的字段(field)。

因为有了上一章节对sync.Map的详解，本章节扩展内容理解会非常容易，关键在于sync.Map本身具备这个能力，无非没有开发专门接口而已

// Update会持续调用tryUpdate()直到更新成功，因为过程中可能会冲突，就像CAS失败一样。每次更新前
// 都会将当前值通过tryUpdate传给调用者，调用者需要参考传入的value，因为其中可能包含已完成的更新，
// 调用者需要将更新的value通过tryUpdate返回，如果不需要更新则返回false
func (m *Map) Update(key interface{}, tryUpdate func(interface{}) (interface{}, bool)) bool {
    for {
        // load()函数实现与Load一样，只是返回值变成了*entry
        e, ok := m.load(key)
        if ok {
            // 即便entry存在，也可能value是空的亦或是expunged，这种entry也视为value不存在
            _, ok = e.load()
        }
        // 如果value不存在则用LoadOrStore()实现.
        if !ok {
            if value, ok := tryUpdate(nil); !ok {
                return false
            } else if _, loaded := m.LoadOrStore(key, value); !loaded {
                return true
            }
        // 如果value存在，让entry尝试更新
        } else if updated, ok := e.tryUpdate(tryUpdate); !ok {
            return false
        } else if updated {
            return true
        }
    }
}

func (e *entry) tryUpdate(tryUpdate func(interface{}) (interface{}, bool)) (bool, bool) {
    // 再次校验，因为可能被更新过
    p := atomic.LoadPointer(&e.p)
    if p == expunged || p == nil {
        return false, true
    }
    // 调用tryUpdate()获取更新的value
    value, ok := tryUpdate(*(*interface{})(p))
    if !ok {
        return false, false
    }
    for {
        // 当前值与调用tryUpdate()之前的值相同才能更新，否则会覆盖其他已完成的更新
        if atomic.CompareAndSwapPointer(&e.p, p, unsafe.Pointer(&value)) {
            return true, true
        }
        p = atomic.LoadPointer(&e.p)
        if p == expunged || p == nil {
            return false, true
        }
        value, ok = tryUpdate(*(*interface{})(p))
        if !ok {
            return false, false
        }
    }
}

现在笔者来解释一下什么场景会用到Update接口，比如gmap中的CAS功能，该功能和etcd的功能相似，就是比较value的revision，如果与指定的revision相同就更新。在sync.Map存储的就是版本化的value，定义如下：

type revisionedValue struct {
    Revision uint64
    Value    interface{}
}

所以此时就需要concurrent.Map能够原子的实现获取revisionedValue、比较revision、更新revisionedValue。tryUpdate回调函数让Update非常灵活，concurrent.Map将当前值传给调用者让其决定是否更新，可以做比较(类似CAS)，也可以是其他的判断。

当然，这样的需求也是可以学习sync.Map抽象entry的方式解决，即在sync.Map存储的是*entry，然后对entry的各种并发操作交给使用者实现。这肯定是没问题的，笔者扩展sync.Map的目标是希望把类似的功能统一在concurrent.Map实现，这样就不用每次使用再实现一遍了。

除了Update，笔者还扩展了Clear、Copy两个接口。Clear是用来原子清空Map的，因为sync.Map是结构体，通过赋新值不是原子的，除非通过用*sync.Map类型并通过原子设置指针的方式。

LEAQ 0(IP), CX          [3:7]R_PCREL:type.sync.Map
MOVQ CX, 0(SP)
MOVQ AX, 0x8(SP)
CALL 0x4be              [1:5]R_CALL:runtime.typedmemclr
以上是下面对sync.Map类型变量x赋值代码的汇编，证明赋值的方式是不原子的。
var x sync.Map
x = sync.Map{}

因为sync.Map有很多非指针的使用场景，所以Clear也是有应用的地方，代码如下所示：

func (m *Map) Clear() {
    // 实现很简单，就是清空read和dirty
    m.mu.Lock()
    m.read.Store(readOnly{})
    m.dirty, m.misses = nil, 0
    m.mu.Unlock()
}

而Copy接口支持原子的将一个map拷贝到concurrent.Map中，因为concurrent.Map存储的map类型是map[interface{}]*entry，而输入map类型无法预知，所以类型转换难以避免。为了最小化开销，笔者定义了Ranger类型，如下代码所示：

// Ranger主要功能是对输入map的遍历，这样只需要读取一次输入map，写入一次输出map，开销最小
type Ranger interface {
    Len() int
    Range(func(key, value interface{}) bool)
}

func (m *Map) Copy(r Ranger) {
    // 构造一个与输入map一样大小的map
    read := readOnly{m: make(map[interface{}]*entry, r.Len())}
    // 遍历输入map然后逐一插入到新map中
    r.Range(func(key, value interface{}) bool {
        read.m[key] = &entry{p: unsafe.Pointer(&value)}
        return true
    })
    // 最后将新的map写入read并清空dirty完成原子拷贝
    m.mu.Lock()
    m.read.Store(read)
    m.dirty, m.misses = nil, 0
    m.mu.Unlock()
}

至于Clear和Copy的需求来自于哪里，当然是gmap，因为笔者开篇就提到了，因为gmap的需求才对sync.Map进行扩展。这两个接口主要用于gmap从snapshot复原。

m0_67390379
关注
专栏目录
sync.Map详解
weixin_41335923的博客
04-09 1万+
导航Golang sync.Map 详解简单的介绍一下 Golang MapMap 使用sync.Mapsync.Map 是什么sync.Map 使用sync.Map 剖析sync.map 整体结构参考参考 Golang sync.Map 详解 原生的 Go Map 在并发读写场景下经常会遇到 panic 的情况。造成的原因是 map 是非线性安全的，并发读写过程中 map 的数据会被写乱。 而一般情况下，解决并发读写 map 的思路是加锁，或者把一个 map 切分成若干个小 map，对 key 进行哈希。
golang中的map与sync.map解析
xixisuli的博客
04-10 3160
golang中的map与sync.map map map的底层实现 golang中的map采用了HashTable的实现，通过数组+链表实现的。一个哈希表会有一定数量的桶，哈希表将键值对均匀存储到这些桶中。哈希表在存储键值对时，会先用哈希函数把键值转换为哈希值，哈希表先用哈希值的低几位去定位到一个哈希桶，然后再去这个哈希桶中查找这个键。由于键值对总是被捆绑在一起存在，一旦找到了键，就找到了值。g...
concurrent.Map:扩展sync.Map
weixin_42663840的博客
08-17 1万+
expunged的意思就是map中这个key已删除，它与nil意义不同，nil表示value被删除，但是key还是可以复用的，而expunged表示key也被删除了。举一个例子，当调用sync.Map.Delete()删除某个键值对的时候，如果这个键值对也在readOnly里，那么该键的entry.p被设置为nil表示value被删除；但是此时再调用sync.Map.Store()，因为readOnly里key已经存在，所以直接设置entry.p即可，这样就可以避免再write-on-copy。这又是syn
ConcurrentHashMap的transfer阅读
栋幺栋幺-的博客
11-17 579
[TOC] 流程图 ![concurrentHashMap#transfer](https://img-blog.csdnimg.cn/60ea534ce2044077ac6fb4919bbdcf9c.jpg) `ConcurrenthashMap` 的 `transfer` 主要是用于扩容重组阶段，当内部数组的容量值超过阈值时，将触发扩容重组， `transfer` 是该过程的主要实现。 相关概念 1. `ConcurrentHashMap` 中，使用一个字段复用了多种功能，如：阈值控制、内部
HashMap与ConCurrentHashMap
程序员小董的专栏
07-24 1443
大家都知道HashMap是线程不安全的,那么到底是怎么个不安全法呢? 例如下面这个例子 package algorithms; import java.util.HashMap; import java.util.Map; import java.util.concurrent.ConcurrentHashMap; public class TestHashMap { publi
go中的sync.Map
panxj856856的博客
05-18 846
Go 1.9中的sync.Map提供了线程安全的map，它的优点总结如下：（网上找的）1.空间换时间。 通过冗余的两个数据结构(read、dirty),实现加锁对性能的影响。2.使用只读数据(read)，避免读写冲突。3.动态调整，miss次数多了之后，将dirty数据提升为read。4.double-checking。5.延迟删除。 删除一个键值只是打标记，只有在提升dirty的时候才清理删除的...
由浅入深聊聊Golang的sync.Map
热门推荐
咖啡色的羊驼
07-21 1万+
前言 今天在技术群中有小伙伴讨论并发安全的东西，其实之前就有写过map相关文章：由浅入深聊聊Golang的map。但是没有详细说明sync.Map是怎么一回事。 回想了一下，竟然脑中只剩下“两个map、一个只读一个读写，xxxxx”等，关键词。有印象能扯，但是有点乱，还是写一遍简单记录一下吧。 1.为什么需要sync.Map？ 2.sync.Map如何使用？ 3.理一理sync.Map源码实现？ ...
Python并发concurrent.futures和asyncio实例
12-20
标准库中的`concurrent.futures`模块提供了一种简洁的接口来管理和执行并发任务，它支持线程池和进程池两种并发模型。 `ThreadPoolExecutor`是`concurrent.futures`模块中的一个关键类，用于在多个线程中执行任务。...
concurrent map使用
努力努力再努力L
07-07 1730
concurrent map使用 目录 概述 例子 1. 概述 Go语言原生的map类型并不支持并发读写。concurrent-map提供了一种高性能的解决方案：通过对内部map进行分片，降低锁粒度，从而达到最少的锁等待时间(锁冲突) 在Go 1.9之前，go语言标准库中并没有实现并发map。在Go 1.9中，引入了sync.Map。新的sync.Map与此concurrent-map有几个关键区别。 标准库中的sync.Map是专为append-only场景设计的。因此，如果想将Map用于一个
concurrent-map 和 sync.Map，我该选择哪个？
轩脉刃的刀光剑影
02-21 259
世上本没有烦恼，选择多了，便有了幸福的烦恼。你好，我是轩脉刃。官方的map并不是线程安全的，如果我们在多线程中并发对一个map进行读写操作，是会引发panic的。解决方案除了使用锁来对map进行保护外，还有两种方式：一，开源项目 concurrent-map 提供了可以用来做并发安全的map二，Go1.9之后，标准库提供了一个sync.Map这两种并发安全的map，我们应该怎么选择呢？在concu...
Go 源码之 Sync.Map
最新发布
五岁小孩的博客
03-26 861
Go 源码之 Sync.Map
ConcurrentHashMap源码分析（二）
W1040585666的博客
09-05 683
ConcurrenHashMap 扩容原理解析
cannot call pointer method on ...
慌
07-09 5161
type Student struct { Name string Score int } func (Student *Student) String() string { return fmt.Sprintf("Student(name: %s, score: %d)",Student.Name,Student.Score) } type Array struct { data ...
ConcurrentHashMap的实现原理
forever-and-ever的博客
08-27 2731
HashMap是Java当中很常用的数据结构。 但是HashMap不是线程安全的，单线程环境下还可以正常使用，不过在并发插入元素的时候有可能出现带环链表，让下一次读操作出现死循环。 那么什么样的哈希数据结构可以保证线程安全呢？ 线程安全的哈希数据结构主要有HashTable和ConcurrentHashMap。而ConcurrentHashMap比HashTable的扩展性更好。 在多并发...
第一天..
qw1231rt的博客
02-24 107
第一天
J.U.C--分段锁
惜暮
01-10 4209
前言：在分析ConcurrentHashMap的源码的时候，了解到这个并发容器类的加锁机制是基于粒度更小的分段锁，分段锁也是提升多并发程序性能的重要手段之一。 在并发程序中，串行操作是会降低可伸缩性，并且上下文切换也会减低性能。在锁上发生竞争时将通水导致这两种问题，使用独占锁时保护受限资源的时候，基本上是采用串行方式—-每次只能有一个线程能访问它。所以对于可伸缩性来说最大的威胁就是独占锁。
go语言 sync.map遍历时删除可以全部删除
papaya的博客
06-18 1万+
结论： sync.map遍历时删除操作是完全的，且可以完全删除指定的元素 实验结果下图： 代码如下： package main import ( "fmt" "sync" ) // 遍历时删除所有的偶数,结果:确实删除了所有的偶数 func fun1() { x := sync.Map{} // 构建 for i := 0; i < 100; i++ { x....
ConcurrentHashMap的锁
秀才的专栏
08-24 7260
ConcurrentHashMap是Java5中新增加的一个线程安全的Map集合。对于ConcurrentHashMap是如何提高其效率的，可能大多人只是知道它使用了多个锁代替HashTable中的单个锁，也就是锁分离技术（Lock Stripping）。实际上，ConcurrentHashMap对提高并发方面的优化，还有一些其它的技巧在里面（比如在get操作的时候它是否也使用了锁来保护？）。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值