内容简介:先上一段代码,优点: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高级
本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。
Spring技术内幕
计文柯 / 机械工业出版社 / 2010-1-1 / 55.00元
内容简介: 本书是Spring领域的问鼎之作,由业界拥有10余年开发经验的资深Java专家亲自执笔!Java开发者社区和Spring开发者社区一致强烈推荐。 国内第一本基于Spring3.0的著作,从源代码的角度对Spring的内核和各个主要功能模块的架构、设计和实现原理进行了深入剖析。你不仅能从木书中参透Spring框架的优秀架构和设计思想,而且还能从Spring优雅的实现源码中一窥......一起来看看 《Spring技术内幕》 这本书的介绍吧!