定义
在runtime的sync.map包中有定义：
type Map struct {
mu Mutex // 锁
read atomic.Pointer[readOnly] //包含了readOnly类型的一个struct，下方把 Pointer 也贴了
dirty map[any]*entry // 一个map 存储数据
misses int // 错过、没有命中
}
// readOnly is an immutable struct stored atomically in the Map.read field.
type readOnly struct {
m map[any]*entry // 一个map，这个map是 read持有的
amended bool // true if the dirty map contains some key not in m.
// 追加，这里已经注释了 当dirty 的map中的key 不在 m的map中（就是 read的）就显示为 true
}
// go 的泛型
type Pointer[T any] struct {
_ [0]*T
_ noCopy
v unsafe.Pointer
}
整体的结构就如上图。
sync.map中有两个map 都是通过指针的形式 ，指向同一份value，但是key两个map都有各自存储。
分析原理
看究竟是如何解决map并发的问题的。
正常读写
正常读写走 m，就是read那个通过泛型结构体指向的那个 map，通过m这个map进行查找后，读取或者更改。
这个时候 misses = 0 ，amended=false
追加
如何写一个key，发现m中没有，那么需要去dirty中追加。
开始追加前，需要对dirty进行上锁，写完解锁。
如图现在追加了一个 d，这个时候 m中没有这个d的信息。
这个时候 misses = 0 ，amended=true 这个时候有了 dirty的key 不在m中了。
追加后读写
这时候就会出现 找d时候，发现m中没有并
amended=true，就会去 dirty中找，而且每找一次，都会给misses加1
这个时候 misses = 1 ，amended=true
dirty 提升
当 misses 等于 len(dirty) 就会触发dirty提升，替代m。
当再次出现追加的情况，重塑 dirty
这时候把 misses = 0 ，amended=false 复原
删除
删除比较麻烦，分为正常删除，和在上面的各种状态下进行删除。
正常删除
只需要把pointer置为nil就好，value因为没有对象指向它，在垃圾回收时候，会被标记为白色，被清理。
追加后删除
正常也是置为nil
删除后，提升
提升之后，如果重建 dirty，就不会重建这个d
这里d标记为 expunge 是为了告诉下方，
这个key已经被删除了，不用同步了，如果出现删除d的请求，不需要和下方dirty同步了。
而且当再对D进行追加时候，这时候 m中有d，但是，应该要放到dirty中去完成。
总结：
1. map 在扩容时会有并发问题
2.sync.Map 使用了两个map，分离了扩容问题
3.不会引发扩容的操作（查、改）使用read map
4.可能引发扩容的操作（新增）使用 dirty map
5.不是采用读写分离的办法