[GO]通道的关闭

并不是往通道里放多少次数据,就必须取多次少数据的(之前的例子都是放3次取3次,放10次取10次),我们可以做一个操作,当子协程没有新放入的时候,主协程不再去取,这就是关闭通道

package main

import "fmt"

//channel并不像文件那样需要经常去关闭它,只有当你确实没有任何发送数据了,或者是你想显示的结束range循环之类的,才去关闭channel
//关闭channel后,无法向channel再发送数据(引发panic错误后导致接收立即返回零值)
//关闭channel后,可以继续向channel接收数据
//对于nil channel,无论收发都会被阻塞

func main() {
    ch := make(chan int)
    go func() {
        for i:=0; i<5; i++ {
            ch <- i
        }
        close(ch) //关闭channel
    }()
    for true {
        //如果OK为true,则说明通道没有关闭
        if num, ok := <-ch; ok==true{
            fmt.Println("num = ", num)
        }else {
            break
        }
    }  //上面的这段死循环也可以使用下面的实现,更简便
  for num := range ch {     fmt.Printf("num = ", num)  } 
}

执行结果

num =  0
num =  1
num =  2
num =  3
num =  4

原文地址:https://www.cnblogs.com/baylorqu/p/9674599.html

时间: 2024-11-10 15:05:32

[GO]通道的关闭的相关文章

JSch : channel never closed or EOF 通道未关闭

最近,我们的项目在开发远程节点管理的时候,使用了jsch库.在测试的时候发现有个节点在cmd执行完成之后,channel.isClosed()一直都是false,导致请求无法返回,但是其它有些节点就没有关系,直接执行都是正常的,返回码也是完全相同.经google,也没有找到相应解决方法比如https://github.com/lucastheisen/jsch-extension/issues/6,https://stackoverflow.com/questions/12138777/jsch

【收藏转】WCF后传系列(8):深度通道编程模型Part 1—设计篇

引言 从本质上说,WCF是一个通信服务框架,它允许我们使用不同的传输协议,使用不同的消息编码形式,跟不同的WS-*系列规范交互,而所有这些细节都是由通道堆栈来处理的.为了简化这些处理,在WCF中提供了两种模型,一是针对开发者的应用程序编程模型:二是用来通信的通道模型,这样对于开发者来说,只要了解应用程序编程模型就足够了,而不会涉及到通道模型,然而,对于通道模型进行必要的学习,可以让我们真正理解WCF中“通信”概念,了解WCF的 整个架构体系,从而构建出更加健壮的WCF服务或者对WCF框架进行扩展

【收藏转】WCF后传系列(9):深度通道编程模型Part 2—实例篇

引言 从本质上说,WCF是一个通信服务框架,它允许我们使用不同的传输协议,使用不同的消息编码形式,跟不同的WS-*系列规范交互,而所有这些细节都是由通道堆栈来处理的.在<WCF专题系列(8):深度通道编程模型Part 1—设计篇>中,对于WCF中的通道模型有了深入的认识,本文中,我将通过实例来说明在通道模型中,服务端是如何接收消息,客户端是如何发送消息的. 服务端通道 本文将不使用WCF的编程模型,而直接利用通道模型来进行通信,这样有助于我们更进一步加深对服务端处理消息的认识,在服务端侦听并接

Go语言之通道

上一篇我们讲的原子函数和互斥锁,都可以保证共享数据的读写.但是呢,它们还是有点复杂,而且影响性能.对此,Go又为我们提供了一种工具,这就是通道. 所以在多个goroutine并发中,我们不仅可以通过原子函数和互斥锁保证对共享资源的安全访问,消除竞争的状态,还可以通过使用通道,在多个goroutine发送和接受共享的数据,达到数据同步的目的. 通道,它有点像在两个routine之间架设的管道:一个goroutine可以往这个管道里塞数据,另外一个可以从这个管道里取数据.有点类似于我们说的队列. 声

python close()是假象,真正关闭Socket的方法

背景: 工作中自己用python写了一个tcp工具,然后用while循环一直接收消息,并且打印出来.然后正常close发现设备并没有离线,然后用了临时的规避方案,发现其实是一直阻塞在recv()接收方法里面,只要传输一条协议,让recv()吃到消息即可正常运行while来让其break退出,但是这种规避方式是临时的,治病要治其根,所以对现在socket进行了研究. 问题原因: 虽然已经将连接close掉了,但是client端仍然可以顺利的接收到消息,而且,如果client端发送数据的间隔小于超时

java nio 通道(二)

本文章来源于我的个人博客: java nio 通道(二) 一,文件通道 文件通道总是堵塞式的,因此不能被置于非堵塞模式. FileChannel对象是线程安全的.多个进程能够在同一个实例上并发调用方法而不会引起不论什么问题,只是非全部的操作都是多线程的.影响通道位置或者影响文件大小的操作都是单线程的. 通过FileChannel实例看到的某个文件的视图同通过一个外部的非java进程看到的该文件的视图可能一致也可能不一致. 创建文件通道: RandomAccessFile randomAccess

6.24 AppCan移动开发者大会:议程重大更新,报名即将关闭

大会倒计时2天,议程重大更新,报名通道即将关闭! 创业6年,由AppCan主办的第一届移动开发者大会将在本周五盛大召开.超过100万开发者线上参与.现场1500人规模.50家移动互联企业深度参与.30位一线技术大咖传道解惑.草根开发者分享创业心路历程,企业级移动门户正益工作发布&开源开放…亮点多.干货多.互动多.上有趋势下有实践,堪称年度最有看点的移动开发者大会. 在倒计时2天之际,议程重大更新,以移动技术为主线,全新加入[技术脱口秀]: 7位AppCan一线技术专家,长达2小时的技术深度.精华

go 通道

1. package main import "fmt" func sum(s []int, c chan int) { sum := 0 for _, v := range s { sum += v } c <- sum // 把 sum 发送到通道 c } func main() { s := []int{7, 2, 8, -9, 4, 0} c := make(chan int) go sum(s[len(s)/2:], c) go sum(s[:len(s)/2], c)

gopl goroutine 和通道

Go 语言的并发编程风格 Go 有两种并发编程风格: goroutine 和通道(chennle),支持通信顺序进程(Communicating Sequential Process, CSP),CSP 是一个并发的模式,在不同的执行体(goroutine)之间传递值,但是变量本身局限于单一的执行体. 共享内存多线程的传统模型,这和在其他主流语言中使用的线程类似. 这章讲第一种 goroutine 和通道. 通道 如果说 goroutine 是 Go 程序并发的执行体,通道就是它们之间的连接.每