锐客网

  1. 首页 > 睿知 > it技术 > >

go语言sync.map go语言适合做什么

mapIT技术

Go语言——sync.Map详解 sync.Map是1.9才推荐的并发安全的map ， 除了互斥量以外 ， 还运用了原子操作，所以在这之前，有必要了解下 Go语言——原子操作
go1.10\src\sync\map.go
entry分为三种情况：
从read中读取key ， 如果key存在就tryStore 。
注意这里开始需要加锁，因为需要操作dirty 。
条目在read中，首先取消标记，然后将条目保存到dirty里 。（因为标记的数据不在dirty里）
最后原子保存value到条目里面，这里注意read和dirty都有条目 。
总结一下Store：
这里可以看到dirty保存了数据的修改，除非可以直接原子更新read，继续保持read clean 。
有了之前的经验，可以猜测下load流程：
与猜测的 区别 ：
由于数据保存两份，所以删除考虑：
先看第二种情况 。加锁直接删除dirty数据 。思考下貌似没什么问题，本身就是脏数据 。
第一种和第三种情况唯一的区别就是条目是否被标记 。标记代表删除，所以直接返回 。否则CAS操作置为nil 。这里总感觉少点什么，因为条目其实还是存在的 ， 虽然指针nil 。
看了一圈貌似没找到标记的逻辑，因为删除只是将他变成nil 。
之前以为这个逻辑就是简单的将为标记的条目拷贝给dirty，现在看来大有文章 。
p == nil，说明条目已经被delete了，CAS将他置为标记删除 。然后这个条目就不会保存在dirty里面 。
这里其实就跟miss逻辑串起来了，因为miss达到阈值之后，dirty会全量变成read，也就是说标记删除在这一步最终删除 。这个还是很巧妙的 。
真正的删除逻辑：
很绕 。。。。
Golang 并发读写map安全问题详解 下面先写一段测试程序，然后看下运行结果：
运行结果：
发生了错误，提示：fatal error: concurrent map read and map write， map 发生了同时读和写了； 但是这个错误并不是每次运行都会出现，就是有的时候会出现 ， 有的时候并不会出现，根据笔者多次运行结果(其他例子，读者可以自己尝试下)来看还会有另外一种报错就是：fatal error: concurrent map writes，就是map发生了同时写 ， 但是只是读是不会有问题的 。关于不同的运行结果小伙伴们可以自己写几个例子去测试下 。下面就这两个错误的发生，笔者给出如下解释：
（1） fatal error: concurrent map read and map write
就是当一个goroutine在写数据，而同时另外一个goroutine要读数据就会报错，不过这个报错也很好理解：还没写完就读，读的数据会有问题，或者反过来还没读完就开始写了，同样会导致读取的数据有问题；
（2） fatal error: concurrent map writes
两个goroutine 同时写一个内存地址，这种操作也是不允许的 ， 会导致一些比较奇怪的问题；
总体来看其实就是写map的操作和其他的读或者写同时发生了 ， 导致的报错，做过几年开发的人可能会想到使用锁来解决 ， 比如写map某个key的时候 ， 通过锁来保证其他goroutine不能再对其写或者读了 。
实现思路：
（1） 当写map的某个key时 ， 通过锁来保证其他goroutine不能再对其写或者读了 。
（2） 当读map的某个key时，通过锁来保证其他的goroutine不能再对其写，但是可以读 。
于是我们马上想到golang 的读写锁貌似符合需求 ， 下面来实现下：
再来看下运行结果：
发现没有报错了，并且多次运行的结果都不会报错，说明这个方法是有用的，不过在go1.9版本后就有sync.Map了，不过这个适用场景是读多写少的场景，如果写很多的话效率比较差，具体的原因在这里笔者就不介绍了，后面会写篇文章详细介绍下 。
今天的文章就到这里了 ， 如果有不对的地方欢迎小伙伴给我留言，看到会即时回复的 。
go面试题整理（附带部分自己的解答）原文：【】
如果有解答go语言sync.map的不对的go语言sync.map，麻烦各位在评论写出来~
go的调度原理是基于GMP模型，G代表一个goroutine，不限制数量go语言sync.map；M=machine，代表一个线程，最大1万，所有G任务还是在M上执行；P=processor代表一个处理器，每一个允许的M都会绑定一个G，默认与逻辑CPU数量相等（通过runtime.GOMAXPROCS(runtime.NumCPU())设置） 。
go调用过程：
可以能 ， 也可以不能 。
因为go存在不能使用==判断类型：map、slice，如果struct包含这些类型的字段，则不能比较 。
这两种类型也不能作为map的key 。
类似栈操作，后进先出 。
因为go的return是一个非原子性操作 ， 比如语句return i ， 实际上分两步进行，即将i值存入栈中作为返回值，然后执行跳转，而defer的执行时机正是跳转前，所以说defer执行时还是有机会操作返回值的 。
select的case的表达式必须是一个channel类型，所有case都会被求值，求值顺序自上而下，从左至右 。如果多个case可以完成 ， 则会随机执行一个case，如果有default分支，则执行default分支语句 。如果连default都没有，则select语句会一直阻塞，直到至少有一个IO操作可以进行 。
break关键字可跳出select的执行 。
goroutine管理、信息传递 。context的意思是上下文，在线程、协程中都有这个概念，它指的是程序单元的一个运行状态、现场、快照，包含 。context在多个goroutine中是并发安全的 。
应用场景：
例子参考：
waitgroup
channel
len：切片的长度，访问时间复杂度为O(1)，go的slice底层是对数组的引用 。
cap：切片的容量，扩容是以这个值为标准 。默认扩容是2倍，当达到1024的长度后 ， 按1.25倍 。
扩容：每次扩容slice底层都将先分配新的容量的内存空间，再将老的数组拷贝到新的内存空间，因为这个操作不是并发安全的 。所以并发进行append操作，读到内存中的老数组可能为同一个，最终导致append的数据丢失 。
共享：slice的底层是对数组的引用，因此如果两个切片引用了同一个数组片段 ， 就会形成共享底层数组 。当sliec发生内存的重新分配（如扩容）时 ， 会对共享进行隔断 。详细见下面例子：
make([]Type,len,cap)
map的底层是hash table(hmap类型)，对key值进行了hash，并将结果的低八位用于确定key/value存在于哪个bucket（bmap类型） 。再将高八位与bucket的tophash进行依次比较，确定是否存在 。出现hash冲撞时，会通过bucket的overflow指向另一个bucket，形成一个单向链表 。每个bucket存储8个键值对 。
如果要实现map的顺序读取 ， 需要使用一个slice来存储map的key并按照顺序进行排序 。
利用map，如果要求并发安全 ， 就用sync.map
要注意下set中的delete函数需要使用delete(map) 来实现，但是这个并不会释放内存，除非value也是一个子map 。当进行多次delete后，可以使用make来重建map 。
使用sync.Map来管理topic，用channel来做队列 。
参考：
多路归并法:
pre class="vditor-reset" placeholder="" contenteditable="true" spellcheck="false"p data-block="0"(1)假设有K路a href=""数据流/a，流内部是有序的，且流间同为升序或降序；
/pp data-block="0"(2)首先读取每个流的第一个数，如果已经EOF，pass；
/pp data-block="0"(3)将有效的k(k可能小于K)个数比较，选出最小的那路mink，输出 ， 读取mink的下一个；
/pp data-block="0"(4)直到所有K路都EOF 。
/p/pre
假设文件又1个G，内存只有256M，无法将1个G的文件全部读到内存进行排序 。
第一步：
可以分为10段读取，每段读取100M的数据并排序好写入硬盘 。
假设写入后的文件为A,B，C...10
第二步:
将A ， B,C...10的第一个字符拿出来 ， 对这10个字符进行排序，并将结果写入硬盘，同时记录被写入的字符的文件指针P 。
第三步：
将刚刚排序好的9个字符再加上从指针P读取到的P 1位数据进行排序，并写入硬盘 。
重复二、三步骤 。
go文件读写参考：
保证排序前两个相等的数其在序列的前后位置顺序和排序后它们两个的前后位置顺序相同的排序叫稳定排序 。
快速排序、希尔排序、堆排序、直接选择排序不是稳定的排序算法 。
基数排序、冒泡排序、直接插入排序、折半插入排序、归并排序是稳定的排序算法 。
参考：
head只请求页面的首部 。多用来判断网页是否被修改和超链接的有效性 。
get请求页面信息，并返回实例的主体 。
参考:
401：未授权的访问 。
403: 拒绝访问 。
普通的http连接是客户端连接上服务端，然后结束请求后，由客户端或者服务端进行http连接的关闭 。下次再发送请求的时候，客户端再发起一个连接，传送数据，关闭连接 。这么个流程反复 。但是一旦客户端发送connection:keep-alive头给服务端，且服务端也接受这个keep-alive的话 ， 两边对上暗号，这个连接就可以复用了，一个http处理完之后，另外一个http数据直接从这个连接走了 。减少新建和断开TCP连接的消耗 。这个可以在Nginx设置 ，
这个keepalive_timout时间值意味着：一个http产生的tcp连接在传送完最后一个响应后，还需要hold住keepalive_timeout秒后 ， 才开始关闭这个连接 。
特别注意TCP层的keep alive和http不是一个意思 。TCP的是指：tcp连接建立后，如果客户端很长一段时间不发送消息，当连接很久没有收到报文，tcp会主动发送一个为空的报文（侦测包）给对方，如果对方收到了并且回复了，证明对方还在 。如果对方没有报文返回，重试多次之后则确认连接丢失，断开连接 。
tcp的keep alive可通过
net.ipv4.tcp_keepalive_intvl = 75// 当探测没有确认时，重新发送探测的频度 。缺省是75秒 。
net.ipv4.tcp_keepalive_probes = 9 //在认定连接失效之前 ， 发送多少个TCP的keepalive探测包 。缺省值是9 。这个值乘以tcp_keepalive_intvl之后决定了，一个连接发送了keepalive之后可以有多少时间没有回应
net.ipv4.tcp_keepalive_time = 7200 //当keepalive起用的时候，TCP发送keepalive消息的频度 。缺省是2小时 。一般设置为30分钟1800
修改：
可以
tcp是面向连接的，upd是无连接状态的 。
udp相比tcp没有建立连接的过程，所以更快，同时也更安全，不容易被攻击 。upd没有阻塞控制，因此出现网络阻塞不会使源主机的发送效率降低 。upd支持一对多 ， 多对多等，tcp是点对点传输 。tcp首部开销20字节，udp8字节 。
udp使用场景：视频通话、im聊天等 。
time-wait表示客户端等待服务端返回关闭信息的状态，closed_wait表示服务端得知客户端想要关闭连接 ， 进入半关闭状态并返回一段TCP报文 。
time-wait作用：
解决办法：
close_wait:
被动关闭，通常是由于客户端忘记关闭tcp连接导致 。
根据业务来啊~
重要指标是cardinality（不重复数量），这个数量/总行数如果过?。ㄇ鹘?）代表索引基本没意义，比如sex性别这种 。
另外查询不要使用select * ， 根据select的条件 where条件做组合索引，尽量实现覆盖索引，避免回表 。
僵尸进程：
即子进程先于父进程退出后 ， 子进程的PCB需要其父进程释放，但是父进程并没有释放子进程的PCB，这样的子进程就称为僵尸进程，僵尸进程实际上是一个已经死掉的进程 。
孤儿进程：
一个父进程退出，而它的一个或多个子进程还在运行 ， 那么那些子进程将成为孤儿进程 。孤儿进程将被init进程(进程号为1)所收养，并由init进程对它们完成状态收集工作 。
子进程死亡需要父进程来处理，那么意味着正常的进程应该是子进程先于父进程死亡 。当父进程先于子进程死亡时，子进程死亡时没父进程处理 ， 这个死亡的子进程就是孤儿进程 。
但孤儿进程与僵尸进程不同的是，由于父进程已经死亡，系统会帮助父进程回收处理孤儿进程 。所以孤儿进程实际上是不占用资源的，因为它终究是被系统回收了 。不会像僵尸进程那样占用ID,损害运行系统 。
原文链接：
产生死锁的四个必要条件：
（1） 互斥条件：一个资源每次只能被一个进程使用 。
（2） 请求与保持条件：一个进程因请求资源而阻塞时 ， 对已获得的资源保持不放 。
（3） 不剥夺条件：进程已获得的资源，在末使用完之前 ， 不能强行剥夺 。
（4） 循环等待条件：若干进程之间形成一种头尾相接的循环等待资源关系 。
避免方法：
端口占用：lsof -i:端口号或者 nestat
cpu、内存占用：top
发送信号：kill -l 列出所有信号，然后用 kill [信号变化] [进程号]来执行 。如kill -9 453 。强制杀死453进程
git log:查看提交记录
git diff ：查看变更记录
git merge：目标分支改变，而源分支保持原样 。优点：保留提交历史，保留分支结构 。但会有大量的merge记录
git rebase：将修改拼接到最新 ， 复杂的记录变得优雅 ， 单个操作变得(revert)很简单；缺点：
git revert:反做指定版本，会新生成一个版本
git reset:重置到某个版本，中间版本全部丢失
etcd、Consul
pprof
节省空间（非叶子节点不存储数据，相对b tree的优势），减少I/O次数（节省的空间全部存指针地址，让树变的矮胖），范围查找方便（相对hash的优势） 。
explain
其他的见：
runtime2.go 中关于 p 的定义： 其中 runnext 指针决定了下一个要运行的 g，根据英文的注释大致意思是说：
所以当设置 runtime.GOMAXPROCS(1) 时，此时只有一个 P ， 创建的 g 依次加入 P ， 当最后一个即 i==9 时 ， 加入的最后 一个 g 将会继承当前主 goroutinue 的剩余时间片继续执行，所以会先输出 9 ， 之后再依次执行 P 队列中其它的 g 。
方法一：
方法二：
[图片上传失败...(image-4ef445-1594976286098)]
方法1：to_days，返回给的日期从0开始算的天数 。
方法2：data_add 。向日期添加指定时间间隔
[图片上传失败...(image-b67b10-1594976286098)]
Golang中sync.Map的实现原理前面，我们讲了map的用法以及原理 Golang中map的实现原理，但我们知道，map在并发读写的情况下是不安全 。需要并发读写时，一般的做法是加锁，但这样性能并不高，Go语言在 1.9 版本中提供了一种效率较高的并发安全的 sync.Map，今天，我们就来讲讲 sync.Map的用法以及原理
sync.Map与map不同，不是以语言原生形态提供，而是在 sync 包下的特殊结构：
我们下来看下sync.Map结构体
结构体之间的关系如下图所示：
总结一下：
Load方法比较简单，总结一下：
总结如下：
Go Map 为什么是非线程安全的？ Go map 默认是并发不安全的 ， 同时对 map 进行并发读写的时 ， 程序会 panic ， 原因如下：Go 官方经过长时间的讨论，认为 map 适配的场景应该是简单的（不需要从多个 gorountine 中进行安全访问的），而不是为了小部分情况（并发访问），导致大部分程序付出锁的代价，因此决定了不支持 。
并发读写可能引发的问题
使用sync.RWMutex解决并发读写的问题
使用 sync.Map 解决并发读写的问题
实际上， sync.Map也是通过加锁的方式实现并发安全的，sync.Map源码的数据结构如下：
就像官方考虑的那样，我们在使用中 ， 应尽量避免对 Map 进行并发读写 ， 尝试通过其他方式解决问题 ， 如数据解耦、分布执行、动态规划等 ， 真的需要并发读写时，为避免产生并发读写的问题，请使用锁的机制进行控制
彻底理解Golang Map 本文目录如下，阅读本文后，将一网打尽下面Golang Map相关面试题
Go中的map是一个指针，占用8个字节，指向hmap结构体;源码 src/runtime/map.go 中可以看到map的底层结构
每个map的底层结构是hmap，hmap包含若干个结构为bmap的bucket数组 。每个bucket底层都采用链表结构 。接下来，我们来详细看下map的结构
bmap就是我们常说的“桶”，一个桶里面会最多装 8 个 key，这些 key 之所以会落入同一个桶，是因为它们经过哈希计算后，哈希结果是“一类”的，关于key的定位我们在map的查询和插入中详细说明 。在桶内，又会根据 key 计算出来的 hash 值的高 8 位来决定 key 到底落入桶内的哪个位置（一个桶内最多有8个位置) 。
bucket内存数据结构可视化如下：
注意到 key 和 value 是各自放在一起的，并不是key/value/key/value/...这样的形式 。源码里说明这样的好处是在某些情况下可以省略掉 padding字段，节省内存空间 。
当 map 的 key 和 value 都不是指针，并且 size 都小于 128 字节的情况下，会把 bmap 标记为不含指针，这样可以避免 gc 时扫描整个 hmap 。但是 ， 我们看 bmap 其实有一个 overflow 的字段，是指针类型的，破坏了 bmap 不含指针的设想 ， 这时会把 overflow 移动到 extra 字段来 。
map是个指针，底层指向hmap，所以是个引用类型
golang 有三个常用的高级类型 slice 、map、channel,它们都是 引用类型 ， 当引用类型作为函数参数时，可能会修改原内容数据 。
golang 中没有引用传递，只有值和指针传递 。所以 map 作为函数实参传递时本质上也是值传递，只不过因为 map 底层数据结构是通过指针指向实际的元素存储空间，在被调函数中修改 map ， 对调用者同样可见，所以 map 作为函数实参传递时表现出了引用传递的效果 。
因此，传递 map 时，如果想修改map的内容而不是map本身，函数形参无需使用指针
map底层数据结构是通过指针指向实际的元素 存储空间，这种情况下，对其中一个map的更改，会影响到其他map
map 在没有被修改的情况下，使用 range 多次遍历 map 时输出的 key 和 value 的顺序可能不同 。这是 Go 语言的设计者们有意为之，在每次 range 时的顺序被随机化，旨在提示开发者们，Go 底层实现并不保证 map 遍历顺序稳定，请大家不要依赖 range 遍历结果顺序 。
map 本身是无序的，且遍历时顺序还会被随机化，如果想顺序遍历 map，需要对 map key 先排序 ， 再按照 key 的顺序遍历 map 。
map默认是并发不安全的 ， 原因如下：
Go 官方在经过了长时间的讨论后，认为 Go map 更应适配典型使用场景（不需要从多个 goroutine 中进行安全访问） ， 而不是为了小部分情况（并发访问），导致大部分程序付出加锁代价（性能），决定了不支持 。
场景:2个协程同时读和写，以下程序会出现致命错误：fatal error: concurrent map writes
如果想实现map线程安全，有两种方式：
方式一：使用读写锁mapsync.RWMutex
方式二：使用golang提供的sync.Map
sync.map是用读写分离实现的，其思想是空间换时间 。和map RWLock的实现方式相比，它做了一些优化：可以无锁访问read map ， 而且会优先操作read map ， 倘若只操作read map就可以满足要求(增删改查遍历)，那就不用去操作write map(它的读写都要加锁)，所以在某些特定场景中它发生锁竞争的频率会远远小于map RWLock的实现方式 。
golang中map是一个kv对集合 。底层使用hash table，用链表来解决冲突，出现冲突时，不是每一个key都申请一个结构通过链表串起来，而是以bmap为最小粒度挂载，一个bmap可以放8个kv 。在哈希函数的选择上，会在程序启动时 ， 检测 cpu 是否支持 aes，如果支持，则使用 aes hash ， 否则使用 memhash 。
map有3钟初始化方式，一般通过make方式创建
map的创建通过生成汇编码可以知道，make创建map时调用的底层函数是 runtime.makemap。如果你的map初始容量小于等于8会发现走的是 runtime.fastrand 是因为容量小于8时不需要生成多个桶，一个桶的容量就可以满足
makemap函数会通过fastrand创建一个随机的哈希种子，然后根据传入的hint计算出需要的最小需要的桶的数量，最后再使用makeBucketArray 创建用于保存桶的数组，这个方法其实就是根据传入的B计算出的需要创建的桶数量在内存中分配一片连续的空间用于存储数据，在创建桶的过程中还会额外创建一些用于保存溢出数据的桶，数量是2^(B-4)个 。初始化完成返回hmap指针 。
找到一个 B，使得 map 的装载因子在正常范围内
Go 语言中读取 map 有两种语法：带 comma 和 不带 comma 。当要查询的 key 不在 map 里，带 comma 的用法会返回一个 bool 型变量提示 key 是否在 map 中；而不带 comma 的语句则会返回一个 value 类型的零值 。如果 value 是 int 型就会返回 0，如果 value 是 string 类型，就会返回空字符串 。
map的查找通过生成汇编码可以知道 ， 根据 key 的不同类型，编译器会将查找函数用更具体的函数替换，以优化效率：
函数首先会检查 map 的标志位 flags 。如果 flags 的写标志位此时被置 1 了，说明有其他协程在执行“写”操作 ， 进而导致程序 panic 。这也说明了 map 对协程是不安全的 。
key经过哈希函数计算后，得到的哈希值如下（主流64位机下共 64 个 bit 位）：
m: 桶的个数
从buckets 通过 hashm 得到对应的bucket ， 如果bucket正在扩容，并且没有扩容完成，则从oldbuckets得到对应的bucket
计算hash所在桶编号：
用上一步哈希值最后的 5 个 bit 位，也就是01010 ，值为 10，也就是 10 号桶（范围是0~31号桶）
计算hash所在的槽位:
用上一步哈希值哈希值的高8个bit 位，也就是 10010111，转化为十进制，也就是151 ， 在 10 号 bucket 中寻找** tophash 值（HOB hash）为 151* 的 槽位**，即为key所在位置，找到了 2 号槽位，这样整个查找过程就结束了 。
如果在 bucket 中没找到，并且 overflow 不为空，还要继续去 overflow bucket 中寻找 ， 直到找到或是所有的 key 槽位都找遍了，包括所有的 overflow bucket 。
通过上面找到了对应的槽位，这里我们再详细分析下key/value值是如何获取的：
bucket 里 key 的起始地址就是 unsafe.Pointer(b) dataOffset 。第 i 个 key 的地址就要在此基础上跨过 i 个 key 的大?。欢颐怯种?，value 的地址是在所有 key 之后，因此第 i 个 value 的地址还需要加上所有 key 的偏移 。
通过汇编语言可以看到 ， 向 map 中插入或者修改 key，最终调用的是mapassign函数 。
实际上插入或修改 key 的语法是一样的，只不过前者操作的 key 在 map 中不存在 ， 而后者操作的 key 存在 map 中 。
mapassign 有一个系列的函数，根据 key 类型的不同 ， 编译器会将其优化为相应的“快速函数” 。
我们只用研究最一般的赋值函数mapassign。
map的赋值会附带着map的扩容和迁移，map的扩容只是将底层数组扩大了一倍，并没有进行数据的转移 ， 数据的转移是在扩容后逐步进行的，在迁移的过程中每进行一次赋值（access或者delete）会至少做一次迁移工作 。
1.判断map是否为nil
每一次进行赋值/删除操作时，只要oldbuckets != nil 则认为正在扩容，会做一次迁移工作，下面会详细说下迁移过程
根据上面查找过程，查找key所在位置 ， 如果找到则更新，没找到则找空位插入即可
经过前面迭代寻找动作 ， 若没有找到可插入的位置，意味着需要扩容进行插入，下面会详细说下扩容过程
通过汇编语言可以看到，向 map 中删除 key，最终调用的是mapdelete函数
删除的逻辑相对比较简单 ， 大多函数在赋值操作中已经用到过，核心还是找到 key 的具体位置 。寻找过程都是类似的，在 bucket 中挨个 cell 寻找 。找到对应位置后，对 key 或者 value 进行“清零”操作，将 count 值减 1，将对应位置的 tophash 值置成Empty
再来说触发 map 扩容的时机：在向 map 插入新 key 的时候，会进行条件检测，符合下面这 2 个条件，就会触发扩容：
1、装载因子超过阈值
源码里定义的阈值是 6.5 (loadFactorNum/loadFactorDen)，是经过测试后取出的一个比较合理的因子
我们知道 ， 每个 bucket 有 8 个空位，在没有溢出，且所有的桶都装满了的情况下，装载因子算出来的结果是 8 。因此当装载因子超过 6.5 时，表明很多 bucket 都快要装满了 ， 查找效率和插入效率都变低了 。在这个时候进行扩容是有必要的 。
对于条件 1，元素太多，而 bucket 数量太少，很简单：将 B 加 1，bucket 最大数量( 2^B )直接变成原来 bucket 数量的 2 倍 。于是，就有新老 bucket 了 。注意 ， 这时候元素都在老 bucket 里，还没迁移到新的 bucket 来 。新 bucket 只是最大数量变为原来最大数量的 2 倍( 2^B * 2 )。
2、overflow 的 bucket 数量过多
在装载因子比较小的情况下 ， 这时候 map 的查找和插入效率也很低，而第 1 点识别不出来这种情况 。表面现象就是计算装载因子的分子比较小，即 map 里元素总数少 ， 但是 bucket 数量多（真实分配的 bucket 数量多，包括大量的 overflow bucket）
不难想像造成这种情况的原因：不停地插入、删除元素 。先插入很多元素 ， 导致创建了很多 bucket，但是装载因子达不到第 1 点的临界值，未触发扩容来缓解这种情况 。之后，删除元素降低元素总数量，再插入很多元素，导致创建很多的 overflow bucket，但就是不会触发第 1 点的规定，你能拿我怎么办？overflow bucket 数量太多，导致 key 会很分散，查找插入效率低得吓人 ， 因此出台第 2 点规定 。这就像是一座空城 ， 房子很多，但是住户很少，都分散了 ， 找起人来很困难
对于条件 2，其实元素没那么多，但是 overflow bucket 数特别多，说明很多 bucket 都没装满 。解决办法就是开辟一个新 bucket 空间，将老 bucket 中的元素移动到新 bucket，使得同一个 bucket 中的 key 排列地更紧密 。这样，原来 ， 在 overflow bucket 中的 key 可以移动到 bucket 中来 。结果是节省空间，提高 bucket 利用率，map 的查找和插入效率自然就会提升 。
由于 map 扩容需要将原有的 key/value 重新搬迁到新的内存地址，如果有大量的 key/value 需要搬迁，会非常影响性能 。因此 Go map 的扩容采取了一种称为“渐进式”的方式，原有的 key 并不会一次性搬迁完毕 ， 每次最多只会搬迁 2 个 bucket 。
上面说的hashGrow()函数实际上并没有真正地“搬迁”，它只是分配好了新的 buckets，并将老的 buckets 挂到了 oldbuckets 字段上 。真正搬迁 buckets 的动作在growWork()函数中，而调用growWork()函数的动作是在 mapassign 和 mapdelete 函数中 。也就是插入或修改、删除 key 的时候，都会尝试进行搬迁 buckets 的工作 。先检查 oldbuckets 是否搬迁完毕，具体来说就是检查 oldbuckets 是否为 nil 。
如果未迁移完毕，赋值/删除的时候，扩容完毕后（预分配内存），不会马上就进行迁移 。而是采取 增量扩容 的方式，当有访问到具体 bukcet 时，才会逐渐的进行迁移（将 oldbucket 迁移到 bucket）
nevacuate 标识的是当前的进度，如果都搬迁完 ， 应该和2^B的长度是一样的
在evacuate 方法实现是把这个位置对应的bucket，以及其冲突链上的数据都转移到新的buckets上 。
转移的判断直接通过tophash 就可以 ， 判断tophash中第一个hash值即可
遍历的过程，就是按顺序遍历 bucket，同时按顺序遍历 bucket 中的 key 。
map遍历是无序的，如果想实现有序遍历，可以先对key进行排序
为什么遍历 map 是无序的？
如果发生过迁移，key 的位置发生了重大的变化 ， 有些 key 飞上高枝，有些 key 则原地不动 。这样，遍历 map 的结果就不可能按原来的顺序了 。
如果就一个写死的 map ， 不会向 map 进行插入删除的操作，按理说每次遍历这样的 map 都会返回一个固定顺序的 key/value 序列吧 。但是 Go 杜绝了这种做法 ， 因为这样会给新手程序员带来误解，以为这是一定会发生的事情，在某些情况下，可能会酿成大错 。
Go 做得更绝，当我们在遍历 map 时，并不是固定地从 0 号 bucket 开始遍历，每次都是从一个**随机值序号的 bucket开始遍历，并且是从这个 bucket 的一个 随机序号的 cell **开始遍历 。这样，即使你是一个写死的 map，仅仅只是遍历它 ， 也不太可能会返回一个固定序列的 key/value 对了 。
【go语言sync.map go语言适合做什么】关于go语言sync.map和go语言适合做什么的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站 。

    推荐阅读


    上一篇：mysql拒绝访问错误1045 mysql为什么拒绝访问

    下一篇：如何查询理财软件的服务器？ 怎么查理财软件服务器