由浅入深聊聊Golang的sync.Map

前言

今天在技术群中有小伙伴讨论并发安全的东西，其实之前就有写过map相关文章：由浅入深聊聊Golang的map。但是没有详细说明sync.Map是怎么一回事。
回想了一下，竟然脑中只剩下“两个map、一个只读一个读写，xxxxx”等，关键词。有印象能扯，但是有点乱，还是写一遍简单记录一下吧。

1.为什么需要sync.Map？
2.sync.Map如何使用？
3.理一理sync.Map源码实现？
4.sync.Map的优缺点？
5.思维扩散？

正文

1.为什么需要sync.Map？

关于map可以直接查看由浅入深聊聊Golang的map,不再赘述。

为什么需要呢？
原因很简单，就是：map在并发情况虚啊，只读是线程安全的，同时写线程不安全，所以为了并发安全 & 高效，官方实现了一把。

1.1 并发写map会有什么问题？

来看看不使用sync.Map的map是如何实现并发安全的：

func main() {
	m := map[int]int {1:1}
	go do(m)
	go do(m)

	time.Sleep(1*time.Second)
	fmt.Println(m)
}

func do (m map[int]int) {
	i := 0
	for i < 10000 {
		m[1]=1
		i++
	}
}

输出：

fatal error: concurrent map writes

oh，no。
报错说的很明显，这哥们不能同时写。

1.2 低配版解决方案

加一把大锁。

// 大家好，我是那把大锁
var s sync.RWMutex
func main() {
	m := map[int]int {1:1}
	go do(m)
	go do(m)

	time.Sleep(1*time.Second)
	fmt.Println(m)
}

func do (m map[int]int) {
	i := 0
	for i < 10000 {
	    // 加锁
		s.Lock()
		m[1]=1
		// 解锁
		s.Unlock()
		i++
	}
}

输出：

map[1:1]

这回终于正常了，但是会有什么问题呢？
加大锁大概率都不是最优解，一般都会有效率问题。
通俗说就是加大锁影响其他的元素操作了。

解决思路：减少加锁时间。
方法： 1.空间换时间。  2.降低影响范围。

sync.Map就是用了以上的思路。继续往下看。

2.sync.Map如何使用？

上代码：

func main() {
    // 关键人物出场
	m := sync.Map{}
	m.Store(1,1)
	go do(m)
	go do(m)

	time.Sleep(1*time.Second)
	fmt.Println(m.Load(1))
}

func do (m sync.Map) {
	i := 0
	for i < 10000 {
		m.Store(1,1)
		i++
	}
}

输出：

1 true

运行ok。这把秀了。

3.理一理sync.Map源码实现？

先白话文说下大概逻辑。让下文看的更快。（大概只有是这样流程就好）
写：直写。
读：先读read，没有再读dirty。

从“基础结构 +