Go并发可视化解释 – select语句

上周,我发布了一篇关于如何直观解释Golang中通道(Channel)的文章。如果你对通道仍然感到困惑,请先查看那篇文章。

Go并发可视化解释 --- Channel

作为一个快速复习:Partier、Candier和Stringer经营着一家咖啡店。Partier负责接受顾客的订单,然后将这些订单传递给厨房,Candier和Stringer制作咖啡。

Gophers' Cafe(Gopher咖啡馆)

在本文中,我将直观解释select语句,这是在Go应用程序中处理并发的另一个强大工具。Gophers和他们的虚构咖啡馆仍然是我的伙伴,但这次,让我们聚焦在Partier和点单部分。

情景

Gopher的Cafe意识到越来越多的顾客希望通过外卖应用程序在线订购咖啡。因此,除了店内点餐外,他们还选择了一个外卖应用程序。Partier会监视来自两个通道的订单,并通过另一个名为queue的通道将这些订单转发给Candier和Stringer。

go 复制代码
select {
case order := <-appOrders:
    queue <- order
case order := <-inShopOrders:
    queue <- order
}

当这两个通道中的任何一个有订单时,Partier会获取订单并将其转发到queue通道。

如果这两个通道都有订单,将会选择其中一个。在实际的咖啡店中,来自inShopOrders的订单可能会被优先处理。但是,在Go应用程序中,我们无法保证哪个订单会被选择。还要注意,select语句的执行只会选择一个订单,Partier不会一次选择两个订单。但是,在许多应用程序中,select语句通常嵌套在for循环中,以便在前一个迭代中剩下的订单有机会在下一个迭代中被选择。

go 复制代码
for {
    select {
    case order := <-appOrders:
        queue <- order
    case order := <-inShopOrders:
        queue <- order
    }
}

但是,如果这两个通道都有订单,它们将再次进行公平竞争。

默认情况(Default)

在非高峰时段,订单不多,Partier花费大量时间在等待上。他认为,他可以通过做其他事情来更有效地利用时间,例如清理桌子。这可以通过default来实现。

go 复制代码
for {
    select {
    case order := <-appOrders:
        log.Println("There is an order coming from appOrders channel")
        queue <- order
    case order := <-inShopOrders:
        log.Println("There is an order coming from inShopOrders channel")
        queue <- order
    default:
        log.Println("There is no order on both channels, I will do cleaning instead")
        doCleaning()
    }
}

time.After()

time.After(duration)通常与select一起使用,以防止永久等待。与default不同,time.After(duration)会创建一个普通的<-chan Time,等待duration时间的流逝,然后将当前时间发送到返回的通道上。这个通道在select语句中与其他通道平等对待。正如你所看到的,select语句中的通道可以是不同类型的。

go 复制代码
shouldClose := false
closeHourCh := time.After(8 * time.Hour)


for !shouldClose {
    select {
    case order := <-appOrders:
        log.Println("There is an order coming from appOrders channel")
        queue <- order
    case order := <-inShopOrders:
        log.Println("There is an order coming from inShopOrders channel")
        queue <- order
    case now := <-closeHourCh:
        log.Printf("It is %v now, the shop is closing\n", now)
        shouldClose = true
    default:
        log.Println("There is no order on both channels, I will go cleaning instead")
        doCleaning()
    }
}


log.Println("Shop is closed, I'm going home now. Bye!")

当处理远程API调用时,这种技术非常常见,因为我们无法保证远程服务器何时返回或是否返回。借助于context,通常不需要这样做。

go 复制代码
responseChannel := make(chan interface{})
timer := time.NewTimer(timeout)


select {
case resp := <-
相关推荐
余槐i4 小时前
PostgreSQL 函数索引报错 must be immutable:3种绕法与代价
数据库·后端·sql·postgresql·性能优化
数据库小学妹4 小时前
PostgreSQL表膨胀怎么办?autovacuum清不动的根因与排查命令
数据库·postgresql·表膨胀·mvcc·数据库运维
mister_guo4 小时前
MySQL-1267错误:排序规则冲突的原因与解决方案
数据库·mysql
需要8265 小时前
Spring Bean 生命周期:从实例化到销毁的完整钩子
java·后端·spring
骇客野人5 小时前
在麒麟操作系统上 分别安装 jdk1.8, 达梦数据库,redis ,memcache 的操作实施方案和步骤
数据库·redis·memcached
死磕音视频5 小时前
让小模型做选择题:限定候选项并读取 logits 概率的入门实践(附 Python 代码)
开发语言·python·大模型·文本分类·transformers
凤山老林6 小时前
Spring Boot 接入国密 SM2/SM3/SM4 的一些实践记录
spring boot·后端·python
美狐美颜SDK开放平台6 小时前
直播APP如何实现美白滤镜功能?视频美颜SDK技术开发方案详解
前端·数据库·人工智能·音视频·美颜sdk·直播美颜sdk·视频美颜sdk
伯恩bourne7 小时前
Spring Boot Bean 注册的两种方式:@Component 家族 vs @Configuration + @Bean
java·spring boot·后端
张彦峰ZYF7 小时前
停顿短不等于延迟低:G1、ZGC 与低延迟服务的目标分野、代价账本与选型标定
后端·回收暂停、应用停止总时长·到达安全点、分配停滞·屏障吃吞吐、并发线程吃核心·并发窗口吃堆余量·分区式靠挑回收集兑现目标·染色指针式不支持压缩引用