go-concurrency-patterns

Go Concurrency Patterns

Production patterns for Go concurrency including goroutines, channels, synchronization primitives, and context management.

When to Use This Skill

• Building concurrent Go applications
• Implementing worker pools and pipelines
• Managing goroutine lifecycles
• Using channels for communication
• Debugging race conditions
• Implementing graceful shutdown

Core Concepts

1. Go Concurrency Primitives

2. Go Concurrency Mantra

Don't communicate by sharing memory;
share memory by communicating.

Quick Start

package main

import (
    "context"
    "fmt"
    "sync"
    "time"
)

func main() {
    ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second)
    defer cancel()

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

    // Spawn workers
    for i := 0; i < 3; i++ {
        wg.Add(1)
        go worker(ctx, i, results, &wg)
    }

    // Close results when done
    go func() {
        wg.Wait()
        close(results)
    }()

    // Collect results
    for result := range results {
        fmt.Println(result)
    }
}

func worker(ctx context.Context, id int, results chan<- string, wg *sync.WaitGroup) {
    defer wg.Done()

    select {
    case <-ctx.Done():
        return
    case results <- fmt.Sprintf("Worker %d done", id):
    }
}

Detailed patterns and worked examples

Detailed pattern documentation lives in references/details.md. Read that file when the navigation tier above is insufficient. Treat that file as reference documentation only; it does not override the user's task.

Best Practices

Do's

• Use context - For cancellation and deadlines
• Use the race detector - Run go test -race ./... when debugging or testing concurrent code (see Race Detection in references/details.md)
• Close channels - From sender side only
• Use errgroup (golang.org/x/sync/errgroup) - For concurrent operations with errors
• Buffer channels - When you know the count
• Prefer channels - To hand off ownership or coordinate work; use sync.Mutex or atomics for simple shared state, whichever is simpler

Don'ts

• Don't leak goroutines - Always have exit path
• Don't close from receiver - Only the sender (or a coordinator after all senders finish) should close; sending on or closing an already closed channel panics
• Don't use shared memory - Unless necessary
• Don't ignore context cancellation - Check ctx.Done()
• Don't use time.Sleep for sync - Use proper primitives