Receiver goroutine never blocks when golang closes channel
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?
Correct Answer
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!

Hot AI Tools

Undresser.AI Undress
AI-powered app for creating realistic nude photos

AI Clothes Remover
Online AI tool for removing clothes from photos.

Undress AI Tool
Undress images for free

Clothoff.io
AI clothes remover

AI Hentai Generator
Generate AI Hentai for free.

Hot Article

Hot Tools

Notepad++7.3.1
Easy-to-use and free code editor

SublimeText3 Chinese version
Chinese version, very easy to use

Zend Studio 13.0.1
Powerful PHP integrated development environment

Dreamweaver CS6
Visual web development tools

SublimeText3 Mac version
God-level code editing software (SublimeText3)

Hot Topics

This article explains Go's package import mechanisms: named imports (e.g., import "fmt") and blank imports (e.g., import _ "fmt"). Named imports make package contents accessible, while blank imports only execute t

This article details efficient conversion of MySQL query results into Go struct slices. It emphasizes using database/sql's Scan method for optimal performance, avoiding manual parsing. Best practices for struct field mapping using db tags and robus

This article explains Beego's NewFlash() function for inter-page data transfer in web applications. It focuses on using NewFlash() to display temporary messages (success, error, warning) between controllers, leveraging the session mechanism. Limita

This article explores Go's custom type constraints for generics. It details how interfaces define minimum type requirements for generic functions, improving type safety and code reusability. The article also discusses limitations and best practices

This article demonstrates creating mocks and stubs in Go for unit testing. It emphasizes using interfaces, provides examples of mock implementations, and discusses best practices like keeping mocks focused and using assertion libraries. The articl

This article details efficient file writing in Go, comparing os.WriteFile (suitable for small files) with os.OpenFile and buffered writes (optimal for large files). It emphasizes robust error handling, using defer, and checking for specific errors.

The article discusses writing unit tests in Go, covering best practices, mocking techniques, and tools for efficient test management.

This article explores using tracing tools to analyze Go application execution flow. It discusses manual and automatic instrumentation techniques, comparing tools like Jaeger, Zipkin, and OpenTelemetry, and highlighting effective data visualization
