golang协程——通道channel阻塞

xiaofengshuyu · · 13576 次点击 · · 开始浏览    
这是一个创建于 的文章,其中的信息可能已经有所发展或是发生改变。

  新的一年开始了,不管今天以前发生了什么,向前看,就够了。

  说到channel,就一定要说一说线程了。任何实际项目,无论大小,并发是必然存在的。并发的存在,就涉及到线程通信。在当下的开发语言中,线程通讯主要有两种,共享内存与消息传递。共享内存一定都很熟悉,通过共同操作同一对象,实现线程间通讯。消息传递即通过类似聊天的方式。golang对并发的处理采用了协程的技术。golang的goroutine就是协程的实现。协程的概念很早就有,简单的理解为轻量级线程,goroutine就是为了解决并发任务间的通信而设计的。golang解决通信的理念是:不要通过共享内存来通信,而应该通过通信来共享内存。golang解决方案是消息传递机制,消息的传递就是通过channel来实现的。

  channel的使用很简单,这里就不在粘别人的东西了。现在谈一谈对channe阻塞l的理解。  

  发送者角度:对于同一个通道,发送操作(协程或者函数中的),在接收者准备好之前是阻塞的。如果chan中的数据无人接收,就无法再给通道传入其他数据。因为新的输入无法在通道非空的情况下传入。所以发送操作会等待 chan 再次变为可用状态:就是通道值被接收时(可以传入变量)。

  接收者角度:对于同一个通道,接收操作是阻塞的(协程或函数中的),直到发送者可用:如果通道中没有数据,接收者就阻塞了。

  通过一个简单的例子来说明:

  

 1 package main
 2 
 3 import (
 4     "fmt"
 5 )
 6 
 7 func f1(in chan int) {
 8     fmt.Println(<-in)
 9 }
10 
11 func main() {
12     out := make(chan int)
13     out <- 2
14     go f1(out)
15 }

  运行结果:fatal error: all goroutines are asleep - deadlock!

  这是由于第13行之前不存在对out的接收,所以,对于out <- 2来说,永远是阻塞的,即一直会等下去。

  将13,14行互换

 1 package main
 2 
 3 import (
 4     "fmt"
 5 )
 6 
 7 func f1(in chan int) {
 8     fmt.Println(<-in)
 9 }
10 
11 func main() {
12     out := make(chan int)
13     go f1(out)
14     out <- 2
15 }

  运行结果:2

  14行前存在对管道的读操作,所以out <- 2 是合法的。就像前文说的,发送操作在接收者准备好之前是阻塞的。

 


有疑问加站长微信联系(非本文作者)

本文来自:博客园

感谢作者:xiaofengshuyu

查看原文:golang协程——通道channel阻塞

入群交流(和以上内容无关):加入Go大咖交流群,或添加微信:liuxiaoyan-s 备注:入群;或加QQ群:692541889

13576 次点击  ∙  1 赞  
加入收藏 微博
2 回复  |  直到 2018-08-02 14:57:19
暂无回复
添加一条新回复 (您需要 登录 后才能回复 没有账号 ?)
  • 请尽量让自己的回复能够对别人有帮助
  • 支持 Markdown 格式, **粗体**、~~删除线~~、`单行代码`
  • 支持 @ 本站用户;支持表情(输入 : 提示),见 Emoji cheat sheet
  • 图片支持拖拽、截图粘贴等方式上传