Chapter 1: Go Concurrency - Making Your Programs Do Multiple Things at Once

Introduction

• A web server handling thousands of simultaneous user requests
• A data pipeline processing millions of records from multiple sources
• A microservice orchestrating calls to several downstream APIs
• A real-time system monitoring hundreds of sensors simultaneously

Core Concepts

What is Concurrency?

Go blog diagram 1

Go blog diagram 2

The Traditional Sequential Model

Task 1 → Complete → Task 2 → Complete → Task 3 → Complete

1. Fetch data from a database (100ms network wait)
2. Call an external API (200ms network wait)
3. Read a file from disk (50ms I/O wait)
4. Process the combined results (10ms computation)

The Go Philosophy: Communicating Sequential Processes

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

Detailed Explanation: Goroutines

What is a Goroutine?

Go blog diagram 3

go
go someFunction()  // This starts someFunction in a new goroutine

1. Goroutine creation: Go allocates a small stack (starting at about 2KB)
2. Scheduling: The Go scheduler adds the goroutine to its run queue
3. Concurrent execution: The scheduler runs the goroutine when a processor is available

The Mechanics: How Goroutines Differ from Threads

Go blog diagram 4

Your First Goroutines

go
// Filename: goroutine_basics.go
package main

import (
    "fmt"
    "time"
)

// brewCoffee simulates making a coffee order.
// Each call represents work that takes time to complete.
// In real applications, this might be a database query,
// an HTTP request, or any I/O-bound operation.
func brewCoffee(order string) {
    fmt.Printf("Starting: %s\n", order)
    time.Sleep(2 * time.Second)  // Simulates the time to brew
    fmt.Printf("Completed: %s\n", order)
}

func main() {
    orders := []string{"Latte", "Espresso", "Cappuccino", "Americano"}

    start := time.Now()

    // Launch each order as a separate goroutine.
    // The 'go' keyword starts concurrent execution.
    for _, order := range orders {
        go brewCoffee(order)
    }

    // IMPORTANT: We must wait for goroutines to complete.
    // Without this sleep, main() would exit immediately,
    // terminating all goroutines before they finish.
    time.Sleep(3 * time.Second)

    fmt.Printf("All orders completed in: %v\n", time.Since(start))
}

Starting: Americano
Starting: Latte
Starting: Cappuccino
Starting: Espresso
Completed: Latte
Completed: Cappuccino
Completed: Americano
Completed: Espresso
All orders completed in: 3.001s

1. Order of "Starting" messages is non-deterministic: Goroutines may start in any order depending on how the scheduler assigns them to processors.
2. Total time is ~3 seconds, not 8 seconds: Four 2-second tasks completed in parallel instead of sequentially. The extra second comes from our sleep margin.
3. The time.Sleep is a temporary workaround: This is not how you'd write production code. We'll explore proper synchronization techniques in subsequent chapters.

Understanding the Execution Model

Go blog diagram 5

• A local run queue for each processor (P)
• A global run queue for overflow
• Network poller queue for goroutines waiting on I/O

• Completes its function
• Makes a blocking call (channel operation, system call)
• Is preempted by the scheduler (after ~10ms of execution)

Code Examples

A Practical Example: Concurrent Web Checker

go
// Filename: website_checker.go
package main

import (
    "fmt"
    "net/http"
    "time"
)

// checkWebsite performs an HTTP GET request and reports the result.
// This is a realistic I/O-bound operation where concurrency shines.
//
// Parameters:
//   - url: The full URL to check (must include http:// or https://)
//
// This function doesn't return a value; it prints results directly.
// In production code, you'd typically return results through a channel.
func checkWebsite(url string) {
    start := time.Now()

    // Create an HTTP client with a timeout.
    // Without a timeout, slow or unresponsive sites could block forever.
    client := http.Client{
        Timeout: 5 * time.Second,
    }

    resp, err := client.Get(url)
    duration := time.Since(start)

    if err != nil {
        fmt.Printf("FAIL: %s (Error: %v)\n", url, err)
        return
    }
    defer resp.Body.Close()  // Always close response bodies

    fmt.Printf("OK: %s (Status: %d, Time: %v)\n", url, resp.StatusCode, duration)
}

func main() {
    websites := []string{
        "https://google.com",
        "https://github.com",
        "https://golang.org",
        "https://stackoverflow.com",
        "https://amazon.com",
    }

    start := time.Now()

    // Check all websites concurrently.
    // Each checkWebsite call runs in its own goroutine.
    for _, site := range websites {
        go checkWebsite(site)
    }

    // Wait for all checks to complete (temporary solution).
    time.Sleep(6 * time.Second)

    fmt.Printf("\nTotal time: %v\n", time.Since(start))
}

Anonymous Goroutines and Closures

go
package main

import (
    "fmt"
    "time"
)

func main() {
    // Anonymous goroutine with no parameters
    go func() {
        fmt.Println("Hello from anonymous goroutine!")
    }()

    // Anonymous goroutine with parameters
    // The (42) at the end immediately calls the function with argument 42
    go func(n int) {
        fmt.Printf("Received number: %d\n", n)
    }(42)

    time.Sleep(time.Second)
}

Common Mistakes and Misconceptions

Mistake 1: Forgetting That main() Doesn't Wait

go
// BROKEN: Program exits before goroutine runs
func main() {
    go fmt.Println("Hello!")
    // main() returns here, program terminates
}

go
func main() {
    go fmt.Println("Hello!")
    time.Sleep(time.Second)  // Give goroutine time to run
}

go
func main() {
    var wg sync.WaitGroup
    wg.Add(1)

    go func() {
        defer wg.Done()
        fmt.Println("Hello!")
    }()

    wg.Wait()  // Blocks until wg.Done() is called
}

Mistake 2: Loop Variable Capture Bug

go
// BROKEN: All goroutines likely print the same value
for i := 0; i < 5; i++ {
    go func() {
        fmt.Println(i)  // Captures 'i' by reference
    }()
}

go
for i := 0; i < 5; i++ {
    go func(n int) {
        fmt.Println(n)  // Each goroutine gets its own copy
    }(i)
}

go
for i := 0; i < 5; i++ {
    i := i  // Shadow with new variable
    go func() {
        fmt.Println(i)  // Captures the new 'i'
    }()
}

Mistake 3: Using time.Sleep for Synchronization

go
// PROBLEMATIC: How long should we sleep?
func main() {
    go doWork()
    time.Sleep(5 * time.Second)  // What if doWork takes 6 seconds?
}

• If work finishes in 1 second, you waste 4 seconds
• If work takes 6 seconds, you exit too early
• Real-world timing is unpredictable (network latency, server load)

• sync.WaitGroup - Wait for a group of goroutines to complete
• Channels - Communicate completion signals
• context.Context - Cancellation and timeouts

Practical Use Cases

When Concurrency Shines

• Database queries
• HTTP requests
• File system operations
• Network socket communication

• Batch processing of items
• Handling multiple user requests
• Running parallel test cases
• Processing queue messages

When Concurrency Has Less Impact

go
// Each calculation depends on the previous result
result := 0
for i := 0; i < 1000000; i++ {
    result = heavyComputation(result)
}

go
// Overhead of goroutine creation exceeds benefit
for i := 0; i < 10; i++ {
    go func(n int) {
        fmt.Println(n)  // Println is fast; goroutine overhead adds latency
    }(i)
}

Performance and Best Practices

Goroutine Overhead

• Memory: ~2KB initial stack (can grow to gigabytes if needed)
• Scheduling: Adding/removing from run queues has cost
• Context switching: ~200ns per switch

Guidelines for Production Code

1. Don't fire-and-forget: Always have a plan for how goroutines will terminate.
2. Propagate cancellation: Use context.Context to signal goroutines to stop.
3. Handle panics: A panic in a goroutine crashes the whole program unless recovered.
4. Limit concurrency when needed: Unbounded goroutines can overwhelm external systems (database connection limits, API rate limits).

go
// Using a semaphore pattern to limit concurrent operations
sem := make(chan struct{}, 10)  // Allow 10 concurrent operations

for _, task := range tasks {
    sem <- struct{}{}  // Acquire
    go func(t Task) {
        defer func() { <-sem }()  // Release
        process(t)
    }(task)
}

Summary

• Concurrency is structure, not necessarily parallelism: It's about organizing your program to handle multiple tasks, which may or may not run simultaneously.
• Goroutines are lightweight: Starting at ~2KB of stack, they're 500x more memory-efficient than OS threads.
• The go keyword is simple but powerful: go someFunction() starts concurrent execution.
• main() exit terminates everything: Goroutines die when the main function returns.
• Time.Sleep is for demos, not production: Use proper synchronization primitives.
• Loop variables need careful handling: Pass values as parameters to avoid capture bugs.
• Concurrency shines for I/O-bound work: Network calls, file operations, and database queries benefit most.

Interview Questions

1. What is the difference between concurrency and parallelism? How does Go's runtime handle both?
2. Explain what happens internally when you write go someFunction(). What data structures and runtime components are involved?
3. Why are goroutines more efficient than operating system threads? Discuss memory, scheduling, and context switching.
4. A developer writes go fmt.Println("Hello") as the only line in main(), and nothing prints. Explain why and how to fix it.
5. Describe the "loop variable capture" bug in goroutines. Why does it happen, and what are two ways to prevent it?
6. When would using concurrency actually slow down your program rather than speed it up?
7. What happens to a goroutine that panics? How does this differ from a panic in the main goroutine?
8. Explain why time.Sleep is inappropriate for production synchronization. What alternatives exist?
9. You need to check 1000 URLs for availability, but the target servers rate-limit to 50 concurrent connections. How would you structure your concurrent solution?
10. How does the Go scheduler decide when to switch between goroutines? What events cause a goroutine to yield execution?
11. A service creates one goroutine per incoming HTTP request. Under heavy load, memory usage spikes dramatically. What's happening, and how would you investigate?
12. Can you return a value from a goroutine? If not, how do you get results back from concurrent operations?
13. Describe a real-world scenario where concurrent execution would significantly improve application performance. What characteristics make it suitable for concurrency?
14. What is GOMAXPROCS, and how does it relate to goroutine execution?
15. How would you gracefully shut down a service that has multiple long-running goroutines?