The characteristic point of the nil channel close channel in the Golang channel

This is a creation in Article, where the information may have evolved or changed.

English original

C1. The following actions can cause panic

• P1. Closing the nil channel.

Instance:

func C1P1() {    var ch chan int    close(ch)}

Results

panic: close of nil channelgoroutine 1 [running]:panic(0x458300, 0xc82000a170)        /home/wdy/go/src/runtime/panic.go:464 +0x3e6main.main()        /home/wdy/learn/program-learn/golang/learnchannel.go:27 +0x1eexit status 2

• P2. Closing a closed channel.

Instance:

func C1P2() {    ch := make(chan int, 0)    close(ch)    close(ch)}

Results:

panic: close of closed channelgoroutine 1 [running]:panic(0x458300, 0xc82000a170)        /home/wdy/go/src/runtime/panic.go:464 +0x3e6main.main()        /home/wdy/learn/program-learn/golang/learnchannel.go:27 +0x4dexit status 2

• P3. Sending on a closed channel.

Instance:

func C1P3() {    ch := make(chan int, 0)    close(ch)    ch <- 2}

Results:

panic: send on closed channelgoroutine 1 [running]:panic(0x458300, 0xc82000a170)        /home/wdy/go/src/runtime/panic.go:464 +0x3e6main.main()        /home/wdy/learn/program-learn/golang/learnchannel.go:23 +0x6cexit status 2

C2. As the recipient of the Goroutine do not close the channel, otherwise the sender will send data to the channel in the future panic

C3. If a channel has multiple senders, the sender does not close the channel or the last goroutine to send the data.

Last one sender to leave, turns off the lights, which can is controlled by a atomic int

C4. For channels that are no longer used, do not show off. If there is no goroutine reference to this channel, the channel will be garbage collected.

Note that if you need to turn off the channel as a control signal to tell other goroutine that there is no more data, you need to show off. Discuss

C5. Channels and select are best paired.

C6. If you need a two-way communication in two goroutine, consider using two separate unidirectional channels. This allows two channels to tell the other party that the communication is terminated by calling close.

C7. If the channel is not responsible for reading the goroutine, then the sender may block forever on that channel.

C8. When designing a goroutine to provide services through the channel, at some point the goroutine no longer needed, think carefully about how goroutine should end. Otherwise, the unused goroutine will serve an unregulated channel.

C9. Dave Cheney ' s four Channel axioms:

• A1. Performing a send operation on a nil channel is always blocked.

Instance:

func C9A1() {    fmt.Println("C9A1")    var ch chan int    ch <- 2}

Results:

C9A1fatal error: all goroutines are asleep - deadlock!goroutine 1 [chan send (nil chan)]:main.C9A1()        /home/wdy/learn/program-learn/golang/learnchannel.go:27 +0xf9main.main()        /home/wdy/learn/program-learn/golang/learnchannel.go:37 +0x14exit status 2

• A2. Performing an accept operation on a nil channel will always block. Sample Example

Send:

func C9A2() {    fmt.Println("C9A2")    var ch chan int    <-ch}

Results:

C9A2fatal error: all goroutines are asleep - deadlock!goroutine 1 [chan receive (nil chan)]:main.C9A2()        /home/wdy/learn/program-learn/golang/learnchannel.go:33 +0xecmain.main()        /home/wdy/learn/program-learn/golang/learnchannel.go:38 +0x14exit status 2

• A3. Sending to the closed channel will cause panic

• A4. From the closed Cannel read operation, the data 0 value is returned immediately.

C10. ' SELECT ' Never chooses to block the case, meaning that if multiple options are blocked, the current goroutine will block on the select.

Postscript

has been in the csdn to write articles, the latter will be gradually converted to the book, but also ask you to support a lot.