add map.md

Author: tydhot

sync/map.md

@@ -0,0 +1,137 @@
+Golang sync map
+在golang中，线程安全的map实现为sync.Map，相较于java中线程安全的map ConcurrentHashMap，在设计与实现上都有巨大的差别。
+## java中的ConcurrentHashMap
+java中的ConcurrentHashMap为了实现线程安全，在1.7当中，通过分段锁的实现达到了这一目的，区别于HashTable的全部阻塞操作，分段锁的设计在一定程度上提升了在并发场景下的访问性能。在1.8的过程中，锁的粒度被进一步降低，被缩小到了一个HashEntry首节点的地步，并通过在一定长度的链表后引入红黑树来降低遍历寻找数据的开销。        
+但是在golang中的线程安全的sync.Map并没有参考java中的实现，其设计反倒更加类似java中的CopyOnWriteArrayList，但是也不尽然，虽然sync.Map也冗分离了一部分的存储，但是包含更复杂的设计。
+## sync.Map的总体结构
+````
+type Map struct {
+	// 对于readOnly的操作都不需要加锁，但是后面所有对于dirty的操作都需要这里的mu加锁。
+	mu Mutex
+
+	// 这里的read实际存放的是下面的readOnly结构体，当从map中寻找数据的时候，将会先从
+	// readOnly中寻找，在readOnly中的查找都不需要加锁。因为插入数据的时候会先插入到dirty中。
+	// 而在readOnly中的操作都是原子操作。
+	read atomic.Value // readOnly
+
+	// dirty与readOnly两个map都会在sync.Map存放具体的数据，当map数据插入的时候，将会先
+	// 插入到dirty中，直到一定条件后才会晋升到readOnly中。
+	dirty map[interface{}]*entry
+
+	// 在从map中根据key寻找数据的时候，先会从readOnly寻找，如果找不到才会从dirty当中寻找，
+	// 当在dirty中找到的时候将会misses加一。当misses与dirty的长度相等的时候，将会开始把dirty
+       // 中的内容晋升到readOnly中
+	misses int
+}
+
+type readOnly struct {
+	m       map[interface{}]*entry
+	
+	// 这个值为true的时候说明有存在于dirty，但没有存在在readOnly中的元素。
+	amended bool 
+}
+
+var expunged = unsafe.Pointer(new(interface{}))
+
+type entry struct {
+	// 在map中，元素将以entry的形式存放在map中。当p == nil的时候，该元素已经被删除，同但是
+	// dirty中可能还指向该元素。当p == expunged的时候，readOnly中该元素已经被删除，同时dirty中
+	// 也没有指向该值。在正常情况下，p为具体存储的值同时dirty中也包含该值。
+	// 当一个元素被删除的时候，将会直接将readOnly中p置nil。接下来该值被放入dirty中的时候，将
+	// 会把该值置为expunged，并先在dirty中存放具体的值。
+	p unsafe.Pointer // *interface{}
+}
+````
+## sync.Map的Store()
+sync.Map通过Store()来存储一个键值对。
+````
+func (m *Map) Store(key, value interface{}) {
+	// 在Store()的一开始，先会在readOnly中寻在是否已经存在该key，如果已经存在，尝试通过
+	// tryStore()方法对键值对进行更新。
+	read, _ := m.read.Load().(readOnly)
+	if e, ok := read.m[key]; ok && e.tryStore(&value) {
+		return
+	}
+
+	// 如果上面直接在readOnly中更新的操作失败，那么需要加锁，将变更操作在dirty中完成。
+	m.mu.Lock()
+	read, _ = m.read.Load().(readOnly)
+	if e, ok := read.m[key]; ok {
+		// 如果在readOnly中，该值已经是expunged，那么先通过cas将其置为nil，代表dirty已经可能存在该值的映射。
+		if e.unexpungeLocked() {
+			// 该值先前为expunged，说明在ditry中不存在一个非nil的映射，直接更新dirty的值与read相同。
+			m.dirty[key] = e
+		}
+		// 更新key的映射到新的value，因为dirty和readOnly都持有一个e，此时dirty和readOnly都已经更新。
+		e.storeLocked(&value)
+	// 如果此时dirty已经持有该映射，那么直接修改该key对应的value的地址即可。
+	} else if e, ok := m.dirty[key]; ok {
+		// 如果该值不存在readOnly，但是在dirty中，那么直接修改dirty的值。
+		e.storeLocked(&value)
+	} else {
+		// 那么在之前的readOnly和dirty中都没有找到，那么就要往dirty中插入。
+		if !read.amended {
+			// 如果read的amended为false，那么说明此次是第一次往dirty中插入数据，需要
+			// 第一次进行dirty的map空间申请。
+			m.dirtyLocked()
+			m.read.Store(readOnly{m: read.m, amended: true})
+		}
+		// 往dirty中更新数据。
+		m.dirty[key] = newEntry(value)
+	}
+	m.mu.Unlock()
+}
+
+func (e *entry) tryStore(i *interface{}) bool {
+	for {
+		p := atomic.LoadPointer(&e.p)
+		// 如果为expunged，说明此时dirty中也没有该值的映射，需要先更新dirty。
+		if p == expunged {
+			return false
+		}
+		// 如果readOnly中存在没有被删除的值，那么通过cas直接更新具体的值。
+		if atomic.CompareAndSwapPointer(&e.p, p, unsafe.Pointer(i)) {
+			return true
+		}
+	}
+}
+````
+## sync.map的Load()
+````
+func (m *Map) Load(key interface{}) (value interface{}, ok bool) {
+	read, _ := m.read.Load().(readOnly)
+	e, ok := read.m[key]
+	// 如果能够在readOnly中找到，那么可以直接返回
+	if !ok && read.amended {
+		m.mu.Lock()
+		// 如果在readOnly中没找到，同时dirty中包含readOnly中没有的数据，那么需要加锁从dirty
+		// 中找。由于加锁的时候可能已经有元素从dirty中晋升到了read，那么需要双重检测。
+		read, _ = m.read.Load().(readOnly)
+		e, ok = read.m[key]
+		if !ok && read.amended {
+			e, ok = m.dirty[key]
+			// 如果在dirty中寻找到，那么需要在missLocked()中对misses加一。
+			m.missLocked()
+		}
+		m.mu.Unlock()
+	}
+	if !ok {
+		return nil, false
+	}
+	return e.load()
+}
+
+func (m *Map) missLocked() {
+	m.misses++
+	if m.misses < len(m.dirty) {
+		return
+	}
+	// 当misses大于dirty的长度的时候，将会把dirty的数据全部晋升到dirty中。并将dirty置为nil。
+	// 代表当前readOnly已经包含map中的所有数据。
+	m.read.Store(readOnly{m: m.dirty})
+	m.dirty = nil
+	m.misses = 0
+}
+````
+## 总结
+总体来说，sync.map通过读写分离，但是并没有像java的CopyOnWriteArrayList完全冗余一个几乎同样大小的数据来保证读写分离，而是将刚插入但是没有几次访问机会的数据隔离在dirty中，保证在执行数据访问的时候尽可能不需要阻塞。但是当需要插入更新readOnly中不存在的数据的时候，则需要对dirty来加锁保证访问，这里的加锁粒度要比java的ConcurrentHashMap要更大，但是不是每次更新都需要加锁，readOnly中的数据可以通过cas保证原子更新。还是如一开始所说，sync.map还是更适合读多写少的场景，当新key的插入十分频繁的时候，性能和普通的map加锁没有太大的区别。