分享
对golang的Channel初始化的有缓存与无缓存解释
paladinosment · · 10195 次点击 · · 开始浏览这是一个创建于 的文章,其中的信息可能已经有所发展或是发生改变。
首先编程的时候遇到疑问,输出跟我所想预想不一样,后来查到了golang社区的帖子,其中一篇帖子 :健哥大人 做出了一些解释。
我摘抄重点过来:
无缓冲的与有缓冲channel有着重大差别,那就是一个是同步的 一个是非同步的。
比如
c1:=make(chan int) 无缓冲
c2:=make(chan int,1) 有缓冲
c1<-1
无缓冲: 不仅仅是向 c1 通道放 1,而是一直要等有别的携程 <-c1 接手了这个参数,那么c1<-1才会继续下去,要不然就一直阻塞着。
有缓冲: c2<-1 则不会阻塞,因为缓冲大小是1(其实是缓冲大小为0),只有当放第二个值的时候,第一个还没被人拿走,这时候才会阻塞。
我对以上做一些解释,首先确实得承认channel有缓存与无缓存确实差别巨大,缓存为1和不设置缓存输出有差别。但是上面有缓存的解释是合理的,无缓存的我保留一下意见,用用代码实例来做下分析。
首先看示例1:
package main
import (
"fmt"
)
func main() {
jobs := make(chan int, 1)
done := make(chan bool)
go func() {
// fmt.Println("GoStart")
for i := 1; ; i++ {
// fmt.Println("GoforSTART", i)
j, more := <-jobs
if more {
fmt.Println("received job", j)
} else {
fmt.Println("received all jobs")
done <- true
return
}
// fmt.Println("GoforEND", i)
}
}()
for j := 1; j <= 3; j++ {
// fmt.Println("OutFOR", j)
jobs <- j
fmt.Println("sent job", j)
}
close(jobs)
fmt.Println("sent all jobs")
<-done
}其输出是:
sent job 1 received job 1 sent job 2 received job 2 sent job 3 sent all jobs received job 3 received all jobs这是有缓存的情况,输出跟大家所预想的是一样的,每次遇到
jobs <- j
程序会继续向下执行,直到程序循环到下次 jobs <- j,因为jobs的开辟的缓存已满,故程序转而执行goroutine部分,在goroutine中,当程序执行至
j, more := <-jobs
取出channel中的值,等到goroutine中遇到阻塞,回到外部main()函数继续执行
然后分析看示例2:
将上一段得程序有缓存channel修改为无缓存,即:
jobs := make(chan int, 1)
修改为
jobs := make(chan int)并将代码中的注释部分全部还原执行。
其输出是:
OutFOR 1 GoStart GoforSTART 1 received job 1 GoforEND 1 GoforSTART 2 sent job 1 OutFOR 2 sent job 2 OutFOR 3 received job 2 GoforEND 2 GoforSTART 3 received job 3 GoforEND 3 GoforSTART 4 sent job 3 sent all jobs received all jobs
当for循环运行至第一次 jobs <- j ,程序直接进入goroutine,由输出的" GoStart" 紧跟 "OutFOR 1" 得到验证。然后程序执行至在goroutine中for的第二次循环
j, more := <-jobs处阻塞,回到外部main()的for循环。
但外部main的for循环执行第二圈时,并未在 jobs <- j 后进入goroutine,而是继续执行,由
sent job 2 OutFOR 3紧跟
OutFOR 2得到验证。
而外部for进入第三次循环时阻塞,因为jobs中得值还未取出,故而转入goroutine继续执行。
问题出在
jobs <- j
是继续执行还是阻塞去在其他goroutine中传递值,按照本文开头索引的帖子所指出,应该jobs 通道放j,需要有携程接手这个参数,才可继续执行,但上面得分析看到情况并非如此。
示例3:
package main
import (
"fmt"
)
func main() {
jobs := make(chan int)
go func() {
fmt.Println("Goroutin Start")
for {
select {
case src := <-jobs:
fmt.Println("Get ", src)
}
}
}()
for j := 0; j < 5; j++ {
jobs <- j
fmt.Println("Sent job ", j)
}
close(jobs)
fmt.Println("finish.")
}其输出为:
Goroutin Start Get 0 Sent job 0 Sent job 1 Get 1 Get 2 Sent job 2 Sent job 3 Get 3 Get 4 Sent job 4 finish.
当遇到向channel写入值,是否往下执行是交替的,也就是说是随机的。
本文示例环境是go 1.4,本文所做的解释也是因为携程都是利用同一cpu在不同时间片上运行所做的输出分析。
goroutine利用阻塞同步携程之间的数据是非常重要的思想,但大家编程的时候要特别小心。
有疑问加站长微信联系(非本文作者)
入群交流(和以上内容无关):加入Go大咖交流群,或添加微信:liuxiaoyan-s 备注:入群;或加QQ群:692541889
关注微信10195 次点击
被以下专栏收入,发现更多相似内容
上一篇:golang的json操作
下一篇:golang的profile
添加一条新回复
(您需要 后才能回复 没有账号 ?)
- 请尽量让自己的回复能够对别人有帮助
- 支持 Markdown 格式, **粗体**、~~删除线~~、
`单行代码` - 支持 @ 本站用户;支持表情(输入 : 提示),见 Emoji cheat sheet
- 图片支持拖拽、截图粘贴等方式上传
收入到我管理的专栏 新建专栏
首先编程的时候遇到疑问,输出跟我所想预想不一样,后来查到了golang社区的帖子,其中一篇帖子 :健哥大人 做出了一些解释。
我摘抄重点过来:
无缓冲的与有缓冲channel有着重大差别,那就是一个是同步的 一个是非同步的。
比如
c1:=make(chan int) 无缓冲
c2:=make(chan int,1) 有缓冲
c1<-1
无缓冲: 不仅仅是向 c1 通道放 1,而是一直要等有别的携程 <-c1 接手了这个参数,那么c1<-1才会继续下去,要不然就一直阻塞着。
有缓冲: c2<-1 则不会阻塞,因为缓冲大小是1(其实是缓冲大小为0),只有当放第二个值的时候,第一个还没被人拿走,这时候才会阻塞。
我对以上做一些解释,首先确实得承认channel有缓存与无缓存确实差别巨大,缓存为1和不设置缓存输出有差别。但是上面有缓存的解释是合理的,无缓存的我保留一下意见,用用代码实例来做下分析。
首先看示例1:
package main
import (
"fmt"
)
func main() {
jobs := make(chan int, 1)
done := make(chan bool)
go func() {
// fmt.Println("GoStart")
for i := 1; ; i++ {
// fmt.Println("GoforSTART", i)
j, more := <-jobs
if more {
fmt.Println("received job", j)
} else {
fmt.Println("received all jobs")
done <- true
return
}
// fmt.Println("GoforEND", i)
}
}()
for j := 1; j <= 3; j++ {
// fmt.Println("OutFOR", j)
jobs <- j
fmt.Println("sent job", j)
}
close(jobs)
fmt.Println("sent all jobs")
<-done
}其输出是:
sent job 1 received job 1 sent job 2 received job 2 sent job 3 sent all jobs received job 3 received all jobs这是有缓存的情况,输出跟大家所预想的是一样的,每次遇到
jobs <- j
程序会继续向下执行,直到程序循环到下次 jobs <- j,因为jobs的开辟的缓存已满,故程序转而执行goroutine部分,在goroutine中,当程序执行至
j, more := <-jobs
取出channel中的值,等到goroutine中遇到阻塞,回到外部main()函数继续执行
然后分析看示例2:
将上一段得程序有缓存channel修改为无缓存,即:
jobs := make(chan int, 1)
修改为
jobs := make(chan int)并将代码中的注释部分全部还原执行。
其输出是:
OutFOR 1 GoStart GoforSTART 1 received job 1 GoforEND 1 GoforSTART 2 sent job 1 OutFOR 2 sent job 2 OutFOR 3 received job 2 GoforEND 2 GoforSTART 3 received job 3 GoforEND 3 GoforSTART 4 sent job 3 sent all jobs received all jobs
当for循环运行至第一次 jobs <- j ,程序直接进入goroutine,由输出的" GoStart" 紧跟 "OutFOR 1" 得到验证。然后程序执行至在goroutine中for的第二次循环
j, more := <-jobs处阻塞,回到外部main()的for循环。
但外部main的for循环执行第二圈时,并未在 jobs <- j 后进入goroutine,而是继续执行,由
sent job 2 OutFOR 3紧跟
OutFOR 2得到验证。
而外部for进入第三次循环时阻塞,因为jobs中得值还未取出,故而转入goroutine继续执行。
问题出在
jobs <- j
是继续执行还是阻塞去在其他goroutine中传递值,按照本文开头索引的帖子所指出,应该jobs 通道放j,需要有携程接手这个参数,才可继续执行,但上面得分析看到情况并非如此。
示例3:
package main
import (
"fmt"
)
func main() {
jobs := make(chan int)
go func() {
fmt.Println("Goroutin Start")
for {
select {
case src := <-jobs:
fmt.Println("Get ", src)
}
}
}()
for j := 0; j < 5; j++ {
jobs <- j
fmt.Println("Sent job ", j)
}
close(jobs)
fmt.Println("finish.")
}其输出为:
Goroutin Start Get 0 Sent job 0 Sent job 1 Get 1 Get 2 Sent job 2 Sent job 3 Get 3 Get 4 Sent job 4 finish.
当遇到向channel写入值,是否往下执行是交替的,也就是说是随机的。
本文示例环境是go 1.4,本文所做的解释也是因为携程都是利用同一cpu在不同时间片上运行所做的输出分析。
goroutine利用阻塞同步携程之间的数据是非常重要的思想,但大家编程的时候要特别小心。