The leak is from the unclosed channel. In the particular example in the article, the leaked goroutine is attempting to write to the unclosed channel which is a

The leak is from the unclosed channel. In the particular example in the article, the leaked goroutine is attempting to write to the unclosed channel which is a good example for using the `context` package. [0] But, if the leaked goroutine was blocking while attempting to read from an unclosed channel, then you could simply `close(channel)` and this would cause the goroutine to return. [1] [0] https://play.golang.org/p/FDfZZfdXgMC https://play.golang.org/p/FDfZZfdXgMC [1] https://play.golang.org/p/cr7JzIdRDjR https://play.golang.org/p/cr7JzIdRDjR EDIT: I am making this comment to emphasize that goroutines pretty much only leak because of unclosed channels. So, it might be a little difficult to justify manual (or even automated) static analysis for leaked goroutines unless you have channel spaghetti. But, channel spaghetti is a sign of faulty design.