Blocking profiler
Blocking profiler shows periods when goroutines are not running but waiting. It is useful for identifying bottlenecks caused by unbuffered or full channels, sync.Mutex locks, or other synchronization issues.
GoLand collects and visualizes CPU profiles, traces, and heap profiles. To collect all the necessary data, GoLand uses the pprof package. GoLand includes four profilers that you can run from the user interface: CPU, memory, blocking (contention), and mutex.
Profiling results help you locate performance issues, but code improvements must be implemented manually. For more information, see the Profiling at go.dev and the description of the pprof package at pkg.go.dev.
After the analysis is complete, the profiler visualizes the results in reports.
Before you start
Before running a profile, make sure that:
Go is installed, you can install, upgrade, or configure Go by using the GOROOT article. For more information, refer to GOROOT.
GoLand is installed on your machine.
The Go project you want to profile is open in the IDE.
All examples in this topic are available in a sample project on GitHub.
Blocking profiling
The blocking profiler helps you detect delays caused by goroutines waiting on unbuffered channels, synchronization primitives, or other blocking operations. It shows when and where your code spends time waiting instead of executing.
Example program
The following program simulates a producer that sends values through a channel and a slow consumer that processes them one by one. Because the consumer is slower, the producer often gets blocked while trying to send new data:
Running this code produces output immediately, but internally, the producer goroutine frequently pauses while waiting for the consumer to become ready.
Create a test for profiling
To analyze blocking behavior, create a unit test for the program:
Run blocking profiler
Open the _test.go file.
Click the Run icon next to the test function in the gutter.
Select Profile with Blocking Profiler.

Analyze blocking profiling results
GoLand presents blocking profiling data in three views:
Flame graph: displays function calls and the amount of time goroutines spend waiting (not running). Each block represents a function in the stack. The Y-axis shows the stack depth (bottom-up), while the X-axis represents the stack profile sorted in ascending order — either by the number of delays (Contentions selected) or by total waiting time (Delay selected).
In the Flame Graph tab, hover over any block to view detailed information.
Call tree: visualizes how functions call each other, showing either the number of delays (Contentions) or the total waiting time (Delay) for each function. The data is organized in descending order to highlight the most time-consuming operations first. To configure or filter the Call Tree view, use the Presentation Settings button
.
Method list: lists all methods sorted by the number of contentions. The Back Traces tab shows where the selected method was called, while the Merged Callees tab displays all call traces originating from the selected method. Callee List is the method list summarizing the methods down the call hierarchy.
Optimize and compare results
To fix the blocking issue, you can use a buffered channel so that the producer can send several values before the consumer catches up:
After rerunning the blocking profiler, the flame graph shows fewer blocking events and shorter waiting durations. This confirms that buffering the channel helps reduce synchronization delays.

Compare the usage of the buffered channel with the previous implementation.
