How to Run Parallel Tasks in Go: Complete Guide with Examples

Last verified: April 2026

Executive Summary

Go’s concurrency model stands apart from most languages because it treats parallelism as a first-class citizen through goroutines and channels. Unlike traditional threading models that require managing OS-level threads directly, Go lets you spawn thousands of lightweight goroutines that the runtime schedules efficiently across available CPU cores. This makes running parallel tasks in Go significantly simpler than in languages like Java or Python, where you’d juggle thread pools and complex synchronization primitives.

Running parallel tasks in Go centers on three core patterns: goroutines for concurrent execution, channels for safe communication between tasks, and sync primitives like WaitGroup for coordination. The difficulty rating is advanced because while the syntax is simple, mastering concurrent program design—handling race conditions, deadlocks, and proper resource cleanup—requires deeper understanding. This guide covers production-ready patterns that avoid the most common pitfalls: unhandled errors in concurrent operations, forgotten resource cleanup, and race conditions that only surface under load.

Main Data Table

Pattern	Use Case	Complexity	Best For
Goroutines + Channels	Passing data between tasks	Intermediate	Pipeline workflows, streaming data
sync.WaitGroup	Coordinating task completion	Beginner	Fire-and-forget parallel work
context.Context	Cancellation and timeouts	Intermediate	Long-running services, graceful shutdown
sync.Mutex	Protecting shared state	Beginner	Shared memory access, counters
sync.atomic	Lock-free synchronization	Advanced	High-performance counters, flags

Breakdown by Experience Level

The approach you take depends on how experienced you are with concurrent programming:

Experience Level	Recommended Pattern	Key Consideration
Beginner	sync.WaitGroup	Start here—simple coordination without channels
Intermediate	Goroutines + Channels	Add context for cancellation in real applications
Advanced	Custom pooling + atomic operations	Optimize for specific workload characteristics

Comparison with Related Patterns

Approach	Memory Overhead	Scalability	Learning Curve
Goroutines	~2KB per goroutine	100,000+ concurrent tasks	Easy
OS Threads (Java)	~1MB per thread	Hundreds of threads max	Complex
Thread Pools	~1MB base + queue overhead	Bounded by pool size	Moderate
Async/Await (JavaScript)	Minimal (single-threaded)	Good for I/O, not CPU-bound	Moderate

Key Factors for Running Parallel Tasks Successfully

1. Choosing the Right Synchronization Primitive

The most common mistake is using channels when a simple WaitGroup would suffice, or vice versa. If you need to coordinate completion of independent tasks and don’t care about passing data between them, sync.WaitGroup is lighter and more straightforward. Reserve channels for pipelines and data flow between goroutines. Using the wrong primitive adds complexity and potential race conditions—channels have blocking semantics that can deadlock if mishandled, while WaitGroup simply counts up and down.

2. Proper Resource Cleanup and Context Propagation

Every parallel task running in production must respect context deadlines and handle cancellation. Without context awareness, goroutines can leak when a parent operation times out or gets cancelled. Passing context.Context through your function signatures costs nothing and provides the entire execution tree with timeout and cancellation information. This is critical for graceful shutdown and preventing resource exhaustion.

3. Error Handling in Concurrent Code

Errors in goroutines don’t propagate up to the caller automatically. You must either collect errors through a channel or use a shared error variable protected by a mutex. The idiomatic pattern uses a dedicated error channel where goroutines send errors if they occur, and the main goroutine reads from it. Forgetting to collect errors silently masks failures.

4. Avoiding Goroutine Leaks

A goroutine leak happens when a goroutine never terminates, consuming memory indefinitely. This typically occurs when a goroutine blocks reading from a channel that no one writes to, or when a goroutine is waiting for a context cancellation that never arrives. Always ensure every goroutine has a clear exit condition—either through context cancellation, channel closure, or a completion signal.

5. Race Condition Prevention Through Design

The most insidious concurrent bugs are race conditions, which are hard to reproduce and trigger unpredictably. Go’s race detector (run tests with `-race` flag) catches data races at runtime. The best prevention is architectural: prefer channels and message passing over shared memory. When you must share memory, protect it with mutexes and keep critical sections minimal. Never share pointers across goroutines without synchronization.

Historical Trends in Go Concurrency

Go’s concurrency model has remained remarkably stable since Go 1.0 in 2012. The core abstractions—goroutines, channels, and sync primitives—haven’t fundamentally changed. However, best practices have evolved:

• Pre-Go 1.9: Context wasn’t built-in; timeouts and cancellation were ad-hoc
• Go 1.9+: Context became the standard for managing deadlines and cancellation across API boundaries
• Go 1.22+: Clearer semantics for loop variable scoping in goroutines (fixing a subtle bug trap)
• Go 1.23+: Iterators introduced as a cleaner alternative to callback-heavy channel patterns

The shift toward context-aware APIs reflects the Go community’s hard-won lessons about production reliability. Most goroutine leaks and hanging servers stem from ignoring cancellation signals, so modern Go code treats context as essential infrastructure, not optional.

Expert Tips for Production Code

Tip 1: Always Use context.Context for Cancellation

Wrap parallel work with a context that has a timeout or can be cancelled. This single practice prevents most goroutine leaks:

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

var wg sync.WaitGroup
for i := 0; i < 100; i++ {
  wg.Add(1)
  go func(id int) {
    defer wg.Done()
    select {
    case <-ctx.Done():
      return // Exit immediately on cancellation
    case <-time.After(time.Duration(id) * time.Second):
      fmt.Printf("Task %d completed\n", id)
    }
  }(i)
}
wg.Wait()

Tip 2: Use Buffered Channels Carefully

Unbuffered channels block the sender until a receiver is ready. Buffered channels let senders queue up to N values before blocking. In high-throughput scenarios, buffering reduces context switches, but oversizing buffers can mask backpressure problems. A good heuristic: buffer size equals the number of goroutines writing to the channel.

Tip 3: Run Race Detector in Tests

Always run your concurrent tests with `go test -race ./…`. The race detector is Go’s gift for catching data races you’d miss in code review. It adds ~20% overhead but is invaluable during development.

Tip 4: Separate Concern Between Task Execution and Result Aggregation

Keep goroutine spawning separate from result collection. Use a goroutine for each task and a separate aggregator goroutine that merges results. This pattern scales better than having one goroutine do both:

results := make(chan Result, 10)
var wg sync.WaitGroup

// Worker goroutines
for i := 0; i < 10; i++ {
  wg.Add(1)
  go func(id int) {
    defer wg.Done()
    results <- doWork(id)
  }(i)
}

// Aggregator in separate goroutine
go func() {
  wg.Wait()
  close(results) // Signal completion
}()

// Consume results
for r := range results {
  process(r)
}

Tip 5: Leverage sync/errgroup for Common Patterns

The errgroup package (golang.org/x/sync/errgroup) wraps WaitGroup with built-in error handling. It’s lighter than managing error channels manually:

eg, ctx := errgroup.WithContext(context.Background())

for i := 0; i < 10; i++ {
  i := i // Capture loop variable
  eg.Go(func() error {
    return doWork(ctx, i)
  })
}

if err := eg.Wait(); err != nil {
  log.Fatal(err)
}

FAQ Section

Q1: How many goroutines can I safely run in parallel?

Go can handle 100,000+ goroutines on modern hardware because each goroutine uses only ~2KB of memory initially (compared to ~1MB for OS threads). The practical limit depends on what those goroutines are doing. CPU-bound work should use at most runtime.NumCPU() goroutines to avoid excessive context switching. I/O-bound work can use many more since goroutines that block on I/O don’t consume CPU time. Start with testing under realistic load; Go’s runtime is excellent at managing large goroutine counts.

Q2: What’s the difference between buffered and unbuffered channels?

An unbuffered channel requires a sender and receiver to synchronize—the sender blocks until a receiver accepts the value. A buffered channel (e.g., make(chan int, 10)) lets the sender queue up to 10 values before blocking. Unbuffered channels are better for tight synchronization and preventing goroutine runaway; buffered channels reduce blocking but can hide backpressure issues. Use unbuffered channels by default unless profiling shows channel blocking is a bottleneck.

Q3: How do I prevent goroutine leaks?

Goroutine leaks happen when a goroutine never exits. Common causes: (1) blocking on a channel with no sender, (2) infinite loops without an exit condition, (3) ignoring context cancellation. Prevention: always propagate context.Context through call chains, use select with <-ctx.Done() in every long-running goroutine, and ensure every goroutine has a clear termination path. Test with pprof to check goroutine count before and after operations.

Q4: When should I use sync.Mutex vs. channels?

Channels are best for moving data and coordinating flow between goroutines (“share memory by communicating”). Mutexes protect shared state that multiple goroutines access and modify (“communicate by sharing memory”). If you’re passing a value from one goroutine to another, use a channel. If multiple goroutines increment a counter or read/write a shared map, use a mutex. Mixing both is fine—use each tool for its purpose.

Q5: What happens if a buffered channel is full?

If you try to send to a buffered channel that’s full (already has capacity elements), the sender blocks until a receiver removes an element. This is identical to sending on an unbuffered channel—the sender waits. It’s actually a feature: buffered channels provide limited backpressure. If a channel is consistently full, it signals that receivers are slower than senders, and you may need more workers or a slower producer. Running with -race catches situations where you deadlock on full channels.

Conclusion

Running parallel tasks in Go is fundamentally simpler than in most languages because goroutines are lightweight and the scheduler is built into the runtime. However, this simplicity invites mistakes if you ignore the discipline required for correct concurrent code.

The actionable takeaway: start with sync.WaitGroup for simple parallelism, upgrade to goroutines + channels when you need data flow, and always pass context.Context to enable graceful cancellation. Test with the race detector enabled. These three practices eliminate the majority of concurrent bugs in production Go applications.

For most workloads, goroutines plus well-chosen channels outperform thread pools and are orders of magnitude simpler than managing thread lifecycle. Respect their power by following the patterns outlined here—your future self (and your on-call rotation) will thank you.