Shared State Anti-Patterns — Find the Bug¶

Category: Concurrency Anti-Patterns → Shared State — mutable data crossing threads without protection, or with protection that doesn't actually protect. Covers (collectively): Shared Mutable State Without Protection · Busy Waiting / Spin Loop · Thread-Per-Request Without Bounds

This file is critical-reading practice. Each snippet below is a plausible chunk of real-world Go or Java (with a Python GIL note where it changes the answer). Your job is to read it the way a reviewer who has been paged at 3 a.m. reads it, and answer three questions:

What's the hazard? Under what interleaving or load does it manifest? How would you fix it?

Concurrency bugs do not announce themselves. The code compiles, the tests pass, the demo works. The bug is a latent property of the code — it needs a specific interleaving of threads, or a specific load, or a specific CPU's memory model to surface. That's exactly why reading for it is a distinct skill: you must simulate the adversarial scheduler in your head. "It worked when I ran it" proves nothing.

How to use this file: read each snippet and write your own answer — what interleaving breaks it? — before expanding the collapsible. Naming the anti-pattern is the easy half; the hard half is constructing the exact schedule that corrupts state. One snippet below is a deliberate trap: it looks racy and is in fact perfectly safe. Don't let the pattern-matching reflex cost you.

A note on Go specifically: most of the Go data races here are caught by go test -race / go run -race. The race detector is the single highest-leverage tool in this chapter — but it only reports races on code paths that actually execute under a race during the run. It finds bugs; it does not prove their absence. Read as if you don't have it, then run it to confirm.

Table of Contents¶

1. The view counter that drifts
2. The cache that panics under load
3. The worker that never wakes
4. The fan-out that fans into the loop variable
5. One goroutine per connection
6. The progress poller
7. The results slice everyone appends to
8. The double-checked ready flag
9. The metrics aggregator that looks racy
10. The Java request dispatcher
11. The retry counter on the hot path
12. The graceful shutdown that hangs
13. The lazy singleton everyone shares
14. The Python scraper that "uses threads"

Snippet 1 — The view counter that drifts¶

// Go — counts page views across many request-handling goroutines
type Counter struct {
    views int64
}

func (c *Counter) Inc() {
    c.views++           // called from every request goroutine
}

func (c *Counter) Value() int64 {
    return c.views
}

// in main: 1000 goroutines, each calling Inc() 1000 times.
// Expected final value: 1,000,000.

What's the hazard? Under what interleaving does it manifest? How would you fix it?

G1: load views (=41)
G2: load views (=41)
G1: add 1 -> 42
G2: add 1 -> 42
G1: store 42
G2: store 42        // one increment lost; should be 43

import "sync/atomic"

type Counter struct {
    views atomic.Int64       // Go 1.19+ typed atomic
}

func (c *Counter) Inc()         { c.views.Add(1) }
func (c *Counter) Value() int64 { return c.views.Load() }

Snippet 2 — The cache that panics under load¶

// Go — a memoizing cache shared by all request handlers
type Cache struct {
    data map[string][]byte
}

func New() *Cache { return &Cache{data: make(map[string][]byte)} }

func (c *Cache) Get(key string) ([]byte, bool) {
    v, ok := c.data[key]        // read
    return v, ok
}

func (c *Cache) Set(key string, val []byte) {
    c.data[key] = val           // write
}

// Get and Set are called concurrently from thousands of goroutines.

What's the hazard? Under what interleaving or load does it manifest? How would you fix it?

type Cache struct {
    mu   sync.RWMutex
    data map[string][]byte
}

func (c *Cache) Get(key string) ([]byte, bool) {
    c.mu.RLock()
    defer c.mu.RUnlock()
    v, ok := c.data[key]
    return v, ok
}

func (c *Cache) Set(key string, val []byte) {
    c.mu.Lock()
    defer c.mu.Unlock()
    c.data[key] = val
}

Snippet 3 — The worker that never wakes¶

// Go — background worker that should stop when `stopped` flips
type Worker struct {
    stopped bool
    jobs    chan Job
}

func (w *Worker) Run() {
    for !w.stopped {            // spin until told to stop
        select {
        case j := <-w.jobs:
            j.Do()
        default:
            // nothing to do right now
        }
    }
}

func (w *Worker) Stop() {
    w.stopped = true            // flip the flag from another goroutine
}

What's the hazard? Under what interleaving does it manifest? How would you fix it?

type Worker struct {
    jobs chan Job
}

func (w *Worker) Run(ctx context.Context) {
    for {
        select {
        case <-ctx.Done():     // wakes immediately on cancel; no spinning
            return
        case j := <-w.jobs:    // blocks (parks the goroutine) until a job arrives
            j.Do()
        }
    }
}

// caller:
ctx, cancel := context.WithCancel(context.Background())
go w.Run(ctx)
// ...later...
cancel()                       // happens-before the receive on ctx.Done()

Snippet 4 — The fan-out that fans into the loop variable¶

// Go (built with Go 1.21 or earlier) — launch one goroutine per URL
func fetchAll(urls []string) map[string]int {
    results := make(map[string]int)
    var wg sync.WaitGroup
    for _, u := range urls {
        wg.Add(1)
        go func() {
            defer wg.Done()
            code := httpGet(u)        // captures loop variable u
            results[u] = code         // writes shared map
        }()
    }
    wg.Wait()
    return results
}

What's the hazard? (There are two.) Under what conditions does each manifest? How would you fix it?

func fetchAll(urls []string) map[string]int {
    results := make(map[string]int)
    var mu sync.Mutex
    var wg sync.WaitGroup
    for _, u := range urls {
        u := u                       // shadow: fresh var per iteration (no-op but harmless on 1.22+)
        wg.Add(1)
        go func() {
            defer wg.Done()
            code := httpGet(u)
            mu.Lock()
            results[u] = code        // serialized; no concurrent map write
            mu.Unlock()
        }()
    }
    wg.Wait()
    return results
}

Snippet 5 — One goroutine per connection¶

// Go — a TCP server accepting client connections
func serve(ln net.Listener) {
    for {
        conn, err := ln.Accept()
        if err != nil {
            continue
        }
        go handle(conn)             // one goroutine per connection, forever
    }
}

func handle(conn net.Conn) {
    defer conn.Close()
    buf := make([]byte, 64*1024)    // 64 KB scratch buffer per connection
    for {
        n, err := conn.Read(buf)
        if err != nil {
            return
        }
        process(buf[:n])            // process() can take seconds under load
    }
}

What's the hazard? Under what load does it manifest? How would you fix it?

var sem = make(chan struct{}, 2000)   // at most 2000 concurrent handlers

func serve(ln net.Listener) {
    for {
        conn, err := ln.Accept()
        if err != nil {
            continue
        }
        sem <- struct{}{}              // blocks once 2000 are in flight (back-pressure)
        go func() {
            defer func() { <-sem }()
            handle(conn)
        }()
    }
}

Snippet 6 — The progress poller¶

// Java — wait for a background import to finish, then read the result
class Importer {
    private boolean done = false;
    private int rowsImported = 0;

    void runImport() {                 // executed on a background thread
        rowsImported = doImport();     // takes ~10s
        done = true;
    }

    int awaitResult() {                // called from the main thread
        while (!done) {
            // spin until the import finishes
        }
        return rowsImported;
    }
}

What's the hazard? (There are two.) Under what conditions does each manifest? How would you fix it?

class Importer {
    private final CountDownLatch latch = new CountDownLatch(1);
    private volatile int rowsImported = 0;

    void runImport() {
        rowsImported = doImport();
        latch.countDown();          // publishes rowsImported with happens-before
    }

    int awaitResult() throws InterruptedException {
        latch.await();              // blocks (0% CPU) until countDown; no spin
        return rowsImported;
    }
}

Snippet 7 — The results slice everyone appends to¶

// Go — parallel map: apply f to each input, collect outputs
func parallelMap(inputs []int, f func(int) int) []int {
    var results []int
    var wg sync.WaitGroup
    for _, x := range inputs {
        x := x
        wg.Add(1)
        go func() {
            defer wg.Done()
            results = append(results, f(x))   // append from many goroutines
        }()
    }
    wg.Wait()
    return results
}

What's the hazard? Under what interleaving does it manifest? How would you fix it?

func parallelMap(inputs []int, f func(int) int) []int {
    results := make([]int, len(inputs))   // preallocated; fixed length
    var wg sync.WaitGroup
    for i, x := range inputs {
        i, x := i, x
        wg.Add(1)
        go func() {
            defer wg.Done()
            results[i] = f(x)             // each goroutine owns one distinct index
        }()
    }
    wg.Wait()
    return results
}

Snippet 8 — The double-checked ready flag¶

// Go — share config loaded once at startup with request goroutines
var (
    config *Config
    ready  bool
)

func loadConfig() {                 // called once, from a startup goroutine
    c := parse(readFile("config.yaml"))
    config = c
    ready = true                    // signal: config is now populated
}

func handler() {
    if !ready {                     // fast path: skip work until ready
        return                      // serve 503 until config loaded
    }
    use(config.Timeout)             // assumes config != nil once ready == true
}

What's the hazard? Under what interleaving does it manifest? How would you fix it?

var (
    config *Config
    once   sync.Once
)

func getConfig() *Config {
    once.Do(func() {
        config = parse(readFile("config.yaml"))   // runs exactly once
    })
    return config                                 // safe: Do() happens-before Do() returns
}

func handler() {
    cfg := getConfig()      // blocks the first time, cheap thereafter; never nil after return
    use(cfg.Timeout)
}

Snippet 9 — The metrics aggregator that looks racy¶

// Go — collect a count from each worker, then sum. Looks like a shared-state race?
func aggregate(work [][]int) int {
    partial := make(chan int, len(work))   // buffered so senders never block

    for _, chunk := range work {
        chunk := chunk
        go func() {
            sum := 0
            for _, v := range chunk {
                sum += v               // mutates a LOCAL variable
            }
            partial <- sum             // publish only via the channel
        }()
    }

    total := 0
    for range work {
        total += <-partial             // single goroutine reads & sums
    }
    return total
}

What's the hazard? Under what interleaving does it manifest? How would you fix it?

Snippet 10 — The Java request dispatcher¶

// Java — handle each incoming request on its own thread
class Server {
    void serve(ServerSocket socket) throws IOException {
        while (true) {
            Socket conn = socket.accept();
            new Thread(() -> handle(conn)).start();   // new OS thread per request
        }
    }

    void handle(Socket conn) {
        try (conn) {
            byte[] req = readRequest(conn);
            byte[] resp = process(req);    // calls a slow downstream API
            writeResponse(conn, resp);
        } catch (IOException e) { /* log */ }
    }
}

What's the hazard? Under what load does it manifest? How would you fix it?

class Server {
    // bounded pool + bounded queue + a rejection policy = survivable under overload
    private final ExecutorService pool = new ThreadPoolExecutor(
        50, 200, 60, TimeUnit.SECONDS,
        new ArrayBlockingQueue<>(1000),
        new ThreadPoolExecutor.CallerRunsPolicy());   // back-pressure when saturated

    void serve(ServerSocket socket) throws IOException {
        while (true) {
            Socket conn = socket.accept();
            pool.submit(() -> handle(conn));
        }
    }
}

Snippet 11 — The retry counter on the hot path¶

// Go — count retries across all in-flight requests, guarded by a mutex
type Stats struct {
    mu      sync.Mutex
    retries int
}

func (s *Stats) recordRetry() {
    s.mu.Lock()
    s.retries++
    s.mu.Unlock()
}

func (s *Stats) Snapshot() int {
    return s.retries          // read without the lock — "it's just an int read"
}

What's the hazard? Under what interleaving does it manifest? How would you fix it?

// Option A: read under the lock (consistent with the existing write path)
func (s *Stats) Snapshot() int {
    s.mu.Lock()
    defer s.mu.Unlock()
    return s.retries
}

// Option B (better for a single counter): no mutex at all, just an atomic
type Stats struct {
    retries atomic.Int64
}
func (s *Stats) recordRetry()  { s.retries.Add(1) }
func (s *Stats) Snapshot() int64 { return s.retries.Load() }

Snippet 12 — The graceful shutdown that hangs¶

// Go — drain a pipeline on shutdown by busy-checking a counter
type Pipeline struct {
    inFlight int32          // incremented on start, decremented on finish
}

func (p *Pipeline) Submit(job Job) {
    atomic.AddInt32(&p.inFlight, 1)
    go func() {
        defer atomic.AddInt32(&p.inFlight, -1)
        job.Run()
    }()
}

func (p *Pipeline) Shutdown() {
    for atomic.LoadInt32(&p.inFlight) > 0 {
        // wait for all in-flight jobs to drain
    }
    log.Println("drained, shutting down")
}

What's the hazard? (The counter itself is fine — look at the loop.) How would you fix it?

type Pipeline struct {
    wg sync.WaitGroup
}

func (p *Pipeline) Submit(job Job) {
    p.wg.Add(1)
    go func() {
        defer p.wg.Done()
        job.Run()
    }()
}

func (p *Pipeline) Shutdown() {
    p.wg.Wait()                 // parks the goroutine; 0% CPU until count hits 0
    log.Println("drained, shutting down")
}

Snippet 13 — The lazy singleton everyone shares¶

// Java — a lazily-initialized shared connection pool
class Pool {
    private static Pool instance;

    private final List<Conn> conns = new ArrayList<>();

    static Pool getInstance() {
        if (instance == null) {            // checked without a lock
            instance = new Pool();         // constructed without a lock
        }
        return instance;
    }

    Conn acquire() { return conns.remove(conns.size() - 1); }
    void release(Conn c) { conns.add(c); }
}

What's the hazard? (There are two layers.) Under what interleaving does each manifest? How would you fix it?

class Pool {
    // Initialization-on-demand holder idiom: thread-safe, lazy, lock-free.
    private static class Holder { static final Pool INSTANCE = new Pool(); }
    static Pool getInstance() { return Holder.INSTANCE; }

    // A blocking queue is the right structure for a connection pool anyway:
    // thread-safe AND it lets acquire() wait when the pool is empty.
    private final BlockingQueue<Conn> conns = new LinkedBlockingQueue<>();

    Conn acquire() throws InterruptedException { return conns.take(); }
    void release(Conn c) { conns.offer(c); }
}

Snippet 14 — The Python scraper that "uses threads"¶

# Python (CPython) — scrape many URLs concurrently with threads
import threading

results = {}                       # shared dict, no lock

def scrape(url):
    html = fetch(url)              # network I/O (releases the GIL while waiting)
    results[url] = parse(html)     # write into the shared dict

def scrape_all(urls):
    threads = [threading.Thread(target=scrape, args=(u,)) for u in urls]
    for t in threads: t.start()
    for t in threads: t.join()
    return results

What's the hazard? Does the GIL save you? Under what load does it manifest? How would you fix it?

from concurrent.futures import ThreadPoolExecutor, as_completed

def scrape_all(urls):
    results = {}
    with ThreadPoolExecutor(max_workers=20) as pool:   # bounded
        futures = {pool.submit(fetch_and_parse, u): u for u in urls}
        for fut in as_completed(futures):
            url = futures[fut]
            results[url] = fut.result()   # written by ONE thread (the main loop)
    return results

def fetch_and_parse(url):
    return parse(fetch(url))              # pure: no shared state touched

Summary — patterns of spotting¶

You don't spot a concurrency bug by reading a single line — you spot it by simulating the adversarial scheduler and asking a fixed set of questions. The repeatable moves from these fourteen snippets:

• Find every piece of mutable state and ask "who else touches this?" If a variable, map, slice, or field is read or written by more than one goroutine/thread and any of those is a write, you need synchronization — a lock, an atomic, or a channel handing off ownership. A counter (x++, Snippets 1, 14), a built-in map (Snippets 2, 4), a slice append (Snippet 7), and an ArrayList (Snippet 13) are all unsafe under concurrent mutation. In Go, a racy map crashes the whole process; in Java a racy HashMap can infinite-loop a core.
• A partial lock is no lock. Synchronizing the writes but reading without the lock is still a data race (Snippet 11). Every access — reads included — must use the same mechanism.
• Distrust every spin loop with an empty body. for !done {} / while (!done) {} is Busy Waiting: it burns 100% of a core and often steals cycles from the thread it's waiting on (Snippets 3, 6, 12). Replace polling with a blocking primitive that wakes on the event — channel/context (Go), CountDownLatch/Future/WaitGroup.
• A bare flag across goroutines is a visibility trap, not just a style nit. Without volatile (Java) or an atomic/channel/lock (Go), a writer's update to a flag may never become visible to a spinning reader — the loop hangs forever — and independent writes may be reordered, publishing a "ready" flag before the data it guards (Snippets 3, 6, 8). Happens-before edges (channel send/receive, sync.Once, lock acquire/release, volatile write/read) are what make a value safely visible.
• Count where concurrency is bounded — and panic if the answer is "it isn't." go handle(conn) or new Thread(...) in an accept loop with no cap is Thread-Per-Request Without Bounds (Snippets 5, 10, 14). It's fine in the demo and fatal under load: fd exhaustion, OOM, scheduler collapse — abruptly, with no graceful slope. Bound it with a semaphore or a fixed pool so overload becomes back-pressure, and remember a slow downstream silently multiplies your thread/goroutine count (Little's Law).
• Know your loop-variable semantics. Capturing a loop variable in a goroutine/lambda is a correctness bug on Go ≤ 1.21, Java lambdas, pre-let JS, and friends (Snippet 4) — independent of any data race that may also be present.
• The GIL is not synchronization. CPython's GIL makes a single bytecode atomic, not your logical operation; x += 1 and read-modify-write on a dict still lose updates, and free-threaded Python removes the accidental safety entirely (Snippets 1, 14).
• Resist the false positive. Goroutines/threads writing to local, confined state and publishing results only through a channel are provably safe — adding a mutex there is cargo-culting (Snippet 9). The hazard is sharing mutable state, not mutating it.

The deeper cure runs through the whole chapter: the root cause is almost always shared mutable state, and every lock, atomic, and volatile is a patch over it. The structural fix — confine state to one goroutine, pass ownership over channels, or make data immutable — removes the hazard instead of guarding it.

Related Topics¶

• tasks.md — small concurrent programs to fix from the writing side.
• junior.md — what each shared-state bug looks like and why it's hard to reproduce.
• middle.md — how to detect these (the race detector, -race, stress tests) and the safer patterns.
• senior.md — debugging a corrupted map or a runaway thread count in production.
• optimize.md — making these implementations both safe and fast.
• interview.md — Q&A across all levels.
• Synchronization Misuse → Find the Bug — the sibling chapter on locks and memory ordering used wrongly.
• Coordination → Find the Bug — deadlocks and lock-granularity bugs.
• Clean Code → Immutability — removing shared mutable state at the source.
• Refactoring → Code Smells — the smell-level view of shared state.
• Concurrency & Async Parallelism — the positive primitives and memory models behind these fixes.