Goroutine Vs Thread
Fast recall
Quick revision
Core answer
Whether you understand Goroutine Vs Thread beyond memorized syntax.
Giving a definition without explaining a practical trade-off.
Connect the concept to a small production example and state its complexity or failure mode.
Interview-ready guide
Interview answer
A goroutine is a function running concurrently under the Go runtime's management; an OS thread is the kernel's unit of scheduling. The Go scheduler multiplexes many goroutines onto few OS threads — M:N scheduling — and that's the entire difference in one sentence. Everything practical follows:
Cost: a goroutine starts with a ~2KB stack (grows/shrinks as needed); an OS thread commits ~1-8MB of stack plus kernel bookkeeping. Executed proof: starting and finishing 100,000 goroutines took ~90ms on a modest machine — try 100,000 threads and the machine falls over (thread limits, scheduler collapse, memory).
Scheduling: the Go scheduler runs in userspace — goroutine switches are function calls the runtime makes (hundreds of nanoseconds), no kernel involvement. Thread switches go through the kernel (microseconds, plus cache pollution). The Go scheduler also switches at channel operations and function calls — places where a goroutine is about to block anyway — making the common case cooperative and cheap.
Blocking behavior: a goroutine blocking on a channel or syscall doesn't block its OS thread (the runtime parks the goroutine and moves the thread to other work — or spins up another thread for the syscall). A blocked OS thread IS blocked, consuming its resources.
Scale: because of all the above, Go code routinely runs servers with hundreds of thousands of concurrent goroutines — one per connection — which is the architectural style the whole ecosystem (net/http) is built around. The answer interviewers want is the M:N model with the cost numbers that make the concurrency style viable.
// 100,000 goroutines on one modest machine — executed in 92ms:
var wg sync.WaitGroup
for i := 0; i < 100000; i++ {
wg.Add(1)
go func() { defer wg.Done() }()
}
wg.Wait() // 100k stacks ≈ 200MB; 100k OS threads would need ~100GBGoroutine Vs Thread
Direct Answer
Goroutines are runtime-managed, multiplexed onto OS threads by the Go scheduler — ~2KB stacks, cheap creation (100k in ~90ms). OS threads are kernel-managed, ~1-8MB stacks, expensive creation. You don't run 100k OS threads on one machine.
Deep Dive & Architecture
The mechanical contrast, layer by layer:
Creation: a goroutine is a runtime bookkeeping entry — a struct with a stack pointer and state, linked into a scheduler queue. ~2KB of committed stack to start. A thread creation goes to the kernel: allocate kernel structures, a full stack region (megabytes), register with the scheduler — orders of magnitude more work and memory.
Switching: goroutine switches happen in userspace at scheduler points — channel operations, blocking calls, function-entry preemption checks. The switch is a few hundred bytes of register save/restore plus a stack pointer swap — no kernel transition, no address-space effects, cache still warm. Thread switches trap into the kernel: microsecond-scale, cache-flushing, bookkeeping-heavy.
Blocking: the Go runtime parks a goroutine at a channel send and the underlying thread moves on to another goroutine — the thread never idles. An OS thread that blocks on something without a non-blocking alternative parks in the kernel, doing nothing until woken.
Multiplexing: GOMAXPROCS goroutines run truly in parallel (that many threads busy); thousands more sit parked in queues costing only their stacks. That's the M:N shape: M goroutines over N threads, with the runtime (not the kernel) deciding the mapping — and having the information the kernel never has (which goroutines are waiting on which channels, which stacks can move).
The 100k-goroutine proof this all enables: 92ms wall time to spawn and complete 100,000 of them on one modest core-count box — under a microsecond each, most of it stack allocation. The same program with OS threads would hit ulimit and memory walls four orders of magnitude earlier.
Common Mistakes & Pitfalls
Giving a definition without explaining a practical trade-off.
Check your understanding
Answer these without looking back at the article.
- When would you use Goroutine Vs Thread in a real project?
- What is a common mistake when using Goroutine Vs Thread?
- How would you compare Goroutine Vs Thread with an alternative?
Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.