大白话讲讲 Go 语言的 sync.Map(一)

2023-07-19 23:36:32 浏览数 (3)

阅读本文大约需要 4.25 分钟。

程序是枯燥乏味的。

在讲 sync.Map 之前,我们先说说什么是 map(映射)。

我们每个人都有身份证号码,如果我需要从身份证号码查到对应的姓名,用 map 存储是非常合适的。

代码语言:txt复制
map[000...001] = 张三
代码语言:txt复制
map[000...002] = 李四
代码语言:txt复制
...
代码语言:txt复制
map[999...993] = 钱五

身份证号码有 18 位,如果要知道 111...002 这个人叫什么名字,没有 map 我只能从 000...001 一个一个往下查找,效率是非常低的。

咦,那 map 不就是在查字典嘛?根据拼音、笔画、部首,可以查到某个字的具体含义!

没错!Go 语言中的 map 在 Python 语言称之为 dict(字典),意思是完全一样的。

再设想另一个场景,

如果 map 存储的是每个人银行卡里的余额(同一所银行),那就是这样子的形式(账本):

代码语言:txt复制
map[张三] = 100.00
代码语言:txt复制
map[李四] = 600.00
代码语言:txt复制
map[钱五] = 800.00

某一天,李四要转账给张三和钱五,各 100 元,银行为了提高转账速度,安排了两名交易员同时处理。

交易员 A 和交易员 B 瞄了一眼账本,开始操作:

交易员 A:李四的余额是 600 元,张三的余额是 100 元,转账后李四的余额是 500 元,张三的余额是 200 元。

交易员 B:李四的余额是 600 元,钱五的余额是 800 元,转账后李四的余额是 500 元,钱五的余额是 900 元。

账本变成这个样子:

代码语言:txt复制
map[张三] = 200.00
代码语言:txt复制
map[李四] = 500.00
代码语言:txt复制
map[钱五] = 900.00

账本出问题了!银行凭空多出 100 元!

一个一个来不就完了?可是你别忘了,我们是为了提高转账速度,才这样做的。

在 Go 1.9 之前,大部分人还真的就是这么干的!

代码语言:go复制
type Name        string
type Money       string
type AccountBook struct {
    lock sync.RWMutex
    m    map[Name]Money
}

sync.RWMutex 是一个读写锁,在写入数据的时候,阻止其他人写入、读取,让其他人处于等待的状态,直到操作完再释放锁。

本质上,上面的例子,就是读取到了脏数据,如果能等待交易员 A 把账本改完,交易员 B 再去操作,账本就不会乱了。

如果你不知道锁是什么,我再给你讲一个例子:

张三和李四两个人,需要打印不同的文档,

打印机只有一台,放在打印室里,打印室有钥匙,

钥匙只有一把,谁拿到打印室的钥匙,谁就能进去打印。

打印室的钥匙,就是锁。

张三拿了钥匙,进去打印室,打印完了,就出来后把钥匙给了李四,李四打印完了把钥匙还回打印室(真是有条不紊)。

我花费这么多笔墨说 map,也是真的希望,就算你不是程序员,不是 Go 语言后端工程师,也可以看懂我的文章。

不得不承认,把复杂琐碎的东西,讲通透、讲明白是一种本事。

教科书讲 if...else、switch、while (true) 、异常和捕获,

如果有下面的图片这么形象生动就好了:

图

看到图片的那一瞬间,真的把我逗乐了。

多么形象生动啊!

回头想想,大学的 C 语言课程是多少人的噩梦,老师都是照书念的,完全听不进去。

我也不感慨了,咱们还是回归正题。

刚刚讲了 map,接着往下讲 sync.Map,它用来解决什么问题?

我们知道 map 锁的形式,还是有等待的现象出现,不符合我们提高转账速度的初衷。

而 sync.Map 有一个非常巧妙的抽象(entry 的 p 指向具体数据的位置):

代码语言:go复制
var m map[key]*entry

type entry struct {
    p unsafe.Pointer
}

还是看回上面的例子,做个小修改——原先的 map 是一个小账本,我们又做了一个大账本,原先的账本变成:

代码语言:txt复制
map[张三] = 记录在大账本第 6 页(翻开第 6 页,内容是:100.00)
代码语言:txt复制
map[李四] = 记录在大账本第 7 页(翻开第 7 页,内容是:600.00)
代码语言:txt复制
map[钱五] = 记录在大账本第 8 页(翻开第 8 页,内容是:800.00)

假设小账本 map 的张三、李四只能一个一个排队改,没办法做到同时修改,

而我们有了大账本,可以直接同时修改张三、李四纸上的内容(两页纸互不影响了)。

(真实的计算机世界确实如此,具体是怎么样的,留一个思考题,下一篇文章细细解答)

更通俗的讲,sync.Map 通过 entry 这个中间层的抽象,

把最开始整个小账本的冲突(影响所有人),降低到大账本上的某一页纸(只影响某个人),

用计算机术语讲,就是降低锁的粒度,从而提升性能!

另一方面,假设李四销户了,

我可以选择在第 7 页的纸上写,已销户(expunged),

代码语言:go复制
// expunged is an arbitrary pointer that marks
// entries which have been deleted from the 
// dirty map.
var expunged = unsafe.Pointer(new(interface{}))

如果是以前,只能把小账本,李四那一张纸撕掉,

而撕掉小账本的某一页,也会影响所有人使用小账本,

如果下次要把撕掉的那一页放回去,也是非常麻烦,

在计算机的世界里,这是资源的分配和回收的问题,会严重影响程序运行效率。

写了一千七百字,直到现在只是冰山一角,sync.Map 的巧妙之处,远远不止 entry 的抽象。

今天先消化这么多,下一篇文章会更深层次一些,敬请期待!


文章来源于本人博客,发布于 2021-05-04,原文链接:https://imlht.com/archives/234/

0 人点赞