机床系统解锁

机床系统解锁map 的 key、value 是存在 buckets 数组里的,每个 bucket 又可以容纳 8 个 key 和 8 个 value。当要插入一个新的 key - value 时,会对 key 进行 hash 运算得到一个 hash 值,然后根据 hash 值 的低几位(取几位取决于桶的数量,比如一开始桶的数量是 5,则取低 5 位)来决定命中哪个 bucket。

在命中某个 bucket 后,又会根据 hash 值的高 8 位来决定是 8 个 key 里的哪个位置。如果不巧,发生了 hash 冲突,即该位置上已经有其他 key 存在了,则会去其他空位置寻找插入。如果全都满了,则使用 overflow 指针指向一个新的 bucket,重复刚刚的寻找步骤。

从上面的流程可以看出,在判断 hash 冲突,即该位置是否已有其他 key 时,肯定是要进行比较的,所以 key 必须得是可比较类型的。像 slice、map、function 就不能作为 key。

10. mutex 的正常模式、饥饿模式、自旋?

正常模式

当 mutex 调用 Unlock() 方法释放锁资源时,如果发现有正在阻塞并等待唤起的 Goroutine 队列时,则会将队头的 Goroutine 唤起。队头的 goroutine 被唤起后,会采用 CAS 这种乐观锁的方式去修改占有标识位,如果修改成功,则表示占有锁资源成功了,当前占有成功的 goroutine 就可以继续往下执行了。

饥饿模式

由于上面的 Goroutine 唤起后并不是直接的占用资源,而是使用 CAS 方法去尝试性占有锁资源。如果此时有新来的 Goroutine,那么它也会调用 CAS 方法去尝试性的占有资源。对于 Go 的并发调度机制来讲,会比较偏向于 CPU 占有时间较短的 Goroutine 先运行,即新来的 Goroutine 比较容易占有资源,而队头的 Goroutine 一直占用不到,导致饿死。

针对这种情况,Go 采用了饥饿模式。即通过判断队头 Goroutine 在超过一定时间后还是得不到资源时,会在 Unlock 释放锁资源时,直接将锁资源交给队头 Goroutine,并且将当前状态改为饥饿模式。

后面如果有新来的 Goroutine 发现是饥饿模式时, 则会直接添加到等待队列的队尾。

自旋

如果 Goroutine 占用锁资源的时间比较短,那么每次释放资源后,都调用信号量来唤起正在阻塞等候的 goroutine,将会很浪费资源。

因此在符合一定条件后,mutex 会让等候的 Goroutine 去空转 CPU,在空转完后再次调用 CAS 方法去尝试性的占有锁资源,直到不满足自旋条件,则*终才加入到等待队列里。

11. Go 的逃逸行为是指?

在传统的编程语言里,会根据*员指定的方式来决定变量内存分配是在栈还是堆上,比如声明的变量是值类型,则会分配到栈上,或者 new 一个对象则会分配到堆上。

在 Go 里变量的内存分配方式则是由编译器来决定的。如果变量在作用域(比如函数范围)之外,还会被引用的话,那么称之为发生了逃逸行为,此时将会把对象放到堆上,即使声明为值类型;如果没有发生逃逸行为的话,则会被分配到栈上,即使 new 了一个对象。

12 context 使用场景及注意事项

Go 里的 context 有 cancelCtx 、timerCtx、valueCtx。它们分别是用来通知取消、通知超时、存储 key - value 值。context 的 注意事项如下:

• context 的 Done() 方法往往需要配合 select {} 使用,以监听退出。

• 尽量通过函数参数来暴露 context,不要在自定义结构体里包含它。

• WithValue 类型的 context 应该尽量存储一些全局的 data,而不要存储一些可有可无的局部 data。

• context 是并发安全的。

• 一旦 context 执行取消动作,所有派生的 context 都会触发取消。

13. context 是如何一层一层通知子 context

当 ctx, cancel := context.WithCancel(父Context)时,会将当前的 ctx 挂到父 context 下,然后开个 goroutine 协程去监控父 context 的 channel 事件,一旦有 channel 通知,则自身也会触发自己的 channel 去通知它的子 context, 关键代码如下

go func() {            select {            case <-parent.Done():
               child.cancel(false, parent.Err())            case <-child.Done():
           }
   }()

14. waitgroup 原理

waitgroup 内部维护了一个计数器,当调用 wg.Add(1) 方法时,就会增加对应的数量;当调用 wg.Done() 时,计数器就会减一。直到计数器的数量减到 0 时,就会调用
runtime_Semrelease 唤起之前因为 wg.Wait() 而阻塞住的 goroutine。

15. sync.Once 原理

内部维护了一个标识位,当它 == 0 时表示还没执行过函数,此时会加锁修改标识位,然后执行对应函数。后续再执行时发现标识位 != 0,则不会再执行后续动作了。关键代码如下:

type Once struct {
   done uint32
   m    Mutex
}func (o *Once) Do(f func()) {    // 原子加载标识值,判断是否已被执行过
   if atomic.LoadUint32(&o.done) == 0 {
       o.doSlow(f)
   }
}func (o *Once) doSlow(f func()) { // 还没执行过函数
   o.m.Lock()    defer o.m.Unlock()    if o.done == 0 { // 再次判断下是否已被执行过函数
       defer atomic.StoreUint32(&o.done, 1) // 原子操作:修改标识值
       f() // 执行函数
   }
}