Golang Concurrency Tricks

最新推荐文章于 2024-07-17 11:46:10 发布

流泪的鱼

最新推荐文章于 2024-07-17 11:46:10 发布

阅读量516

点赞数

分类专栏： go 文章标签： golang

go 专栏收录该内容

33 篇文章 1 订阅

订阅专栏

Golang Concurrency Tricks

Golang concurrency model based on goroutines and channels is not free from sharp edges.

This page intends both (1) to collect helpful guidelines for writing concurrent code in Go and (2) to bring up well known potential issues to attention.

Channel Hints

C1. Some channel operations cause runtime panic:
- P1. Closing the nil channel.
- P2. Closing a closed channel.
- P3. Sending on a closed channel.
C2. Do not close a channel from a receiver goroutine. Closing the channel from a receiver could make future sender goroutines to panic.
C3. If a channel has multiple senders, do not close the channel from a sender goroutine. Closing the channel from a sender could make future sender goroutine to panic.

Alternatively, coordinate senders so that only the last sender to leave closes the channel (for instance by using either atomic int or sync.WaitGroup)
Last one sender to leave, turns off the lights, which can be controlled by a atomic int.
https://groups.google.com/d/msg/golang-nuts/LM648yrPpck/oZFSD-oMAwAJ
C4. It is not required to close an unused channel. If no goroutine is left referencing the channel, it will be garbage collected.
Note that it is only necessary to close a channel if the receiver is looking for a close. Closing the channel is a control signal on the channel indicating that no more data follows.
https://groups.google.com/forum/#!msg/golang-nuts/pZwdYRGxCIk/qpbHxRRPJdUJ
C5. Channels work well when enclosed in a 'select'.
If you are ever using a channel outside of a select in production code, you are probably doing it wrong.
https://groups.google.com/d/msg/golang-nuts/LM648yrPpck/j5eHsPc2AwAJ
C6. If you need bidirectional communication between two goroutines, consider using two unidirectional channels. Thus both channel sides will be able to use the close idiom to signal termination.
C7. Beware: one sender goroutine risks blocking indefinitely when writing on a channel if there is no goroutine left receiving from it.
C8. When designing a goroutine which provides service through channels, and at some point a running goroutine is no longer needed, consider exactly how it will finish. Otherwise, unused goroutines may leak idly servicing an unattended channel.
C9. Keep Dave Cheney's Four Channel Axioms in mind:
- A1. A send to a nil channel blocks forever.
- A2. A receive from a nil channel blocks forever. (Why? Here is why. Example.)
- A3. A send to a closed channel panics.
- A4. A receive from a closed channel returns the zero value immediately.
C10. 'select' never selects a blocking case.

Goroutine Hints

G1. Only one goroutine accessing a piece of data is good practice.
In particular, consider structuring your program so that only one goroutine at a time is ever responsible for a particular piece of data.
https://golang.org/doc/faq#What_operations_are_atomic_What_about_mutexes
G2. runtime.Goexit() terminates the goroutine that calls it.