在 Golang 中的 map 结构,在删除键值对的时候,并不会真正的删除,而是标记。那么随着键值对越来越多,会不会造成大量内存浪费?
首先答案是会的,很有可能导致 OOM,而且针对这个还有一个讨论:https://github.com/golang/go/issues/20135。大致的意思就是在很大的map
中,delete
操作没有真正释放内存而可能导致内存 OOM。
所以一般的做法:就是 重建map。而go-zero
中内置了safemap
的容器组件。safemap
在一定程度上可以避免这种情况发生。
那首先我们看看go
原生提供的map
是怎么删除的?
原生map删除
1 package main
2
3 func main() {
4 m := make( map[ int] string, 9)
5 m[ 1] = "hello"
6 m[ 2] = "world"
7 m[ 3] = "go"
8
9 v, ok := m[ 1]
10 _, _ = fn(v, ok)
11
12 delete(m, 1)
13 }
14
15 func fn(v string, ok bool) (string, bool) {
16 return v, ok
17 }
测试代码如上,我们可以通过go tool compile -S -N -l testmap.go | grep "CALL"
:
0x0071 00113 (test/testmap.go:4) CALL runtime.makemap(SB)
0x0099 00153 (test/testmap.go:5) CALL runtime.mapassign_fast64(SB)
0x00ea 00234 (test/testmap.go:6) CALL runtime.mapassign_fast64(SB)
0x013b 00315 (test/testmap.go:7) CALL runtime.mapassign_fast64(SB)
0x0194 00404 (test/testmap.go:9) CALL runtime.mapaccess2_fast64(SB)
0x01f1 00497 (test/testmap.go:10) CALL "".fn(SB)
0x0214 00532 (test/testmap.go:12) CALL runtime.mapdelete_fast64(SB)
0x0230 00560 (test/testmap.go:7) CALL runtime.gcWriteBarrier(SB)
0x0241 00577 (test/testmap.go:6) CALL runtime.gcWriteBarrier(SB)
0x0252 00594 (test/testmap.go:5) CALL runtime.gcWriteBarrier(SB)
0x025c 00604 (test/testmap.go:3) CALL runtime.morestack_noctxt(SB)
执行第12行的delete
,实际执行的是runtime.mapdelete_fast64
。
这些函数的参数类型是具体的int64
,mapdelete_fast64
跟原始的delete
操作一样的,所以我们来看看mapdelete
。
mapdelete
长图预警!!!
大致代码分析如上,具体代码就留给大家去阅读了。其实大致过程:
写保护,防止并发写
查询要删除的
key
是否存在存在则对其标志做删除标记
count--
所以你在大面积删除key
,实际map
存储的key
是不会删除的,只是标记当前的key状态为empty
。
其实出发点,和mysql
的标记删除类似,防止后续会有相同的key
插入,省去了扩缩容的操作。
但是这个对有些场景是不妥的,如果开发者在未来时间内都不会再插入相同的key
,很可能会导致OOM
。
所以针对以上情况,go-zero
开发了safemap
。下面我们看看safemap
是如何避免这个问题的?
safemap
直接从操作safemap
中分析为什么要这么设计:
预设一个 删除阈值,如果触发会放到一个新预设好的
newmap
中两个
map
是一个整体,所以key
只能留一份
所以为什么要设置两个map
就很清楚了:
dirtyOld
作为存储主体,如果delete
操作达到阈值,则会触发迁移。dirtyNew
作为暂存体,会在到达阈值时,存放部分key/value
所以在迁移操作时,我们需要做的就是:将原先的dirtyOld
清空,存储的 key/value 通过 for-range 重新存储到dirtyNew
,然后将dirtyNew
指向dirtyOld
。
> 可能会有疑问:不是说key/value
没有删除吗,只是标记了tophash=empty
> > 其实在for-range
过程中,会过滤掉tophash <= emptyOne
的 key
这样就实现了不需要的 key 不会被加入到dirtyNew
,进而不会影响dirtyOld
。
这其实也就是垃圾回收的年老代和新生代的概念。
更多实现细节,可以查看源码!
项目地址
https://github.com/tal-tech/go-zero
https://gitee.com/kevwan/go-zero
欢迎使用 go-zero 并 star 支持我们!
END
如何有效表白
特别声明:以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布,本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.