Go on Kingcanfish 的小星球 🪐

【转】GO：sync.Mutex 的实现与演进

Wed, 09 Dec 2020 14:31:00 +0800

本文转自：https://www.jianshu.com/p/ce1553cc5b4f

前几天某个群里问，sync.Mutex 是否有自旋逻辑，抽时间看了下源码。不得了，小小的 Mutex 居然进化了三个版本，从这也可以看到 go 社区一直在积极的优化与演进

最朴素的实现互斥锁，拿到锁返回，拿不到就将当前 goroutine 休眠
增加了自旋 spinlock 的逻辑，也就是说大部份 Mutex 锁住时间如果很短，那么自旋可以减小无谓的 runtime 调度。推荐看官方 spin commit
进化成了公平锁，老版本中当前抢锁中的 goroutine 大概率比休眠的优先拿到锁，会产生 latency 长尾。新版本中超过一定时间没拿到锁，这个优先级会反转，尽可能减小长尾。推荐大家看 #issue 13086，这里面反映了问题，另外看 commit, 里面有很详细的测试数据，值得学习

那么具体怎么实现呢？分别以 1.3, 1.7, 1.12 三个版本源码为例

Mutex 结构体及常用变量

type Mutex struct {
    state int32
    sema  uint32
}
// 1.3 与 1.7 老的实现共用的常量
const (
    mutexLocked = 1 << iota // mutex is locked
    mutexWoken
    mutexWaiterShift = iota
)
// 1.12 公平锁使用的常量
const (
    mutexLocked = 1 << iota // mutex is locked
    mutexWoken
    mutexStarving
    mutexWaiterShift = iota
    starvationThresholdNs = 1e6
)

从中可以看到，Mutex 有两个变量：

state 4 字节 int, 其中低几位用于做标记，高位地址空间用于计数，表示有多少个 goroutine 正在等待而处于休眠中。
sema 是一个互斥的信号量，初始默认值是 0，用于将 goroutine park 休眠或是唤醒。sema acquire 时如果 sema 大于 0，那么减一返回，否则休眠等待。sema release 将 sema 加一，然后唤醒等待队列的第一个 goroutine

默认直接使用 sync.Mutex 或是嵌入到结构体中，state 零值代表未上锁，sema 零值也是有意义的，参考下面源码加锁与解锁逻辑，稍想下就会明白的。另外参考大胡子 dave 的关于零值的文章

朴素互斥锁

朴素是什么意思呢？就是能用，粗糙…

上锁

// Lock locks m.
// If the lock is already in use, the calling goroutine
// blocks until the mutex is available.
func (m *Mutex) Lock() {
    // Fast path: grab unlocked mutex. 快速上锁，当前 state 为 0，说明没人锁。CAS 上锁后直接返回
    if atomic.CompareAndSwapInt32(&m.state, 0, mutexLocked) {
        if raceenabled {
            raceAcquire(unsafe.Pointer(m))
        }
        return
    }

    awoke := false // 被唤醒标记，如果是被别的 goroutine 唤醒的那么后面会置 true
    for {
        old := m.state // 老的 m.state 值
        new := old | mutexLocked // 新值要置 mutexLocked 位为 1
        if old&mutexLocked != 0 { // 如果 old mutexLocked 位不为 0，那说明有人己经锁上了，那么将 state 变量的 waiter 计数部分 +1
            new = old + 1<<mutexWaiterShift
        }
        if awoke {
            // The goroutine has been woken from sleep,
            // so we need to reset the flag in either case. 如果走到这里 awoke 为 true, 说明是被唤醒的，那么清除这个 mutexWoken 位，置为 0
            new &^= mutexWoken
        }
        // CAS 更新，如果 m.state 不等于 old，说明有人也在抢锁，那么 for 循环发起新的一轮竞争。
        if atomic.CompareAndSwapInt32(&m.state, old, new) {
            if old&mutexLocked == 0 { // 如果 old mutexLocked 位为 1，说明当前 CAS 是为了更新 waiter 计数。如果为 0，说明是抢锁成功，那么直接 break 退出。
                break
            }
            runtime_Semacquire(&m.sema) // 此时如果 sema <= 0 那么阻塞在这里等待唤醒，也就是 park 住。走到这里都是要休眠了。
            awoke = true  // 有人释放了锁，然后当前 goroutine 被 runtime 唤醒了，设置 awoke true
        }
    }

    if raceenabled {
        raceAcquire(unsafe.Pointer(m))
    }
}

上锁逻辑其实也不难，这里面更改计数都是用 CAS

fast path 快速上锁，如果当前 state == 0, 肯定是没人上锁，也没人等待，CAS 更新后直接退出好了
当前如果有人锁住了，那么更新 m.state 值的 waiter 计数部份，然后 runtime_Semacquire 将自己休眠，等待被唤醒
runtime_Semacquire 函数返回说明锁释放了，有人将自己唤醒了，那么设置 awoke，大循环发起新的一轮竞争。
新的竞争到最后，cas 更新了 new 值，此时 old 值 mutexLocked 位肯定为 0，获取锁成功，break 退出即可。

解锁

// Unlock unlocks m.
// It is a run-time error if m is not locked on entry to Unlock.
//
// A locked Mutex is not associated with a particular goroutine.
// It is allowed for one goroutine to lock a Mutex and then
// arrange for another goroutine to unlock it.
func (m *Mutex) Unlock() {
    if raceenabled {
        _ = m.state
        raceRelease(unsafe.Pointer(m))
    }

    // Fast path: drop lock bit. 快速将 state 的 mutexLocked 位清 0，然后 new 返回更新后的值，注意此 add 完成后，很有可能新的 goroutine 抢锁，并上锁成功
    new := atomic.AddInt32(&m.state, -mutexLocked)
    if (new+mutexLocked)&mutexLocked == 0 { // 如果释放了一个己经释放的锁，直接 panic
        panic("sync: unlock of unlocked mutex")
    }

    old := new
    for {// 如果 state 变量的 waiter 计数为 0 说明没人等待锁，直接 return 就好，同时如果 old 值的 mutexLocked|mutexWoken 任一置 1，说明要么有人己经抢上了锁，要么说明己经有被唤醒的 goroutine 去抢锁了，没必要去做通知操作
        // If there are no waiters or a goroutine has already
        // been woken or grabbed the lock, no need to wake anyone.
        if old>>mutexWaiterShift == 0 || old&(mutexLocked|mutexWoken) != 0 {
            return
        }
        // Grab the right to wake someone. 将 waiter 计数位减一，并设置 awoken 位
        new = (old - 1<<mutexWaiterShift) | mutexWoken
        if atomic.CompareAndSwapInt32(&m.state, old, new) {
            runtime_Semrelease(&m.sema) // cas 成功后，再做 sema release 操作，唤醒休眠的 goroutine
            return
        }
        old = m.state
    }
}

解锁逻辑也不难，注意一个 goroutine 可以释放别的 goroutine 上的锁

原子操作, m.state - mutexLocked, 如果之后 (new+mutexLocked)&mutexLocked 说明释放了一个没上锁的 Mutex，直接 panic
接下来为什么是 for 循环呢？原因在于，第一步原子操作后，很可能有第三方刚好获得锁了，那么 for 里面的 CAS 肯定会失败
快速判断，如果 waiter 计数为 0，说明没有休眠的 goroutine，不用唤醒。如果 old&(mutexLocked|mutexWoken) != 0 说明要么有人获得了锁，要么己经有 woken 的 goroutine 了，也不用去唤醒。注意这里，mutexLocked 是 for 循环再次判断时才有的， old 值是循环底部重新又获取得
然后 CAS 更新成 new 值，设置 woken 标记位，并将等待 waiter 计数减一。最后 runtime_Semrelease 真正的唤醒等待 goroutine

朴素锁的问题

因获取 sema 休眠的 goroutine 会以一个 FIFO 的链表形式保存，如果唤醒时可以优先拿到锁。但是看代码的逻辑，处于休眠中的 goroutine 优先级低于当前活跃的。Unlock 解锁的顺间，最新活跃的 goroutine 是会抢到锁的。另外有时锁时间很短，如果没有自旋 spin 的逻辑，所有 goroutine 都要休眠 park, 徒增 runtime 调度的开销。

自旋 spin 的优化

后来优化时增加了 spin 逻辑，自旋只存在 Lock 阶段，代码以 go 1.7 为例

// Lock locks m.
// If the lock is already in use, the calling goroutine
// blocks until the mutex is available.
func (m *Mutex) Lock() {
    // Fast path: grab unlocked mutex.
    if atomic.CompareAndSwapInt32(&m.state, 0, mutexLocked) {
        if race.Enabled {
            race.Acquire(unsafe.Pointer(m))
        }
        return
    }

    awoke := false
    iter := 0
    for {
        old := m.state
        new := old | mutexLocked
        if old&mutexLocked != 0 { // 如果当前己经锁了，那么判断是否可以自旋
            if runtime_canSpin(iter) {
                // Active spinning makes sense.
                // Try to set mutexWoken flag to inform Unlock
                // to not wake other blocked goroutines.
                if !awoke && old&mutexWoken == 0 && old>>mutexWaiterShift != 0 &&
                    atomic.CompareAndSwapInt32(&m.state, old, old|mutexWoken) {
                    awoke = true
                }
                runtime_doSpin()
                iter++
                continue
            }
            new = old + 1<<mutexWaiterShift
        }
        if awoke {
            // The goroutine has been woken from sleep,
            // so we need to reset the flag in either case.
            if new&mutexWoken == 0 {
                panic("sync: inconsistent mutex state")
            }
            new &^= mutexWoken
        }
        if atomic.CompareAndSwapInt32(&m.state, old, new) {
            if old&mutexLocked == 0 {
                break
            }
            runtime_Semacquire(&m.sema)
            awoke = true
            iter = 0
        }
    }

    if race.Enabled {
        race.Acquire(unsafe.Pointer(m))
    }
}

可以看到，for 循环开始增加了 spin 判断逻辑。

如果 runtime 判断允许自旋，那么走 if 逻辑，否则走原有的 Lock 逻辑
如果当前 m.state 未设置 woken 标记，并且等待 waiter 计数大于 0，说明有人在等待，那么 CAS 更新 m.state 置位 mutexWoken
执行 runtime_doSpin 逻辑，同时 iter++ 表示自旋次数

const (
    mutex_unlocked = 0
    mutex_locked   = 1
    mutex_sleeping = 2

    active_spin     = 4
    active_spin_cnt = 30
    passive_spin    = 1
)
// Active spinning for sync.Mutex.
//go:linkname sync_runtime_canSpin sync.runtime_canSpin
//go:nosplit
func sync_runtime_canSpin(i int) bool {
    // sync.Mutex is cooperative, so we are conservative with spinning.
    // Spin only few times and only if running on a multicore machine and
    // GOMAXPROCS>1 and there is at least one other running P and local runq is empty.
    // As opposed to runtime mutex we don't do passive spinning here,
    // because there can be work on global runq on on other Ps.
    if i >= active_spin || ncpu <= 1 || gomaxprocs <= int32(sched.npidle+sched.nmspinning)+1 {
        return false
    }
    if p := getg().m.p.ptr(); !runqempty(p) {
        return false
    }
    return true
}

判断 runtime_canSpin 是否允许自旋逻辑也简单，也比较严格

iter 不大小最大的 active_spin 次数，默认是 4
当前机器是多核，并且 GOMAXPROCS > 1，这个很好理解，并发为 1 自旋也没意义
最后一个就是当前 P 的本地 runq 队列为空，如果有待运行的 G，那么也不允许自旋

func sync_runtime_doSpin() {
    procyield(active_spin_cnt)
}

TEXT runtime·procyield(SB),NOSPLIT,$0-0
    MOVL    cycles+0(FP), AX
again:
    PAUSE
    SUBL    $1, AX
    JNZ again
    RET

自旋代码涉及汇编了，在 amd64 平台调用 PAUSE，循环 active_spin_cnt 30 次。

代码以 go1.12 为例，可以看到注释关于公平锁的实现初衷和逻辑。越是基础组件更新越严格，背后肯定有相关测试数据。

Mutex 两种工作模式，normal 正常模式，starvation 饥饿模式。normal 情况下锁的逻辑与老版相似，休眠的 goroutine 以 FIFO 链表形式保存在 sudog 中，被唤醒的 goroutine 与新到来活跃的 goroutine 竞解，但是很可能会失败。如果一个 goroutine 等待超过 1ms，那么 Mutex 进入饥饿模式
饥饿模式下，解锁后，锁直接交给 waiter FIFO 链表的第一个，新来的活跃 goroutine 不参与竞争，并放到 FIFO 队尾
如果当前获得锁的 goroutine 是 FIFO 队尾，或是等待时长小于 1ms，那么退出饥饿模式
normal 模式下性能是比较好的，但是 starvation 模式能减小长尾 latency

公平锁上锁逻辑

// Lock locks m.
// If the lock is already in use, the calling goroutine
// blocks until the mutex is available.
func (m *Mutex) Lock() {
    // Fast path: grab unlocked mutex. 快速上锁逻辑
    if atomic.CompareAndSwapInt32(&m.state, 0, mutexLocked) {
        if race.Enabled {
            race.Acquire(unsafe.Pointer(m))
        }
        return
    }

    var waitStartTime int64 // waitStartTime 用于判断是否需要进入饥饿模式
    starving := false // 饥饿标记
    awoke := false // 是否被唤醒
    iter := 0 // spin 循环次数
    old := m.state
    for {
        // Don't spin in starvation mode, ownership is handed off to waiters
        // so we won't be able to acquire the mutex anyway. 饥饿模式下不进行自旋，直接进入阻塞队列
        if old&(mutexLocked|mutexStarving) == mutexLocked && runtime_canSpin(iter) {
            // Active spinning makes sense.
            // Try to set mutexWoken flag to inform Unlock
            // to not wake other blocked goroutines.
            if !awoke && old&mutexWoken == 0 && old>>mutexWaiterShift != 0 &&
                atomic.CompareAndSwapInt32(&m.state, old, old|mutexWoken) {
                awoke = true
            }
            runtime_doSpin()
            iter++
            old = m.state
            continue
        }
        new := old
        // Don't try to acquire starving mutex, new arriving goroutines must queue.
        if old&mutexStarving == 0 { // 只有此时不是饥饿模式时，才设置 mutexLocked，也就是说饥饿模式下的活跃 goroutine 直接排队去
            new |= mutexLocked
        }
        if old&(mutexLocked|mutexStarving) != 0 { // 处于己经上锁或是饥饿时，waiter 计数 + 1
            new += 1 << mutexWaiterShift
        }
        // The current goroutine switches mutex to starvation mode.
        // But if the mutex is currently unlocked, don't do the switch.
        // Unlock expects that starving mutex has waiters, which will not
        // be true in this case. 如果当前处于饥饿模式下，并且己经上锁了，mutexStarving 置 1，接下来 CAS 会用到
        if starving && old&mutexLocked != 0 {
            new |= mutexStarving
        }
        if awoke { // 如果当前 goroutine 是被唤醒的，然后清 mutexWoken 位
            // The goroutine has been woken from sleep,
            // so we need to reset the flag in either case.
            if new&mutexWoken == 0 {
                throw("sync: inconsistent mutex state")
            }
            new &^= mutexWoken
        }
        if atomic.CompareAndSwapInt32(&m.state, old, new) {
            if old&(mutexLocked|mutexStarving) == 0 { // 如果 old 没有上锁并且也不是饥饿模式，上锁成功直接退出
                break // locked the mutex with CAS
            }
            // If we were already waiting before, queue at the front of the queue.
            queueLifo := waitStartTime != 0 // 第一次 queueLifo 肯定是 false
            if waitStartTime == 0 {
                waitStartTime = runtime_nanotime() 
            }
            runtime_SemacquireMutex(&m.sema, queueLifo) // park 在这里，如果 queueLifo 为真，那么扔到队头，也就是 LIFO
      // 走到这里，说明被其它 goroutine 唤醒了，继续抢锁时先判断是否需要进入 starving
            starving = starving || runtime_nanotime()-waitStartTime > starvationThresholdNs // 超过 1ms 就进入饥饿模式
            old = m.state
            if old&mutexStarving != 0 { // 如果原来就是饥饿模式的话，走 if 逻辑
                // If this goroutine was woken and mutex is in starvation mode,
                // ownership was handed off to us but mutex is in somewhat
                // inconsistent state: mutexLocked is not set and we are still
                // accounted as waiter. Fix that.
                if old&(mutexLocked|mutexWoken) != 0 || old>>mutexWaiterShift == 0 {
                    throw("sync: inconsistent mutex state")
                }
        // 此时饥饿模式下被唤醒，那么一定能上锁成功。因为 Unlock 保证饥饿模式下只唤醒 park 状态的 goroutine
                delta := int32(mutexLocked - 1<<mutexWaiterShift) // waiter 计数 -1
                if !starving || old>>mutexWaiterShift == 1 { // 如果是饥饿模式下并且自己是最后一个 waiter ，那么清除 mutexStarving 标记
                    // Exit starvation mode.
                    // Critical to do it here and consider wait time.
                    // Starvation mode is so inefficient, that two goroutines
                    // can go lock-step infinitely once they switch mutex
                    // to starvation mode.
                    delta -= mutexStarving
                }
                atomic.AddInt32(&m.state, delta) // 更新，抢锁成功后退出
                break
            }
            awoke = true // 走到这里，不是饥饿模式，重新发起抢锁竞争
            iter = 0
        } else {
            old = m.state // CAS 失败，重新发起竞争
        }
    }

    if race.Enabled {
        race.Acquire(unsafe.Pointer(m))
    }
}

整体来讲，公平锁上锁逻辑复杂了不少，边界点要考滤的比较多

同样的 fast path 快速上锁逻辑，原来 m.state 为 0，锁就完事了
进入 for 循环，也要走自旋逻辑，但是多了一个判断，如果当前处于饥饿模式禁止自旋，根据实现原理，此时活跃的 goroutine 要直接进入 park 的队列
自旋后面的代码有四种情况：饥饿抢锁成功，饥饿抢锁失败，正常抢锁成功，正常抢锁失败。上锁失败的最后都要 waiter 计数加一后，更新 CAS
如果 CAS 失败，那么重新发起竞争就好
如果 CAS 成功，此时要判断处于何种情况，如果 old 没上锁也处于 normal 模式，抢锁成功退出
如果 CAS 成功，但是己经有人上锁了，那么要根据 queueLifo 来判断是扔到 park 队首还是队尾，此时当前 goroutine park 在这里，等待被唤醒
runtime_SemacquireMutex 被唤醒了有两种情况，判断是否要进入饥饿模式，如果老的 old 就是饥饿的，那么自己一定是唯一被唤醒，一定能抢到锁的，waiter 减一，如果自己是最后一个 waiter 或是饥饿时间小于 starvationThresholdNs 那么清除 mutexStarving 标记位后退出
如果老的不是饥饿模式，那么 awoke 置 true，重新竞争

公平锁解锁逻辑

// Unlock unlocks m.
// It is a run-time error if m is not locked on entry to Unlock.
//
// A locked Mutex is not associated with a particular goroutine.
// It is allowed for one goroutine to lock a Mutex and then
// arrange for another goroutine to unlock it.
func (m *Mutex) Unlock() {
    if race.Enabled {
        _ = m.state
        race.Release(unsafe.Pointer(m))
    }

    // Fast path: drop lock bit. 和原有逻辑一样，先减去 mutexLocked，并判断是否解锁了未上锁的 Mutex, 直接 panic
    new := atomic.AddInt32(&m.state, -mutexLocked)
    if (new+mutexLocked)&mutexLocked == 0 {
        throw("sync: unlock of unlocked mutex")
    }
    if new&mutexStarving == 0 { // 查看 mutexStarving 标记位，如果 0 走老逻辑，否则走 starvation 分支
        old := new
        for {
            // If there are no waiters or a goroutine has already
            // been woken or grabbed the lock, no need to wake anyone.
            // In starvation mode ownership is directly handed off from unlocking
            // goroutine to the next waiter. We are not part of this chain,
            // since we did not observe mutexStarving when we unlocked the mutex above.
            // So get off the way.
            if old>>mutexWaiterShift == 0 || old&(mutexLocked|mutexWoken|mutexStarving) != 0 {
                return
            }
            // Grab the right to wake someone.
            new = (old - 1<<mutexWaiterShift) | mutexWoken
            if atomic.CompareAndSwapInt32(&m.state, old, new) {
                runtime_Semrelease(&m.sema, false)
                return
            }
            old = m.state
        }
    } else {
        // Starving mode: handoff mutex ownership to the next waiter.
        // Note: mutexLocked is not set, the waiter will set it after wakeup.
        // But mutex is still considered locked if mutexStarving is set,
        // so new coming goroutines won't acquire it.
        runtime_Semrelease(&m.sema, true) // 直接 runtime_Semrelease 唤醒等待的 goroutine
    }
}

原子操作，将 m.state 减去 mutexLocked，然后判断是否释放了未上锁的 Mutex，直接 panic
根据 m.state 的 mutexStarving 判断当前处于何种模式，0 走 normal 分支，1 走 starvation 分支
starvation 模式下，直接 runtime_Semrelease 做信号量 UP 操作，唤醒 FIFO 队列中的第一个 goroutine
noarmal 模式类似原有逻辑，唯一不同的是多了一个 mutexStarving 位判断逻辑

推荐阅读《Go设计与实现》6.2同步原语和锁

https://draveness.me/golang/docs/part3-runtime/ch06-concurrency/golang-sync-primitives/

Go 语言的 sync.Map 浅析

Wed, 02 Dec 2020 10:46:00 +0000

Start

今天讲一下 Go 语言中的 sync.Map 包 , 那么 sync.Map 和内建的 map 有什么区别呢， map 是线程不安全的，并发读的情况下还好，要是并发写的话会报pannic

func main() {

	m := map[string]int{}

	for i := 0; i < 10; i++ {
		go func() {
			m["s"] = 1
		}()
	}
	return
}
//➜  go-inside go run "/home/guo/code/goproj/src/github.com/kingcanfish/go-inside/main.go"
//fatal error: concurrent map writes

那么问题来了，如果有多线程或者多协程并发需求的话应该怎么办呢？

我们可以在 map 结构体外层包装一个带锁的结构，比如

type currentMap struct {
	mu sync.RWMutex
	m map[interface{}] interface{}
}

cm := currentMap{m:make(map[interface{}]interface{})}

//read
cm.RLock()
value := cm.m["somekey"]
cm.RUnlock()

//write
cm.Lock()
cm.m["comekey"] = "some"
cm.Unlock()

因为互斥锁效率有点低，对于 map 这种读多写少的数据结构，我们能最大限度的提高读写效率，所以我们使用读写锁

但是数据量大的话，大并发情况下只使用一把锁会使客户端争用严重，影响性能，熟悉 Java 同学都知道 Java 中的 ConcurrentHashMap 并不是全局使用一个读写锁的， Java 的实现方法是内部一个区间使用一把锁， GitHub 上用 Go 版本的实现

https://github.com/orcaman/concurrent-map

sync.Map 正文

Golang 在版本 1.9 之后引入 sync.Map 用于并发情况下使用 Map , 下面分析一下 sync.Map 那不到400行的源码 ~~但是我还是看了好几天啊淦~~

以下基于Go v1.15.5 最近几个版本对 sync.Map 有做改动，对比自己的版本要注意区别~~后面的题外话会说到~~

结构

type Map struct {
	mu Mutex

	// read contains the portion of the map's contents that are safe for
	// concurrent access (with or without mu held).
	//
	// The read field itself is always safe to load, but must only be stored with
	// mu held.
	//
	// Entries stored in read may be updated concurrently without mu, but updating
	// a previously-expunged entry requires that the entry be copied to the dirty
	// map and unexpunged with mu held.
	read atomic.Value // readOnly

	// dirty contains the portion of the map's contents that require mu to be
	// held. To ensure that the dirty map can be promoted to the read map quickly,
	// it also includes all of the non-expunged entries in the read map.
	//
	// Expunged entries are not stored in the dirty map. An expunged entry in the
	// clean map must be unexpunged and added to the dirty map before a new value
	// can be stored to it.
	//
	// If the dirty map is nil, the next write to the map will initialize it by
	// making a shallow copy of the clean map, omitting stale entries.
	dirty map[interface{}]*entry

	// misses counts the number of loads since the read map was last updated that
	// needed to lock mu to determine whether the key was present.
	//
	// Once enough misses have occurred to cover the cost of copying the dirty
	// map, the dirty map will be promoted to the read map (in the unamended
	// state) and the next store to the map will make a new dirty copy.
	misses int
}

type readOnly struct {
	m       map[interface{}]*entry
	amended bool // true if the dirty map contains some key not in m.
}

// expunged is an arbitrary pointer that marks entries which have been deleted
// from the dirty map.
var expunged = unsafe.Pointer(new(interface{}))

// An entry is a slot in the map corresponding to a particular key.
type entry struct {
	// p points to the interface{} value stored for the entry.
	//
	// If p == nil, the entry has been deleted and m.dirty == nil.
	//
	// If p == expunged, the entry has been deleted, m.dirty != nil, and the entry
	// is missing from m.dirty.
	//
	// Otherwise, the entry is valid and recorded in m.read.m[key] and, if m.dirty
	// != nil, in m.dirty[key].
	//
	// An entry can be deleted by atomic replacement with nil: when m.dirty is
	// next created, it will atomically replace nil with expunged and leave
	// m.dirty[key] unset.
	//
	// An entry's associated value can be updated by atomic replacement, provided
	// p != expunged. If p == expunged, an entry's associated value can be updated
	// only after first setting m.dirty[key] = e so that lookups using the dirty
	// map find the entry.
	p unsafe.Pointer // *interface{}
}

Map 结构包含了互斥锁 m , 只读的底层 map read (atomic.Value 实际上指向一个接口，而这个接口又指回了 readOnly 这个数据结构，通过 atomic.Value 来提供一些原子性的操作，比如CAS –比较并交换)
readOnly 这个结构包含底层map 和amended 两个结构 ,其中amended 用来表示有没有存在 dirty 中但是没有存在 readOnly 中的元素, 如果有则为真, 否则为假
missed 表示 read 中未命中的次数, 无论后续在 dirty 中是否再次命中 ,该值都会加1
uxpunged 是开始就初始化好的空指针, 如果有键要删除,可以将它标为 uxpunged 也就是空指针, 等待特定条件下回收
dirty 简简单单的底层 map
entry 简简单单指向真正值的指针
详细的说明的话还是要看注释
不如看图

内置方法

Load

// Load returns the value stored in the map for a key, or nil if no
// value is present.
// The ok result indicates whether value was found in the map.
func (m *Map) Load(key interface{}) (value interface{}, ok bool) {
	read, _ := m.read.Load().(readOnly)
	e, ok := read.m[key]
	if !ok && read.amended {
		m.mu.Lock()
		// Avoid reporting a spurious miss if m.dirty got promoted while we were
		// blocked on m.mu. (If further loads of the same key will not miss, it's
		// not worth copying the dirty map for this key.)
		read, _ = m.read.Load().(readOnly)
		e, ok = read.m[key]
		if !ok && read.amended {
			e, ok = m.dirty[key]
			// Regardless of whether the entry was present, record a miss: this key
			// will take the slow path until the dirty map is promoted to the read
			// map.
			m.missLocked()
		}
		m.mu.Unlock()
	}
	if !ok {
		return nil, false
	}
	return e.load()
}

func (e *entry) load() (value interface{}, ok bool) {
	p := atomic.LoadPointer(&e.p)
	if p == nil || p == expunged {
		return nil, false
	}
	return *(*interface{})(p), true
}

Load 方法的主要代码就在这里了

首先会从 read 获取, 如果没有获取到那么这时候在再判断 amended 字段 ,之前我们说了 amended 是一个哨兵位, 用来表示 dirty 中是否有 read 中没有的数据
所以判断 !ok && read.amended 进入 dirty 检查, 注意这里在上锁的时候使用了双重检查锁, 因为在边界上可能发生中断 , 恢复的时候可能 read 中已经有值了, 所以需要再进行一次检查 , 单例模式里面有双重检查锁的应用 ~~扯远了~~
再往下如果 !ok 的话,说明 amended 为 false 就说明 dirty 中肯定没有,直接返回 false
再往下就是获得到了 entry 调用 e.load() ,如果 e 的指针指向的 nil 或者 expunged ( 之前被删除标记成了 expunged ) 说明值是不存在的 ,所以返回 nil,
否则返回这个指针指向的值
还有 m.missLocked() 函数如下
1 2 3 4 5 6 7 8 9

func (m *Map) missLocked() { m.misses++ if m.misses < len(m.dirty) { return } m.read.Store(readOnly{m: m.dirty}) m.dirty = nil m.misses = 0 }
- 当 read未命中的时候, 会调用这个函数, 此时 misses 自增 1 , 当miss的次数大于 dirty 中元素的个数,的时候,会进行升级, 将 dirty 中所有的键值对提升到 read 中, 同时计数清 0 , dirty 也清空 ~

Store

func (m *Map) Store(key, value interface{}) {
	read, _ := m.read.Load().(readOnly)
	if e, ok := read.m[key]; ok && e.tryStore(&value) {
		return
	}

	m.mu.Lock()
	read, _ = m.read.Load().(readOnly)
	if e, ok := read.m[key]; ok {
		if e.unexpungeLocked() {
			// The entry was previously expunged, which implies that there is a
			// non-nil dirty map and this entry is not in it.
			m.dirty[key] = e
		}
		e.storeLocked(&value)
	} else if e, ok := m.dirty[key]; ok {
		e.storeLocked(&value)
	} else {
		if !read.amended {
			// We're adding the first new key to the dirty map.
			// Make sure it is allocated and mark the read-only map as incomplete.
			m.dirtyLocked()
			m.read.Store(readOnly{m: read.m, amended: true})
		}
		m.dirty[key] = newEntry(value)
	}
	m.mu.Unlock()
}
func (e *entry) tryStore(i *interface{}) bool {
	for {
		p := atomic.LoadPointer(&e.p)
		if p == expunged {
			return false
		}
		if atomic.CompareAndSwapPointer(&e.p, p, unsafe.Pointer(i)) {
			return true
		}
	}
}

func (e *entry) unexpungeLocked() (wasExpunged bool) {
	return atomic.CompareAndSwapPointer(&e.p, expunged, nil)
}

func (m *Map) dirtyLocked() {
	if m.dirty != nil {
		return
	}

	read, _ := m.read.Load().(readOnly)
	m.dirty = make(map[interface{}]*entry, len(read.m))
	for k, e := range read.m {
		if !e.tryExpungeLocked() {
			m.dirty[k] = e
		}
	}
}

以上就是Store方法的主要实现

和 Load 一样先从read 里面读取, 如果 ok 的话,直接调用 e.tryStore()方法原子地更换底层的值, 又由于底层实现是指针 , read 里面替换了 dirty 里面也会替换, 注意
- 1 2 3
  
  if p == expunged { return false }
  如果指向的是 expunged 的话,返回 false , 流程往后走
如果read里面没有或者 read 里指向的是 expunged 的话上互斥锁,这里又用到了双重检查锁,理由同 Load 部分
如果read 里面是 expunged然后通过 e.unexpungeLocked() 函数调用 CAS (比较并交换) 如果 e.p 指向的是expunged 的话,替换成nil
- 疑问:这里为什么要将expunged替换成nil呢?既然都以及被标记为待回收的垃圾了,那直接复制就好了,为什么要这样?
- 猜测: 和后面 e.storeLocked(&value) 的操作有关, 这个操作可能就是要nil 才能满足背后的原子性的store操作(仅为猜测与思考,不一定准确)
如果上一步判断 read 没有的话,就在 dirty 里面检查是否命中 ,如果命中的话直接替换
如果dirty里面也没有的话, 继续往下判断如果 read.amended 为false 的话, 说明 dirty 现在为 nil , 这个键值对为第一个添加到 dirty 里面的, 调用m.dirtyLocked() 将 read 里面的元素迭代添加到 dirty 里面, 添加的过程中会判断键值对是不是出于 unexpunge 或者 nil 状态并进行过滤
如果不是 dirty 的第一个元素, 直接创建个新的添加进去就行了
Tips : 为什么向 dirty 添加第一个元素的时候要将 read 里面的拷贝到 dirty 里?
因为miss过多将 dirty全部提升到read里 ,注意这里时直接将read的指针指向dirty ,所以之前read里的数据就会丢失,所以为了避免 read 里的数据丢失,就要将read里面的数据再存到dirty里, 由于这是一个迭代传值的过程,频繁进行这个操作肯定是会影响性能的

Delete

func (m *Map) LoadAndDelete(key interface{}) (value interface{}, loaded bool) {
	read, _ := m.read.Load().(readOnly)
	e, ok := read.m[key]
	if !ok && read.amended {
		m.mu.Lock()
		read, _ = m.read.Load().(readOnly)
		e, ok = read.m[key]
		if !ok && read.amended {
			e, ok = m.dirty[key]
			delete(m.dirty, key)
			// Regardless of whether the entry was present, record a miss: this key
			// will take the slow path until the dirty map is promoted to the read
			// map.
			m.missLocked()
		}
		m.mu.Unlock()
	}
	if ok {
		return e.delete()
	}
	return nil, false
}

// Delete deletes the value for a key.
func (m *Map) Delete(key interface{}) {
	m.LoadAndDelete(key)
}

func (e *entry) delete() (value interface{}, ok bool) {
	for {
		p := atomic.LoadPointer(&e.p)
		if p == nil || p == expunged {
			return nil, false
		}
		if atomic.CompareAndSwapPointer(&e.p, p, nil) {
			return *(*interface{})(p), true
		}
	}
}

Delete 方法看起来比较简单

实际上Delete 方法就是LoadAndDelete 方法的套壳,只是没有吧Load出来的数据返回而已

在前几个版本中貌似没有 LoadAndDelete 方法,至少1.9.x 版本是没有的,现在只不过是把之前 Delete 的逻辑移动到了 DeleteAndLoad 方法中而已

首先也是从 read 中获取
没有获取到的话再通过 read.amended 判断 dirty 中有没有数据, 有的话通过双重检查锁进入 dirty 中获取, 如果在 dirty 中获取到了,调用 delete() 方法直接删除
注意这里是直接删除,能被 GC 回收,在1.15.1版本是调用 e.delete() 方法的,是不会进行垃圾回收的,有内存泄露的风险,直至我现在 1.15.5 版本已经修复~
如果有的话就进入 e.delete() 方法将 e 指向 nil 间接删除, 这里值实体是可以被 GC 回收的, 但是 entry 依然是在的,所以这部分是不会被 GC 回收的

Range

// Range calls f sequentially for each key and value present in the map.
// If f returns false, range stops the iteration.
//
// Range does not necessarily correspond to any consistent snapshot of the Map's
// contents: no key will be visited more than once, but if the value for any key
// is stored or deleted concurrently, Range may reflect any mapping for that key
// from any point during the Range call.
//
// Range may be O(N) with the number of elements in the map even if f returns
// false after a constant number of calls.
func (m *Map) Range(f func(key, value interface{}) bool) {
	// We need to be able to iterate over all of the keys that were already
	// present at the start of the call to Range.
	// If read.amended is false, then read.m satisfies that property without
	// requiring us to hold m.mu for a long time.
	read, _ := m.read.Load().(readOnly)
	if read.amended {
		// m.dirty contains keys not in read.m. Fortunately, Range is already O(N)
		// (assuming the caller does not break out early), so a call to Range
		// amortizes an entire copy of the map: we can promote the dirty copy
		// immediately!
		m.mu.Lock()
		read, _ = m.read.Load().(readOnly)
		if read.amended {
			read = readOnly{m: m.dirty}
			m.read.Store(read)
			m.dirty = nil
			m.misses = 0
		}
		m.mu.Unlock()
	}

	for k, e := range read.m {
		v, ok := e.load()
		if !ok {
			continue
		}
		if !f(k, v) {
			break
		}
	}
}

Range 方法提供了一个遍历元素的方法,需要传入一个回调函数, 该方法会将遍历出来的键值对传入这个回调函数里,用户自己的逻辑就要放在这个函数里实现
而且什么时候停止遍历有回调函数决定, 当回调函数返回 false 的时候就会停止遍历
注意因为是 Range , 所以在 Range 之前需要将 dirty 提升到 read 然后对 read 实现遍历

example

var m sync.Map

m.Range(func(k,v interface{})bool{
        fmt.Print(k)
        fmt.Print(":")
        fmt.Print(v)
        fmt.Println()
        return true
 })

Other

这里有关于 v1.15.1 内存泄露的案例 https://gocn.vip/topics/10860

sync.Map 是典型的用空间换时间的做法, 通过一个read做高速缓冲, 极大提高了多线程读的效率,但是由于 first entry 的存在,会将 read 中数据迭代拷贝回dirty 中,这里可能会比较耗时,所以sync.Map的使用场景应该更偏向于读多写少的情况

参考博文:

https://www.cnblogs.com/qcrao-2018/p/12833787.html

https://tonybai.com/2020/11/10/understand-sync-map-inside-through-examples/

Golang 调度器 GMP 原理与调度全分析

Sun, 19 Jul 2020 21:43:24 +0800

本文转自: https://learnku.com/articles/41728
作者：Aceld

Golang “调度器” 的由来？

(1) 单进程时代不需要调度器

我们知道，一切的软件都是跑在操作系统上，真正用来干活 (计算) 的是 CPU。早期的操作系统每个程序就是一个进程，知道一个程序运行完，才能进行下一个进程，就是 “单进程时代”

一切的程序只能串行发生。

早期的单进程操作系统，面临 2 个问题：

单一的执行流程，计算机只能一个任务一个任务处理。
进程阻塞所带来的 CPU 时间浪费。

那么能不能有多个进程来宏观一起来执行多个任务呢？

后来操作系统就具有了最早的并发能力：多进程并发，当一个进程阻塞的时候，切换到另外等待执行的进程，这样就能尽量把 CPU 利用起来，CPU 就不浪费了。

(2) 多进程 / 线程时代有了调度器需求

在多进程 / 多线程的操作系统中，就解决了阻塞的问题，因为一个进程阻塞 cpu 可以立刻切换到其他进程中去执行，而且调度 cpu 的算法可以保证在运行的进程都可以被分配到 cpu 的运行时间片。这样从宏观来看，似乎多个进程是在同时被运行。

但新的问题就又出现了，进程拥有太多的资源，进程的创建、切换、销毁，都会占用很长的时间，CPU 虽然利用起来了，但如果进程过多，CPU 有很大的一部分都被用来进行进程调度了。

怎么才能提高 CPU 的利用率呢？

但是对于 Linux 操作系统来讲，cpu 对进程的态度和线程的态度是一样的。

很明显，CPU 调度切换的是进程和线程。尽管线程看起来很美好，但实际上多线程开发设计会变得更加复杂，要考虑很多同步竞争等问题，如锁、竞争冲突等。

(3) 协程来提高 CPU 利用率

多进程、多线程已经提高了系统的并发能力，但是在当今互联网高并发场景下，为每个任务都创建一个线程是不现实的，因为会消耗大量的内存 (进程虚拟内存会占用 4GB [32 位操作系统], 而线程也要大约 4MB)。

大量的进程 / 线程出现了新的问题

高内存占用
调度的高消耗 CPU

好了，然后工程师们就发现，其实一个线程分为 “内核态 “线程和” 用户态 “线程。

一个 “用户态线程” 必须要绑定一个 “内核态线程”，但是 CPU 并不知道有 “用户态线程” 的存在，它只知道它运行的是一个 “内核态线程”(Linux 的 PCB 进程控制块)。

这样，我们再去细化去分类一下，内核线程依然叫 “线程 (thread)”，用户线程叫 “协程 (co-routine)”.

看到这里，我们就要开脑洞了，既然一个协程 (co-routine) 可以绑定一个线程 (thread)，那么能不能多个协程 (co-routine) 绑定一个或者多个线程 (thread) 上呢。

之后，我们就看到了有 3 中协程和线程的映射关系

N:1

N 个协程绑定 1 个线程，优点就是协程在用户态线程即完成切换，不会陷入到内核态，这种切换非常的轻量快速。但也有很大的缺点，1 个进程的所有协程都绑定在 1 个线程上

缺点：

某个程序用不了硬件的多核加速能力
一旦某协程阻塞，造成线程阻塞，本进程的其他协程都无法执行了，根本就没有并发的能力了。

1:1关系

1 个协程绑定 1 个线程，这种最容易实现。协程的调度都由 CPU 完成了，不存在 N:1 缺点，

缺点：

协程的创建、删除和切换的代价都由 CPU 完成，有点略显昂贵了。

M:N

M 个协程绑定 1 个线程，是 N:1 和 1:1 类型的结合，克服了以上 2 种模型的缺点，但实现起来最为复杂

协程跟线程是有区别的，线程由 CPU 调度是抢占式的，协程由用户态调度是协作式的，一个协程让出 CPU 后，才执行下一个协程。

(4) Go 语言的协程 goroutine

Go 为了提供更容易使用的并发方法，使用了 goroutine 和 channel, goroutine 来自协程的概念，让一组可复用的函数运行在一组线程之上，即使有协程阻塞，该线程的其他协程也可以被 runtime 调度，转移到其他可运行的线程上。最关键的是，程序员看不到这些底层的细节，这就降低了编程的难度，提供了更容易的并发。

Go 中，协程被称为 goroutine，它非常轻量，一个 goroutine 只占几 KB，并且这几 KB 就足够 goroutine 运行完，这就能在有限的内存空间内支持大量 goroutine，支持了更多的并发。虽然一个 goroutine 的栈只占几 KB，但实际是可伸缩的，如果需要更多内容，runtime 会自动为 goroutine 分配。

Goroutine 特点：

占用内存更小（几 kb）调度更灵活 (runtime 调度)

(5) 被废弃的 goroutine 调度器

好了，既然我们知道了协程和线程的关系，那么最关键的一点就是调度协程的调度器的实现了。

Go 目前使用的调度器是 2012 年重新设计的，因为之前的调度器性能存在问题，所以使用 4 年就被废弃了，那么我们先来分析一下被废弃的调度器是如何运作的？

大部分文章都是会用 G 来表示 Goroutine，用 M 来表示线程，那么我们也会用这种表达的对应关系。

下面我们来看看被废弃的 golang 调度器是如何实现的？

M 想要执行、放回 G 都必须访问全局 G 队列，并且 M 有多个，即多线程访问同一资源需要加锁进行保证互斥 / 同步，所以全局 G 队列是有互斥锁进行保护的。

老调度器有几个缺点：

创建、销毁、调度 G 都需要每个 M 获取锁，这就形成了激烈的锁竞争。
M 转移 G 会造成延迟和额外的系统负载。比如当 G 中包含创建新协程的时候，M 创建了 G’ ，为了继续执行 G ，需要把 G’ 交给 M’ 执行，也造成了很差的局部性，因为 G’ 和 G 是相关的，最好放在 M 上执行，而不是其他 M’ 。
系统调用 (CPU 在 M 之间的切换) 导致频繁的线程阻塞和取消阻塞操作增加了系统开销。

Goroutine 调度器的 GMP 模型的设计思想

面对之前调度器的问题，Go 设计了新的调度器。

在新调度器中，出列 M (thread) 和 G (goroutine)，又引进了 P (Processor)。

Processor，它包含了运行 goroutine 的资源，如果线程想运行 goroutine，必须先获取 P，P 中还包含了可运行的 G 队列。

(1) GMP 模型

在 Go 中，线程是运行 goroutine 的实体，调度器的功能是把可运行的 goroutine 分配到工作线程上。

全局队列（Global Queue）：存放等待运行的 G。
P 的本地队列：同全局队列类似，存放的也是等待运行的 G，存的数量有限，不超过 256 个。新建 G’时，G’优先加入到 P 的本地队列，如果队列满了，则会把本地队列中一半的 G 移动到全局队列。
P 列表：所有的 P 都在程序启动时创建，并保存在数组中，最多有 GOMAXPROCS(可配置) 个。
M：线程想运行任务就得获取 P，从 P 的本地队列获取 G，P 队列为空时，M 也会尝试从全局队列拿一批 G 放到 P 的本地队列，或从其他 P 的本地队列偷一半放到自己 P 的本地队列。M 运行 G，G 执行之后，M 会从 P 获取下一个 G，不断重复下去。

Goroutine 调度器和 OS 调度器是通过 M 结合起来的，每个 M 都代表了 1 个内核线程，OS 调度器负责把内核线程分配到 CPU 的核上执行。

有关 P 和 M 的个数问题

1、P 的数量：

由启动时环境变量 $GOMAXPROCS 或者是由 runtime 的方法 GOMAXPROCS() 决定。这意味着在程序执行的任意时刻都只有 $GOMAXPROCS 个 goroutine 在同时运行。

2、M 的数量:

go 语言本身的限制：go 程序启动时，会设置 M 的最大数量，默认 10000. 但是内核很难支持这么多的线程数，所以这个限制可以忽略。
runtime/debug 中的 SetMaxThreads 函数，设置 M 的最大数量
一个 M 阻塞了，会创建新的 M。

M 与 P 的数量没有绝对关系，一个 M 阻塞，P 就会去创建或者切换另一个 M，所以，即使 P 的默认数量是 1，也有可能会创建很多个 M 出来

P 和 M 何时会被创建

1、P 何时创建：在确定了 P 的最大数量 n 后，运行时系统会根据这个数量创建 n 个 P。

2、M 何时创建：没有足够的 M 来关联 P 并运行其中的可运行的 G。比如所有的 M 此时都阻塞住了，而 P 中还有很多就绪任务，就会去寻找空闲的 M，而没有空闲的，就会去创建新的 M

(2)调度器的设计策略

复用线程：避免频繁的创建、销毁线程，而是对线程的复用。

work stealing 机制

当本线程无可运行的 G 时，尝试从其他线程绑定的 P 偷取 G，而不是销毁线程。

hand off 机制

当本线程因为 G 进行系统调用阻塞时，线程释放绑定的 P，把 P 转移给其他空闲的线程执行。

利用并行：GOMAXPROCS 设置 P 的数量，最多有 GOMAXPROCS 个线程分布在多个 CPU 上同时运行。GOMAXPROCS 也限制了并发的程度，比如 GOMAXPROCS = 核数/2，则最多利用了一半的 CPU 核进行并行。
抢占：在 coroutine 中要等待一个协程主动让出 CPU 才执行下一个协程，在 Go 中，一个 goroutine 最多占用 CPU 10ms，防止其他 goroutine 被饿死，这就是 goroutine 不同于 coroutine 的一个地方。
全局 G 队列：在新的调度器中依然有全局 G 队列，但功能已经被弱化了，当 M 执行 work stealing 从其他 P 偷不到 G 时，它可以从全局 G 队列获取 G。

(3) go func () 调度流程

从上图我们可以分析出几个结论：

我们通过 go func () 来创建一个 goroutine；
有两个存储 G 的队列，一个是局部调度器 P 的本地队列、一个是全局 G 队列。新创建的 G 会先保存在 P 的本地队列中，如果 P 的本地队列已经满了就会保存在全局的队列中；
G 只能运行在 M 中，一个 M 必须持有一个 P，M 与 P 是 1：1 的关系。M 会从 P 的本地队列弹出一个可执行状态的 G 来执行，如果 P 的本地队列为空，就会想其他的 MP 组合偷取一个可执行的 G 来执行；
一个 M 调度 G 执行的过程是一个循环机制；
当 M 执行某一个 G 时候如果发生了 syscall 或则其余阻塞操作，M 会阻塞，如果当前有一些 G 在执行，runtime 会把这个线程 M 从 P 中摘除 (detach)，然后再创建一个新的操作系统的线程 (如果有空闲的线程可用就复用空闲线程) 来服务于这个 P；
当 M 系统调用结束时候，这个 G 会尝试获取一个空闲的 P 执行，并放入到这个 P 的本地队列。如果获取不到 P，那么这个线程 M 变成休眠状态，加入到空闲线程中，然后这个 G 会被放入全局队列中。

(4) 调度器的生命周期

特殊的 M0 和 G0

M0 是启动程序后的编号为 0 的主线程，这个 M 对应的实例会在全局变量 runtime.m0 中，不需要在 heap 上分配，M0 负责执行初始化操作和启动第一个 G，在之后 M0 就和其他的 M 一样了。

G0 是每次启动一个 M 都会第一个创建的 gourtine，G0 仅用于负责调度的 G，G0 不指向任何可执行的函数，每个 M 都会有一个自己的 G0。在调度或系统调用时会使用 G0 的栈空间，全局变量的 G0 是 M0 的 G0。

我们来跟踪一段代码

package main

import "fmt"

func main() {
    fmt.Println("Hello world")
}

接下来我们来针对上面的代码对调度器里面的结构做一个分析。

也会经历如上图所示的过程：

runtime 创建最初的线程 m0 和 goroutine g0，并把 2 者关联。
调度器初始化：初始化 m0、栈、垃圾回收，以及创建和初始化由 GOMAXPROCS 个 P 构成的 P 列表。
示例代码中的 main 函数是 main.main，runtime 中也有 1 个 main 函数 ——runtime.main，代码经过编译后，runtime.main 会调用 main.main，程序启动时会为 runtime.main 创建 goroutine，称它为 main goroutine 吧，然后把 main goroutine 加入到 P 的本地队列
启动 m0，m0 已经绑定了 P，会从 P 的本地队列获取 G，获取到 main goroutine。
G 拥有栈，M 根据 G 中的栈信息和调度信息设置运行环境
M 运行 G
G 退出，再次回到 M 获取可运行的 G，这样重复下去，直到 main.main 退出，runtime.main 执行 Defer 和 Panic 处理，或调用 runtime.exit 退出程序

调度器的生命周期几乎占满了一个 Go 程序的一生，runtime.main 的 goroutine 执行之前都是为调度器做准备工作， runtime.main 的 goroutine 运行，才是调度器的真正开始，直到 runtime.main 结束而结束

(5) 可视化 GMP 编程

有 2 种方式可以查看一个程序的 GMP 的数据。

方式 1：go tool trace

trace 记录了运行时的信息，能提供可视化的 Web 页面。

简单测试代码：main 函数创建 trace，trace 会运行在单独的 goroutine 中，然后 main 打印”Hello World” 退出。

# trace.go
package main

import (
    "os"
    "fmt"
    "runtime/trace"
)

func main() {

    //创建trace文件
    f, err := os.Create("trace.out")
    if err != nil {
        panic(err)
    }

    defer f.Close()

    //启动trace goroutine
    err = trace.Start(f)
    if err != nil {
        panic(err)
    }
    defer trace.Stop()

    //main
    fmt.Println("Hello World")
}

运行程序

1
2

$ go run trace.go 
Hello World

会得到一个 trace.out 文件，然后我们可以用一个工具打开，来分析这个文件。

$ go tool trace trace.out 
2020/02/23 10:44:11 Parsing trace...
2020/02/23 10:44:11 Splitting trace...
2020/02/23 10:44:11 Opening browser. Trace viewer is listening on http://127.0.0.1:33479

我们可以通过浏览器打开 http://127.0.0.1:33479 网址，点击 view trace 能够看见可视化的调度流程。

G 信息

点击 Goroutines 那一行可视化的数据条，我们会看到一些详细的信息。

一共有两个G在程序中，一个是特殊的G0，是每个M必须有的一个初始化的G，这个我们不必讨论。

其中 G1 应该就是 main goroutine (执行 main 函数的协程)，在一段时间内处于可运行和运行的状态。

M 信息

点击 Threads 那一行可视化的数据条，我们会看到一些详细的信息。

一共有两个 M 在程序中，一个是特殊的 M0，用于初始化使用，这个我们不必讨论。

P 信息

G1 中调用了 main.main，创建了 trace goroutine g18。G1 运行在 P1 上，G18 运行在 P0 上。

这里有两个 P，我们知道，一个 P 必须绑定一个 M 才能调度 G。

我们在来看看上面的 M 信息。

我们会发现，确实 G18 在 P0 上被运行的时候，确实在 Threads 行多了一个 M 的数据，点击查看如下：

多了一个 M2 应该就是 P0 为了执行 G18 而动态创建的 M2.

方式 2：Debug trace

package main

import (
    "fmt"
    "time"
)

func main() {
    for i := 0; i < 5; i++ {
        time.Sleep(time.Second)
        fmt.Println("Hello World")
    }
}

build

`1`	`$ go build trace2.go`

通过 Debug 方式运行

$ GODEBUG=schedtrace=1000 ./trace2 
SCHED 0ms: gomaxprocs=2 idleprocs=0 threads=4 spinningthreads=1 idlethreads=1 runqueue=0 [0 0]
Hello World
SCHED 1003ms: gomaxprocs=2 idleprocs=2 threads=4 spinningthreads=0 idlethreads=2 runqueue=0 [0 0]
Hello World
SCHED 2014ms: gomaxprocs=2 idleprocs=2 threads=4 spinningthreads=0 idlethreads=2 runqueue=0 [0 0]
Hello World
SCHED 3015ms: gomaxprocs=2 idleprocs=2 threads=4 spinningthreads=0 idlethreads=2 runqueue=0 [0 0]
Hello World
SCHED 4023ms: gomaxprocs=2 idleprocs=2 threads=4 spinningthreads=0 idlethreads=2 runqueue=0 [0 0]
Hello World

SCHED：调试信息输出标志字符串，代表本行是 goroutine 调度器的输出；
0ms：即从程序启动到输出这行日志的时间；
gomaxprocs: P 的数量，本例有 2 个 P, 因为默认的 P 的属性是和 cpu 核心数量默认一致，当然也可以通过 GOMAXPROCS 来设置；
idleprocs: 处于 idle 状态的 P 的数量；通过 gomaxprocs 和 idleprocs 的差值，我们就可知道执行 go 代码的 P 的数量；
threads: os threads/M 的数量，包含 scheduler 使用的 m 数量，加上 runtime 自用的类似 sysmon 这样的 thread 的数量；
spinningthreads: 处于自旋状态的 os thread 数量；
idlethread: 处于 idle 状态的 os thread 的数量；
runqueue=0： Scheduler 全局队列中 G 的数量；
[0 0]: 分别为 2 个 P 的 local queue 中的 G 的数量。

下一篇，我们来继续详细的分析 GMP 调度原理的一些场景问题。

Go 调度器调度场景过程全解析

(1) 场景 1

P 拥有 G1，M1 获取 P 后开始运行 G1，G1 使用 go func() 创建了 G2，为了局部性 G2 优先加入到 P1 的本地队列。

(2) 场景 2

G1 运行完成后 (函数：goexit)，M 上运行的 goroutine 切换为 G0，G0 负责调度时协程的切换（函数：schedule）。从 P 的本地队列取 G2，从 G0 切换到 G2，并开始运行 G2 (函数：execute)。实现了线程 M1 的复用。

(3) 场景 3

假设每个 P 的本地队列只能存 3 个 G。G2 要创建了 6 个 G，前 3 个 G（G3, G4, G5）已经加入 p1 的本地队列，p1 本地队列满了。

(4)场景4

G2 在创建 G7 的时候，发现 P1 的本地队列已满，需要执行负载均衡 (把 P1 中本地队列中前一半的 G，还有新创建 G 转移到全局队列)

（实现中并不一定是新的 G，如果 G 是 G2 之后就执行的，会被保存在本地队列，利用某个老的 G 替换新 G 加入全局队列）

这些 G 被转移到全局队列时，会被打乱顺序。所以 G3,G4,G7 被转移到全局队列。

(5) 场景 5

G2 创建 G8 时，P1 的本地队列未满，所以 G8 会被加入到 P1 的本地队列。

G8 加入到 P1 点本地队列的原因还是因为 P1 此时在与 M1 绑定，而 G2 此时是 M1 在执行。所以 G2 创建的新的 G 会优先放置到自己的 M 绑定的 P 上。

(6) 场景 6

规定：在创建 G 时，运行的 G 会尝试唤醒其他空闲的 P 和 M 组合去执行。

假定 G2 唤醒了 M2，M2 绑定了 P2，并运行 G0，但 P2 本地队列没有 G，M2 此时为自旋线程**（没有 G 但为运行状态的线程，不断寻找 G）**。

(7) 场景 7

M2 尝试从全局队列 (简称 “GQ”) 取一批 G 放到 P2 的本地队列（函数：findrunnable()）。M2 从全局队列取的 G 数量符合下面的公式：

`1`	`n = min(len(GQ)/GOMAXPROCS + 1, len(GQ/2))`

至少从全局队列取 1 个 g，但每次不要从全局队列移动太多的 g 到 p 本地队列，给其他 p 留点。这是从全局队列到 P 本地队列的负载均衡。

假定我们场景中一共有 4 个 P（GOMAXPROCS 设置为 4，那么我们允许最多就能用 4 个 P 来供 M 使用）。所以 M2 只从能从全局队列取 1 个 G（即 G3）移动 P2 本地队列，然后完成从 G0 到 G3 的切换，运行 G3。

(8)场景 8

假设 G2 一直在 M1 上运行，经过 2 轮后，M2 已经把 G7、G4 从全局队列获取到了 P2 的本地队列并完成运行，全局队列和 P2 的本地队列都空了，如场景 8 图的左半部分。

**全局队列已经没有 G，那 m 就要执行 work stealing (偷取)：从其他有 G 的 P 哪里偷取一半 G 过来，放到自己的 P 本地队列。**P2 从 P1 的本地队列尾部取一半的 G，本例中一半则只有 1 个 G8，放到 P2 的本地队列并执行。

(9) 场景 9

G1 本地队列 G5、G6 已经被其他 M 偷走并运行完成，当前 M1 和 M2 分别在运行 G2 和 G8，M3 和 M4 没有 goroutine 可以运行，M3 和 M4 处于自旋状态，它们不断寻找 goroutine。

为什么要让 m3 和 m4 自旋，自旋本质是在运行，线程在运行却没有执行 G，就变成了浪费 CPU. 为什么不销毁现场，来节约 CPU 资源。因为创建和销毁 CPU 也会浪费时间，我们希望当有新 goroutine 创建时，立刻能有 M 运行它，如果销毁再新建就增加了时延，降低了效率。当然也考虑了过多的自旋线程是浪费 CPU，所以系统中最多有 GOMAXPROCS 个自旋的线程 (当前例子中的 GOMAXPROCS=4，所以一共 4 个 P)，多余的没事做线程会让他们休眠。

(10) 场景 10

假定当前除了 M3 和 M4 为自旋线程，还有 M5 和 M6 为空闲的线程 (没有得到 P 的绑定，注意我们这里最多就只能够存在 4 个 P，所以 P 的数量应该永远是 M>=P, 大部分都是 M 在抢占需要运行的 P)，G8 创建了 G9，G8 进行了阻塞的系统调用，M2 和 P2 立即解绑，P2 会执行以下判断：如果 P2 本地队列有 G、全局队列有 G 或有空闲的 M，P2 都会立马唤醒 1 个 M 和它绑定，否则 P2 则会加入到空闲 P 列表，等待 M 来获取可用的 p。本场景中，P2 本地队列有 G9，可以和其他空闲的线程 M5 绑定。

(11) 场景 11

G8 创建了 G9，假如 G8 进行了非阻塞系统调用。

M2 和 P2 会解绑，但 M2 会记住 P2，然后 G8 和 M2 进入系统调用状态。当 G8 和 M2 退出系统调用时，会尝试获取 P2，如果无法获取，则获取空闲的 P，如果依然没有，G8 会被记为可运行状态，并加入到全局队列，M2 因为没有 P 的绑定而变成休眠状态 (长时间休眠等待 GC 回收销毁)。

小结

总结，Go 调度器很轻量也很简单，足以撑起 goroutine 的调度工作，并且让 Go 具有了原生（强大）并发的能力。Go 调度本质是把大量的 goroutine 分配到少量线程上去执行，并利用多核并行，实现更强大的并发。

Go的channel 的小学习

Thu, 11 Jun 2020 14:31:00 +0800

channel

GO 语言的 channel 是一个比较神奇的东西，也可以说在 go 协程通信里面是不可或缺的一部分，现在就整理一下channel 相关的知识，下面的内容并非所有都是原创，只是简单的说一下可能比较重要的地方具体的用法我也不多说，网上的教程很多

源码如下，位置在 src/runtime/chan.go

type hchan struct {
	qcount   uint           // total data in the queue
	dataqsiz uint           // size of the circular queue
	buf      unsafe.Pointer // points to an array of dataqsiz elements
	elemsize uint16
	closed   uint32
	elemtype *_type // element type
	sendx    uint   // send index
	recvx    uint   // receive index
	recvq    waitq  // list of recv waiters
	sendq    waitq  // list of send waiters

	// lock protects all fields in hchan, as well as several
	// fields in sudogs blocked on this channel.
	//
	// Do not change another G's status while holding this lock
	// (in particular, do not ready a G), as this can deadlock
	// with stack shrinking.
	lock mutex
}

type waitq struct {
	first *sudog
	last  *sudog
}

qcount 是 chan 中已有元素的数量， dataqsiz 循环队列的节点数
buf 是一个循环队列，缓冲区
sendx 为写入数据的索引位，之后的数据写在环形队列的这个索引位置上；
recvx 读取数据的索引位下一次读取数据就从这个位置开始读取
elemtype chan 元素类型，一个chan 只可以有一种类型
recvq 读取的 goroutine ( 源码里成为G，我觉得大概是一个意思) 的阻塞队列; sendq 是写入 chan 的 goroutine 的阻塞队列
lock 互斥锁，不允许并发读写,仅允许一个goroutine 进行操作，也就是说串行的
elemsize 代表类型大小，方便在缓冲队列中定位元素的位置

向 channel 写数据

简单过程如下：

如果等待接收队列recvq不为空，说明缓冲区中没有数据或者没有缓冲区，此时直接从recvq取出G,并把数据写入，最后把该G唤醒，结束发送过程
如果缓冲区中有空余位置，将数据写入缓冲区，结束发送过程
如果缓冲区中没有空余位置，将待发送数据写入 G，将当前G加入 sendq，进入睡眠，等待被读 goroutine 唤醒

向 Channel 读数据

如果等待发送队列 sendq 不为空，且没有缓冲区，直接从 sendq 中取出G，把G中数据读出，最后把G唤醒，结束读取
如果等待发送队列 sendq 不为空，此时说明缓冲区已满，从缓冲区中首部读出数据，把发送队列第一个G的数据写入缓冲区尾部，把G唤醒，结束读取过程
如果等待发送队列 sendq 为空，但是缓冲区中有数据，则从缓冲区取出数据，结束读取过程
如果等待发送队列 sendq 为空，且缓冲区没数据，将当前 goroutine 加入 recvq，进入睡眠，等待被写 goroutine 唤醒

举个例子

拿餐厅的厨师，窗口，服务员为例子

厨师就是向 chan 写入的
窗口就是缓冲队列
服务员就是向 chan 读取的

写入数据：

厨师准备上菜，看看窗口外有没有服务员，如果有服务员，就叫醒服务员拿菜，然后把菜给他
没有服务员的话就看看窗口上菜有没有放满，如果没放满，就把菜放在窗口上，然后溜了
如果窗口满了或者没有窗口，那就在窗口旁边睡觉，等待服务员把我叫醒拿菜

读取数据：

先看看有没有睡觉的厨师，如果有，再看看窗口有没有菜，如果也有，那就从窗口拿走一个菜，然后叫醒厨师可以把菜放下了
如果窗口放不了菜（无缓存队列）直接叫醒厨师把他手上的菜拿过来
如果没有睡觉的厨师，窗口有菜拿的话直接从窗口拿菜，拿完之后就溜了溜了
如果没有睡觉的厨师窗口也没有菜，那就在窗口旁边睡觉等待厨师送菜过来

关闭 channel

关闭channel时会把recvq 中的G全部唤醒，本该写入G的数据位置为nil。把 sendq 中的G全部唤醒，但这些 G 会 panic。

除此之外，panic出现的常见场景还有： 1. 关闭值为nil的channel 2. 关闭已经被关闭的channel 3. 向已经关闭的channel写数据

Go和Redis中的Hash

Sat, 30 May 2020 21:43:24 +0800

之前看 Redis设计与实现 的时候看了一些字典的底层实现是基于hash表的，然后这几天看到Golang 的map 时也是基于hash表的，~~实际上大部分开发语言的map数据类型基本上都是基于hash表的~~ 所以就打算写一篇比较垃圾的博客~~集百家之长~~把这两个东西的底层实现放在一块讲了，加深下自己的映像。（由于水平不够，如果有错误还请一起探讨指出）

Hash

散列表（Hash table，也叫哈希表），是根据关键码值(Key value)而直接进行访问的数据结构。也就是说，它通过把关键码值映射到表中一个位置来访问记录，以加快查找的速度。这个映射函数叫做散列函数，存放记录的数组叫做散列表。

给定表M，存在函数f(key)，对任意给定的关键字值key，代入函数后若能得到包含该关键字的记录在表中的地址，则称表M为哈希(Hash）表，函数f(key)为哈希(Hash) 函数。

摘自百度百科

Redis 中的 Hash

结构图

图源 Redis 设计与实现

Hash 表

Redis 中的hash表由以下结构定义:

typedef struct dictht {
    dictEntry **table; //哈希桶数组
    unsigned long size; //哈希表的大小,就是 哈希桶数组长度
    unsigned long sizemask; //哈希表大小掩码，数值上为size-1，用于计算索引值
    unsigned long used; //哈希表已有的节点数量
}

table 为一个数组，每个数组里都存放着一个一组指向 dict.h/dictEntry 结构的指针，然后每一个 dicEntry 结构保存着一个键值对，这个结构也称为HashBucket ，哈希桶
used 表示这个 hash表中现在已有的键值对的数量

Hash 表节点（哈希桶）

dictEntry 结构定义:

typedef struct dictEntry {
    void *key; //键
    unoin{
        void *val; // 值
        unit64_t u64;
        int64_t s64;
    } v;
    struct dictEntry *next;
} dictEntry;

next 属性是指向另一个哈希表节点的指针，该指针可以将多个 hash 键值对连在一起，用来解决哈希冲突的问题。

字典

Redis 中的字典由dict.h/dict 结构表示，也就是我们 Redis 用到的数据结构的最外层了

typedef struct dict {
    dictType *type; //某类型的特定函数
    void *privdata; //私有数据
    dictht ht[2]; //这里包含了两个Hash 表
    int rehashidx; // rehash索引，用来表示当前rehash的状态
}

~~好累啊，下次再更新~~我回来了

ht属性为包含两个项的数组，数组中的每个项都是一个 dictht 的哈希表，一般情况下 redis 只会使用第一个hash表，第二个hash表时用来rehash的
hashidx用来记录rehash的状态
- 没有进行rehash的时候，值为-1
type 属性是一个指向dictType 类型的指针, 这个结构里面包含了一些用于操作特定类型键值对的函数，比如：
- 计算哈希值的函数（hashFunction）
- 复制键的函数
- 复制值的函数
- 对比键的函数
- 销毁键的函数
- 销毁值的函数

哈希算法

当添加新键值对进redis 时，redis 首先要根据键计算出哈希值和索引值，再根据索引值将包含键值对的hash表节点（hash桶）放到哈希表数组（哈希桶数组）的指定索引上面

计算路径：

`1`	`hash = dict -> type -> hashFunction`

`1`	`index = hash & dict -> ht[x].sizemask`

通过每一种 type 的hash函数计算出hash值，然后和哈希表中的掩码进行按位与运算得到index值
使用的算法为 MurmurHash2

哈希冲突

redis 使用链地址法 ( separate chaining ) 来解决哈希冲突，每个哈希桶都有一个next指针来构成单链表
为了考虑速度，redis 总是将新节点添加到链表头的位置(因为没有指向链表尾的指针，所以如果放在链表尾需要遍历整个链表)

Rehash

为什么要rehash？

随着操作的不断的执行，哈希表保存的键值对会相应增加或者减少,如果一个索引上链接这N多键值对而其他索引上有没有键值对~~那和遍历一个链表有什么区别~~

所以为了让哈希表的负载因子维持在一个合理的范围内，就需要对hash表进行相应的扩容和收缩

rehash是指重新计算键的hash值和index值

负载因子=ht[0].used / ht[0].size

rehash 步骤

- redis 没有执行BGSAVE 或者 BGREWRITEAOF 命令时，负载因子大于 1 开始扩展
- 执行BGSAVE 或者 BGEWRITEAOF 时，负载因子大于 5 开始拓展
- 负载因子小于 0.1 时开始收缩
创建适当空间用于 ht[1] ，空间大小取决于是要扩展收缩以及现在ht[0] 中存在的键值对数量 (dict->ht[0]->used)
- 拓展: 创建新 hashtable 的大小为第一个大于等于两倍的现在已存在的键值对数量的2的n次方
- ~~说起来有点绕，我自己都不知道在说什么~~
- 假如现在存了7个键值对，那么就是要扩展到大于2*7=14 个的 hashtable
- 2^0 =1 不够，2^1不够，2^2不够，2^3不够，2^4 够了够了谢谢妈妈妈妈真好！就它了！所以新创建的表大小为16~
- 收缩：新hashtable的大小为第一个大于等于现在已存在的键值对数量的2的n次方
- 一样举例，比如现在hashtable 大小为8，但是只存了三个数据，就缩小到4
将 ht[0] 上的键值对 rehash 到 ht[1] 上，具体怎么rehash 请查看后面的 渐进式rehash
迁移完成后，释放 ht[0] , 将 ht[1] 设为 ht[0] ，同时创建新的 ht[1] 准备下一次 rehash

渐进式 rehash

顾名思义，就是慢慢慢慢 rehash，并不是一次性做完

rehashidx 设置为 0 ,表示 rehash 工作正式开始
当对某个键做出增删查改的操作时，redis 都会将该键索引上的键值对 rehash 到 ht[1],同时rehashidx 加1
当 rehash 全部完成后，rehashidx 重新设置为 -1

在rehash 过程中，查找会先在 ht[0] 上查找，如果没有则到 ht[1] 上查找；而添加则只会在 ht[1] 上添加。保证 ht[0] 只增不减

Go 中的 Hash

结构图

hash 表

Go 中的 hash 表在 /src/runtime/map.go 中定义

type hmap struct {
	// Note: the format of the hmap is also encoded in cmd/compile/internal/gc/reflect.go.
	// Make sure this stays in sync with the compiler's definition.
	count     int // # live cells == size of map.  Must be first (used by len() builtin)
	flags     uint8
	B         uint8  // log_2 of # of buckets (can hold up to loadFactor * 2^B items)
	noverflow uint16 // approximate number of overflow buckets; see incrnoverflow for details
	hash0     uint32 // hash seed

	buckets    unsafe.Pointer // array of 2^B Buckets. may be nil if count==0.
	oldbuckets unsafe.Pointer // previous bucket array of half the size, non-nil only when growing
	nevacuate  uintptr        // progress counter for evacuation (buckets less than this have been evacuated)

	extra *mapextra // optional fields
}

Go 的源码注释一直是很完善的，想必看注释也看得八九不离十了

count 属性就是 len(map) 调用得到的值，map 中存在的键值对的数量
flag 属性暂时还不清楚
B 属性用来标记hash 桶的数量，是2的指数，也就是 B 为3 的时候 hash bucket 的数量为8
noverflow 属性是 overflow 的 bucket 近似数
hash0 属性是哈的种子，它能为哈希函数的结果引入随机性，这个值在创建哈希表时确定，并在调用哈希函数时作为参数传入
oldbuckets 是哈希在扩容时用于保存之前 buckets 的字段，它的大小是当前 buckets 的一半

hash 桶

// A bucket for a Go map.
type bmap struct {
	// tophash generally contains the top byte of the hash value
	// for each key in this bucket. If tophash[0] < minTopHash,
	// tophash[0] is a bucket evacuation state instead.
	tophash [bucketCnt]uint8
	// Followed by bucketCnt keys and then bucketCnt elems.
	// NOTE: packing all the keys together and then all the elems together makes the
	// code a bit more complicated than alternating key/elem/key/elem/... but it allows
	// us to eliminate padding which would be needed for, e.g., map[int64]int8.
	// Followed by an overflow  pointer.
}

看似这个结构里只有一个属性，其实在编译期间会对该结构进行重建，重建得到的 struct 如下

type bmap struct {
    topbits  [8]uint8
    keys     [8]keytype
    values   [8]valuetype
    pad      uintptr
    overflow uintptr
}

上面猛男色对应的就是 topbits / tophash
青色对应的是 keys
黄色对应的是 values
基佬色：每个桶只能装8个键值对，当溢出时，就需要链接一个溢出桶，你懂的

Key 的寻找过程

当一个 key 甩过来让你找，当然是用 hash 函数计算 hash 值辣，那么就能得到一个 64 位的 hash 值（32 位CPU得到的是32位，是时候退出群聊了）
假设 hmap.B 为 5，那么一共就有 2^5 也就是 32 个 hash 桶
经过计算后得到下面的hash值

`1`	`10010111 000011110110110010001111001010100010010110010101010 01010`

我们对后 B 位 ( 这里是5 )进行对 B 取余操作 ( 实现时是用按位操作，取余开销太大，这里说取余是为了方便理解 )，得到值为 10，所以要找的值在10 号桶里
进入 10 号桶，再取 hash 值的高 8 位，就是前面 bmap 中定义的 tophash了，然后对比，桶里面 tophash 在哪个位置那么键和值就在哪个位置
如果 8 个tophash 都没有的话，进入溢出桶继续寻找，如果走遍溢出桶都没有，那就是真没有
word is cheap show me the picture

rehash

同样这里有一个装载因子的概念，Go源码给的定义是这样的：

`1`	`loadFactor := count / (2^B)`

扩容条件：
- 装载因子超过阈值，源码里定义的阈值是 6.5
- overflow 的 bucket 数量过多：当 B 小于 15，也就是 bucket 总数 2^B 小于 2^15 时，如果 overflow 的 bucket 数量超过 2^B；当 B >= 15，也就是 bucket 总数 2^B 大于等于 2^15，如果 overflow 的 bucket 数量超过 2^15

增量扩容

当满足第一个扩容条件时触发增量扩容

创建一组新桶，桶的数量是旧桶数量的两倍
将原来的桶设置到 oldbuckets 上，再将新桶设置到 buckets 上，同理 overflow 也设置到 oldoverflow 上
渐进式 hash：go 只在插入、更新、删除操作上会发生搬迁工作，而且每次最多搬迁两个 bucket
搬迁时怎么确定落入哪个新桶？
由之前的知识我们知道落入哪个桶时由 hash 值的后 B 位决定的
比如扩容前B是 ⑤，所以由后 5 位决定，现在扩容成了 ⑥ ，所以就在加一位，由 6 位决定
这样能保证旧桶的能够落到两个新桶内
当搬迁完毕时 oldbuckets 和 oldoverflow 设为 nil

所以当每次进行插入，更新，删除的操作时，会判断 oldbuckets 状态来确定是否在扩容中

等量扩容

当满足第二个条件时进行等量扩容

可能是由于大量插入再大量删除键值对造成的，会导致键值对在桶（以及 overflow ）中过于分散，就像一座城由很多房子，很多是空的，只有几栋房子有人家，我们就很难找到他们，那只要我们将他们集中在某个小区中，我们就能够快速的找到他们 ~

当扩容完毕后，所有的键值对都集中到了相对集中的 bucket 上，overflow 上的键值对就拜拜辣

总结

相同点

hashtable -> hashbucket -> key/value
都使用拉链法来解决 hash 冲突，但是也有不同的是 Redis 是链接键值对，Go 链接溢出桶
rehash 时都采用渐进式 rehash

不同点

Redis 一个桶只能存一个键值对； Go 一个桶存可以存 8 个键值对
确定位置时 Redis 使用的是 hash 值和表掩码为与得到索引值确定位置； Go 用 hash 值得高8位和低 B 位确定位置

参考

《Redis 设计与实现》

cch123/golang-notes

Go 设计与实现

2020 Go 开发者学习路线

Mon, 18 May 2020 23:00:26 +0800

Go 开发者路线图

由于Github 在正常人模式访问速度捉急，所以搬运到这里来，~~这里好找~~

原地址: https://github.com/Alikhll/golang-developer-roadmap

在 2020年成为一名 Go 开发者的路线图：

在下边有一个路线图，如果你想要成为一名Go语言的开发者的话，你可以沿着这张图里面的路径去学习，里面记录了一些你可能也想学习的库。当你问到：”我想成为一名Go语言开发者，接下来我要学些什么？“，我做的这个路线图就是一个很好的建议。

免责声明

本路线图的目的是让你看到学习Go语言的一个全景图。在你对接下来要学习什么感到困惑的时候，这个路线图会给你一些指导，而不是鼓励你去选择当下流行的东西。你需要逐渐了解为什么一个工具可能会比另一个工具更适合某些场景。但请记住，流行的东西并不意味着一定适合你的工作。

给我一个 Star！ :star:

如果您喜欢或者正在使用这个项目来学习或者开始你的计划，请给我一个 Star，谢谢！

路线图

资源

先决条件
- Go
- SQL
通用开发技能
- 学习GIT，在GitHub上建立一些仓库，与其它人分享你的代码
- 了解 HTTP(S) 协议，request 方法（GET, POST, PUT, PATCH, DELETE, OPTIONS）
- 不要害怕使用Google，Google 搜索的力量
- 看一些和数据结构以及算法有关的书籍
- 学习关于认证的基础实现
- 面向对象原则等等
命令行工具
1. cobra
2. urfave/cli
网页框架 + 路由
1. Echo
2. Beego
3. Gin
4. Revel
5. Chi
数据库
1. 关系型
  - SQL Server
  - PostgreSQL
  - MariaDB
  - MySQL
  - CockroachDB
2. 云数据库
  - CosmosDB
  - DynamoDB
3. 搜索引擎
4. NoSQL
  - MongoDB
  - Redis
  - Apache Cassandra
  - RavenDB
  - CouchDB
对象关系映射框架
1. Gorm
2. Xorm
高速缓存
1. GCache
2. 分布式缓存
  - Go-Redis
  - GoMemcached
日志
1. 日志框架
  - Zap
  - ZeroLog
  - Logrus
2. 日志管理系统
  - Sentry.io
  - Loggly.com
3. 分布式追踪
  - Jaeger
实时通信
1. Socket.IO
API 客户端
1. REST
2. GraphQL
  - gqlgen
  - graphql-go
最好知道
- Validator
- Glow
- GJson
- Authboss
- Go-Underscore
测试
1. 单元、行为和集成测试
  1. GoMock
  2. Testify
  3. GinkGo
  4. GoMega
  5. GoCheck
  6. GoDog
  7. GoConvey
2. 端对端测试
  - Selenium
  - Endly
任务调度
- Gron
- JobRunner
微服务
1. 消息代理
2. 构建事件驱动型服务
  - Watermill
  - Message-Bus
3. 框架
  - GoKit
  - Micro
  - rpcx
4. RPC
Go-模式

最后

如果您认为该路线图有待改进，请务必提交PR或者发Issue。当然，我也会持续地改进它，所以你可以给这个仓库点个 Star 以便于再次访问。

想法来源于 : ASP.NET Core Developer Roadmap

贡献

这个路线图是用 Draw.io 做的。项目文件为该仓库下的 golang-developer-roadmap-zh-CN.xml 文件。您如果想要修改它，您可以进入 Draw.io 点击打开已有图表并且选择这个 xml 文件。它会为您打开这个路线图。改进它，并且上传，以及更新该 ReadMe 中的对应图片，然后提交 PR（以 400% 的缩放导出 PNG 以及使用 Compressor.io 来压缩它）。

用 PR 提交改进
在 Issue 中交流想法
传播这个图表