chan队列之发送方等待接收方处理结果

从一个nil通道中接收元素，当前goroutine会阻塞

向一个nil通道中发送元素，当前gotoutine也会阻塞

向一个已关闭的通道中发送元素，会引发一个运行时panic,即使发送操作因通道已满而阻塞。

多个goroutine向同一个已满的通道发送元素阻塞时，当通道有空余空间时，最早被阻塞的goroutine会最先被唤醒。

多个goroutine从同一个空的通道接收元素阻塞时，当通道有元素时，最早被阻塞的goroutine会最先被唤醒。

Go运行时每次只唤醒一个goutine.

发送方向通道发送的值会被复制，接收方接收的总是该值的副本。

经由通道传递的值至少会复制一次，最多复制两次。

如：复制1次，向一个已空的通道发送元素，且已有至少一个接收方等待接收时，该通道会绕过本身的缓冲队列，直接复制给最早等待接收的接收方。

如：复制2次，从一个已满的通道接收元素，且至少一个发送方等待发送时，该通道会把缓冲队列中最早进入的元素复制给接收方，再把最早等待发送的发送方的数据复制到空的位置上。

当接收方从通道接收一个值类型的值时，对该值的修改不会影响到发送方持有的那个源值；

当接收方从通道接收一个引用类型的值时，对该值的修改会影响到发送方持有的那个源值；

package mainimport ("fmt"//"time"
)type dataItem struct {curl     stringparamReq interface{}resp     chan error
}type metaset struct {key   stringvalue stringuid   stringpath  string
}var dataChan = make(chan interface{}, 1)
/*
syncChan1和syncChan2的元素类型都是 struct{},struct{}代表不含任何字段的结构体类型（空结构体）空结构体变量不占内存空间，所以所有该类型的变量都拥有相同的内存地址。建议用于传递信号的通道都用struct{}作元素类型，除非需要传递更多的元素。
*/
func main() {syncChan := make(chan struct{}, 2)go func() {for {if elem, ok := <-dataChan; ok {if elem, ok := elem.(dataItem); ok {elem.resp <- nilfmt.Printf("elem:%v\n", elem)fmt.Printf("elem.paramReq:%v\n", elem.paramReq)} else {fmt.Printf("error")}} else {break}}fmt.Println("stopped.[receiver]")syncChan <- struct{}{}}()go func() {meta := metaset{key: "key1", value: "value1", uid: "00", path: "/root/dir1"}data := &dataItem{curl: "/api/test", paramReq: meta, resp: make(chan error, 1)}for i := 0; i < 5; i++ {dataChan <- *data//time.Sleep(time.Second)fmt.Printf("The count map:%v.[sender]\n", data)res := <-data.respfmt.Println("res:", res)}close(dataChan)syncChan <- struct{}{}}()<-syncChan<-syncChan}

结果：

elem:{/api/test {key1 value1 00 /root/dir1} 0xc042034120}
elem.paramReq:{key1 value1 00 /root/dir1}
The count map:&{/api/test {key1 value1 00 /root/dir1} 0xc042034120}.[sender]
res: <nil>
elem:{/api/test {key1 value1 00 /root/dir1} 0xc042034120}
elem.paramReq:{key1 value1 00 /root/dir1}
The count map:&{/api/test {key1 value1 00 /root/dir1} 0xc042034120}.[sender]
res: <nil>
elem:{/api/test {key1 value1 00 /root/dir1} 0xc042034120}
elem.paramReq:{key1 value1 00 /root/dir1}
The count map:&{/api/test {key1 value1 00 /root/dir1} 0xc042034120}.[sender]
res: <nil>
elem:{/api/test {key1 value1 00 /root/dir1} 0xc042034120}
elem.paramReq:{key1 value1 00 /root/dir1}
The count map:&{/api/test {key1 value1 00 /root/dir1} 0xc042034120}.[sender]
res: <nil>
elem:{/api/test {key1 value1 00 /root/dir1} 0xc042034120}
elem.paramReq:{key1 value1 00 /root/dir1}
The count map:&{/api/test {key1 value1 00 /root/dir1} 0xc042034120}.[sender]
res: <nil>
stopped.[receiver]

chan队列之发送方等待接收方处理结果相关推荐

C#事件的发送方和接收方（订阅方）
C#事件的发送方和接收方(订阅方) 基于Windows的应用程序也是基于消息的,Windows使用预定义消息与应用程序通讯..NET Framework将Windows消息封装在事件中,可以把事件作为 ...
如何创建基本的高级队列之一：创建发送方代码
/* 基本组成发送方(DB1): Queue type :决定发送消息的类型 Queue table :消息发送的载体 Queue :队列 Subscriber :订购者,同一个队列可以有n个订购者 ...
【计算机网络】数据链路层 : 后退 N 帧协议 GBN ( 滑动窗口 | 发送窗口长度 | “发送方“ 累计确认、超时机制 | “接收方“ 按序接收、确认帧发送机制 | 计算示例 )★
文章目录一. 滑动窗口协议引入二. 后退 N 帧协议 ( GBN ) 滑动窗口三. 后退 N 帧协议 ( GBN ) 运行过程四. 后退 N 帧协议 ( GBN ) 发送方数据分类五. 后退 ...
【计算机网络】数据链路层 : 选择重传协议 SR ( 帧分类 | “发送方“ 确认帧、超时事件 | “接受方“ 接收帧机制 | 滑动窗口长度 | 计算示例 )★
文章目录一. 选择重传协议 ( SR ) 引入二. 选择重传协议 ( SR ) 帧分类三. 发送方事件 ( 确认帧.超时事件 ) 四. 接收方事件 ( 接收帧 ) 五. 滑动窗口长度五. ...
RabbitMQ事务和Confirm发送方消息确认——深入解读
引言根据前面的知识(深入了解RabbitMQ工作原理及简单使用.Rabbit的几种工作模式介绍与实践)我们知道,如果要保证消息的可靠性,需要对消息进行持久化处理,然而消息持久化除了需要代码的设置之外 ...
rabbitmq 手动提交_RabbitMQ系列（四）RabbitMQ事务和Confirm发送方消息确认——深入解读 - 王磊的博客 - 博客园...
RabbitMQ事务和Confirm发送方消息确认--深入解读 RabbitMQ系列文章引言根据前面的知识( 深入了解RabbitMQ工作原理及简单使用 . Rabbit的几种工作模式介绍与实践 ...
一个TCP连接总是以1KB的最大段发送TCP段，发送方有足够多的数据要发送。当拥塞窗口为16KB时发生了超时，如果接下来的4个RTT(往返时间)时间内的TCP段的传输都是成功的，那么当第4个RTT时间
无论在慢开始阶段还是在拥塞避免阶段,只要发送方判断网络出现拥塞(其根据就是没有按时收到确认),就要把慢开始门限ssthresh设置为出现拥塞时的发送方窗口值的一半(但不能小于2).把拥塞窗口cwnd重 ...
django多任务开启rabbitmq，并进行声明队列、发送、阻塞监听消息
一,编写rabbitmq基础模块类 1,安装pika模块 pip install pika 这里需要注意的是: pika官网明确说明 pika==0.11.0版本只支持python2.6以前的版本. ...
{网络编程}和{多线程}应用：基于UDP协议【实现多发送方发送数据到同一个接收者】--练习
要求: 使用多线程实现多发送方发送数据到同一个接收者代码: 发送端:可以在多台电脑上启动发送端,同时向接收端发送数据注意:匹配地址和端口号 package com.qf.demo;import j ...

chan队列之发送方等待接收方处理结果

chan队列之发送方等待接收方处理结果相关推荐

最新文章

热门文章