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 语句
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 215,133评论 6 497
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 91,682评论 3 390
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 160,784评论 0 350
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 57,508评论 1 288
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 66,603评论 6 386
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 50,607评论 1 293
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 39,604评论 3 415
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 38,359评论 0 270
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 44,805评论 1 307
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 37,121评论 2 330
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 39,280评论 1 344
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 34,959评论 5 339
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 40,588评论 3 322
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 31,206评论 0 21
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,442评论 1 268
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 47,193评论 2 367
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 44,144评论 2 352

推荐阅读更多精彩内容