Synchronization Misuse Anti-Patterns — Interview Q&A¶

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

A bank of 60+ interview questions and answers on the three ways engineers misuse synchronization: trying to skip a lock with a flag check (Double-Checked Locking), treating volatile/atomic as if it gave mutual exclusion (Volatile Misuse), and the unguarded if instance == nil { instance = new() } (Race-Prone Lazy Init). Examples are in Go and Java with a Python GIL note. Each answer models the reasoning a strong candidate gives — including the trade-offs. Use the <details> toggles to self-quiz: read the question, answer out loud, then expand.

Table of Contents¶

1. Fundamentals / Junior
2. Intermediate / Middle
3. Senior — Memory Models, Why DCL Broke, Auditing
4. Professional / Deep — Fences, Cache Coherence, CAS, Lock Cost
5. Code-Reading — Diagnose the Race
6. Curveballs
7. Rapid-Fire / One-Liners
8. How to Talk About Concurrency in Interviews
9. Summary
10. Related Topics

Fundamentals / Junior¶

Definitions, recognition, and the "why is it broken" reasoning.

Q1. Name the three synchronization-misuse anti-patterns and give a one-line symptom for each.

Q2. What is the difference between a race condition and a data race?

Q3. What does volatile (Java) actually guarantee, and what does it not?

Q4. Go has no volatile keyword. What's the equivalent, and what's the rule?

Q5. What is lazy initialization, and why does the naive version race?

var instance *Config
func Get() *Config {
    if instance == nil {           // (1) check
        instance = loadConfig()    // (2) create + assign
    }
    return instance
}

Q6. What is Double-Checked Locking, and what problem was it trying to solve?

if (instance == null) {              // 1st check, no lock
    synchronized (lock) {
        if (instance == null) {      // 2nd check, under lock
            instance = new Config();
        }
    }
}
return instance;

Q7. Why is taking a lock "every time" considered a cost worth avoiding here?

Q8. What is "memory visibility" and why is it surprising to newcomers?

Q9. Does Python's GIL make locks unnecessary? (curveball)

Q10. Does marking a variable volatile (Java) or using atomic (Go) make count++ thread-safe? (curveball)

Q11. What's the simplest correct way to do lazy init in Go and in Java?

var (
    once     sync.Once
    instance *Config
)
func Get() *Config {
    once.Do(func() { instance = loadConfig() })
    return instance
}

class Cfg {
    private static class Holder { static final Config INSTANCE = new Config(); }
    static Config get() { return Holder.INSTANCE; }
}

Q12. Why are these bugs so hard to reproduce?

Intermediate / Middle¶

Happens-before, choosing primitives, and the safe lazy-init idioms.

Q13. Explain happens-before. Why is it the central concept for all three anti-patterns?

Q14. How do you choose between a mutex and an atomic?

Q15. Show the correct DCL in modern Java and modern Go. What's the one keyword/type that makes it work?

private static volatile Config instance;
static Config get() {
    Config local = instance;          // read volatile once
    if (local == null) {
        synchronized (Lock.class) {
            local = instance;
            if (local == null) {
                instance = local = new Config();
            }
        }
    }
    return local;
}

var instance atomic.Pointer[Config]
var mu sync.Mutex
func Get() *Config {
    if c := instance.Load(); c != nil { return c }
    mu.Lock(); defer mu.Unlock()
    if c := instance.Load(); c != nil { return c }
    c := loadConfig()
    instance.Store(c)
    return c
}

Q16. Why is the holder idiom often better than even a correct DCL?

Q17. When is a plain atomic flag the right tool (not a misuse)?

Q18. How does the race detector work, and what are its limits?

Q19. A teammate replaced a sync.Mutex with two atomic.Int64s "for speed." What do you check?

Q20. What's the difference between sync.Once and a volatile-guarded boolean flag?

Q21. Is double-checked locking ever correct? (curveball)

Q22. How would you fix the naive lazy init in Q5 in Go, and explain why it now publishes safely?

var (
    once     sync.Once
    instance *Config
)
func Get() *Config {
    once.Do(func() { instance = loadConfig() })
    return instance
}

Q23. What's "safe publication" and why does it matter for all three patterns?

Q24. Why might eager initialization be the right answer instead of any lazy idiom?

Q25. What signal in code review flags each of the three anti-patterns?

Senior — Memory Models, Why DCL Broke, Auditing¶

The JMM and Go memory model, the historical failure, and how to audit a concurrent codebase.

Q26. Explain precisely why pre-Java-5 DCL was broken, at the memory-model level.

Q27. Compare the Java Memory Model and the Go Memory Model on the points that matter here.

Q28. What are acquire and release semantics, and how do they map to these idioms?

Q29. You inherit a service with intermittent "field is null but shouldn't be" crashes under load. How do you audit for synchronization misuse?

Q30. Why can a bug be invisible on x86 but crash on ARM (or Apple Silicon)?

Q31. How does the compiler — not just the CPU — break naive synchronization?

Q32. When auditing, how do you tell a benign data race from a dangerous one — and is "benign data race" a real category?

Q33. How do final fields (Java) and immutability help you sidestep this whole category?

Q34. A singleton's loadConfig() can fail. How does that change your idiom choice?

Q35. What's the cost of using a RWMutex to protect a lazily-initialized read-mostly value, versus an atomic pointer?

Q36. How do you write a test that actually exercises these races?

Professional / Deep — Fences, Cache Coherence, CAS, Lock Cost¶

Hardware ordering, the mechanics of atomics and locks, and where they cost.

Q37. What is a memory fence (barrier), and what does the compiler emit for a volatile write / atomic.Store?

Q38. Explain cache coherence (MESI) and how it relates to contention cost.

Q39. What is false sharing and how do you fix it?

Q40. How does compare-and-swap (CAS) work, and what is the ABA problem?

Q41. Roughly what does an uncontended lock cost versus a contended one, and why does it matter for DCL?

Q42. Distinguish atomicity, visibility, and ordering precisely.

Q43. What's the difference between a lock-free, wait-free, and obstruction-free algorithm, and why prefer a lock sometimes?

Q44. Why is sync.Once so cheap on the fast path, mechanically?

Code-Reading — Diagnose the Race¶

You're shown a snippet; name the anti-pattern and state the fix.

Q45. Diagnose and fix.

var cache map[string]int
func Get(k string) int {
    if cache == nil {
        cache = make(map[string]int) // lazy init
    }
    return cache[k]
}

var (
    once  sync.Once
    mu    sync.RWMutex
    cache map[string]int
)
func Get(k string) int {
    once.Do(func() { cache = make(map[string]int) })
    mu.RLock(); defer mu.RUnlock()
    return cache[k]
}

Q46. Is this DCL correct? If not, fix it.

class Reg {
    private static Reg instance;          // not volatile
    static Reg get() {
        if (instance == null) {
            synchronized (Reg.class) {
                if (instance == null) instance = new Reg();
            }
        }
        return instance;
    }
}

private static volatile Reg instance;

Q47. What's wrong here, given count is atomic.Int64?

func (s *Stats) Bump() {
    if s.count.Load() < s.limit {   // check
        s.count.Add(1)              // act
    }
}

for {
    c := s.count.Load()
    if c >= s.limit { return }
    if s.count.CompareAndSwap(c, c+1) { return }
}

Q48. Diagnose this Java increment.

class Counter {
    private volatile long count;
    void inc() { count++; }
    long get() { return count; }
}

private final AtomicLong count = new AtomicLong();
void inc() { count.incrementAndGet(); }
long get() { return count.get(); }

Q49. This Python code uses a lock around init. Is it safe under the GIL? Under no-GIL?

_inst = None
def get():
    global _inst
    if _inst is None:          # check, no lock
        _inst = Service()      # create
    return _inst

import threading
_inst = None
_lock = threading.Lock()
def get():
    global _inst
    if _inst is None:
        with _lock:
            if _inst is None:
                _inst = Service()
    return _inst

Q50. This Go spin loop never exits. Why, and what's the fix?

var done bool
func worker() { for !done { } }          // goroutine A
func stop()   { done = true }            // goroutine B

done := make(chan struct{})
go func() { <-done; /* stop */ }()
close(done) // from stop()

Q51. Two anti-patterns in one snippet — name both.

class Conn {
    private static Conn instance;            // not volatile
    private boolean ready;
    static Conn get() {
        if (instance == null) instance = new Conn();   // lazy init, no lock
        if (!instance.ready) { instance.connect(); instance.ready = true; }
        return instance;
    }
}

class Conn {
    private static class H { static final Conn I = create(); }
    static Conn get() { return H.I; }
    private static Conn create() { Conn c = new Conn(); c.connect(); return c; }
}

Curveballs¶

The questions designed to catch glib answers.

Q52. "Does volatile make count++ thread-safe?"

Q53. "Is double-checked locking ever correct?"

Q54. "Does Python's GIL make locks unnecessary?"

Q55. "What's the difference between a race condition and a data race?"

Q56. "We added -race to CI and it's green. Are we race-free?"

Q57. "If I make every shared field volatile/atomic, is my code thread-safe?"

Q58. "x86 worked fine for years; why did the same binary corrupt on ARM?"

Q59. "Can I just time.Sleep a bit to let the other goroutine finish initializing?"

Rapid-Fire / One-Liners¶

Crisp answers; what an interviewer wants in one or two sentences.

Q60. volatile/atomic gives you ___ but not ___?

Q61. One-line cure for each of the three?

Q62. Go's one rule for shared variables?

Q63. The fastest-correct lazy singleton in Java? In Go?

Q64. What does sync.Once guarantee beyond "runs once"?

Q65. Race detector: sound or complete?

Q66. The two-word reason broken DCL fails?

Q67. CAS in one sentence, and its classic bug?

Q68. Atomicity vs. visibility vs. ordering — one word each?

Q69. When is an atomic.Bool flag genuinely the right tool?

Q70. Eager vs. lazy init — default to which?

How to Talk About Concurrency in Interviews¶

A few habits separate a strong answer from a textbook recital:

• Lead with happens-before, not the keyword. Don't say "add volatile and it's fixed." Say why — "the lock-free read needs a happens-before edge to the construction, which the volatile write supplies." The reasoning is the signal; the keyword is the conclusion.
• Separate the three properties out loud. Stating "this needs atomicity, not just visibility" instantly distinguishes you from candidates who think volatile cures everything. Name atomicity / visibility / ordering precisely.
• Distinguish data race from race condition every time it's relevant. It's the single most reliable way to show you understand the memory model versus logic — and many interviewers ask it explicitly.
• Prefer the boring correct idiom. "I'd use sync.Once / the holder idiom" beats hand-rolling DCL. Mention that DCL can be correct with volatile/atomic, then say why you still wouldn't write it. Knowing the safe default is senior signal.
• Show you'd find it, not just reason about it. Mention go test -race, jcstress, stress tests with high parallelism and -count, and testing on ARM. "Sound but not complete" shows you understand the tool's limits.
• Go deep only when asked. Fences, MESI, false sharing, CAS/ABA, lock cost — these demonstrate depth, but lead with the model and reach for hardware when the interviewer pushes.
• Avoid absolutism. "Always lock," "atomics are always faster," "the GIL makes Python safe" are juniorisms. Calibrate: lock for invariants, atomics for independent single words, immutability to sidestep the whole problem.
• Use a concrete war story. "We had a config singleton that double-created under load on Graviton; here's how we found it with -race and fixed it with sync.Once" lands harder than any definition.

Summary¶

• The three synchronization-misuse anti-patterns are all attempts to coordinate shared state more cheaply than a lock allows, each getting the memory semantics wrong: Double-Checked Locking (broken without volatile/atomic), Volatile Misuse / Wrong Memory Ordering (treating visibility as atomicity or mutual exclusion), and Race-Prone Lazy Init (unguarded check-then-create).
• The junior bar is knowing what volatile/atomic does and doesn't give (visibility/ordering, not atomicity or exclusion) and the data-race-vs-race-condition distinction. The middle bar is happens-before, choosing mutex vs. atomic, and the safe lazy-init idioms (sync.Once, the holder idiom, eager init). The senior bar is the JMM and Go memory model, why pre-Java-5 DCL was broken, and auditing a codebase. The professional bar is fences, cache coherence (MESI), false sharing, CAS/ABA, and lock cost.
• Modern verdict on the curveballs: volatile does not make count++ thread-safe; DCL is correct with volatile/atomic but you should still prefer sync.Once/holder; the GIL does not remove the need for locks; and a race condition can exist with zero data races.
• The deepest cure is structural: eliminate shared mutability (immutability, final fields, snapshot-and-swap) and most of this category disappears — exactly the root-cause message of the concurrency chapter.

Related Topics¶

• junior.md — what the bug looks like and why it's hard to reproduce.
• middle.md — detection and the safer patterns (Once, holder, atomics vs. locks).
• senior.md — debugging in prod, memory models, and auditing a contended path.
• professional.md — memory models, hardware ordering, and lock-free structures.
• tasks.md · find-bug.md · optimize.md — practice diagnosing and fixing the races.
• Coordination Anti-Patterns — deadlock, holding a lock during I/O, wrong lock granularity.
• Shared State Anti-Patterns — unprotected shared mutable state, busy-waiting, unbounded thread-per-request.
• Async Anti-Patterns — the single-threaded event-loop sibling chapter.
• Clean Code → Immutability — the structural cure that removes the shared writes entirely.
• Concurrency Anti-Patterns (chapter) — how all nine relate, rooted in shared mutable state.