Panics in Go are triggered when the program cannot handle an error properly, such as invalid memory access. It can also be triggered by the developer if the error is unexpected and there is no other way to deal with it. Understanding the process of recovery or termination can be useful to understand the consequences of a panicking program.
The classic example for a panic and its recover function is well documented, including by the Go blog in “Defer, Panic, and Recover.” …
A goroutine leak can easily be detected via an APM that monitors the number of live goroutines. Here is an example from NewRelic of a graph that monitors the goroutines:
A leak would lead to a continuous increase of this number until the server crashes. However, there are ways to prevent leaks even before the code is deployed.
The Go team at Uber, which is very active on Github, made their goroutine leak detector, a tool that aims to be integrated with the unit tests. …
ℹ️ This article is based on Go 1.14.
The Go standard library dedicates a thread to watch after your application and help with bottlenecks your program could face. This thread, called
sysmon, stands for system monitor, is not linked to any
P in the G,M,P model, meaning it is not taken into account in the scheduler and therefore is always running. Here is an updated diagram with this special thread:
For more information about the G, M, P model, I suggest you read my article “Go: Goroutine, OS Thread and CPU Management.”
Also, you will not see this thread in the traces via the Go tool