Shared State Anti-Patterns — Interview Q&A¶

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

A bank of 60+ interview questions and answers on the shared-state family of concurrency bugs — data races, polling vs. blocking, and unbounded concurrency. Examples are in Go and Java primarily, with a Python GIL note where it matters. Each answer models the reasoning a strong candidate gives, trade-offs included. 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 — Architecture & Capacity
4. Professional / Deep — Hardware, Scheduling, Queueing
5. Code-Reading — Diagnose the Snippet
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 dangerous" reasoning.

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

Q2. What is a data race, precisely?

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

Q4. Why is shared mutable state without protection so dangerous if the code "works on my machine"?

Q5. Show the classic counter++ race in Go and explain why it loses increments.

var counter int
var wg sync.WaitGroup
for i := 0; i < 1000; i++ {
    wg.Add(1)
    go func() { defer wg.Done(); counter++ }() // RACE
}
wg.Wait()
fmt.Println(counter) // almost never 1000

Q6. Show the same race in Java and the two standard fixes.

class Counter {
    private int n = 0;
    void inc() { n++; }        // RACE: read-modify-write, not atomic
    int get() { return n; }
}

// 1. Lock the read-modify-write:
synchronized void inc() { n++; }
synchronized int get() { return n; }

// 2. Use an atomic and skip the lock entirely:
private final AtomicInteger n = new AtomicInteger();
void inc() { n.incrementAndGet(); }
int get() { return n.get(); }

Q7. What does volatile (Java) / atomic actually guarantee, and what does it not?

Q8. What is busy waiting, and why is it usually wrong?

for !done { } // burns a whole CPU core doing nothing useful

Q9. What's the channel-based fix for "wait until a worker finishes" in Go?

done := make(chan struct{})
go func() {
    work()
    close(done) // signal completion
}()
<-done // blocks here, zero CPU, woken when closed

Q10. What is thread-per-request, and why is it tempting?

Q11. Roughly how much does an OS thread cost versus a goroutine?

Q12. What is the simplest way to "protect" shared state — and what's the catch?

Q13. Why can't you reproduce most data races with a normal unit test?

Intermediate / Middle¶

Detection, the safer patterns, and the trade-offs between them.

Q14. What is "confinement" and how does it eliminate the need for locks?

Q15. Channels vs. mutexes in Go — when do you reach for which?

Q16. Condition variable vs. spin loop — what's the difference and when is each appropriate?

synchronized (lock) {
    while (!ready) lock.wait();  // releases lock, parks thread, re-acquires on wake
    consume();
}

Q17. What is a worker pool, and what problem does it solve?

jobs := make(chan Job, 100)
for i := 0; i < runtime.NumCPU(); i++ {  // bounded workers
    go func() { for j := range jobs { process(j) } }()
}

Q18. How do you bound concurrency in Go without a full worker pool?

sem := make(chan struct{}, 100) // at most 100 concurrent
for req := range requests {
    sem <- struct{}{}            // acquire (blocks when full)
    go func(r Req) {
        defer func() { <-sem }() // release
        handle(r)
    }(req)
}

Q19. What is backpressure and why does it matter for thread-per-request?

Q20. A read-heavy shared map is contended under a single mutex. What are your options?

Q21. How do you detect these problems before production?

Q22. Does adding a lock around each access guarantee correctness?

Q23. Show the check-then-act race and fix it in Java.

// RACE CONDITION even with a thread-safe map:
if (!cache.containsKey(k)) {        // thread A and B both see false
    cache.put(k, expensiveLoad(k)); // both compute and store
}

cache.computeIfAbsent(k, key -> expensiveLoad(key)); // atomic check-and-insert

Q24. Why is time.Sleep in a polling loop still busy waiting (sort of), and what's better?

Q25. What's wrong with a goroutine leak, and how does it relate to unbounded spawning?

Q26. Immutability as a concurrency tool — how does it help here?

Q27. What's the difference between blocking and parking a thread?

Senior — Architecture & Capacity¶

System-level cures, capacity math, and the C10k lineage.

Q28. Contrast the Actor model and CSP. How do they attack shared mutable state?

Q29. What is the single-writer principle and why is it powerful?

Q30. What was the C10k problem and how does it inform modern server design?

Q31. Apply Little's Law to size a worker pool / connection pool.

Q32. How do you choose a pool size for CPU-bound vs. I/O-bound work?

Q33. "Goroutines are cheap, so why bound them?" — give the senior answer.

Q34. How do you make a contended hot path scale without one giant lock?

Q35. When is shared mutable state with locks actually the right choice over channels/actors?

Q36. How does cancellation/timeout fit into bounding concurrency?

Professional / Deep — Hardware, Scheduling, Queueing¶

Memory hardware, scheduler internals, and the math behind the cures.

Q37. What is false sharing, and why does it slow down code with no logical contention?

Q38. Show false sharing concretely and the padding fix.

// FALSE SHARING: counters[0] and counters[1] share a 64-byte cache line.
// Two goroutines each hammering its own index still ping-pong the line.
type counters struct { a, b int64 }

// FIX: pad so each counter occupies its own cache line.
type paddedCounters struct {
    a int64
    _ [56]byte // 8 (int64) + 56 = 64 bytes → next field on a new line
    b int64
    _ [56]byte
}

Q39. Spin vs. park: how do real lock implementations decide, and why?

Q40. So — is busy waiting ever the right answer?

Q41. Does Python's GIL eliminate data races?

Q42. Why does an unbounded queue in front of a worker pool not save you?

Q43. What does queueing theory say about running a pool near 100% utilization?

Q44. How does the Go scheduler turn thread-per-request into something sustainable, and where are its limits?

Q45. What memory-ordering guarantee actually makes a channel send/lock safe to rely on?

Code-Reading — Diagnose the Snippet¶

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

Q46. What's wrong, and how do you fix it?

func main() {
    m := map[string]int{}
    for i := 0; i < 100; i++ {
        go func(k string) { m[k]++ }(fmt.Sprint(i)) // concurrent map writes
    }
    time.Sleep(time.Second)
}

var mu sync.Mutex
var wg sync.WaitGroup
for i := 0; i < 100; i++ {
    wg.Add(1)
    go func(k string) { defer wg.Done(); mu.Lock(); m[k]++; mu.Unlock() }(fmt.Sprint(i))
}
wg.Wait()

Q47. What's wrong, and how do you fix it?

class Worker {
    private boolean stopped = false;       // not volatile
    public void stop() { stopped = true; }
    public void run() { while (!stopped) { doWork(); } }  // may loop forever
}

private volatile boolean stopped = false;

Q48. What's wrong, and how do you fix it?

func serve(l net.Listener) {
    for {
        conn, _ := l.Accept()
        go handle(conn) // unbounded: one goroutine per connection, no cap
    }
}

sem := make(chan struct{}, 1000) // cap in-flight handlers
for {
    conn, err := l.Accept()
    if err != nil { return }      // also: stop swallowing the error
    sem <- struct{}{}             // blocks when at capacity → backpressure
    go func(c net.Conn) { defer func() { <-sem }(); handle(c) }(conn)
}

Q49. What's wrong, and how do you fix it?

class Latch {
    private boolean ready = false;
    void await() { while (!ready) { } }   // spin
    synchronized void signal() { ready = true; }
}

class Latch {
    private final CountDownLatch ready = new CountDownLatch(1);
    void await() throws InterruptedException { ready.await(); } // parks, zero CPU
    void signal() { ready.countDown(); }                        // wakes the waiter
}

Q50. What's wrong, and how do you fix it?

import threading
total = 0
def add():
    global total
    for _ in range(100_000):
        total += 1   # GIL does NOT make this safe
threads = [threading.Thread(target=add) for _ in range(4)]
[t.start() for t in threads]; [t.join() for t in threads]
print(total)  # rarely 400_000

lock = threading.Lock()
def add():
    global total
    for _ in range(100_000):
        with lock:
            total += 1

Q51. What's wrong, and how do you fix it?

func loadConfig() *Config {
    if cfg == nil {           // two goroutines both see nil
        cfg = parse(file)     // both parse, one wins, racy publish of *Config
    }
    return cfg
}
var cfg *Config

var (
    cfg     *Config
    cfgOnce sync.Once
)
func loadConfig() *Config {
    cfgOnce.Do(func() { cfg = parse(file) })
    return cfg
}

Q52. Spot the subtle bug.

sem := make(chan struct{}, 100)
for _, r := range requests {
    sem <- struct{}{}
    go func() {
        defer func() { <-sem }()
        handle(r)              // BUG: closure captures loop variable r
    }()
}

Curveballs¶

The questions designed to catch glib answers.

Q53. Explain Go's mantra "Don't communicate by sharing memory; share memory by communicating."

Q54. Is busy waiting ever the right thing to do?

Q55. "Goroutines are basically free — why not just spawn one per request and forget about pools?"

Q56. Does Python's GIL mean Python programmers can ignore thread safety?

Q57. What is false sharing, and why is it surprising?

Q58. If a program passes go test -race, is it guaranteed race-free?

Q59. Your service has plenty of CPU and memory headroom but tail latency is terrible under load. Could it be a concurrency anti-pattern?

Rapid-Fire / One-Liners¶

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

Q60. Three conditions for a data race?

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

Q62. volatile fixes which bug and not which?

Q63. Channel or mutex: moving data vs. guarding data?

Q64. Little's Law, and what it sizes?

Q65. Why bound goroutines if they're cheap?

Q66. The single-writer principle in one line?

Q67. What does go test -race prove and not prove?

Q68. False sharing in one sentence?

Q69. Unbounded queue in front of a pool — good idea?

Q70. The deep model of what "synchronization" buys you?

How to Talk About Concurrency in Interviews¶

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

• Distinguish the failure modes precisely. Data race ≠ race condition; visibility bug ≠ atomicity bug; cheap ≠ free. Interviewers probe exactly these confusions, and naming the distinction signals depth.
• Lead with "eliminate the sharing," then "synchronize what's left." The senior instinct is confinement, immutability, and single-writer before reaching for a lock. Locks are the fallback, not the first move.
• Always bound, always backpressure. For any "handle many requests" question, the missing word is usually bounded — pool, semaphore, bounded queue, timeout. Say it unprompted.
• Bring numbers. Little's Law to size a pool, 1/(1−ρ) for why you don't run at 100%, ~1 MB thread vs. ~KB goroutine, the 64-byte cache line. Concrete math beats hand-waving.
• Reach for the right tool to detect. go test -race, mutex/block profiles, goroutine-count graphs, perf c2c. Knowing how you'd find the bug is as convincing as knowing the fix.
• Refuse dogma. "Always use channels," "the GIL makes Python safe," "always early-return on a flag" are juniorisms. Calibrate: channels for moving data, mutexes for guarding it; bounded spins are legitimate inside primitives.
• Trace it to a real incident. "We had a goroutine-per-request handler that OOM'd under a downstream slowdown; we capped it with errgroup.SetLimit and added a context deadline" lands harder than a definition.

Summary¶

• The three shared-state anti-patterns are three failed ways to coordinate mutable state across parallel execution: Shared Mutable State Without Protection (data races / corruption), Busy Waiting (burning a core polling instead of blocking on the event), and Thread-Per-Request Without Bounds (unbounded concurrency that exhausts the real bottleneck and kills backpressure).
• The junior bar is recognizing them and explaining why a race is undefined behavior you can't reliably reproduce. The middle bar is the safer patterns and their trade-offs: confinement, channels vs. mutexes, condvars vs. spins, worker pools, semaphores, and computeIfAbsent-style atomic compound ops. The senior bar is architecture and capacity: actor/CSP, the single-writer principle, C10k, and Little's-Law pool sizing. The professional bar is the hardware and math underneath: false sharing, adaptive spin-then-park, goroutine vs. thread cost, the M:N scheduler, queueing theory, and happens-before memory ordering.
• The strongest answers eliminate sharing before synchronizing it, bound concurrency with backpressure by default, bring concrete numbers, and refuse dogma (channels vs. locks by access shape; the GIL is not thread safety; bounded spinning is legitimate inside a primitive).
• Recurring curveballs hinge on one insight each: the Go mantra is "give state an owner," busy-waiting is only ever bounded, goroutines are cheap-not-free, the GIL serializes bytecode-not-compound-ops, and false sharing is a hardware cost invisible in the source.

Related Topics¶

• junior.md — recognize the race, the spin, and the unbounded spawn.
• middle.md — detection (-race, profiles) and the safer patterns.
• senior.md — actor/CSP, single-writer, capacity sizing, contended hot paths.
• professional.md — false sharing, spin-vs-park, scheduling, queueing, memory ordering.
• tasks.md · find-bug.md · optimize.md — practice the diagnosis and the fix.
• Concurrency Anti-Patterns — the parent category and how these relate to the other six.
• Synchronization Misuse — volatile, atomics, and correct lazy init (sync.Once).
• Coordination — lock ordering, holding locks across I/O, and lock granularity.
• Clean Code → Immutability — the structural cure: data that can't be mutated can't race.
• Refactoring — extracting owners and pipelines from tangled shared state.
• Distributed Systems — the same coordination problems at the network scale.