Concurrency — Find the Bug¶

Concurrency is the richest bug source in software: the code reads correctly, the tests pass, the demo works — and then it fails once in ten thousand runs on a customer's machine. The bugs below are real, subtle, and intermittent. Each compiles and runs. Find the race, the visibility hole, or the deadlock before you open the answer.

Table of Contents¶

1. Snippet 1 — Check-then-act on a map (Go)
2. Snippet 2 — Lost update on a counter (Java)
3. Snippet 3 — Visibility bug on a stop flag (Java)
4. Snippet 4 — Loop variable captured by goroutines (Go)
5. Snippet 5 — Deadlock from inconsistent lock ordering (Go)
6. Snippet 6 — synchronized on the wrong lock object (Java)
7. Snippet 7 — Double-checked locking without volatile (Java)
8. Snippet 8 — Goroutine leak on a blocked channel (Go)
9. Snippet 9 — WaitGroup.Add inside the goroutine (Go)
10. Snippet 10 — Shared SimpleDateFormat across threads (Java)
11. Snippet 11 — TOCTOU on a lock file (Python)
12. Snippet 12 — Unbuffered channel deadlock on the main goroutine (Go)
13. Snippet 13 — Closing a channel from the receiver (Go)
14. Snippet 14 — defer mu.Unlock() after an early return path (Go)
15. Scorecard
16. Related Topics

How to Use¶

Read each snippet and decide what's wrong before expanding the answer. For a concurrency bug, a complete diagnosis answers four questions:

1. What is the data race or coordination flaw? Name the two operations that interleave badly, or the channel/lock that never gets signaled.
2. Why is it intermittent? Almost every concurrency bug passes the first thousand runs. Explain the window that has to be hit.
3. What's the fix? Usually a lock, an atomic, a volatile/memory barrier, a context, or restructuring ownership so the data is never shared.
4. Would a race detector catch it? Go's -race flag and Java's tooling (e.g. the FindBugs/SpotBugs MT_CORRECTNESS checks, ThreadSanitizer for native code) catch data races — unsynchronized access to shared memory. They do not catch deadlocks, channel leaks, or logical races where every access happens to go through a lock but the sequence is still wrong. Knowing which category a bug falls into tells you which tool to reach for.

Difficulty is marked Easy / Medium / Hard. The Hard ones survive code review at most companies.

Snippet 1¶

Difficulty: Easy — Check-then-act on a map (Go)

package cache

import "sync"

type Counter struct {
    mu     sync.Mutex
    counts map[string]int
}

func NewCounter() *Counter {
    return &Counter{counts: make(map[string]int)}
}

// Increment bumps the count for key by one.
func (c *Counter) Increment(key string) {
    if _, ok := c.counts[key]; !ok {
        c.mu.Lock()
        c.counts[key] = 0
        c.mu.Unlock()
    }
    c.mu.Lock()
    c.counts[key]++
    c.mu.Unlock()
}

What's wrong?

func (c *Counter) Increment(key string) {
    c.mu.Lock()
    defer c.mu.Unlock()
    c.counts[key]++ // zero value of int is 0, so no need to pre-initialize
}

Snippet 2¶

Difficulty: Easy — Lost update on a counter (Java)

public class RequestMeter {
    private long total = 0;

    public void record() {
        total++;
    }

    public long total() {
        return total;
    }
}

// Used from a thread-per-request server:
//   meter.record();   // called by every request thread

What's wrong?

import java.util.concurrent.atomic.AtomicLong;

public class RequestMeter {
    private final AtomicLong total = new AtomicLong();

    public void record() {
        total.incrementAndGet();
    }

    public long total() {
        return total.get();
    }
}

Snippet 3¶

Difficulty: Medium — Visibility bug on a stop flag (Java)

public class Worker implements Runnable {
    private boolean running = true;

    public void stop() {
        running = false;
    }

    @Override
    public void run() {
        while (running) {
            doWork();
        }
    }

    private void doWork() { /* CPU-bound, no I/O, no locks */ }
}

// Main thread:
//   Worker w = new Worker();
//   new Thread(w).start();
//   Thread.sleep(1000);
//   w.stop();   // worker should exit... does it?

What's wrong?

Why it's intermittent: This one is the classic "works on my laptop, hangs in production."

private volatile boolean running = true;

Snippet 4¶

Difficulty: Medium — Loop variable captured by goroutines (Go)

package main

import (
    "fmt"
    "sync"
)

func main() {
    urls := []string{"a.com", "b.com", "c.com"}
    var wg sync.WaitGroup

    for _, url := range urls {
        wg.Add(1)
        go func() {
            defer wg.Done()
            fmt.Println("fetching", url)
        }()
    }
    wg.Wait()
}

What's wrong?

for _, url := range urls {
    url := url // new variable each iteration
    wg.Add(1)
    go func() {
        defer wg.Done()
        fmt.Println("fetching", url)
    }()
}

for _, url := range urls {
    wg.Add(1)
    go func(u string) {
        defer wg.Done()
        fmt.Println("fetching", u)
    }(url)
}

Snippet 5¶

Difficulty: Hard — Deadlock from inconsistent lock ordering (Go)

package bank

import "sync"

type Account struct {
    mu      sync.Mutex
    balance int
}

func Transfer(from, to *Account, amount int) {
    from.mu.Lock()
    defer from.mu.Unlock()
    to.mu.Lock()
    defer to.mu.Unlock()

    from.balance -= amount
    to.balance += amount
}

What's wrong?

type Account struct {
    id      uint64 // unique, assigned at creation
    mu      sync.Mutex
    balance int
}

func Transfer(from, to *Account, amount int) {
    first, second := from, to
    if first.id > second.id {
        first, second = second, first
    }
    first.mu.Lock()
    defer first.mu.Unlock()
    second.mu.Lock()
    defer second.mu.Unlock()

    from.balance -= amount
    to.balance += amount
}

Snippet 6¶

Difficulty: Hard — synchronized on the wrong lock object (Java)

public class BoundedBuffer {
    private final Object writeLock = new Object();
    private final java.util.LinkedList<Integer> items = new java.util.LinkedList<>();

    public void put(int value) {
        synchronized (writeLock) {
            items.addLast(value);
        }
    }

    public Integer poll() {
        synchronized (items) {            // <-- different lock!
            return items.isEmpty() ? null : items.removeFirst();
        }
    }
}

What's wrong?

public class BoundedBuffer {
    private final Object lock = new Object();
    private final java.util.LinkedList<Integer> items = new java.util.LinkedList<>();

    public void put(int value) {
        synchronized (lock) { items.addLast(value); }
    }

    public Integer poll() {
        synchronized (lock) {
            return items.isEmpty() ? null : items.removeFirst();
        }
    }
}

Snippet 7¶

Difficulty: Hard — Double-checked locking without volatile (Java)

public class ConfigRegistry {
    private static ConfigRegistry instance;  // not volatile

    private final Map<String, String> settings;

    private ConfigRegistry() {
        this.settings = loadFromDisk(); // expensive
    }

    public static ConfigRegistry getInstance() {
        if (instance == null) {                 // first check (no lock)
            synchronized (ConfigRegistry.class) {
                if (instance == null) {          // second check (locked)
                    instance = new ConfigRegistry();
                }
            }
        }
        return instance;
    }

    private static Map<String, String> loadFromDisk() { /* ... */ return null; }
}

What's wrong?

private static volatile ConfigRegistry instance;

public class ConfigRegistry {
    private ConfigRegistry() { /* ... */ }

    private static class Holder {
        static final ConfigRegistry INSTANCE = new ConfigRegistry();
    }

    public static ConfigRegistry getInstance() {
        return Holder.INSTANCE;
    }
}

Snippet 8¶

Difficulty: Medium — Goroutine leak on a blocked channel (Go)

package search

import "context"

// First returns the first result from any backend; the rest are abandoned.
func First(query string, backends []func(string) string) string {
    results := make(chan string) // unbuffered

    for _, backend := range backends {
        b := backend
        go func() {
            results <- b(query) // send result
        }()
    }

    return <-results // take the first, ignore the rest
}

What's wrong?

func First(ctx context.Context, query string, backends []func(context.Context, string) string) string {
    results := make(chan string, len(backends)) // buffered: every sender can finish
    ctx, cancel := context.WithCancel(ctx)
    defer cancel() // signal the losers to stop

    for _, backend := range backends {
        b := backend
        go func() {
            results <- b(ctx, query)
        }()
    }
    return <-results
}

Snippet 9¶

Difficulty: Medium — WaitGroup.Add inside the goroutine (Go)

package main

import (
    "fmt"
    "sync"
)

func processAll(jobs []int) {
    var wg sync.WaitGroup

    for _, job := range jobs {
        go func(j int) {
            wg.Add(1)        // <-- Add inside the goroutine
            defer wg.Done()
            fmt.Println("processing", j)
        }(job)
    }

    wg.Wait() // wait for all jobs
    fmt.Println("all done")
}

What's wrong?

func processAll(jobs []int) {
    var wg sync.WaitGroup
    for _, job := range jobs {
        wg.Add(1) // before launching — happens-before Wait
        go func(j int) {
            defer wg.Done()
            fmt.Println("processing", j)
        }(job)
    }
    wg.Wait()
    fmt.Println("all done")
}

Snippet 10¶

Difficulty: Hard — Shared SimpleDateFormat across threads (Java)

public final class Timestamps {
    // shared static formatter to avoid allocating one per call
    private static final SimpleDateFormat FORMAT =
        new SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ss");

    public static String format(Date when) {
        return FORMAT.format(when);
    }
}

// Called concurrently from many request threads:
//   String ts = Timestamps.format(new Date());

What's wrong?

import java.time.Instant;
import java.time.ZoneOffset;
import java.time.format.DateTimeFormatter;

public final class Timestamps {
    private static final DateTimeFormatter FORMAT =
        DateTimeFormatter.ofPattern("yyyy-MM-dd'T'HH:mm:ss").withZone(ZoneOffset.UTC);

    public static String format(Instant when) {
        return FORMAT.format(when);
    }
}

Snippet 11¶

Difficulty: Medium — TOCTOU on a lock file (Python)

import os

LOCK = "/tmp/job.lock"

def run_exclusive(task):
    # Acquire a crude file lock so only one process runs the task.
    if not os.path.exists(LOCK):      # time-of-check
        open(LOCK, "w").close()        # time-of-use
        try:
            task()
        finally:
            os.remove(LOCK)
    else:
        print("another instance is running; skipping")

What's wrong?

import os

LOCK = "/tmp/job.lock"

def run_exclusive(task):
    try:
        fd = os.open(LOCK, os.O_CREAT | os.O_EXCL | os.O_WRONLY)
    except FileExistsError:
        print("another instance is running; skipping")
        return
    try:
        task()
    finally:
        os.close(fd)
        os.remove(LOCK)

Snippet 12¶

Difficulty: Easy — Unbuffered channel deadlock on the main goroutine (Go)

package main

import "fmt"

func main() {
    ch := make(chan int) // unbuffered

    ch <- 42             // send

    value := <-ch        // receive
    fmt.Println(value)
}

What's wrong?

func main() {
    ch := make(chan int)
    go func() { ch <- 42 }() // sender on its own goroutine
    fmt.Println(<-ch)         // main receives
}

func main() {
    ch := make(chan int, 1)
    ch <- 42
    fmt.Println(<-ch)
}

Snippet 13¶

Difficulty: Hard — Closing a channel from the receiver (Go)

package pipeline

import "sync"

// fanIn merges values from multiple producers into one channel.
func fanIn(producers []<-chan int) <-chan int {
    out := make(chan int)
    var wg sync.WaitGroup

    for _, p := range producers {
        wg.Add(1)
        go func(in <-chan int) {
            defer wg.Done()
            for v := range in {
                out <- v
            }
            close(out) // close when this producer is drained
        }(p)
    }

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

    return out
}

What's wrong?

func fanIn(producers []<-chan int) <-chan int {
    out := make(chan int)
    var wg sync.WaitGroup

    for _, p := range producers {
        wg.Add(1)
        go func(in <-chan int) {
            defer wg.Done()
            for v := range in {
                out <- v // never close here
            }
        }(p)
    }

    go func() {
        wg.Wait()  // all producers drained
        close(out) // exactly one close, by the owner
    }()

    return out
}

Snippet 14¶

Difficulty: Medium — defer mu.Unlock() placed after an early return path (Go)

package store

import (
    "errors"
    "sync"
)

type Store struct {
    mu   sync.Mutex
    data map[string]int
}

func (s *Store) Bump(key string, delta int) (int, error) {
    if delta == 0 {
        return 0, errors.New("delta must be non-zero")
    }

    s.mu.Lock()
    v, ok := s.data[key]
    if !ok {
        return 0, errors.New("key not found") // <-- returns while holding the lock
    }
    defer s.mu.Unlock()

    v += delta
    s.data[key] = v
    return v, nil
}

What's wrong?

func (s *Store) Bump(key string, delta int) (int, error) {
    if delta == 0 {
        return 0, errors.New("delta must be non-zero")
    }

    s.mu.Lock()
    defer s.mu.Unlock() // registered before any early return

    v, ok := s.data[key]
    if !ok {
        return 0, errors.New("key not found") // unlock still runs
    }
    v += delta
    s.data[key] = v
    return v, nil
}

Scorecard¶

Track how many you diagnosed correctly before opening the answer. A correct diagnosis names the racing operations (or the missed signal), explains the intermittency window, and gives the right fix category.

Scoring:

• 12–14: You think in interleavings. You'd catch these in review before they ship.
• 8–11: Solid. Re-study the Hard ones — unsafe publication (7) and split locks (6) are the ones that survive most code reviews.
• 4–7: You spot the obvious races but miss the visibility and ordering subtleties. Internalize the rule that on x86 most visibility bugs hide — test on ARM, run jcstress/-race.
• 0–3: Re-read junior.md for the foundations, then come back. Every bug here maps to one rule there.

The meta-lesson: notice how often the bug is invisible to ordinary tests and only a category-specific tool catches it — -race/TSan for data races, jcstress for memory-model reordering, goleak/pprof for leaks, goroutine dumps for partial deadlocks, and plain reasoning about ordering for logical races that no tool flags. Concurrency correctness is designed in (clear ownership, immutability, one lock per invariant), not tested in.

Related Topics¶

• junior.md — the foundational rules each of these bugs violates.
• tasks.md — hands-on exercises: write the failing test, then the fix.
• Chapter README — the positive concurrency rules and anti-patterns to avoid.
• Anti-Patterns — broader catalog of recurring design mistakes, including concurrency anti-patterns.
• Refactoring — restructuring code (e.g. extracting a single locked critical section, introducing immutability) to make these bugs structurally impossible.