channel 阻塞_channelshell 判断阻塞时间-优快云博客

本文链接：https://blog.youkuaiyun.com/qq_34751210/article/details/127771103

本文介绍了Go语言中的轻量级线程——goroutine，以及它们如何通过通道(channel)进行通信。发送者在接收者未准备好之前会被阻塞，而接收者在通道无数据时也会等待。示例代码展示了如何在主函数中正确使用goroutine和通道，强调了通道关闭的重要性，以及不正确使用可能导致的死锁问题。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

-轻量级线程
-过通信来共享内存，消息的传递就是通过channel来实现的。

发送者角度：
　 ch <- x // a send statement
-对于同一个通道，发送操作，在接收者准备好之前是阻塞的。
-chan中的数据无人接收，再给通道传入其他数据。
接收者角度：

		x = <-ch // a receive expression in an assignment statement
		<-ch     // a receive statement; result is discarded

	接收操作是阻塞的（协程或函数中的），直到发送者可用
	如果通道中没有数据，接收者就阻塞了。


```go
 package main
 2 
 3 import (
 4     "fmt"
 5 )
 6 
 7 func f1(in chan int) {
 8     fmt.Println(<-in)
 9 }
10 
11 func main() {
12     out := make(chan int)
13     out <- 2
14     go f1(out)
15 }

func main() {
    conn, err := net.Dial("tcp", "localhost:8000")
    if err != nil {
        log.Fatal(err)
    }
    done := make(chan struct{})
    go func() {
        io.Copy(os.Stdout, conn) // NOTE: ignoring errors
        log.Println("done")
        done <- struct{}{} // signal the main goroutine
    }()
    mustCopy(conn, os.Stdin)
    conn.Close()
    <-done // wait for background goroutine to finish
}

所以主函数不应该先有一个 conn <- 发送的操作应该在一个groutine 中或者在接受后面

运行结果：fatal error: all goroutines are asleep - deadlock!

这是由于第13行之前不存在对out的接收，所以，对于out <- 2来说，永远是阻塞的，即一直会等下去。

将13,14行互换
　　　　14行前存在对管道的读操作，所以out <- 2 是合法的。就像前文说的，发送操作在接收者准备好之前是阻塞的。

关闭
发送操作都将导致panic异常。
接收操作依然可以接受到之前已经成功发送的数据；
如果channel中已经没有数据的话将产生一个零值的数据。

读取进阶：

 go func() {
        for x := range naturals {
            squares <- x * x
        }
        close(squares)
    }()

**关闭每一个channel。
只有当需要告诉接收者goroutine，所有的数据已经全部发送时才需要关闭channel。