极客时间已完结课程限时免费阅读

34 | 并发安全字典sync.Map （上）

34 | 并发安全字典sync.Map （上）-极客时间

34 | 并发安全字典sync.Map （上）

2018-10-29 郝林 来自北京
《Go语言核心36讲》
课程介绍

讲述：黄洲君

时长08:20大小7.62M

在前面，我几乎已经把 Go 语言自带的同步工具全盘托出了。你是否已经听懂了会用了呢？
无论怎样，我都希望你能够多多练习、多多使用。它们和 Go 语言独有的并发编程方式并不冲突，相反，配合起来使用，绝对能达到“一加一大于二”的效果。
当然了，至于怎样配合就是一门学问了。我在前面已经讲了不少的方法和技巧，不过，更多的东西可能就需要你在实践中逐渐领悟和总结了。
我们今天再来讲一个并发安全的高级数据结构：sync.Map。众所周知，Go 语言自带的字典类型map并不是并发安全的。

前导知识：并发安全字典诞生史

换句话说，在同一时间段内，让不同 goroutine 中的代码，对同一个字典进行读写操作是不安全的。字典值本身可能会因这些操作而产生混乱，相关的程序也可能会因此发生不可预知的问题。
在sync.Map出现之前，我们如果要实现并发安全的字典，就只能自行构建。不过，这其实也不是什么麻烦事，使用 sync.Mutex或sync.RWMutex，再加上原生的map就可以轻松地做到。
GitHub 网站上已经有很多库提供了类似的数据结构。我在《Go 并发编程实战》的第 2 版中也提供了一个比较完整的并发安全字典的实现。它的性能比同类的数据结构还要好一些，因为它在很大程度上有效地避免了对锁的依赖。
尽管已经有了不少的参考实现，Go 语言爱好者们还是希望 Go 语言官方能够发布一个标准的并发安全字典。
经过大家多年的建议和吐槽，Go 语言官方终于在 2017 年发布的 Go 1.9 中，正式加入了并发安全的字典类型sync.Map。
这个字典类型提供了一些常用的键值存取操作方法，并保证了这些操作的并发安全。同时，它的存、取、删等操作都可以基本保证在常数时间内执行完毕。换句话说，它们的算法复杂度与map类型一样都是O(1)的。
在有些时候，与单纯使用原生map和互斥锁的方案相比，使用sync.Map可以显著地减少锁的争用。sync.Map本身虽然也用到了锁，但是，它其实在尽可能地避免使用锁。
我们都知道，使用锁就意味着要把一些并发的操作强制串行化。这往往会降低程序的性能，尤其是在计算机拥有多个 CPU 核心的情况下。
因此，我们常说，能用原子操作就不要用锁，不过这很有局限性，毕竟原子只能对一些基本的数据类型提供支持。
无论在何种场景下使用sync.Map，我们都需要注意，与原生map明显不同，它只是 Go 语言标准库中的一员，而不是语言层面的东西。也正因为这一点，Go 语言的编译器并不会对它的键和值，进行特殊的类型检查。
如果你看过sync.Map的文档或者实际使用过它，那么就一定会知道，它所有的方法涉及的键和值的类型都是interface{}，也就是空接口，这意味着可以包罗万象。所以，我们必须在程序中自行保证它的键类型和值类型的正确性。
好了，现在第一个问题来了。今天的问题是：并发安全字典对键的类型有要求吗？
这道题的典型回答是：有要求。键的实际类型不能是函数类型、字典类型和切片类型。
解析一下这个问题。 我们都知道，Go 语言的原生字典的键类型不能是函数类型、字典类型和切片类型。
由于并发安全字典内部使用的存储介质正是原生字典，又因为它使用的原生字典键类型也是可以包罗万象的interface{}；所以，我们绝对不能带着任何实际类型为函数类型、字典类型或切片类型的键值去操作并发安全字典。
由于这些键值的实际类型只有在程序运行期间才能够确定，所以 Go 语言编译器是无法在编译期对它们进行检查的，不正确的键值实际类型肯定会引发 panic。
因此，我们在这里首先要做的一件事就是：一定不要违反上述规则。我们应该在每次操作并发安全字典的时候，都去显式地检查键值的实际类型。无论是存、取还是删，都应该如此。
当然，更好的做法是，把针对同一个并发安全字典的这几种操作都集中起来，然后统一地编写检查代码。除此之外，把并发安全字典封装在一个结构体类型中，往往是一个很好的选择。
总之，我们必须保证键的类型是可比较的（或者说可判等的）。如果你实在拿不准，那么可以先通过调用reflect.TypeOf函数得到一个键值对应的反射类型值（即：reflect.Type类型的值），然后再调用这个值的Comparable方法，得到确切的判断结果。

知识扩展

问题 1：怎样保证并发安全字典中的键和值的类型正确性？（方案一）

简单地说，可以使用类型断言表达式或者反射操作来保证它们的类型正确性。
为了进一步明确并发安全字典中键值的实际类型，这里大致有两种方案可选。
第一种方案是，让并发安全字典只能存储某个特定类型的键。
比如，指定这里的键只能是int类型的，或者只能是字符串，又或是某类结构体。一旦完全确定了键的类型，你就可以在进行存、取、删操作的时候，使用类型断言表达式去对键的类型做检查了。
一般情况下，这种检查并不繁琐。而且，你要是把并发安全字典封装在一个结构体类型里面，那就更加方便了。你这时完全可以让 Go 语言编译器帮助你做类型检查。请看下面的代码：
type IntStrMap struct {
m sync.Map
}
func (iMap *IntStrMap) Delete(key int) {
iMap.m.Delete(key)
}
func (iMap *IntStrMap) Load(key int) (value string, ok bool) {
v, ok := iMap.m.Load(key)
if v != nil {
value = v.(string)
}
return
}
func (iMap *IntStrMap) LoadOrStore(key int, value string) (actual string, loaded bool) {
a, loaded := iMap.m.LoadOrStore(key, value)
actual = a.(string)
return
}
func (iMap *IntStrMap) Range(f func(key int, value string) bool) {
f1 := func(key, value interface{}) bool {
return f(key.(int), value.(string))
}
iMap.m.Range(f1)
}
func (iMap *IntStrMap) Store(key int, value string) {
iMap.m.Store(key, value)
}
如上所示，我编写了一个名为IntStrMap的结构体类型，它代表了键类型为int、值类型为string的并发安全字典。在这个结构体类型中，只有一个sync.Map类型的字段m。并且，这个类型拥有的所有方法，都与sync.Map类型的方法非常类似。
两者对应的方法名称完全一致，方法签名也非常相似，只不过，与键和值相关的那些参数和结果的类型不同而已。在IntStrMap类型的方法签名中，明确了键的类型为int，且值的类型为string。
显然，这些方法在接受键和值的时候，就不用再做类型检查了。另外，这些方法在从m中取出键和值的时候，完全不用担心它们的类型会不正确，因为它的正确性在当初存入的时候，就已经由 Go 语言编译器保证了。
稍微总结一下。第一种方案适用于我们可以完全确定键和值的具体类型的情况。在这种情况下，我们可以利用 Go 语言编译器去做类型检查，并用类型断言表达式作为辅助，就像IntStrMap那样。

总结

我们今天讨论的是sync.Map类型，它是一种并发安全的字典。它提供了一些常用的键、值存取操作方法，并保证了这些操作的并发安全。同时，它还保证了存、取、删等操作的常数级执行时间。
与原生的字典相同，并发安全字典对键的类型也是有要求的。它们同样不能是函数类型、字典类型和切片类型。
另外，由于并发安全字典提供的方法涉及的键和值的类型都是interface{}，所以我们在调用这些方法的时候，往往还需要对键和值的实际类型进行检查。
这里大致有两个方案。我们今天主要提到了第一种方案，这是在编码时就完全确定键和值的类型，然后利用 Go 语言的编译器帮我们做检查。
在下一次的文章中，我们会提到另外一种方案，并对比这两种方案的优劣。除此之外，我会继续探讨并发安全字典的相关问题。
感谢你的收听，我们下期再见。
戳此查看 Go 语言专栏文章配套详细代码。
分享给需要的人，Ta购买本课程，你将得18元
生成海报并分享

赞 15

提建议

© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
上一篇
33 | 临时对象池sync.Pool
下一篇
35 | 并发安全字典sync.Map (下)
unpreview
 写留言

精选留言(18)

  • 虢國技醬
    2019-03-01
    打卡，后面的留言越来越少，看来有点难度了，加油啃下它！后面的兄弟
    29
  • 闫飞
    2019-07-17
    我觉得这里的主要麻烦之一是golang不支持泛型编程这一重大的范式，用户不得不在上层代码里面做繁琐的检查。
    共 2 条评论
    8
  • 给力
    2020-05-18
    并发安全的字典里少了两个方法，比如已经有多少key，我们有什么解决办法没，只能自己每次插入或者删除key记录元素个数变化吗？

    作者回复: 是的，这种并发安全字典是在一些特定场景下用的，比如配置信息同步、批量计数等等。在这类场景下，键值对数量并不是关键问题。如果你想找通用的，可以参看一下这个：https://github.com/gopcp/example.v2/tree/master/src/gopcp.v2/chapter5/cmap

    3
  • mkii
    2021-02-28
    这下可以把项目里丑陋的mutex+map去掉了👍👍👍
    1
  • MClink
    2022-07-10
    感觉并发编程和日常的业务CRUD还是有很多区别的，一般业务很多东西都用不上。

    作者回复: 程序例有共享程序实体或者资源的时候就肯定会用上并发编程的

  • DayDayUp
    2022-05-08
    老师，看到有人用github.com/orcaman/concurrent-map，不知道二者有何区别呢？

    作者回复: 我没研究过那个concurrent-map。你可以功能测试比较一下两者的功能差异和API便捷度，并用基准测试比较一下两者的性能。

  • 寄居与蟹
    2022-03-25
    打卡，冲
  • jxs1211
    2021-10-30
    能用原子操作就不要用锁，不过这很有局限性，毕竟原子只能对一些基本的数据类型提供支持。问题： atomic.Value不是可以支持除了二进制和int类型以外的数据类型的原子操作吗，还是其仍有一定局限性，另外atomic.Value使用是否有禁忌或者需要注意的地方

    作者回复: atomic.Value 原则上可以存任何值，但对于引用类型的值，要避免外界直接去修改这个值，否则 Value 的保护就形同虚设了。

  • jxs1211
    2021-10-30
    我们都知道，使用锁就意味着要把一些并发的操作强制串行化。这往往会降低程序的性能，尤其是在计算机拥有多个 CPU 核心的情况下。问题： 1 一个程序的每个进程只能跑在一个cpu的核心上，对吗？ 2 每个进程中的锁只会控制该进程内部的goroutine串行执行，应该是不能控制其他进程里的goroutine的吧，那这里多核CPU下使用互斥锁更加影响性能的意思是指什么

    作者回复: 1. 不对，进程与CPU核心之间一般不会有特定的对应关系，除非程序里手动锁定一对一的关系。大多数程序一般都会充分利用所有的CPU核心。 2. 每个进程的锁都只能控制当前进程中的代码执行流程。至于你的疑问，请参考第一个问题的答案：程序一般会同时使用多个CPU核心。

    共 2 条评论
  • lesserror
    2021-08-21
    郝林老师，在 IntStrMap 的方法中这种 值点上 括号 string int。 key.(int) 、value.(string) 、a.(string) 代表的是将对应的数据转换为 string和 int 类型吧？ 我这样理解对吗？

    作者回复: v.(T) 是在做类型转换断言，把 v 的类型转换成 T，如果转换失败就抛出 panic，如果不想让它抛 panic，可以： v2, ok := v.(T) 如果 ok 为 false，就说明失败了；如果 ok 为 true 就说明成功了，此时 v2 就是转换后的值。

  • 下雨天
    2020-10-19
    我最近遇到一个问题，sync.Map之间赋值操作之后，会变成线程不安全的map（原始map），赋值之后可能会导致底的原始map操作出现读写，导致问题。
    共 1 条评论
  • 漂泊的小飘
    2020-08-24
    什么字典的并发写会造成fatal error呢，简单的原理是什么？

    作者回复: 你没说上下文，我没法解释啊。

  • 涛声依旧
    2020-03-28
    这个章节我又学习一招
  • 疯琴
    2020-01-04
    我觉得老师的示例代码要是对 sync.map 做一些可能引发冲突的并发操作就更好了。

    作者回复: 这个不容易复现，尤其对于简单的示例来说。

  • 猫九
    2019-12-08
    打卡
  • 羽仔
    2019-10-22
    Fine.
  • 么乞儿
    2019-04-26
    打卡!
  • show
    2019-03-15
    打卡，读完了，还需要实践下