I wrote some code to learn the go channel, as shown below:
func main(){ intChan := make(chan int, 1) strChan := make(chan string, 1) intChan <- 3 strChan <- "hello" fmt.Println("send") // comment this, fatal error: all goroutines are asleep - deadlock! // close(intChan) // close(strChan) for { select { case e, ok := <-intChan: time.Sleep(time.Second * 2) fmt.Println("The case intChan ok: ", ok) fmt.Println("The case intChan is selected.", e) case e, ok := <-strChan: time.Sleep(time.Second) fmt.Println("The case strChan ok: ", ok) fmt.Println("The case strChan is selected.", e) } } }
If I comment out the close()
function, the "for" statement will be blocked, as the error says "all goroutine are sleep - deadlock!", which seems reasonable.
If I uncomment close()
, the "for" statement never stops. The receiver gets the default values 0 and nil from the channel and never blocks.
Even though I'm not sending anything to the channel and calling close()
after defining the channel. The receiver will never block or cause any errors.
I'm confused about what the close
function does, does it start a go routine that sends a specific type of default value to the channel, and never stops?
When the channel is closed, you can still read it, but your ok
will be false. So, that's why your for
never stops. And, you need to break the for
statement with a condition if !ok {break }
.
When the channel is not closed, when you try to read data from it, it will be blocked or not, depending on the buffered/unbuffered channel.
Buffer channel: You specify the size (make(chan int, 1)
).
Unbuffered channel: You did not give a size (make(chan int)
)
In the case of your comment close
it will read the data once from your buffered channel because you pass intchan <- 3
and strchan < - "hello"
Send data to the channel. Therefore, you will see the following results printed by the console.
send the case strchan ok: true the case strchan is selected. hello the case intchan ok: true the case intchan is selected. 3
However, after this, both buffer channels no longer have data. Then if you try to read it you will be blocked because there is no data in the buffered channel. (In fact, no buffering is also the case when there is no data.)
Then, you get all goroutine are sleep - deadlock
because the main goroutine is blocked waiting for data from the channel. By the way, when you run this program, it starts a main goroutine to run your code. If only one main goroutine is blocked, that means no one can help you run your code.
You can add the following code before the for statement.
go func() { fmt.Println("another goroutine") for {} }()
You will find that you do not encounter a deadlock because there is still a goroutine that "might" run your code.
The above is the detailed content of Receiver goroutine never blocks when golang closes channel. For more information, please follow other related articles on the PHP Chinese website!