关于go:Golang-基础之并发知识-三

大家好，明天将梳理出的 Go 语言并发常识内容，分享给大家。请多多指教，谢谢。

本次《Go 语言并发常识》内容共分为三个章节，本文为第三章节。

• Golang 根底之并发常识 (一)
• Golang 根底之并发常识 (二)
• Golang 根底之并发常识 (三)

本章节内容

• 根本同步原语
• 常见的锁类型
• 扩大内容

根本同步原语

Go 语言在 sync 包中提供了用于同步的一些根本原语，包含常见的互斥锁 Mutex 与读写互斥锁 RWMutex 以及 Once、WaitGroup。这些根本原语的次要作用是提供较为根底的同步性能，本次仅对 Mutex开展介绍，残余其余原语将在后续并发章节中应用。

Mutex 是什么

Mutex 是 golang 规范库的 互斥锁，次要用来解决并发场景下共享资源的拜访抵触问题。

Mutex 互斥锁在 sync 包中，它由两个字段 state 和 sema 组成，state 示意以后互斥锁的状态，而 sema 真正用于管制锁状态的信号量，这两个加起来只占 8 个字节空间的构造体就示意了 Go 语言中的互斥锁。

type Mutex struct {
    state int32
    sema  uint32
}

互斥锁的作用，就是同步访问共享资源。互斥锁这个名字来自互斥 (mutual exclusion) 的概念，互斥锁用于在代码上创立一个临界区，保障同一个工夫只有一个 goroutine 能够执行这个临界区代码。

package main

import (
    "fmt"
    "runtime"
    "sync"
)

var (
    counter int
    wg sync.WaitGroup
    mutex sync.Mutex // 定义代码临界区
)

func main() {wg.Add(2)
    go incCounter()
    go incCounter()
    wg.Wait()
    fmt.Println("counter:", counter)
}

func incCounter() {defer wg.Done()
    for count := 0; count < 2; count++ {mutex.Lock() // 临界区, 同一时刻只容许一个 goroutine 进入
        {
            value := counter
            runtime.Gosched() // goroutine 退出, 返回队列
            value++
            counter = value
        }
        mutex.Unlock() // 开释锁}
}

Lock() 和 Unlock() 函数调用定义的临界区里被爱护起来。应用大括号只是为了让临界区看起来更清晰，并不是必须的。同一时刻只有一个 goroutine 能够进入临界区，直到调用 Unlock() 函数之后，其余 goroutine 能力进入临界区。

Mutex 几种状态

• mutexLocked — 示意互斥锁的锁定状态；
• mutexWoken — 示意从失常模式被从唤醒；
• mutexStarving — 以后的互斥锁进入饥饿状态；
• waitersCount — 以后互斥锁上期待的 Goroutine 个数；

失常模式和饥饿模式

sync.Mutex 有两种模式 — 失常模式和饥饿模式。

在失常模式中，锁的期待者会依照先进先出的程序获取锁。然而刚被唤起的 Goroutine 与新创建的 Goroutine 竞争时，大概率会获取不到锁，为了缩小这种状况的呈现，一旦 Goroutine 超过 1ms 没有获取到锁，它就会将以后互斥锁切换饥饿模式，避免局部 Goroutine 被 “ 饿死 ”。

饥饿模式是在 Go 语言在 1.9 中通过提交 sync: make Mutex more fair 引入的优化，引入的目标是保障互斥锁的公平性。

在饥饿模式中，互斥锁会间接交给期待队列最后面的 Goroutine。新的 Goroutine 在该状态下不能获取锁、也不会进入自旋状态，它们只会在队列的开端期待。如果一个 Goroutine 取得了互斥锁并且它在队列的开端或者它期待的工夫少于 1ms，那么以后的互斥锁就会切换回失常模式。

常见锁类型

死锁、活锁与饥饿

对于这三种锁模式，曾经在 [Golang 根底之并发常识 (一)]() 文章中进行了简略阐明，上文中针对饥饿模式进行一次补充。

死锁，作为最常见的锁，这里在进行一次补充。

死锁能够了解为实现一项工作的资源被两个（或多个）不同的协程别离占用了，导致它们全都处于期待状态不能实现上来。在这种状况下, 如果没有内部干涉, 程序将永远不会复原。

// 死锁案例
package main

import (
    "fmt"
    "sync"
    "time"
)
type value struct {
    mu sync.Mutex
    value int
}

var wg sync.WaitGroup

func main() {printSum := func(v1, v2 *value) {defer wg.Done()
        v1.mu.Lock() // 加锁
        defer v1.mu.Unlock() // 开释锁

        time.Sleep(1 * time.Second)
        v2.mu.Lock()
        defer v2.mu.Unlock()
        fmt.Printf("sum=%v\n", v1.value+v2.value)
    }

    var a, b value
    wg.Add(2)
    go printSum(&a, &b) // 协程 1
    go printSum(&b, &a) // 协程 2
    wg.Wait()}

输入

fatal error: all goroutines are asleep - deadlock!

死锁的三个动作

1. 试图拜访带锁的局部
2. 试图调用 defer 关键字开释锁
3. 增加休眠工夫 以造成死锁

本质上, 咱们创立了两个不能一起运行的齿轮: 咱们的第一个打印总和调用 a 锁定, 而后尝试锁定 b, 但与此同时, 咱们打印总和的第二个调用锁定了 b 并尝试锁定 a。两个 goroutine 都有限地期待着彼此。

自旋锁

介绍

自旋锁是指当一个线程在获取锁的时候，如果锁曾经被其余线程获取，那么该线程将循环期待，而后一直地判断是否可能被胜利获取，直到获取到锁才会退出循环。

获取锁的线程始终处于沉闷状态，然而并没有执行任何无效的工作，应用这种锁会造成 busy-waiting。

它是为实现爱护共享资源而提出的一种锁机制。其实，自旋锁与互斥锁比拟相似，它们都是为了解决某项资源的互斥应用。无论是互斥锁，还是自旋锁，在任何时刻，最多只能由一个保持者，也就说，在任何时刻最多只能有一个执行单元取得锁。然而两者在调度机制上略有不同。对于互斥锁，如果资源曾经被占用，资源申请者只能进入睡眠状态。然而自旋锁不会引起调用者睡眠，如果自旋锁曾经被别的执行单元放弃，调用者就始终循环在那里看是否该自旋锁的保持者曾经开释了锁，“自旋”一词就是因而而得名。

自旋锁与互斥锁

• 自旋锁与互斥锁都是为了实现爱护资源共享的机制。
• 无论是自旋锁还是互斥锁，在任意时刻，都最多只能有一个保持者。
• 获取互斥锁的线程，如果锁曾经被占用，则该线程将进入睡眠状态；获取自旋锁的线程则不会睡眠，而是始终循环期待锁开释。

总结

• 自旋锁：线程获取锁的时候，如果锁被其余线程持有，则以后线程将循环期待，直到获取到锁。
• 自旋锁期待期间，线程的状态不会扭转，线程始终是用户态并且是流动的(active)。
• 自旋锁如果持有锁的工夫太长，则会导致其它期待获取锁的线程耗尽 CPU。
• 自旋锁自身无奈保障公平性，同时也无奈保障可重入性。
• 基于自旋锁，能够实现具备公平性和可重入性质的锁。

读写锁

读写锁即针对读写操作的互斥锁。它与一般的互斥锁最大的不同，就是能够别离针对读操作和写操作进行锁定和解锁操作。读写锁遵循的访问控制规定有所不同。读写锁管制下的多个写操作之间都是互斥的，并且写操作与读操作之间也都是互斥的。

然而，多个读操作之间却不存在互斥关系。在这样的互斥策略之下，读写锁能够在大大降低因应用锁造成的性能损耗的状况下，实现对共享资源的访问控制。

Go 语言中的读写锁由构造体类型 sync.RWMutex 示意。与互斥锁一样，sync.RWMutex 类型的零值就曾经是可用的读写锁实例了。

// 类型办法集
func (*RWMutex) Lock()
func (*RWMutex) Unlock()
func (*RWMutex) RLock()
func (*RWMutex) RUnlock()

扩大内容

不偏心的锁

不偏心的锁可被看成是饥饿的一种不太重大的表现形式，当某些线程争抢同一把锁时，其中一部分线程在绝大多数工夫都可获取到锁，另一部分线程则遭逢不偏心看待。这在带有共享高速缓存或者 NUMA 内存 的机器中可能呈现，如果 CPU 0 开释了一把其余 CPU 都 想获取的锁，因为 CPU 0 与 CPU 1 共享外部连贯，所以 CPU 1 相较于 CPU 2 到 7 更容易抢到锁。

反之亦然，如果一段时间后 CPU 0 又开始争抢该锁，那么 CPU 1 开释锁时 CPU 0 也更容易获取锁，导致锁绕过了 CPU 2 到 7，只在 CPU 0 和 1 之间换手。

低效率的锁

锁是由原子操作和内存屏障实现，并且经常带来高速缓存未命中。这些指令代价都比拟低廉，粗略地说开销比简略指令高两个数量级。这可能是锁的一个重大问题，如果用锁来爱护一条指令，你很可能在以百倍的速度带来开销。对于雷同的代码，即便假如扩展性十分完满，也须要 100 个 CPU 能力跟上一个执行不加锁版本的 CPU。

不过一旦持有了锁，持有者能够不受烦扰地拜访被锁爱护的代码。获取锁可能代价昂扬，然而一旦持有，特地是对较大的临界区来说，CPU 的高速缓存反而是高效的性能加速器。

技术文章继续更新，请大家多多关注呀~~

搜寻微信公众号，关注我【帽儿山的枪手】

参考资料

《Go 语言设计与实现》书籍
《Concurrency in Go》书籍
《Go 并发编程实战》书籍
《Go 语言实战》书籍
晁岳攀老师 (鸟窝) 的《Go 并发编程实战课》
《深刻了解并行编程》书籍