Synchronization Misuse Anti-Patterns — Find the Bug¶

Category: Concurrency Anti-Patterns → Synchronization Misuse — locks and memory primitives applied wrongly. Covers (collectively): Double-Checked Locking · Volatile Misuse / Wrong Memory Ordering · Race-Prone Lazy Init

This file is critical-reading practice for races. Each snippet is a plausible chunk of real Go, Java, or Python. Unlike structural anti-patterns, these are inherently bugs — the whole family is about subtle memory-visibility and interleaving failures. Your job is to read each one the way a reviewer who has been burned before does, and answer three questions:

What's the race or bug? Under what interleaving does it manifest? How do you fix it?

The danger of this family is that the code works almost every time. A missing memory barrier or a check-then-act gap fails once in millions of runs — on the customer's machine, under load, on a weak-memory CPU (ARM), never on your x86 laptop. You cannot find these by running the code; you find them by reasoning about the interleaving and the memory model. That's the skill this file trains.

How to use this file: read each snippet and construct the breaking interleaving yourself — write down "Thread A does X, then Thread B does Y" — before expanding the answer. Naming the anti-pattern is worth little; being able to draw the schedule that corrupts state is the whole game.

One snippet is a deliberate trap: code that looks racy but is actually correct. Train yourself to say "this is fine, and here's precisely why," not to flag everything that touches a shared variable.

Table of Contents¶

1. The lazy singleton that skips the lock
2. The connection pool everyone shares
3. The shutdown flag
4. The Java config holder from 2004
5. The hit counter that uses atomics
6. The sync.Once that wasn't
7. The volatile balance
8. The metrics registry
9. The correct double-checked lock
10. The Python lazy cache
11. The feature-flag refresh
12. The "atomic" bank transfer
13. The lazily-built map and its volatile guard
14. The Go double-checked lock with a flag

Snippet 1 — The lazy singleton that skips the lock¶

// Java — a singleton that "optimizes away" the lock on the hot path
public class Config {
    private static Config instance;

    private final Map<String, String> values;

    private Config() {
        this.values = loadFromDisk();   // ~50ms; runs exactly once, we hope
    }

    public static Config getInstance() {
        if (instance == null) {                 // 1st check, no lock
            synchronized (Config.class) {
                if (instance == null) {          // 2nd check, under lock
                    instance = new Config();     // publish
                }
            }
        }
        return instance;
    }
}

What's the race or bug? Under what interleaving does it manifest? How do you fix it?

private static volatile Config instance;   // the one word that makes DCL correct

public class Config {
    private Config() { /* ... */ }
    private static class Holder { static final Config INSTANCE = new Config(); }
    public static Config getInstance() { return Holder.INSTANCE; }
}

Snippet 2 — The connection pool everyone shares¶

// Go — package-level lazy initialization of a shared DB pool
package store

var pool *ConnPool

func Pool() *ConnPool {
    if pool == nil {
        pool = newConnPool(32)   // opens 32 sockets, starts a health-check goroutine
    }
    return pool
}

What's the race or bug? Under what interleaving does it manifest? How do you fix it?

var (
    pool     *ConnPool
    poolOnce sync.Once
)

func Pool() *ConnPool {
    poolOnce.Do(func() { pool = newConnPool(32) })
    return pool
}

Snippet 3 — The shutdown flag¶

// Go — a worker loop that should stop when asked
type Worker struct {
    stopped bool   // set by Stop(), read by the loop
}

func (w *Worker) Run() {
    for !w.stopped {        // poll the flag
        job := dequeue()
        process(job)
    }
}

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

What's the race or bug? Under what interleaving does it manifest? How do you fix it?

type Worker struct{ done chan struct{} }

func NewWorker() *Worker { return &Worker{done: make(chan struct{})} }

func (w *Worker) Run() {
    for {
        select {
        case <-w.done:
            return
        default:
            process(dequeue())
        }
    }
}

func (w *Worker) Stop() { close(w.done) }   // channel close is a release; the receive is an acquire

var stopped atomic.Bool
for !stopped.Load() { ... }   // Stop(): stopped.Store(true)

Snippet 4 — The Java config holder from 2004¶

// Java — lifted from a real codebase; the author "knew about" double-checked locking
public class ServiceRegistry {
    private static ServiceRegistry instance;
    private final Map<String, Service> services = new HashMap<>();

    private ServiceRegistry() {
        services.put("auth", new AuthService());
        services.put("billing", new BillingService());
    }

    public static ServiceRegistry get() {
        ServiceRegistry r = instance;          // read once into a local — "for performance"
        if (r == null) {
            synchronized (ServiceRegistry.class) {
                r = instance;
                if (r == null) {
                    r = new ServiceRegistry();
                    instance = r;
                }
            }
        }
        return r;
    }
}

What's the race or bug? Under what interleaving does it manifest? How do you fix it?

private static volatile ServiceRegistry instance;   // <-- the actual fix
// (keeping the local-variable read is fine and slightly faster, but it was never the cure)

Snippet 5 — The hit counter that uses atomics¶

// Go — counting requests across many goroutines
import "sync/atomic"

var hits int64

func handle(w http.ResponseWriter, r *http.Request) {
    atomic.AddInt64(&hits, 1)
    // ... serve the request ...
}

func currentHits() int64 {
    return atomic.LoadInt64(&hits)
}

What's the race or bug? Under what interleaving does it manifest? How do you fix it?

Snippet 6 — The sync.Once that wasn't¶

// Go — lazy initialization that "uses Once" but reintroduces the race
type Cache struct {
    once sync.Once
    data map[string]string
}

func (c *Cache) Get(key string) string {
    if c.data == nil {                 // fast path: skip Once if already built
        c.once.Do(func() {
            c.data = loadAll()         // expensive
        })
    }
    return c.data[key]
}

What's the race or bug? Under what interleaving does it manifest? How do you fix it?

func (c *Cache) Get(key string) string {
    c.once.Do(func() { c.data = loadAll() })   // Do() is cheap after the first call,
    return c.data[key]                          // and establishes happens-before for ALL callers
}

Snippet 7 — The volatile balance¶

// Java — a thread-safe-looking account
public class Account {
    private volatile int balance;

    public Account(int initial) { this.balance = initial; }

    public int balance() { return balance; }

    public void withdraw(int amount) {
        if (balance >= amount) {        // check
            balance = balance - amount; // act
        }
    }
}

What's the race or bug? Under what interleaving does it manifest? How do you fix it?

public class Account {
    private int balance;                         // no longer needs volatile under the lock

    public Account(int initial) { this.balance = initial; }

    public synchronized int balance() { return balance; }

    public synchronized void withdraw(int amount) {
        if (balance >= amount) {
            balance -= amount;
        }
    }
}

Snippet 8 — The metrics registry¶

// Go — lazily register a metric the first time it's used
type Registry struct {
    mu      sync.Mutex
    metrics map[string]*Counter
}

func (r *Registry) Counter(name string) *Counter {
    r.mu.Lock()
    c, ok := r.metrics[name]
    r.mu.Unlock()                       // release before creating — "don't hold the lock during allocation"
    if !ok {
        c = newCounter(name)
        r.mu.Lock()
        r.metrics[name] = c
        r.mu.Unlock()
    }
    return c
}

What's the race or bug? Under what interleaving does it manifest? How do you fix it?

func (r *Registry) Counter(name string) *Counter {
    r.mu.Lock()
    defer r.mu.Unlock()
    if c, ok := r.metrics[name]; ok {
        return c
    }
    c := newCounter(name)
    r.metrics[name] = c
    return c
}

func (r *Registry) Counter(name string) *Counter {
    r.mu.Lock()
    if c, ok := r.metrics[name]; ok { r.mu.Unlock(); return c }
    r.mu.Unlock()

    c := newCounter(name)              // expensive work outside the lock

    r.mu.Lock()
    defer r.mu.Unlock()
    if existing, ok := r.metrics[name]; ok {   // someone else won the race
        return existing                         // throw away our c
    }
    r.metrics[name] = c
    return c
}

Snippet 9 — The correct double-checked lock¶

// Java — reviewed in a PR; a reviewer wants to flag it as "the classic DCL bug"
public final class IdGenerator {
    private static volatile IdGenerator instance;
    private final long epoch;

    private IdGenerator() { this.epoch = System.currentTimeMillis(); }

    public static IdGenerator getInstance() {
        IdGenerator local = instance;            // single volatile read
        if (local == null) {
            synchronized (IdGenerator.class) {
                local = instance;
                if (local == null) {
                    local = new IdGenerator();
                    instance = local;            // volatile write — publishes safely
                }
            }
        }
        return local;
    }
}

What's the race or bug? Under what interleaving does it manifest? How do you fix it?

Snippet 10 — The Python lazy cache¶

# Python — lazily build an expensive lookup table, shared across threads
import threading

class Geo:
    def __init__(self):
        self._table = None

    def lookup(self, ip):
        if self._table is None:           # check
            self._table = self._build()   # act: ~2s, downloads + parses a GeoIP DB
        return self._table.get(ip)

    def _build(self):
        ...   # returns a dict

What's the race or bug? Under what interleaving does it manifest? How do you fix it? (Mind the GIL.)

import threading

class Geo:
    def __init__(self):
        self._table = None
        self._lock = threading.Lock()

    def lookup(self, ip):
        table = self._table
        if table is None:
            with self._lock:
                if self._table is None:        # re-check under the lock
                    self._table = self._build()
                table = self._table
        return table.get(ip)

from functools import cached_property   # NB: not thread-safe by itself pre-3.12 nuances
# or, for a module-level singleton:
import functools

@functools.lru_cache(maxsize=1)
def geo_table():
    return _build()      # lru_cache holds a lock around the miss path

Snippet 11 — The feature-flag refresh¶

// Java — feature flags reloaded periodically from a config service
public class Flags {
    private volatile Map<String, Boolean> flags = new HashMap<>();

    // called by a background scheduler every 30s
    public void refresh(Map<String, Boolean> latest) {
        flags.clear();              // mutate the live map in place
        flags.putAll(latest);
    }

    public boolean isOn(String name) {
        return flags.getOrDefault(name, false);   // read by request threads
    }
}

What's the race or bug? Under what interleaving does it manifest? How do you fix it?

public class Flags {
    private volatile Map<String, Boolean> flags = Map.of();

    public void refresh(Map<String, Boolean> latest) {
        this.flags = Map.copyOf(latest);   // build fully, then publish atomically
    }

    public boolean isOn(String name) {
        return flags.getOrDefault(name, false);   // reads a consistent immutable snapshot
    }
}

Snippet 12 — The "atomic" bank transfer¶

// Go — moving money between two atomic balances
import "sync/atomic"

type Bank struct {
    checking atomic.Int64
    savings  atomic.Int64
}

func (b *Bank) Transfer(amount int64) bool {
    if b.checking.Load() >= amount {                  // check
        b.checking.Add(-amount)                       // debit
        b.savings.Add(amount)                         // credit
        return true
    }
    return false
}

What's the race or bug? Under what interleaving does it manifest? How do you fix it?

type Bank struct {
    mu       sync.Mutex
    checking int64
    savings  int64
}

func (b *Bank) Transfer(amount int64) bool {
    b.mu.Lock()
    defer b.mu.Unlock()
    if b.checking < amount {
        return false
    }
    b.checking -= amount
    b.savings += amount     // debit + credit now atomic together; invariant holds
    return true
}

Snippet 13 — The lazily-built map and its volatile guard¶

// Java — lazy, cached parse of a big immutable lookup, "made safe" with a volatile flag
public class Parser {
    private Map<String, Rule> rules;     // the expensive thing
    private volatile boolean ready;      // the guard flag

    public Rule ruleFor(String key) {
        if (!ready) {                    // 1st check (volatile read)
            synchronized (this) {
                if (!ready) {            // 2nd check
                    rules = parseAll();  // build
                    ready = true;        // signal done (volatile write)
                }
            }
        }
        return rules.get(key);           // read the non-volatile field
    }
}

What's the race or bug? Under what interleaving does it manifest? How do you fix it?

public class Parser {
    private volatile Map<String, Rule> rules;   // the reference is the guard

    public Rule ruleFor(String key) {
        Map<String, Rule> r = rules;            // one volatile read
        if (r == null) {
            synchronized (this) {
                r = rules;
                if (r == null) {
                    r = parseAll();
                    rules = r;                  // volatile write publishes the fully-built map
                }
            }
        }
        return r.get(key);                      // reads the local — provably the published map
    }
}

Snippet 14 — The Go double-checked lock with a flag¶

// Go — a hand-rolled lazy init that mirrors Java's DCL
type Service struct {
    mu    sync.Mutex
    ready bool
    conn  *Conn
}

func (s *Service) Conn() *Conn {
    if !s.ready {                 // fast path, no lock
        s.mu.Lock()
        if !s.ready {
            s.conn = dial()
            s.ready = true
        }
        s.mu.Unlock()
    }
    return s.conn
}

What's the race or bug? Under what interleaving does it manifest? How do you fix it?

type Service struct {
    once sync.Once
    conn *Conn
}

func (s *Service) Conn() *Conn {
    s.once.Do(func() { s.conn = dial() })   // exactly-once + happens-before for every caller
    return s.conn
}

func (s *Service) Conn() *Conn {
    s.mu.Lock()
    defer s.mu.Unlock()
    if s.conn == nil {
        s.conn = dial()
    }
    return s.conn       // read under the same lock that guards the write
}

Summary — how to reason about interleavings¶

You cannot find these bugs by running the code; the failing schedule appears once in millions of runs, on hardware you don't own. You find them by reasoning about interleavings and the memory model. The repeatable moves from these fourteen snippets:

• Find every check-then-act and ask "what if a thread runs between the check and the act?" Withdraw (7), transfer (12), lazy-init (2, 6, 8, 10, 14) all break in exactly that gap. If the check and the act must be one indivisible decision, only a lock (or a single CAS) can make them so — volatile/atomic cannot.
• For any lazy initialization, draw the schedule where two threads both pass the nil-check. That's the Race-Prone Lazy Init signature: duplicate connection pools, duplicate metrics, duplicate expensive builds, lost writes (Snippets 2, 6, 8, 10). The cure is sync.Once / holder idiom / DCL-done-right — pick the one your language blesses.
• For Double-Checked Locking, the diagnosis is one local detail: is the published field volatile / AtomicReference (Java) — or does Go even allow this (no)? Same shape, opposite verdict: Snippet 9 is correct because of one volatile; Snippets 1 and 4 are the classic pre-Java-5 bug because it's missing; Snippet 14 is unfixable-as-written because Go has no volatile and wants sync.Once.
• Separate "publish a reference" from "protect the referent." volatile/atomic make a reference swap visible; they do nothing for in-place mutation of the object (Snippet 11) or for an invariant spanning two variables (Snippet 12). Publish immutable snapshots, or take a lock.
• Don't put your own check in front of a primitive that already has one. Wrapping sync.Once.Do in an unsynchronized if x == nil (Snippet 6) or splitting a volatile flag from its data (Snippet 13) reintroduces the race the primitive was built to remove. Call the primitive unconditionally.
• Resist false positives. A lone independent counter under atomic.Add/Load is correct (Snippet 5); a correctly-volatile DCL is correct (Snippet 9). "Touches a shared variable" is not the diagnostic — "is there an unprotected invariant across operations or variables?" is.
• Know what your platform's memory model and runtime give you. Go has no volatile and demands sync.Once/channels/atomics for visibility; Java's volatile provides acquire/release on a single field; Python's GIL turns many memory-safety races into mere duplicated-work races but never closes a check-then-act. The right fix is always memory-model-specific.

The meta-lesson: synchronization that "looks taken" usually wasn't. A missing volatile published a half-built object; a volatile flag was mistaken for a lock; atomics protected each variable but not the relationship between them; a dropped lock reopened the very window it guarded. When you see a shared variable, don't ask "does this line look right?" — ask "draw me the interleaving, and show me the happens-before edge that makes it safe." If you can't draw the edge, it isn't there.

Related Topics¶

• tasks.md — small concurrent programs to make correct and race-free from the writing side.
• junior.md — what each synchronization-misuse bug looks like and why it's so hard to reproduce.
• middle.md — detecting these with the race detector and choosing the safer primitive.
• senior.md — debugging a visibility bug in production and refactoring a hand-rolled DCL.
• professional.md — memory models, acquire/release semantics, and lock-free publication.
• interview.md — Q&A across all levels on synchronization misuse.
• optimize.md — implementations to make both safe and fast.
• Coordination Anti-Patterns and Shared State Anti-Patterns — the sibling find-bug files in this chapter.
• Clean Code → Immutability — eliminating shared mutability so these races can't form.
• Concurrency Roadmap — the positive patterns: sync.Once, channels, memory models.
• Distributed Systems — the same check-then-act races at network scale.