How much stack does a new goroutine start with, and what happens when it needs more?

## Why the number matters The reason Go programs can start goroutines so freely is that a goroutine is cheap in exactly the place threads are expensive: **stack memory**. A new goroutine begins with a stack of about **2 KB**, plus a small runtime structure holding its scheduling state. A typical OS thread reserves stack address space measured in megabytes when it is created. That difference is what turns "start one goroutine per unit of work" from a stunt into an idiom. ```go for _, h := range hosts { // hosts holds 100,000 names go check(h) // ~2 KB of stack each to begin with } ``` This is a normal thing to write in Go (whether it is a *good* thing depends on what `check` does downstream, which is a separate question about bounding concurrency). ## Growing Goroutine stacks are **contiguous and growable**. The mechanism has two halves: - **The check.** The compiler emits a small comparison at the top of most functions: does the frame this function needs fit in the remaining stack? Leaf functions with tiny frames can skip it. - **The copy.** If it does not fit, the runtime allocates a new stack — larger, usually double the old size — copies the existing frames into it, and then fixes up every pointer that pointed into the old stack so it points at the corresponding place in the new one. The goroutine then resumes as if nothing had happened. The fix-up step is why Go can move stacks at all: the runtime knows, from compiler-generated metadata, exactly which words in a frame are pointers. A language that cannot identify pointers precisely cannot relocate a stack, which is why this design is not universal. ## Shrinking The growth is not permanent. During garbage collection the runtime may **shrink** a goroutine's stack if it is using far less than it currently holds, copying the frames down into a smaller allocation. A goroutine that once recursed deeply and now sits in a loop does not keep paying for the peak forever. ## The ceiling Growth is not unbounded. The runtime enforces a maximum stack size per goroutine; `runtime/debug.SetMaxStack` reads and sets it. Infinite recursion therefore does not consume all of memory — it hits the ceiling and the program dies with a fatal `stack overflow` error and a dump. Note this is a *fatal* runtime error, not a panic you can recover from. ## What this buys the scheduler Cheap stacks are what make blocking cheap. Because a parked goroutine costs only its (often still small) stack plus bookkeeping, the runtime can afford to have a great many goroutines blocked on channels, mutexes and network I/O at once, and to park them rather than blocking OS threads. That is the practical reason a straightforward blocking style — "write it as if it were sequential, and start a goroutine per unit of work" — is idiomatic Go rather than a performance trap. ## What it does not mean Two cautions worth voicing in an interview: - **2 KB is a floor, not a budget.** A goroutine whose work allocates large buffers, or recurses, uses far more. Estimating memory as "goroutines times 2 KB" is wrong for anything but idle goroutines. - **Cheap does not mean free.** Each goroutine still costs a stack that survives as long as the goroutine does, plus scheduler bookkeeping. A million goroutines blocked forever is still a large amount of live memory that the garbage collector must scan, which is precisely why goroutines that never finish are a problem worth taking seriously. ## Answering crisply "About 2 KB, heap-allocated by the runtime and grown by copying when a prologue check finds it too small, shrunk again during GC, with a hard ceiling you can set through `runtime/debug.SetMaxStack`. That is why a `go` statement in a loop over a hundred thousand items is unremarkable, whereas a hundred thousand OS threads is not."