Goroutines
A goroutine is a lightweight function managed by Go's own runtime scheduler rather than the operating system, letting a single program run hundreds of thousands of concurrent tasks cheaply instead of the handful an OS thread model allows.
Why it exists
A server handling many thousands of simultaneous connections needs a way to run that many tasks concurrently, but a real operating system thread costs megabytes of stack space and real kernel scheduling overhead, so spawning one thread per connection stops working at any real scale. Goroutines exist so a Go program can express that same one-task-per-unit-of-work model, without a programmer hand-rolling callback chains or a thread pool, while staying cheap enough to spawn by the hundreds of thousands.
The mental model
A goroutine is a lightweight ticket handed to Go's own scheduler that says run this whenever you get a chance, rather than a request to the operating system for a dedicated worker. Go's runtime multiplexes many of these tickets onto a small number of real OS threads, the way many passengers share a handful of taxis instead of each getting a private car, so concurrency stops being limited by how many threads the OS can afford to hand out.
How it works
Starting a goroutine with the go keyword begins it with an initial stack of roughly 2 kilobytes that grows and shrinks as needed, far smaller than a typical fixed multi-megabyte OS thread stack. Go's M:N scheduler maps M goroutines onto N OS threads, cooperatively switching between goroutines at function calls, channel operations, and other safe points, so thousands of goroutines can make progress on just a handful of real threads. GOMAXPROCS controls how many OS threads can execute Go code at once. Goroutines are meant to coordinate through channels rather than shared memory guarded by locks, following Go's own mantra of sharing memory by communicating instead of communicating by sharing memory.
When it matters
It matters for any server or workload that fans out into many simultaneous, mostly idle tasks, like handling concurrent network connections. The footgun is that goroutines can leak: one blocked forever reading from a channel nobody will ever write to just sits there consuming its stack for the life of the program, since Go has no forced cancellation, only cooperative signaling through a context or a closed channel.
A concrete example
Go's net/http package spawns one goroutine per incoming request automatically. Serving 10,000 simultaneous slow requests costs only tens of megabytes of total goroutine stack space, work that would demand 10,000 real OS threads and many gigabytes of stack in a naive thread-per-request server.
Interview question
A Go server spawns a goroutine per incoming request, and one handler blocks forever reading from a channel that nothing will ever write to. What happens to that goroutine?
- a.The Go runtime automatically kills any goroutine blocked for more than a few seconds to prevent leaks
- b.It stays alive indefinitely, quietly consuming its stack memory, because Go never force-cancels a blocked goroutine on its ownCorrect
- c.The program crashes immediately with a deadlock error as soon as one goroutine blocks on a channel
- d.Go's garbage collector detects the unreachable goroutine and frees it the next time it runs
Why? this is the answer
Go has no automatic timeout or forced cancellation for a blocked goroutine, so it simply stays parked, leaking its stack, until the process exits or something explicitly unblocks it. The runtime does not kill it after a timeout, a single blocked goroutine does not crash the whole program since Go only reports a deadlock when every goroutine is blocked at once, and the garbage collector does not collect a goroutine that could still be unblocked.
Just read this? Test yourself on what you have been reading.
Read the original → go.dev
- #go
- #goroutine
- #concurrency
- #source-mismatch
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on go — each one lists the topics its interview covers.
See open roles