Go基础之锁的初识

当我们的程序就一个线程的时候是不需要用到锁的，但是通常我们实际的代码不会是单个线程的，所有这个时候就需要用到锁了，那么关于锁的使用场景主要涉及到哪些呢？

• 当我们多个线程在读相同的数据的时候则是需要加锁的
• 当我们的程序既有读又有写的时候更是需要加锁的
• 当我们有多个线程在写的时候同样也是需要加锁

互斥锁

互斥锁：同一个时刻只有一个线程能够拿到锁

我们先通过一个例子来演示，如果当多个线程同时更改一个变量，结果会是怎么样
不加锁版本

package main

import (
    "sync"
    "fmt"
)

var (
    //lock sync.Mutex
    count int
    w sync.WaitGroup  //用于等待子线程执行完之后退出
)

func main() {
    w.Add(1) // 在调用线程前执行w.add
    go func(){
        for i:=0;i<100000;i++{
            count++
        }
        w.Done()  //执行完 执行w.Done
    }()
    for i :=0;i<100000;i++{
        count++
    }
    w.Wait() // 最后执行w.wait等待所有的线程执行完毕
    fmt.Println(count)

}

当我们运行多次就可以发现，最后的结果基本不可能是我们先看到的：200000
我们修改代码代码需要加锁保护的地方加上锁，并且这里加的是互斥锁，修改后的代码为：

package main

import (
    "sync"
    "fmt"
)

var (
    lock sync.Mutex
    count int
    w sync.WaitGroup  //用于等待子线程执行完之后退出
)

func main() {
    w.Add(1) // 在调用线程前执行w.add
    go func(){
        for i:=0;i<100000;i++{
            lock.Lock()
            count++
            lock.Unlock()
        }
        w.Done()  //执行完 执行w.Done
    }()
    for i :=0;i<100000;i++{
        lock.Lock()
        count++
        lock.Unlock()
    }
    w.Wait() // 最后执行w.wait等待所有的线程执行完毕
    fmt.Println(count)

}

这次当我们多次运行的时候，就能保证我们每次都能看到我们想要的值：200000
接下来看读写锁

读写锁

读写锁主要用到读多写少的场景
读写锁分为：读锁和写锁

如果自己设置了一个写锁，那么其他读的线程以及写的线程都拿不到锁，这个时候和互斥锁的功能相同
如果自己设置了一个读锁，那么其他写的线程是拿不到锁的，但是其他读的线程都是可以拿到这个锁

我们把上面的例子代码进行更改：

package main

import (
    "sync"
    "fmt"
)    

var (
    rwlock sync.RWMutex
    w sync.WaitGroup
    count int
)


func main() {
    w.Add(1)
    go func(){
        for i:=0;i<1000000;i++{
            rwlock.Lock() // 这里定义了一个写锁
            count++
            rwlock.Unlock()
        }
        w.Done()
    }()

    for i:=0;i<1000000;i++{
        rwlock.Lock() // 这里定义了一个写锁
        count++
        rwlock.Unlock()
    }
    w.Wait()
    fmt.Println(count)
}

通过设置写锁，我们同样可以实现数据的一致性
下面是一个读锁的使用例子：

package main

import (
    "sync"
    "fmt"
)

var (
    rwlock sync.RWMutex
    w sync.WaitGroup
    count int
)


func main() {
    w.Add(1)
    go func(){
        for i:=0;i<1000000;i++{
            rwlock.Lock() // 这里定义了一个写锁
            count++
            rwlock.Unlock()
        }
        w.Done()
    }()

    for i:=0;i<16;i++{
        w.Add(1)
        go func(){
            rwlock.RLock() //这里定义了一个读锁
            fmt.Println(count)
            rwlock.RUnlock() //释放读锁
            w.Done()
        }()
    }
    w.Wait()
    fmt.Println(count)
}

Go中的原子操作

原子操作，我们则不需加锁，也能保证数据的一致性
并且如果只是计算，那么原子操作则是最快的

实例代码：

package main

import (
    "sync"
    //"time"
    "sync/atomic"
    "fmt"
)

var (
    w sync.WaitGroup
    count int32
)


func main() {
    w.Add(1)
    //start := time.Now().UnixNano()
    go func() {
        for i:=0;i<1000000;i++{
            atomic.AddInt32(&count,1)
        }
        w.Done()
    }()

    for i:=0;i<1000000;i++{
        atomic.AddInt32(&count,1)
    }
    w.Wait()
    //end := time.Now().UnixNano()
    //fmt.Println((end- start)/1000/1000)
    fmt.Println(count)
}

关于互斥锁的补充

互斥锁需要注意的问题：

1、不要重复锁定互斥锁

2、不要忘记解锁互斥锁， 必要时使用defer语句

3、不要对尚未锁定或者已解锁的互斥锁解锁

4、不要对在多个函数之间直接传递互斥锁

对已经锁定的互斥锁进行锁定，会立即阻塞当前的goroutine 这个goroutine所执行的流程会一直停滞在该调用互斥锁的Lock方法的那行代码

所谓死锁： 当前程序中的主goroutine以及我们启用的那些goroutine 都已经被阻塞，这些goroutine可以被称为用户级的goroutine 这就相当于整个程序已经停滞不前了，并且这个时候go程序会抛出如下的panic:

fatal error: all goroutines are asleep - deadlock!

并且go语言运行时系统抛出自行抛出的panic都属于致命性错误，都是无法被恢复的，调用recover函数对他们起不到任何作用

Go语言中的互斥锁是开箱即用的，也就是我们声明一个sync.Mutex 类型的变量，就可以直接使用它了，需要注意：该类型是一个结构体类型，属于值类型的一种，把它传给一个函数

将它从函数中返回，把它赋值给其他变量，让它进入某个通道都会导致他的副本的产生。并且原值和副本以及多个副本之间是完全独立的，他们都是不同的互斥锁

所以不应该将锁通过函数的参数进行传递

关于读写锁的补充

1、在写锁已被锁定的情况下再次试图锁定写锁，会阻塞当前的goroutine

2、在写锁已被锁定的情况下再次试图锁定读锁，也会阻塞当前的goroutine

3、在读锁已被锁定的情况下试图锁定写锁，同样会阻塞当前的goroutine

4、在读锁已被锁定的情况下再试图锁定读锁，并不会阻塞当前的goroutine

对于某个受到读写锁保护的共享资源，多个写操作不能同时进行，写操作和读操作也不能同时进行，但多个读操作却可以同时进行

对写锁进行解锁，会唤醒“所有因试图锁定读锁，而被阻塞的goroutine”, 并且这个通常会使他们都成功完成对读锁的锁定

对读锁进行解锁，只会在没有其他读锁锁定的前提下，唤醒“因试图锁定写锁，而被阻塞的goroutine” 并且只会有一个被唤醒的goroutine能够成功完成对写锁的锁定，其他的goroutine

还要在原处继续等待，至于哪一个goroutine，那么就要看谁等待的事件最长

解锁读写锁中未被锁定的写锁， 会立即引发panic ，对其中的读锁也是如此，并且同样是不可恢复的