27 reasons why Goroutine hangs

• waitReasonZero: No official explanation, judging from usage. Mainly used in two scenarios: sleep and lock.
• waitReasonGCAssistMarking: The GC auxiliary marking phase will cause blocking waiting.
• waitReasonIOWait: When IO is blocked and waiting, for example: network request, etc.

Part 2

• waitReasonChanReceiveNilChan: Read the uninitialized channel.
• waitReasonChanSendNilChan: Write to an uninitialized channel.

Part 3

• waitReasonDumpingHeap: When dumping the Go Heap heap, this usage scenario is only blocked during runtime.debug, which is the common pprof type of collection.
• waitReasonGarbageCollection: Triggered during garbage collection, the main scenario is the GC Mark Termination phase.
• waitReasonGarbageCollectionScan: During garbage collection scanning, the main scenario is triggered when the GC mark (GC Mark) scans the Root stage.

Part 4

• waitReasonPanicWait: Triggered when a panic occurs in main goroutine.
• waitReasonSelect: Triggered when calling the keyword select.
• waitReasonSelectNoCases: When calling the keyword select, if there is no case, it will be triggered directly.

Part 5

• waitReasonGCAssistWait: The end behavior in the GC auxiliary mark phase will be triggered.
• waitReasonGCSweepWait: The end behavior in the GC cleaning phase will be triggered.
• waitReasonGCScavengeWait: The end behavior of the GC scavenge phase will be triggered. GC Scavenge is mainly garbage collection of new space. It is a frequently running, fast GC that is responsible for cleaning up smaller objects from new space.

Part 6

• waitReasonChanReceive: Read operation on channel will trigger.
• waitReasonChanSend: Triggered when writing on channel.
• waitReasonFinalizerWait: Triggered at the end of the finalizer. In a Go program, you can set a finalizer function for an object by calling the runtime.SetFinalizer function. This behavior corresponds to the recycling caused by the end phase.

Part 7

• waitReasonForceGCIdle: Triggered when the forced GC (idle time) ends.
• waitReasonSemacquire: Triggered when semaphore processing ends.
• waitReasonSleep: classic sleep behavior, will be triggered.

Part 8

• waitReasonSyncCondWait: Combined with the sync.Cond usage, we can know that it is triggered when the sync.Wait method is called.
• waitReasonTimerGoroutineIdle: related to Timer, triggered when no timer needs to perform tasks.
• waitReasonTraceReaderBlocked: Related to Trace, ReadTrace will return binary trace data and will block until the data is available.

Part 9

• waitReasonWaitForGCCycle: Waiting for the GC cycle will sleep and cause blocking.
• waitReasonGCWorkerIdle: When GC Worker is idle, it will sleep and cause blocking.
• waitReasonPreempted: When a cyclic call preemption occurs, it will sleep and wait for scheduling.
• waitReasonDebugCall: Triggered when GODEBUG is called.

Summary

Today’s article is a supplement to the detailed explanation of the runtime.gopark function at the beginning. We can learn about it. inducing factors.

The main scene is:

1. Channel.
2. Garbage collection (GC).
3. Sleep.
4. Lock waiting (Lock).
5. Preempted.
6. IO blocking (IO Wait)
7. Others, such as: panic, finalizer, select, etc.

We can use these characteristics to dismantle the reasons that may cause blocking. In fact, there is no need to remember it. They will cause blocking because there are factors that affect the control flow, which will lead to the call of gopark.