Go Concurrency

A goroutine is a lightweight function managed by the Go runtime, not the OS. The runtime multiplexes many goroutines onto a few OS threads, so they start with a tiny stack and switch in user space without a kernel context switch.

GOMAXPROCS sets the number of P's — logical processors — so it caps how many goroutines run Go code in parallel at once. It defaults to the number of CPU cores and does not limit how many OS threads the runtime may create overall.

A goroutine starts with a small stack of about 8 KB. When a function would overflow it, the runtime allocates a larger contiguous stack, copies all frames over, fixes up pointers, and frees the old one — so growth happens by copying, not by linking segments.

A context switch saves one execution's state (stack pointer, registers, instruction pointer) and loads another's. An OS-thread switch traps into the kernel, which is expensive. The Go scheduler switches goroutines in user space without a kernel trap, so it only restores the goroutine's stack and program counter — far cheaper, though not free.

G is a goroutine — the unit of work. M is an OS thread, the only thing that can actually run code. P is a logical processor: a scheduling context holding a run queue. An M must hold a P to execute Go code, and the P count is GOMAXPROCS.

By default the runtime sets GOMAXPROCS to the host's logical CPU count, not the container's cgroup CPU quota. On a 64-core host capped at 2 cores it runs 64 Ps, so the kernel CFS throttles the process — latency spikes and wasted context switches. Fix: set it to the quota or use automaxprocs.

Each goroutine is a runtime g struct, not an OS thread. It holds its own growable stack with bounds, a gobuf saving the program counter and stack pointer so it can be paused and resumed, a status, an id, and scheduling links.

The netpoller is the runtime's event-based bridge to the OS readiness API (epoll, kqueue, IOCP). When a goroutine blocks on network I/O the runtime parks it and registers the fd with the netpoller, freeing the M to run others; when the fd is ready the poller marks the goroutine runnable.

A per-P local queue is owned by one P, so most operations need no lock and stay cache-local. The shared global queue needs a lock; it holds goroutines that overflow from full local queues and is polled periodically so they are not starved.

When a P's local run queue empties, its M tries the global queue, then steals from another randomly chosen P, taking about half of that victim's local queue. This keeps every P busy and balances load without a central dispatcher.

Since Go 1.14 the runtime uses asynchronous preemption: the sysmon thread sends the goroutine's M a signal (SIGURG). The signal handler stops the goroutine at a safe point and reschedules it, so a loop with no calls no longer monopolizes its P.

Each blocking file read keeps its M stuck in the kernel, so the runtime must spin up or grab a fresh M to keep the handed-off P busy — N concurrent file reads pin up to N threads. A socket read parks the goroutine and registers its fd with the netpoller instead, returning the M to the scheduler, so one M serves many waiting sockets and the thread count stays flat.

The M stays blocked in the kernel with that goroutine, but it first detaches its P. The sysmon thread (or the M itself) hands the freed P to another M — idle or newly created — so the P's run queue keeps executing other goroutines.