go当中的channel 无缓冲channel和缓冲channel的适用场景、结合select的使用
Channel
Go channel就像Go并发模型中的“胶水”,它将诸多并发执行单元连接起来,或者正是因为有channel的存在,Go并发模型才能迸发出强大的表达能力。
无缓冲channel
无缓冲channel兼具通信和同步特性,在并发程序中应用颇为广泛。
可以通过不带有capacity参数的内置make函数创建一个可用的无缓冲channel:
c := make(chan T)
由于无缓冲channel的运行时层实现不带有缓冲区,因此对无缓冲channel的接收和发送操作是同步的。
一个无缓冲的channel动作发生和完成的时序如下:
- 发送动作一定发生在接收动作完成之前;
- 接收动作一定发生在发送动作完成之前。
这与Go官方“Go内存模型”一文中对channel通信的描述是一致的。正因如此,下面的代码可以保证main输出的变量a的值为"hello, world":
var c = make(chan int)
var a string

func f() {
a = "hello, world"
<-c
}
func main() {
go f()
c <- 5
println(a)
}
因为函数f中的channel接收动作发生在主goroutine对channel发送动作完成之前,而a = “hello, world"语句又发生在channel接收动作之前,因此主goroutine在channel发送操作完成后看到的变量a的值一定是"hello, world”,而不是空字符串。
用作信号传递
1)一对一通知信号
无缓冲channel常被用于在两个goroutine之间一对一地传递通知信号,
(2)一对多通知信号
无缓冲channel还被用来实现一对多的信号通知机制
关闭一个无缓冲channel会让所有阻塞在该channel上的接收操作返回,从而实现一种一对多的广播机制。该一对多的信号通知机制还常用于通知一组worker goroutine退出:
// 通知其他goroutine工作线程已完成
type signal struct{}
func worker(i int) {
fmt.Printf("worker %v is working\n", i)
time.Sleep(5 * time.Second)
fmt.Printf("worker %v : works done\n", i)
}
// spawnGroup 是一个用于生成一组工作线程的函数
// 参数:
// - f: 工作函数,每个工作线程都会执行该函数
// - num: 工作线程的数量
// - groupSignal: 用于控制工作线程启动和停止的信号通道
//
// 返回值:
// - <-chan signal: 用于接收所有工作线程完成的信号通道
func spawnGroup(f func(i int), num int, groupSignal <-chan signal) <-chan signal {
c := make(chan signal)
var wg sync.WaitGroup
for i := 0; i < num; i++ {
wg.Add(1)
go func(i int) {
<-groupSignal //阻塞,等待启动信号
fmt.Printf("worker %v: start to work\n", i)
f(i)
wg.Done() //工作完成,减少WaitGroup的计数
}(i + 1)
}
go func() {
wg.Wait()
c <- signal(struct{}{}) //发送信号通知
}()
return c
}
func main() {
fmt.Println("start a group of workers...")
groupSignal := make(chan signal)
c := spawnGroup(worker, 5, groupSignal)
time.Sleep(10 * time.Second)
fmt.Println("the group of workers start to work...")
// 关闭工作组信号通道,通知所有工作线程开始工作
close(groupSignal)
<-c
fmt.Println("the group of workers work done!")
}
最后结果:
用于替代锁机制
由于无缓冲channel具有同步特性,因此可以在某些场合替代锁,让程序更加清晰,可读性增强;以下给出基于共享内存+锁模式的goroutine安全的计数器:
type counter struct {
c chan int
i int
}
var cter counter
func InitCounter() {
cter = counter{
c: make(chan int),
}
// 增加计数器的动作相当于一次接收动作
go func() {
for {
cter.i++
cter.c <- cter.i
}
}()
fmt.Println("counter init ok")
}
func Increase() int {
return <-cter.c
}
func init() {
InitCounter()
}
func main() {
for i := 0; i < 10; i++ {
go func(i int) {
v := Increase()
fmt.Printf("goroutine-%d: current counter value is %d\n", i, v)
}(i)
}
time.Sleep(5 * time.Second)
}
此代码通过无缓冲channel的同步阻塞特性实现计数器的控制
也符合“不要通过共享内存来通信,而应该通过通信来共享内存”的原则
缓冲channel
带缓冲channel可以通过带有capacity参数的内置make函数创建
c := make(chan T, capacity)
接收操作在缓冲区非空的情况下是异步的(发送或接收无须阻塞等待)
用作消息队列
channel的原生特性与我们认知中的消息队列十分相似,包括goroutine安全、有fifo(first-in, first out)保证等。异步收发的带缓冲channel更适合用作消息队列,并且带缓冲channel在数据收发性能上要明显好于无缓冲channel
用作计数信号量 counting semaphore
带缓冲channel当前数据个数代表的是同时处于活跃状态的goroutine数量,capacity则代表同时处于活跃状态的最大数量。以下是一个例子:
// 同一时间最多3个活跃状态
var active = make(chan struct{}, 3)
var jobs = make(chan int, 10)
func main() {
go func() {
for i := 0; i < 8; i++ {
jobs <- i + 1
}
close(jobs)
}()
var wg sync.WaitGroup
for j := range jobs {
wg.Add(1)
go func(j int) {
active <- struct{}{}
log.Printf("handle job: %v\n", j)
time.Sleep(2 * time.Second)
<-active
wg.Done()
}(j)
}
wg.Wait()
}
结果:
可以发现同一时间处于处理状态的job最多为3个
len(channel)的应用
如果s是chan T类型,那么len(s)针对channel的类型不同,有如下两种语义:
- 当s为无缓冲channel时,len(s)总是返回0;
- 当s为带缓冲channel时,len(s)返回当前channel s中尚未被读取的元素个数。
但是单纯依靠if语句来判断channel元素状态并不可靠,因为在并发状态下不能保证后续对channel进行收发时channel状态不变:
oroutine1在使用len(channel)判空后,便尝试从channel中接收数据。但在其真正从channel中读数据前,goroutine2已经将数据读了出去,goroutine1后面的读取将阻塞在channel上,导致后面逻辑失效。因此,为了不阻塞在channel上,常见的方法是将判空与读取放在一个事务中,将判满与写入放在一个事务中,而这类事务我们可以通过select实现。来看下面的示例:
func producer(c chan<- int) {
var i int = 1
for {
time.Sleep(2 * time.Second)
ok := trySend(c, i)
if ok {
fmt.Printf("[producer]: send [%d] to channel\n", i)
i++
continue
}
fmt.Printf("[producer]: try send [%d], but channel is full\n", i)
}
}
func tryRecv(c <-chan int) (int, bool) {
select {
case i := <-c:
return i, true
default:
return 0, false
}
}
func trySend(c chan<- int, i int) bool {
select {
case c <- i:
return true
default:
return false
}
}
func consumer(c <-chan int) {
for {
i, ok := tryRecv(c)
if !ok {
fmt.Println("[consumer]: try to recv from channel, but the channel is empty")
time.Sleep(1 * time.Second)
continue
}
fmt.Printf("[consumer]: recv [%d] from channel\n", i)
if i >= 3 {
fmt.Println("[consumer]: exit")
return
}
}
}
func main() {
c := make(chan int, 3)
go producer(c)
go consumer(c)
select {} // 仅用于演示,临时用来阻塞主goroutine
}
结果:
这种方法的缺点就在于改变了channel的状态
想在不改变channel状态的前提下单纯地侦测channel的状态,又不会因channel满或空阻塞在channel上。但很遗憾,目前没有一种方法既可以实现这样的功能又适用于所有场合。在特定的场景下,可以用len(channel)来实现。比如图34-2中的这两种场景。
在图34-2中,a是一个多发送单接收的场景,即有多个发送者,但有且只有一个接收者。在这样的场景下,我们可以在接收者goroutine中根据len(channel)是否大于0来判断channel中是否有数据需要接收。
b是一个多接收单发送的场景,即有多个接收者,但有且只有一个发送者。在这样的场景下,我们可以在发送goroutine中根据len(channel)是否小于cap(channel)来判断是否可以执行向channel的发送操作。
nil channel的妙用
没有初始化的channel(nil channel)进行读写操作将会发生阻塞
func main() {
var c chan int
<-c
}
结果:
main goroutine被阻塞在channel上,导致Go运行时认为出现deadlock状态并抛出panic。
但nil channel并非一无是处。来看一个例子:
func main() {
c1, c2 := make(chan int), make(chan int)
go func() {
time.Sleep(time.Second * 5)
c1 <- 5
close(c1)
}()
go func() {
time.Sleep(time.Second * 7)
c2 <- 7
close(c2)
}()
for {
select {
case x, ok := <-c1:
// 对于一个nil channel执行获取操作,该操作会被堵塞,因此可以显示设置
if !ok {
c1 = nil
} else {
fmt.Println(x)
}
case x, ok := <-c2:
if !ok {
c2 = nil
} else {
fmt.Println(x)
}
}
if c1 == nil && c2 == nil {
break
}
}
fmt.Println("program end")
}
与select结合
避免阻塞
default的使用通常是在没得选的情况下,因此也有一种可以避免堵塞的特性
func sendTime(c interface{}, seq uintptr) {
// 无阻塞地向c发送当前时间
// ...
select {
case c.(chan Time) <- Now():
default:
}
}
实现超时机制
通过超时事件,既可以避免陷入无尽的等待也可以做一些异常处理工作:
func worker() {
select {
case <-c:
//...
case <-time.After(30*time.Second):
return
}
}
timer实质上是由go运行时自动维护的,而不是操作系统的定时器资源:
go通过名为timerproc的函数,维护了一个“最小堆”。该goroutine会被定期唤醒并读取堆顶的timer对象,执行该timer对象对应的函数(向timer.C中发送一条数据,触发定时器),执行完毕后就会从最小堆中移除该timer对象。
所以我们在使用timer的时候应该即使调用timer的Stop方法从最小堆中删除尚未到达过期时间的timer对象。
实现心跳机制
这种机制可以使我们在监听的同时执行一些周期性任务,比如下面这段代码:
func worker() {
heartbeat := time.NewTicker(30 * time.Second)
defer heartbeat.Stop()
for {
select {
case <-c:
// ... 处理业务逻辑
case <- heartbeat.C: //记得调用方法停止运作
//... 处理心跳
}
}
}