内容简介:先上一段代码,优点:go 语言自带的唯一一个并发安全性的类型
一. 通道的定义
先上一段代码,
func main() { // 示例1 //通道是一个先进先出(FIFO)的队列 channel := make(chan int,3) channel <- 1 channel <- 2 channel <- 3 fmt.Printf("the first channel value is %v\n",<-channel) v := <- channel fmt.Printf("the first channel value is %v\n",v) fmt.Printf("the first channel value is %v\n",<-channel) // 报错:fatal error: all goroutines are asleep - deadlock! // fmt.Printf("the first channel value is %v\n",<-channel) }
优点:
go 语言自带的唯一一个并发安全性的类型
定义:使用 go 的内建函数make, chan 是关键字, int是通道类型的数据,3是通道容量大小,不能小于0,如果为0,则表示非缓冲通道。
性质:
1. 通道中发送操作是互斥的,接收操作也是互斥的,比如上面,往channel中发送1,2,3,这发生再三个时刻,同一时刻你不可能发送1同时发送2,接收操作也是同样的道理。
2. 发送和接收操作对同一个元素是原子性的,就是说上面市不可能往channe1中发送1的同时又把1从channel取出来,只有1这个元素完整的复制进channel中时,你才可以取出1这个元素来
3. 发送操作在完成之前会被阻塞,接收操作也是同理,比如你把1往channel完完整整地复制进去通道,这需要时间,在这个时间内,channel <- 1 这句代码之后的代码是不会得到执行的,这就是所谓的阻塞.
以上这三个性质,隐约的感觉到了,就是为了实现互斥同时保证元素的安全性
补充:通道元素值移动的过程:比如把1发送到channel中,首先元素1复制一个副本发送到通道,等到要取走时,通道的副本1再复制一个副本2,给要取值的对方,等到对方完全取走后,通道里的副本1才会被删除。
以上代码 GitHub代码地址
二. 通道阻塞情况分析
func main() { // 示例2 channel := make(chan int,3) channel <- 1 channel <- 2 channel <- 3 // 报错1:fatal error: all goroutines are asleep - deadlock! //channel <- 4 fmt.Printf("the first channel value is %v\n",<-channel) v := <- channel fmt.Printf("the first channel value is %v\n",v) fmt.Printf("the first channel value is %v\n",<-channel) // 报错2:fatal error: all goroutines are asleep - deadlock! //fmt.Printf("the first channel value is %v\n",<-channel) // 示例3 channel2 := make(chan int,0) go func() { time.Sleep(time.Second*5) v := <- channel2 fmt.Printf("the value is %v\n",v) }() channel2 <- 1 fmt.Print("the time is over\n") }
分析:
- 发生在通道缓存已满,但还忘通道里面发送元素,比如注释中的"报错1"处,因为通道的容量就是3,你写了1,2,3之后再往里面写这时就写不进一直阻塞再那里
- 发送再通道缓存已空,但是还想从通道中取值,比如注释中的"报错2"处,此时你已取走了1,2,3,你再取值时,已经为空就一直阻 塞再那里
-
对于非缓冲通道,比如示例3,定义了一个channel2通道,容量为0,程序执行到“channel2 <- 1”处会阻塞,因为你忘里面发送元素了,而没有取走,后面的代码就不执行一直阻塞,直到这个值被取走了之后,才会被执行。就如上面再goroutine中只有5秒过后channel2的元素被取走给了v之后,"the time is over\n" 语句才会被执行输出。
以上代码 GitHub代码地址
三. 通道引发panic
func main() { // 示例4 channel3 := make(chan int,2) channel3 <- 1 channel3 <- 2 close(channel3) // 报错3: panic: send on closed channel // channel3 <- 3 // 报错4:panic: close of closed channel //close(channel3) // 示例5 channel5 := make(chan int,2) channel5 <- 1 channel5 <- 2 v1,b1 := <- channel5 fmt.Printf("v1:%v b1:%v\n",v1,b1) v2,b2 := <- channel5 fmt.Printf("v2:%v b2:%v\n",v2,b2) close(channel5) v3,b3 := <- channel5 fmt.Printf("v3:%v b3:%v\n",v3,b3) /*输出: v1:1 b1:true v2:2 b2:true v3:0 b3:false */ // 示例6 channel6 := make(chan int,2) channel6 <- 1 channel6 <- 2 v4,b4 := <- channel6 fmt.Printf("v4:%v b4:%v\n",v4,b4) close(channel6) v5,b5 := <- channel6 fmt.Printf("v5:%v b5:%v\n",v5,b5) /*输出: v4:1 b4:true v5:2 b5:true */ }
- 往一个已经关闭了的通道里面发送值时会引发“panic”。比如上面注释报错3处,前面已执行“close(channel3)”关闭通道操作,再往里面发送值就会引发panic。
- 关闭一个已经关闭的通道时,会引发“panic”。比如上面注释“报错4”处。
-
示例5和示例6的区别仅仅在于关闭通道后,里面是否还有值剩余?假设有剩余,我们就可以从通道取值同时赋给两个变量,第二个变量是bool类型值,其为true表示取到了值,其为false表示没有取到值,这样仅仅可以避免引发“panic”,如果通道已经关闭且无元素值,则取出的第二个bool值为false;若从已关闭的通道里面(里面无剩余元素值)再次读取元素值,则第二个值为true。 总结:第二个bool值为false,则通道肯定关闭了,值为true,可能关闭也可能没有关闭
以上代码 GitHub代码地址
以上就是本文的全部内容,希望本文的内容对大家的学习或者工作能带来一定的帮助,也希望大家多多支持 码农网
猜你喜欢:- Golang 并发,有缓存通道,通道同步案例演示
- 科普 | 菜鸟学习状态通道,Part-2:App 定制型状态通道
- 通道 | Java NIO
- Go 通道
- golang 通道channel 基础
- golang通道channel高级
本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。
Programming Amazon Web Services
James Murty / O'Reilly Media / 2008-3-25 / USD 49.99
Building on the success of its storefront and fulfillment services, Amazon now allows businesses to "rent" computing power, data storage and bandwidth on its vast network platform. This book demonstra......一起来看看 《Programming Amazon Web Services》 这本书的介绍吧!
HTML 编码/解码
HTML 编码/解码
XML、JSON 在线转换
在线XML、JSON转换工具