Avoid Goroutine Leaks and Race Conditions in Go: Proven Patterns

1 Goroutine Leak Issues

Rob Pike's 2012 Google I/O talk introduced basic concurrency patterns, such as returning the first result from multiple replicas. The example First uses an unbuffered channel, causing goroutine leaks when more than one replica is invoked because other goroutines block on send.

Solution: use a buffered channel sized to the number of replicas, or a select with a default case to avoid blocking, or a dedicated cancellation channel to stop workers.

2 Goroutine Race Conditions

Goroutine misuse often leads to race conditions, especially when a goroutine modifies shared data like a pointer argument. The example with saveRequest spawns a goroutine that mutates request, violating Go's “share memory by communicating” principle.

The official Go race detector example shows a hidden race between a timer goroutine and the main goroutine accessing the same time.Timer variable.

A safe pattern is to encapsulate mutable state in a single goroutine and communicate via channels. The SimpleAccount type is not safe for concurrent use, while the ConcurrentAccount wrapper routes all operations through channels to a dedicated listener goroutine, eliminating races.

By serializing access through channels, only one goroutine manipulates the underlying data, ensuring thread‑safe behavior.

Link: https://www.cnblogs.com/zhangboyu/p/7456629.html