go goroutine

segmentfault Go 语言基础——协程(goroutine)&共享内存线程安全
github 并发理念

go 中协成一些方法

- sync.WaitGroup()
- channel  
- channel  select 

一些术语

串行

即按照指定的顺序一个个执行，是最古老的执行方式

并发

采用调度算法，来回切换执行，造成宏观上的一起执行（发现后切换运行）

并行

多核实现， 真正的一起执行。齐头并进

程序执行的状态

操作系统会分为两大区域，一个是内核区，一个是用户区

• 内核区

大量的系统底层函数，比如 open()，write()， 上层语言基于这些函数接口开发自己的库函数 （c 的 fopen()，fwrite()），方便开发人员使用。

• 用户区
  用户自己的函数区域，不是调用内核函数的状态

程序执行的时候，先执行用户自己写的函数，这个状态为用户态，当调用内核函数的时候，程序就进入了 内核态。

之所以这样，就是因为内核区域太重要了，所有的上层语言，都是基于这些内核函数开发的，所以内核内存只有内核函数才能访问（内存隔离）

线程 进程，协程的区别

线程，协程 内存共享，进程内存隔离
线程，协程 有资源竞争，进程没有
线程需要调度分配，不听切换，争抢模式，协程是程序自己调度切换或者遇到 I/O ，协调模式，不需要再消耗调度的资源了。

go 语言本身就实现了 协程，通过管道进行通信（因为管道底层是枷锁的，安全，当然你也可以直接用变量，需要考虑资源竞争的关系）

go 语言中的 进程，协成操作

• 进程

一个cpu 内核，同一时刻只能运行一个进程，但是CPU可以在多个进程间进行来回切换，我们称之为上下文切换。 context 在 go 中用处非常广泛。

操作系统会按照调度算法为每个进程分配一定的CPU运行时间，称之为时间轮片，每个进程在运行时都会认为自己独占了CPU，如图所示

时间轮片五个状态

父进程无法预测子进程什么时候结束，只有进程完成工作后，父进程才会调用子进程的终止态

进程回收
一个进程结束，能回收自己的用户空间的内存，但是不能回收内核区的资源， 内核区的资源必须父进程调用 wait 函数回收。

• 孤儿进程：父结束，子进程还在运行。这时子进程会被 init 进程 管理
• 僵尸进程
  子进程结束，但未被父进程回收。
  （可以杀死父进程，然后子进程就可以被 init 回收）

进程通信
文件、管道、信号、共享内存、消息队列、套接字
go 支持的ipc 方式：

管道、信号、socket (http， rpc, ws 等等 tcp 的应用层协议)

• 管道

  
  管道 实质是 内核缓冲区

数据从写端流向 读取端，只可读取一次数据就删除了。
读写默认都是阻塞的。

进程同步
进程是内存隔离的，但是如果是两个进程同时操作一个文件，那也会产生竞争的。所以也需要同步
使用 互斥锁 吧！Golang的sync包也有对互斥的支持
— — —— — — — — 进程结束— — — — — — — — — —

• 线程

多进程示意图：

多进程 多线程示意图

一个进程会有一个主线程，这个是时间轮片的最小单元

线程同步

互斥量（常见互斥锁）
死锁：资源没有绑在一起，导致互斥量拿到的资源不全，一直阻塞
解决办法：
试锁定： 即拿到一个资源后，尝试锁定后续需要的资源，如果不能全部锁定，则解除已经锁定的资源。然后重新争夺锁
（其实这个操作就是相当于吧所有资源做一个绑定，有点原子的意思， 比较复杂）
差分资源：
就是把需要的资源差分一个个的，这样针对单个资源锁定，自然不会死锁了（ 不灵活 ）

条件变量
互斥量有时候也不能完美解决问题，比如最常见的生产消费模型中

由于生产者线程和消费者线程都会对数据队列进行并发访问，那么我们肯定会为数据队列进行加锁操作，以实现同步

此时如果生产者线程获得互斥量，发现数据队列已满，无法添加新数据，生产者线程就可能在临界区一直等待，直到有空闲区间。这种做法明显是错误的，因为该线程一直阻塞在临界区，直接影响了其他消费者线程的使用！生产者线程应该在发现没有空闲区间时直接解锁退出

条件变量有三种操作：
等待通知 单发通知 广播通知

就是说条件变量就是通知线程，满足条件了，可以操作数据了，不用等待，然后线程直接使用互斥量操作数据。

艹， 直奔主题， goroutine

channel

其实除了 channel ， 全局变量也可以交换数据，只不过要自己枷锁

• 无缓冲channel

make(chan int)  // 不加长度，默认为 0 长度

无缓冲的管道，读写至少有两个 goroutine ，否则报错

func nocache_chan(){
    ch := make(chan int)
    go func(){ch <- 10}()  // go 开启的另一个协成
    <-ch   // 主协成
}

下面报错：

func wrong(){
    ch := make(chan int)
    ch <- 10
    <-ch
}
>>
fatal error: all goroutines are asleep - deadlock!

• 有缓存channel

make(chan int, 10)  // 管道长度 > 0

首先，无缓冲上面报错的例子这里就正常运行拉了

func wrong(){
    ch := make(chan int, 2)
    ch <- 10
    fmt.Println(<-ch)
}
>> 10

同样的，当数据全部读取完毕后，再次读取也会造成阻塞，如下所示

func main() {
    ch := make(chan int, 1)
    ch <- 10
        // ch <- 10  加这个也会报错
    <-ch
    // <-ch   加上这个依然报错
}

很显然，如果在一个 协成（上个例子为主协成，要注意写入读取按照顺序，如果有阻塞则汇报错）

• channel的相关操作

遍历： // 用 range 遍历等 channel 关闭，就自动退出循环，不会报错，这里不用手动取值判断 管道是否关闭

for data := range ch {
        fmt.Println("data==", data)
        if data == 3 {
            break
        }
    }

这样就省得 <- chan 取了

通道关闭 可以不用管主动回收，也可以自己关闭

ch := make(chan int)
    close(ch)               // 关闭通道
    ch <- 1                 // 报错：send on closed channel

从通道中接收数据时，可以利用多返回值判断通道是否已经关闭

func close_chan(){
    var c = make(chan int, 2)
    go func(){ c <- 1; c <- 2 ; close(c) }()
    go func(){fmt.Println(<-c, "\n", <-c, "\n", <-c)}()
    time.Sleep(time.Second)
    x, ok := <- c
    fmt.Println(x, ok)
}

>> 
1 
2 
0

0 false

channel已经关闭则：
不能再向其写入数据， 可以读数据,如果没有多余数据，则取到的是 类型零值

通道读写
有的时候分为只读只写的管道（默认为双向管道）

var chan1 chan<- int        // 声明 只写channel
var chan2 <-chan int        // 声明 只读channel

这样记：
(chan)<- (chan)    type     // <- 代表左边是数据进入方向
默认是 chan  type

单向管道不能转双向，但双向可以转单向

隐式转换

var ch chan int         // 声明一个双向
ch = make(chan int, 10) // 初始化

func write(ch chan<- int) {}
func read(ch <-chan int) {}

go write(ch)
go read(ch)

// 这样  write 函数，的chan 就只可以放数据，read 函数的chan只可以取数据

**显示转换 （这个好像有问题) **

ch := make(chan int)        // 声明普通channel
ch1 := <-chan int(ch)       // 转换为 只读channel
ch2 := chan<- int(ch)       // 转换为 只写channel

** 等待组 sync.WaitGroup 同步数据**
sync.WaitGroup类型的值也是并发安全的

(wg *WaitGroup) Add(delta int) 等待组计数器+1，该方法也可以传
入负值让等待计数
(wg *WaitGroup) Done() 等待组计数器-1，等同于Add传入负值
(wg *WaitGroup) Wait() 等待组计数器!=0时阻塞，直到为0

应用场景：WaitGroup一般用于协调多个goroutine运行, 当然你可以用 一个 channel 计数阻塞，但是没有 WaitGroup 轻便

实例：

var mt sync.Mutex
    var wg sync.WaitGroup
    var money = 10000

    // 开启10个协程，每个协程内部 循环1000次，每次循环值+10
    for i := 0; i < 10; i++ {
        wg.Add(1)
        go func(index int) {    
            mt.Lock()       
            fmt.Printf("协程 %d 抢到锁\n", index)            
            for j := 0; j < 100; j++ {
                money += 10             //  多个协程对 money产生了竞争
            }
            fmt.Printf("协程 %d 准备解锁\n", index)       
            mt.Unlock()
            wg.Done()
        }(i)
    }

    wg.Wait()
    fmt.Println("最终的monet = ", money)       // 应该输出20000才正确

就是说 穿件 WaitGroup -> add -> done -> wait

channel select
即满足一个条件就执行，不会从上倒下阻塞（switch 是从上倒下顺序判断的）

select {
    case 操作1:
        响应操作1
    case 操作2:
        响应操作2
    ...
    default:
        没有操作的情况
}

以下例子：两个管道中只要有一个管道能够取出数据，那么就使用该数据
（select中的case必须是I/O操作）

func fn1(ch chan string) {
    time.Sleep(time.Second * 3)
    ch <- "fn1111"
}

func fn2(ch chan string) {
    time.Sleep(time.Second * 6)
    ch <- "fn2222"
}

func main() {

    ch1 := make(chan string)
    go fn1(ch1)

    ch2 := make(chan string)
    go fn2(ch2)

    select {
    case r1 := <-ch1:
        fmt.Println("r1=", r1)
    case r2 := <-ch2:
        fmt.Println("r2=", r2)
    }
}

利用select()可以实现超时处理：

timeout := make(chan bool, 1)

    go func() {
        time.Sleep(1e9)         // 等待1秒钟
        timeout <- true
    }()

    select {
        case <-ch:              // 能取到数据
        case <-timeout:         // 没有从-cha中取到数据，此时能从timeout中取得数据
    }
// 就是人为 弄一个一定时间后 管道有值的select 语句