DEV Community: Codebaker

Inside the Go Scheduler: How GMP Model Powers Millions of Goroutines

Codebaker — Mon, 30 Mar 2026 10:48:00 +0000

Introduction

A common question developers ask when learning Go is: "Why goroutines when threads already work?" Take Java, for example—each client request is executed on an OS thread. Simple, straightforward, and battle-tested. So why did Go introduce this additional abstraction?
The answer lies in scalability and efficiency. While OS threads are powerful, they're also heavyweight—creating thousands of them can overwhelm a system. Goroutines, on the other hand, are lightweight and managed by Go's runtime, allowing you to spawn millions without breaking a sweat. But this raises another question: how does Go efficiently map thousands of goroutines onto a limited number of OS threads?
This is where Go's ingenious GMP scheduling model comes into play.

The Challenge: Mapping Goroutines to Threads

OS threads are maintained by the operating system, which means the OS only knows about threads, not goroutines. Therefore, a goroutine must be mapped onto a thread to execute. This implies M:N mapping. At any given time, one thread handles one goroutine.
But how should this mapping occur? Let's explore two approaches and their problems:

Approach 1: A Single Global Queue

Idea: A single global queue where threads push and pull goroutines concurrently.
Problem: This creates lock contention on the global queue. Each thread must acquire a lock, push or pull a goroutine, and then release the lock. Under high goroutine throughput, every thread is constantly fighting over the same queue. Each thread has to:

Acquire a lock on the global queue
Pull/Push a goroutine in the queue
Release the lock

Approach 2: A Local Queue Per Thread

Idea: Give each thread its own local queue, eliminating contention on a shared structure.
Problem: Two issues arise. First, if a goroutine makes a blocking system call, the OS blocks that thread — all goroutines waiting behind it are now stuck, even though the CPU is free. Second, load becomes unbalanced: one thread's queue may hold 100 goroutines while another's is empty, and there is no rebalancing mechanism.

The Solution: The GMP Scheduling Model

The Go developers devised an elegant solution called the GMP scheduling model, which cleverly avoids these bottlenecks. The model consists of three key components:
The Three Components:

G (Goroutine) - The lightweight thread of execution
M (Machine) - An OS thread (the term "Machine" is used in Go's runtime)
P (Processor) - Not a CPU, but a logical processor that acts as a middleman.

Important: There is still a global run queue in the GMP model, but it's not the primary queue. It is used as a secondary queue.

What is a Processor (P)?
Instead of assigning queues directly to threads, Go uses distributed run queues owned by Ps. Each P maintains its own local run queue that holds multiple goroutines. Think of P as a scheduling context that bridges goroutines and threads.
Key relationships:

Each P maintains a local run queue of goroutines
Each P is attached to an M (OS thread)
P controls the parallelism in your program

Understanding GOMAXPROCS: Tuning the Engine's Parallelism

When are Goroutines and Threads Created?

Goroutines (G) are created as per your code instructions (e.g., go functionName())
Threads (M) are created by the scheduler when needed.

Here's the crucial insight: P controls parallelism. The number of Ps determines:

The number of local run queues
The maximum number of goroutines that can run in parallel
The number of threads (Ms) required

The GOMAXPROCS Setting
GOMAXPROCS determines the number of Ps in your program, and it can be manually configured.
Example scenario:

System: 2 CPU cores
Goroutines: 16 created
Setting: GOMAXPROCS = 4

What happens:

4 Ps are created → 4 local run queues
Goroutines are distributed across queues (e.g., 4 goroutines per queue)
4 Goroutines can run in parallel.
The Go runtime requests 4 Ms (threads) from the OS
Each P attaches to an M

The problem: With only 2 CPU cores but 4 threads, the OS must perform context switching between threads at the kernel level, which is relatively expensive.

Best practice: Set GOMAXPROCS = number of CPU cores (this is also the default in modern Go).

Thread Management: Creation, Parking, and Reuse

The scheduler doesn't always create new threads. Here's how Go optimizes thread management:
Scenario 1: Blocking System Call
When a goroutine makes a blocking system call:

The goroutine (G) is blocked
The OS marks the thread (M) executing it as blocked
The local run queue (P) needs to be attached to a thread
The runtime detaches the P from the blocked M — this is called a P Handoff
A new M is created and attached to P to continue running other goroutines.
When the blocking call completes:
- The unblocked G is placed into a randomly chosen local run queue
- The M is parked (not destroyed) to save CPU overhead

Scenario 2: Subsequent Blocking Call
When another goroutine makes a blocking system call:

Again, the local run queue needs attachment to M
This time, no new M is created
Instead, the parked M is reused, saving creation overhead

This parking and reusing strategy significantly reduces the overhead of thread management.

Scheduling Goroutines:

Scheduling loop:

When P needs to assign a G to the attached M, runtime runs this loop:

a. Every 61st goroutine — check global queue first — If a goroutine is found in the global queue, run it. If empty, proceed to b.
b. Check local queue — The P checks its own local queue. If a goroutine is found, run it. If empty, proceed to c.
c. Check global queue — Checked when local queue is empty (skipped if already checked in step a). If a goroutine is found, run it. If empty, proceed to d.
d. Work Stealing — Steals up to half the goroutines from another P. The runtime visits all Ps in a random order and stops when it finds a victim with stealable goroutines.
e. Checks the network poller - Runtime checks if any I/O bound goroutine is ready to resume.

What is network poller - When Goroutine does non-blocking syscall, then the runtime parks the Goroutine, and registers the file descriptor with the netpoller. The M that was executing the Goroutine is not blocked (unlike with blocking syscalls), and it picks up another runnable Goroutine. When the file descriptor is ready, netpoller unparks the Goroutine into a run queue. Examples of non-blocking sys-calls are: net.Dial(), net.Listen() etc.

Cooperative Scheduling:

Go was primarily designed for backend systems that rely heavily on channels, function calls, and I/O. These naturally act as yield points where the scheduler can switch goroutines:

Channel send/receive
System calls
Function calls

This is Cooperative Scheduling, happening entirely within the Go runtime.

The Problem: CPU-Bound Goroutines
A goroutine with no yield points — such as a tight infinite loop — will never cooperate:

func monopoly() {
    for {
        x++ // no function calls, no channel operation — never yields
    }
}

Before Go 1.14, this goroutine would monopolize its P indefinitely, starving every other goroutine in the same local queue.

Preemptive Scheduling (Go 1.14+)

Go 1.14 introduced signal-based preemption as a fallback for CPU-bound goroutines.
The mechanism is driven by sysmon — a background thread that runs without a P, continuously monitoring the scheduler. When sysmon detects a goroutine has been running for approximately 10ms without yielding:

Sysmon sends SIGURG to the M running that goroutine
The Go runtime's signal handler fires and hijacks execution
The goroutine is paused, marked runnable, and placed back in its local queue
The M proceeds to the next goroutine

Timer-based preemption only kicks in for goroutines that never reach a yield point.

Key Takeaways

Distributed Scheduling: Per-P local queues eliminate global lock contention, allowing threads to pick work independently.

Thread Efficiency: Threads (Ms) are parked and reused rather than destroyed, significantly reducing creation overhead.

P Handoff: During blocking syscalls, the P detaches from the blocked M and attaches to a new or parked M to keep other goroutines moving.

Work Stealing: Idle Ps automatically balance the load by stealing half the tasks from a randomly selected P.

Starvation Prevention: The 61-tick rule ensures the global queue is periodically prioritized so no goroutine is left behind.

Hybrid Scheduling: Combines Cooperative yielding at natural code points (I/O, channels) with Signal-based preemption (via sysmon and SIGURG) for long-running CPU tasks.

This design allows Go programs to efficiently manage millions of goroutines with only a handful of OS threads, giving you the simplicity of synchronous code with the performance of asynchronous systems.

From Deadlock Hell to Worker Pool Heaven: A Go Journey

Codebaker — Thu, 19 Mar 2026 18:07:46 +0000

This script is going to make you control your code's concurrency.
Hi! This is going to be my meticulous attempt to incite the interest and curiosity that piqued in me too, while I was exploring Concurrency patterns in Golang. It delineates the key idea behind controlled concurrency, provides deadlock insights, discusses optimisations & presents a correct concurrency control pattern.

Prerequisite:

Knowledge of Golang syntax, how concurrency works & slight theoretical knowledge of how channels in Go work is useful to get the comprehensive guide work out for you.

Would you like to give some thoughts over this question before we start?

Ask yourself: Suppose you have 100,000 goroutines working concurrently, and they all do some CPU work, some DB call, some network I/O, what happens?
... What happens to the Memory usage, the GC pressure? What happens to the External system(eg. DB)?

Let's mentally simulate this:
Each Goroutine starts small (nearly 2KB stack) but 100K -> 200MB+ stack space quickly;
There can be many variables allocated in the Heap or they escaped to the heap (Go's Escape Analysis);
The DB connection pool can exhaust, Queries to the DB queue up, Multiple timeout and retries to the DB occur.

What issues arise from this?

Large no. of Goroutines => Scheduler overhead is more. While goroutines are "cheaper" than threads, still the scheduler needs to find the runnable goroutines to schedule them to the CPU.
200MB+ space in modern servers, sounds manageable, but the danger lies at the heap level. The GC has to mark the "simultaneous live objects in the heap" and "CPU Stealing" can occur, which means, the GC takes up CPU time away from the application logic.
If the DB has let's say a connection pool of 100, but 100k goroutines try to query it, 99,900 goroutines will block waiting for a connection. This creates a long queue, thereby again consuming memory.

You see, this can cause the system to collapse. Therefore, we need to limit the no. of concurrent goroutines. And, so let's introduce Worker Pools.

Let us take a working example to gradually ramp up our understanding on worker pools:

Take 2 Unbuffered channels - Jobs & Results => In a gist, unbuffered channel works like this - Sender on the channel is blocked until receive happens, OR Receiver is blocked until a send happens.
Consider the Main Goroutine is both the producer to the Jobs channel and the consumer to the Results channel.
3 worker goroutines (let's say G1, G2, G3) consume on the Jobs channel and produce on the Results channel.
Apart from these goroutines, we have a Listener Goroutine that closes the Results channel as soon as all the worker goroutines execute their exit code (implemented using WaitGroup wg)

package main

import (
    "fmt"
    "sync"
    "strings"
    "strconv"
)

type Job struct{
    Id  int
    Url string
}

type Result struct{
    JobId   int
    Url     string
    StatusCode int
    Err     error
}

func main(){
    /*
        Unbuffered channels - jobs and results
        jobs := make(chan Job)
        results := make(chan Result)
    */

    jobs    := make(chan Job)
    results := make(chan Result)

    var wg sync.WaitGroup 

    for i := 1; i <= 3; i++{
        wg.Add(1)
        go worker(jobs, results, &wg) // 3 worker goroutines spawned
    }

    urls := [5]string{
    "https://httpbin.org/status/200",
        "https://httpbin.org/status/404",
        "https://httpbin.org/status/500",
        "https://httpbin.org/delay/1",
        "https://httpbin.org/status/200",
    }
    for i, url := range urls{  // Main produces jobs
        jobs <- Job{Id: i+1, Url: url}
    }
    close(jobs)

    go func(){   // Listener Goroutine
        wg.Wait()
        close(results)
    }()

    for result := range results{   // Main consumes results
        fmt.Printf("job-%d %s → %d\n", result.JobId, result.Url, result.StatusCode)
    }
    fmt.Println("Main ended")
}

func worker(jobs <-chan Job, results chan<- Result, wg *sync.WaitGroup){
    defer wg.Done()
    for job := range jobs {
        tp := strings.Split(job.Url, "/")
        statusCode, _ := strconv.Atoi(tp[len(tp)-1])
        results <- Result{
            JobId:      job.Id,
            Url:        job.Url,
            StatusCode: statusCode,
        }
    }
    fmt.Println("G ended")
}

Let's dry run:

When Main goroutine puts a job in the Jobs channel, it gets blocked on the Jobs channel, until any worker goroutine receives the job.
Suppose G1 takes the job from the Jobs channel and consequently Main unblocks, then G1 extracts status code from the job URL, and produces a result in the Results Channel. Since no receiver is there on the Results channel currently, G1 gets blocked on the Results channel.
Main again produces the job in the Jobs channel, and gets blocked again; Let's say now G2 picks up that job, similar to G1, G2 gets blocked on the Results channel.
Main again produces the job, and now G3 picks the job and similarly, gets blocked on the Results channel.
That means, after Main produces 3 jobs, G1, G2, G3 are blocked on the Results channel, and Main now gets blocked on the Jobs channel when it tries to produce 4th job. => DEADLOCK!

That implies, when Main is both the producer on the Jobs channel, and the consumer on the Results channel, and the Jobs and the Results channels both are unbuffered, Deadlock occurs if no. of jobs > no. of worker goroutines.

To avoid Deadlock in this case:

The no. of jobs = no. of worker goroutines = 3 (in our example)(must condition). After producing the 3rd job, Main moves out of the job producer loop and closes the Jobs channel implying that now no jobs would be produced. At this state, G1, G2 & G3 are all blocked on the Results channel.
Now, Main starts to consume on the Results channel "pairing with the 3 blocked worker goroutines one by one", consequently unblocking all of them".
G1, G2 & G3 all exit the job consumer loop since Jobs channel was closed.
The "Listener Goroutine" now closes the Results channel as soon as all the 3 workers exit.
Subsequently, the Main exits the Results consumer loop, as Results channel was closed.

But, this is not the reality. No. of jobs can be 10, 20, 30.... any number. So, what can we do?

Let's try using buffered channels:

jobs := make(chan Job, 4) // You can simulate with any size
results := make(chan Result, 6)

Now, let's assume for one moment (This can help a lot if you pay attention to what I mean to say) -
There are infinite jobs that the Main goroutine wants to produce.
So, Tell me -- How many jobs can Main produce before deadlock happens? Think carefully! Run Concurrent goroutines in your head, simulating how buffered channels work..

Let me Answer (I hope you thought of it!) -

Main produces job in the Jobs channel -> Any goroutine picks it up -> it produces result in the Results channel
Until Results channel fills up (size = 6), 6 jobs can be produced by Main.
The 3 worker goroutines can take up 3 more jobs and all 3 get blocked on the filled Results channel.
Further, Main can produce 4 more jobs until the Jobs channel fills up (size = 4).
Now, if Main tries to produce another job, it gets blocked; and Deadlock occurs. This gives us the formula => Max. Number of jobs that Main can produce without Deadlock = Results channel size (6) + no. of worker goroutines (3) + Jobs channel size (4) = 13.

Similarly, you can simulate for yourself, in the case of:

Unbuffered Jobs channel & Buffered Results channel: Max. Number of jobs that Main can produce without Deadlock = Results channel size + no. of worker goroutines.
Buffered Jobs channel & Unbuffered Results channel: Max. Number of jobs that Main can produce without Deadlock = Jobs channel size + no. of worker goroutines.

That implies our controlled concurrency mechanism failed to scale with the number of jobs; once the job count exceeds a threshold, it causes a deadlock.

This Reveals the key insight!

Buffer is just a performance optimisation, not a correctness mechanism. It only delayed the Deadlock.
Correctness comes from the *correct goroutine pattern *. What is that pattern??

Correct Goroutine pattern: Decoupled Producer and Consumer

Earlier, the pattern we were studying was - Main being both the Producer to the Jobs channel and the Consumer to the Results channel. Deadlock occurred when the Main goroutine blocks on the Jobs channel and the worker goroutines block on the Results channel.
What if - we side-by-side (concurrently) start a consumer service on the Results channel, consequently unblocking the worker goroutines, and making them ready to pick another jobs. And, hence, we found the solution!

A service produces jobs to the Jobs channel -> Worker routines pick up jobs and produce to the Results channel -> A service consumes from the Results channel. This is the Correct Goroutine pattern.

** Take a look at the code: **

/*
    Decoupled Producer and Consumer
    Main is the results Consumer, new Goroutine spawned as jobs Producer.
    ** Why not main as producer? Because after producing jobs, main will end without waiting for the consumer to finish.
    Unbuffered Channels - Jobs and Results
*/

func main(){
    jobs    := make(chan Job)
    results := make(chan Result)

    var wg sync.WaitGroup

    for i := 1; i <= 3; i++{
        wg.Add(1)
        go worker(jobs, results, &wg)
    }

    go func(){            // Producer goroutine
        urls := [15]string{
        "https://httpbin.org/status/200",
        "https://httpbin.org/status/404",
        "https://httpbin.org/status/500",
        "https://httpbin.org/status/500",
        "https://httpbin.org/delay/1",
        "https://httpbin.org/delay/1",
        "https://httpbin.org/status/200",
        "https://httpbin.org/status/200",
        "https://httpbin.org/status/404",
        "https://httpbin.org/status/500",
        "https://httpbin.org/delay/1",
        "https://httpbin.org/status/200",
        "https://httpbin.org/status/200",
        "https://httpbin.org/status/404",
        "https://httpbin.org/status/404",
    }

        for i, url := range urls{
            jobs <- Job{Id: i+1, Url: url}
        }
        close(jobs)
    }()

    go func(){
        wg.Wait()
        close(results)
    }()

    for result := range results{     // Main consumes results
        fmt.Printf("job-%d %s → %d\n", result.JobId, result.Url, result.StatusCode)
    }

    fmt.Println("Main ended")
}

func worker(jobs <-chan Job, results chan<- Result, wg *sync.WaitGroup){
    defer wg.Done()
    for job := range jobs {
        tp := strings.Split(job.Url, "/")
        statusCode, _ := strconv.Atoi(tp[len(tp)-1])
        results <- Result{
            JobId:      job.Id,
            Url:        job.Url,
            StatusCode: statusCode,
        }
    }
    fmt.Println("G ended")
}

Therefore, we have arrived at a correct implementation of a worker pool and established control over concurrency. You can now experiment further:

a. Use buffered channels to improve performance in this pattern.
b. Replace the URL parsing with actual HTTP calls, and incorporate context cancellation.

From here, you can compose more advanced primitives within this model.”

_Thanks a lot! _