Shared State Anti-Patterns — Refactoring Practice¶

Category: Concurrency Anti-Patterns → Shared State — mutable data crossing threads without the right protection. Covers (collectively): Shared Mutable State Without Protection · Busy Waiting / Spin Loop · Thread-Per-Request Without Bounds

These are not "spot the race" puzzles — find-bug.md does that. Here the code already runs and usually produces the right answer, and your job is to make it correct under concurrency and scalable under load without changing what it computes. The skill on display is the discipline, not the destination:

1. Reproduce the failure with a tool, not with luck. A race is invisible until you point an instrument at it: Go's -race detector, Java's jcstress/TSan, a ThreadSanitizer build, or a load generator that drives real concurrency. "It passed once" is not evidence.
2. Fix with the cheapest correct primitive. Confinement < immutability < channel/queue < atomic < mutex < lock-free, roughly in order of how easy they are to reason about. Reach for the simplest one that makes the invariant true.
3. Verify the fix the same way you reproduced the bug. Re-run -race to green; re-run the load test and watch the metric move (CPU drops, p99 stabilizes, goroutine count plateaus). Then benchmark to confirm you didn't trade a race for a contention cliff.

How to use this file: read the "Before," predict which tool would catch the bug and which primitive you'd reach for before expanding the solution. The gap between your plan and the worked plan is the learning.

A recurring theme: the fastest fix is often to stop sharing. Confinement, value-passing, and immutability remove the data race at the root; locks and atomics only manage a race you chose to keep. The exercises deliberately include cases where keeping a plain mutex (or a small unbounded fan-out) is the correct, simple answer — knowing when not to reach for the fancy primitive is senior judgment.

Table of Contents¶

Python note. The CPython GIL serializes bytecode, so x += 1 looks atomic — but it is not: += is LOAD/ADD/STORE, three bytecodes, and a thread switch can land between them, so lost updates happen in pure Python too. The GIL only guarantees that a single bytecode is uninterrupted. Use threading.Lock, queue.Queue, or concurrent.futures exactly as you would elsewhere; and for CPU-bound work the GIL means you want multiprocessing/a process pool, not threads, regardless of correctness. Go and Java examples below transfer directly.

Exercise 1 — The lost-update counter¶

Anti-pattern: Shared Mutable State Without Protection. Goal: make a concurrent counter correct. Constraints: same final value as a single-threaded run (N increments ⇒ N); must pass -race.

// Before — N goroutines each do counter++ on a shared int. Racy.
func CountConcurrently(n int) int {
    counter := 0
    var wg sync.WaitGroup
    wg.Add(n)
    for i := 0; i < n; i++ {
        go func() {
            defer wg.Done()
            counter++ // read-modify-write, not atomic
        }()
    }
    wg.Wait()
    return counter // often < n, and varies run to run
}

// After — atomic increment; lock-free and correct.
func CountConcurrently(n int) int64 {
    var counter atomic.Int64
    var wg sync.WaitGroup
    wg.Add(n)
    for i := 0; i < n; i++ {
        go func() {
            defer wg.Done()
            counter.Add(1)
        }()
    }
    wg.Wait()
    return counter.Load()
}

Exercise 2 — Map written from many goroutines¶

Anti-pattern: Shared Mutable State Without Protection. Goal: make a concurrent word-frequency aggregator correct. Constraints: same counts as a serial run; must pass -race. This is the counter-case where a plain mutex is the right, simple answer — keep it.

// Before — concurrent writes to a map. Go maps are NOT safe for concurrent write.
func WordCounts(docs [][]string) map[string]int {
    counts := map[string]int{}
    var wg sync.WaitGroup
    for _, doc := range docs {
        wg.Add(1)
        go func(d []string) {
            defer wg.Done()
            for _, w := range d {
                counts[w]++ // concurrent map write → fatal "concurrent map writes"
            }
        }(doc)
    }
    wg.Wait()
    return counts
}

// After — a plain mutex. The correct, simple answer for a shared map.
func WordCounts(docs [][]string) map[string]int {
    counts := map[string]int{}
    var mu sync.Mutex
    var wg sync.WaitGroup
    for _, doc := range docs {
        wg.Add(1)
        go func(d []string) {
            defer wg.Done()
            local := map[string]int{} // count per-doc lock-free...
            for _, w := range d {
                local[w]++
            }
            mu.Lock() // ...then merge under the lock once per doc
            for w, c := range local {
                counts[w] += c
            }
            mu.Unlock()
        }(doc)
    }
    wg.Wait()
    return counts
}

Exercise 3 — Confine state to one owner goroutine¶

Anti-pattern: Shared Mutable State Without Protection. Goal: serve a counter to many callers without a lock, by confining the state. Constraints: correct totals; -race clean; demonstrates the channel-as-monitor alternative to locking.

// Before — shared balance behind ad-hoc, inconsistent locking.
type Account struct {
    mu      sync.Mutex
    balance int
}

func (a *Account) Deposit(n int) { a.mu.Lock(); a.balance += n; a.mu.Unlock() }
func (a *Account) Balance() int  { return a.balance } // BUG: unlocked read races with Deposit

// After (a) — the minimal correct fix: lock the read as well.
func (a *Account) Balance() int {
    a.mu.Lock()
    defer a.mu.Unlock()
    return a.balance
}

// After (b) — confinement: state owned by one goroutine, accessed via channels.
type Account struct {
    deposits chan int
    queries  chan chan int
}

func NewAccount() *Account {
    a := &Account{deposits: make(chan int), queries: make(chan chan int)}
    go a.loop() // the single owner of `balance`
    return a
}

func (a *Account) loop() {
    balance := 0 // confined: no other goroutine can touch this
    for {
        select {
        case n := <-a.deposits:
            balance += n
        case reply := <-a.queries:
            reply <- balance
        }
    }
}

func (a *Account) Deposit(n int) { a.deposits <- n }
func (a *Account) Balance() int {
    reply := make(chan int)
    a.queries <- reply
    return <-reply
}

Exercise 4 — Stop the spin: a done flag¶

Anti-pattern: Busy Waiting / Spin Loop. Goal: wait for completion without burning a CPU. Constraints: same "wait until worker finishes" semantics; CPU usage during the wait must drop to ~0.

// Before — spin on a bool. 100% of one core, and the read is itself a race.
func WaitForWorker(work func()) {
    done := false
    go func() {
        work()
        done = true // racy write
    }()
    for !done { // busy-wait: pegs a core; may also never observe the write
        // nothing
    }
}

// After — block on a channel close. Zero CPU while waiting, memory-safe.
func WaitForWorker(work func()) {
    done := make(chan struct{})
    go func() {
        work()
        close(done) // signal + happens-before edge
    }()
    <-done // parks the goroutine; no spinning
}

Exercise 5 — Condition variable, not sleep(10ms)¶

Anti-pattern: Busy Waiting / Spin Loop (sleep-poll variant). Goal: block until a bounded buffer has space, without periodic wakeups. Constraints: identical "wait until not full" semantics; no fixed-interval polling.

// Before — Java. "Poll-sleep" is busy waiting with extra latency AND a race.
class Buffer {
    private final int[] data;
    private int size = 0;
    Buffer(int cap) { data = new int[cap]; }

    void put(int x) throws InterruptedException {
        while (size == data.length) {
            Thread.sleep(10); // wake every 10ms to re-check — wasteful AND racy
        }
        data[size++] = x;     // unsynchronized: size races with take()
    }
    int take() {
        int x = data[--size]; // also unsynchronized
        return x;
    }
}

// After — intrinsic lock + condition predicates. Blocks precisely, no polling.
class Buffer {
    private final int[] data;
    private int size = 0;
    Buffer(int cap) { data = new int[cap]; }

    synchronized void put(int x) throws InterruptedException {
        while (size == data.length) {
            wait();                 // releases the lock, parks until notified
        }
        data[size++] = x;
        notifyAll();                // a slot was added → wake takers
    }

    synchronized int take() throws InterruptedException {
        while (size == 0) {
            wait();
        }
        int x = data[--size];
        notifyAll();                // a slot freed → wake putters
        return x;
    }
}

Exercise 6 — Producer/consumer with a blocking queue¶

Anti-pattern: Busy Waiting + Shared Mutable State. Goal: hand work from producers to consumers without polling or hand-rolled locking. Constraints: every produced item consumed exactly once; no busy-wait; bounded memory.

// Before — shared ArrayList + a poll loop. Racy and spinning.
class Pipeline {
    private final List<Task> queue = new ArrayList<>(); // not thread-safe

    void produce(Task t) { queue.add(t); }              // concurrent add → corruption

    void consumeLoop() {
        while (true) {
            if (!queue.isEmpty()) {
                Task t = queue.remove(0);                // races with add and other consumers
                t.run();
            } // else: spin (busy wait), pegging the CPU
        }
    }
}

// After — ArrayBlockingQueue carries thread-safety, blocking, and backpressure.
class Pipeline {
    private final BlockingQueue<Task> queue = new ArrayBlockingQueue<>(1024);
    private static final Task POISON = () -> {};

    void produce(Task t) throws InterruptedException {
        queue.put(t);            // blocks if full → backpressure, bounded memory
    }

    void consumeLoop() throws InterruptedException {
        while (true) {
            Task t = queue.take(); // blocks (0 CPU) until an item arrives
            if (t == POISON) {
                queue.put(POISON); // re-arm for sibling consumers, then exit
                return;
            }
            t.run();
        }
    }
}

Exercise 7 — Bound the goroutine-per-request fan-out¶

Anti-pattern: Thread-Per-Request Without Bounds. Goal: process a stream of jobs concurrently with a ceiling, so a traffic spike can't exhaust memory. Constraints: every job processed; total concurrency capped; survives a load test that OOM'd the original.

// Before — one goroutine per job, unbounded. 1M jobs → 1M goroutines → OOM/scheduler thrash.
func ProcessAll(jobs []Job) {
    var wg sync.WaitGroup
    for _, j := range jobs {
        wg.Add(1)
        go func(j Job) { // unbounded fan-out
            defer wg.Done()
            handle(j) // each holds a buffer, a conn, etc.
        }(j)
    }
    wg.Wait()
}

// After — fixed worker pool; concurrency capped at W; channel gives backpressure.
func ProcessAll(jobs []Job, workers int) {
    jobCh := make(chan Job) // unbuffered → producer blocks when all workers are busy
    var wg sync.WaitGroup

    wg.Add(workers)
    for i := 0; i < workers; i++ {
        go func() {
            defer wg.Done()
            for j := range jobCh { // pull until channel closed
                handle(j)
            }
        }()
    }

    for _, j := range jobs {
        jobCh <- j // blocks here under load = backpressure, not unbounded spawn
    }
    close(jobCh) // no more work → workers drain and exit
    wg.Wait()
}

Exercise 8 — Bound a thread-per-task server¶

Anti-pattern: Thread-Per-Request Without Bounds. Goal: stop spawning an OS thread per connection. Constraints: same request handling; bounded threads; defined behavior under overload (reject or queue, not crash).

// Before — new Thread per accepted socket. OS threads are ~1MB stack each.
void serve(ServerSocket server) throws IOException {
    while (true) {
        Socket conn = server.accept();
        new Thread(() -> handle(conn)).start(); // 10k connections → 10k threads → OOM
    }
}

// After — fixed pool + bounded queue + explicit overload policy.
ExecutorService pool = new ThreadPoolExecutor(
    /* core   */ 32,
    /* max    */ 32,
    /* keepAlive */ 0L, TimeUnit.MILLISECONDS,
    /* bounded queue */ new ArrayBlockingQueue<>(1000),
    /* on overload  */ new ThreadPoolExecutor.CallerRunsPolicy() // backpressure to acceptor
);

void serve(ServerSocket server) throws IOException {
    while (true) {
        Socket conn = server.accept();
        pool.execute(() -> handle(conn)); // capped threads; queue absorbs bursts
    }
}

Exercise 9 — Semaphore-limited concurrency¶

Anti-pattern: Thread-Per-Request Without Bounds. Goal: limit concurrent calls to a downstream (e.g., an API allowing 10 in-flight requests) while still launching goroutines naturally. Constraints: never more than N in flight; all calls complete; respects cancellation.

// Before — fan out one goroutine per URL with no cap. Downstream gets hammered / rate-limited.
func FetchAll(urls []string) []Result {
    results := make([]Result, len(urls))
    var wg sync.WaitGroup
    for i, u := range urls {
        wg.Add(1)
        go func(i int, u string) { // 10k URLs → 10k simultaneous requests → 429s / connection storm
            defer wg.Done()
            results[i] = fetch(u)
        }(i, u)
    }
    wg.Wait()
    return results
}

// After — semaphore caps concurrency at N; context-aware.
import "golang.org/x/sync/semaphore"

func FetchAll(ctx context.Context, urls []string, max int64) ([]Result, error) {
    results := make([]Result, len(urls))
    sem := semaphore.NewWeighted(max)
    var wg sync.WaitGroup

    for i, u := range urls {
        if err := sem.Acquire(ctx, 1); err != nil { // blocks past N; aborts on ctx cancel
            break
        }
        wg.Add(1)
        go func(i int, u string) {
            defer wg.Done()
            defer sem.Release(1)
            results[i] = fetch(u) // results[i] is a disjoint slot → no lock needed
        }(i, u)
    }
    wg.Wait()
    return results, ctx.Err()
}

Exercise 10 — Kill false sharing with padding¶

Anti-pattern: Shared State at the cache-line level (false sharing). Goal: stop independent per-worker counters from thrashing the same cache line. Constraints: identical results; measurably faster under -bench. This one is correct-but-slow — a performance race, not a data race.

// Before — per-worker counters packed adjacently. They share a 64-byte cache line.
type Counters struct {
    c [8]int64 // 8 × 8 bytes = 64 bytes = ONE cache line; 8 cores fight over it
}

func (cs *Counters) Bump(worker int) {
    atomic.AddInt64(&cs.c[worker], 1) // correct, but every core invalidates the others' line
}

go test -bench=BumpParallel -cpu=1,2,4,8 -benchmem
# Before: ns/op climbs sharply from 1→8 CPUs (contention on one line)

// After — each counter owns a full cache line. No false sharing.
const cacheLine = 64

type paddedCounter struct {
    v   int64
    _   [cacheLine - 8]byte // pad so the next counter starts on a new line
}

type Counters struct {
    c [8]paddedCounter
}

func (cs *Counters) Bump(worker int) {
    atomic.AddInt64(&cs.c[worker].v, 1)
}

func BenchmarkBumpParallel(b *testing.B) {
    cs := &Counters{}
    b.RunParallel(func(pb *testing.PB) {
        w := int(rand.Int31n(8))
        for pb.Next() {
            cs.Bump(w)
        }
    })
}

Exercise 11 — Immutable snapshot for readers¶

Anti-pattern: Shared Mutable State Without Protection (read-heavy config). Goal: let many goroutines read a config that an occasional writer replaces, with zero reader locking. Constraints: readers always see a consistent snapshot; -race clean; readers never block.

// Before — readers and the writer touch the same map under no / partial locking.
type Config struct {
    settings map[string]string // writer mutates in place; readers race
}

func (c *Config) Get(k string) string { return c.settings[k] }    // racy read
func (c *Config) Reload(m map[string]string) { c.settings = m }   // racy write + torn for readers

// After — immutable snapshots, atomic pointer swap. Lock-free reads.
type Config struct {
    snapshot atomic.Pointer[map[string]string]
}

func NewConfig(initial map[string]string) *Config {
    c := &Config{}
    c.snapshot.Store(&initial) // initial is treated as frozen from here on
    return c
}

func (c *Config) Get(k string) string {
    m := *c.snapshot.Load() // atomic load of an immutable map
    return m[k]
}

func (c *Config) Reload(next map[string]string) {
    c.snapshot.Store(&next) // publish a brand-new map; never mutate in place
}

Exercise 12 — Channel vs mutex — pick the right one¶

Anti-pattern: Shared Mutable State Without Protection — and the judgment of when the simple guard is correct. Goal: make a small in-memory cache safe, and decide between a mutex and a channel-owned goroutine. Constraints: correct under concurrency; choose the simpler correct design and justify it; this is the KEEP-the-mutex counter-case.

// Before — a tiny LRU-ish cache with an unsynchronized map. Racy.
type Cache struct {
    m map[string][]byte
}

func (c *Cache) Get(k string) ([]byte, bool) { v, ok := c.m[k]; return v, ok } // racy
func (c *Cache) Put(k string, v []byte)      { c.m[k] = v }                    // racy

// After — a plain mutex. The correct, simple answer; we deliberately do NOT use channels.
type Cache struct {
    mu sync.RWMutex
    m  map[string][]byte
}

func NewCache() *Cache { return &Cache{m: map[string][]byte{}} }

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

func (c *Cache) Put(k string, v []byte) {
    c.mu.Lock()
    defer c.mu.Unlock()
    c.m[k] = v
}

Exercise 13 — The full combo: racy, spinning, unbounded¶

Anti-pattern: all three at once. Goal: refactor a "results aggregator" that shares an unprotected map, busy-waits for completion, and spawns an unbounded goroutine per item. Constraints: same aggregated result; -race clean; bounded concurrency; no spinning; tackle the patterns in a safe order.

// Before — a bit of everything wrong.
func Aggregate(items []int) map[int]int {
    results := map[int]int{} // shared mutable state, unprotected
    pending := len(items)

    for _, it := range items {
        go func(it int) { // unbounded goroutine-per-item
            results[expensive(it)]++ // concurrent map write → race/panic
            pending--                // racy decrement
        }(it)
    }

    for pending > 0 { // busy-wait spin on a racy counter
        // nothing
    }
    return results
}

// After — confinement + worker pool + WaitGroup. No race, no spin, bounded.
func Aggregate(items []int, workers int) map[int]int {
    jobs := make(chan int)
    partials := make(chan int) // each worker sends the key it computed

    var wg sync.WaitGroup
    wg.Add(workers)
    for i := 0; i < workers; i++ {
        go func() {
            defer wg.Done()
            for it := range jobs {
                partials <- expensive(it) // hand the result to the single owner
            }
        }()
    }

    // Single owner of `results` → confinement → no lock required.
    results := map[int]int{}
    done := make(chan struct{})
    go func() {
        for key := range partials {
            results[key]++ // only this goroutine ever writes the map
        }
        close(done)
    }()

    // Feed jobs (backpressure: unbuffered channel blocks when workers are busy).
    for _, it := range items {
        jobs <- it
    }
    close(jobs)        // workers finish their range and exit
    wg.Wait()          // all workers done...
    close(partials)    // ...so no more partials will be sent; collector can finish
    <-done             // wait for the collector to drain (0 CPU, no spin)
    return results
}

Refactoring discipline (concurrency) — the recap¶

Every exercise above runs the same loop. Internalize it and the specific primitives become mechanical:

reproduce with a tool  →  fix with the cheapest correct primitive  →  verify with the same tool  →  benchmark  →  commit

• Reproduce with an instrument, never by eye. A data race is invisible until -race / jcstress / TSan points at it; a busy-wait is invisible until top shows a pegged core; an unbounded fan-out is invisible until a load test OOMs. "It passed once" proves nothing about concurrency. Make the failure reproducible before you touch the code.
• Prefer eliminating the share over guarding it. Confinement (one owner goroutine), value-passing, and immutability remove the race at the root; locks and atomics only manage a race you chose to keep. Reach down the ladder — confinement < immutability < channel/queue < atomic < mutex < lock-free — and stop at the first rung that makes the invariant true.
• Match the primitive to the shape. atomic for one independent word (Ex. 1); a plain mutex for a couple of guarded fields (Ex. 2, 12); a channel/condition var/blocking queue to wait on an event without spinning (Ex. 4, 5, 6); a bounded pool/semaphore to cap concurrency on the limiting resource (Ex. 7, 8, 9); an immutable snapshot for read-mostly state (Ex. 11).
• Bound on the resource, not the request. Thread/goroutine-per-request fails because each one holds memory, a connection, a downstream slot. Put the cap where the scarce resource is, and use a bounded channel/queue so saturation becomes backpressure, not a crash.
• Verify, then benchmark. Re-run the detector to green; re-run the load test and watch the metric move; then -bench to confirm you didn't trade a race for a contention cliff (false sharing, Ex. 10) or an over-engineered monitor for a one-line mutex (Ex. 12).
• Know when to keep it simple. A plain mutex on a small map (Ex. 2) and choosing a mutex over a channel monitor (Ex. 12) are the right answers. Converting every lock into a goroutine-and-channels machine, or padding every struct, or sharding every map, is the over-correction — concurrency's version of Lasagna Code.

Related Topics¶

• tasks.md — guided exercises building these primitives from scratch.
• find-bug.md — the spotting counterpart: identify the race / spin / unbounded fan-out, don't fix it.
• junior.md · middle.md · senior.md · professional.md — recognize → countermove → refactor-at-scale → memory models & lock-free.
• Refactoring → Refactoring Techniques — the mechanical catalog (Extract Function, Replace Conditional, etc.) underpinning the structural moves above.
• Clean Code → Immutability — the immutable-snapshot cure (Ex. 11) at the principle level.
• Over-Engineering — Lasagna Code: the over-correction to avoid when reaching past a simple mutex.
• Concurrency Anti-Patterns — the chapter overview and the other two categories (Synchronization Misuse, Coordination).