Limit Goroutines in Go: Concurrency Control Patterns That Scale

Why Unlimited Goroutines Are Risky For more context, see Go Installation Guide, Go Ecosystem Overview, Go Best Practices.

Goroutines are lightweight, but they are not free. Unbounded spawning can cause:

1. Memory pressure.
2. Scheduler overhead.
3. Connection storms to downstream systems.
4. Timeouts and cascading failures.

Concurrency should be controlled as a first-class design decision.

Pattern 1: Buffered Channel Semaphore

A buffered channel is the simplest concurrency limiter.

package main

import (
    "fmt"
    "math/rand"
    "sync"
    "time"
)

const MaxConcurrentJobs = 4

func main() {
    rand.Seed(time.Now().UnixNano())

    sem := make(chan struct{}, MaxConcurrentJobs)
    var wg sync.WaitGroup

    for i := 1; i <= 20; i++ {
        wg.Add(1)
        sem <- struct{}{} // block when full

        go func(id int) {
            defer wg.Done()
            defer func() { <-sem }() // release slot

            job(id)
        }(i)
    }

    wg.Wait()
}

func job(id int) {
    fmt.Printf("job %d start\n", id)
    time.Sleep(time.Duration(rand.Intn(500)+100) * time.Millisecond)
    fmt.Printf("job %d done\n", id)
}

This ensures at most MaxConcurrentJobs run simultaneously.

Pattern 2: Worker Pool

Worker pools are better when jobs come from a stream/queue.

type Job struct {
    ID int
}

func worker(id int, jobs <-chan Job, results chan<- int) {
    for j := range jobs {
        // process
        time.Sleep(100 * time.Millisecond)
        results <- j.ID
    }
}

Benefits:

1. Fixed concurrency by number of workers.
2. Clear backpressure via channel buffering.
3. Easier shutdown control.

Pattern 3: Weighted Semaphore (x/sync/semaphore)

Useful when tasks have different resource cost.

Example idea:

1. small task weight = 1
2. heavy task weight = 5

Weighted limits prevent one class of jobs from starving others.

Add Context for Cancellation

Concurrency limits are incomplete without cancellation.

Use context.Context to:

1. stop new work.
2. cancel in-flight operations where possible.
3. enforce deadlines.

ctx, cancel := context.WithTimeout(context.Background(), 3*time.Second)
defer cancel()

Backpressure Is a Feature

If your input rate exceeds processing capacity, the system must apply backpressure instead of unlimited buffering.

Backpressure options:

1. Block producer.
2. Drop low-priority tasks.
3. Spill to durable queue.
4. Return 429 Too Many Requests upstream.

Choosing MaxConcurrentJobs

Set concurrency by bottleneck type:

1. CPU-bound: close to CPU cores.
2. I/O-bound: higher, tuned by downstream limits.
3. External API-limited: align with provider rate limits.

Always benchmark and observe.

Observability Metrics to Track

For concurrency control, monitor:

1. active goroutine count.
2. queue depth.
3. task latency percentiles.
4. error/timeout rates.
5. dropped/rejected job count.

Without metrics, tuning is guesswork.

Common Mistakes

1. Infinite producer loop without stop condition.
2. Missing defer release on semaphore slot.
3. Ignoring context cancellation.
4. Large unbounded buffered channels.
5. No timeout around external calls.

Production Checklist

1. Concurrency limit defined.
2. Cancellation path implemented.
3. Queue/backpressure policy documented.
4. Metrics exported.
5. Load test performed.

Conclusion

Goroutine limits are essential reliability controls. The buffered-channel semaphore pattern is excellent for simple workloads, and worker pools or weighted semaphores are better for complex systems.

Design concurrency intentionally, measure continuously, and tune based on actual bottlenecks.

Resources

• Go Concurrency Patterns
• Effective Go: Concurrency
• x/sync/semaphore