Data Race vs Race Condition in Java — Memory-Level vs Logical-Level Bugs

They're related but not the same — one is a memory-level bug, one is a logic-level bug.

Data race — memory-level concept from the JMM

• Two threads access the same memory location
• At least one access is a write
• No happens-before ordering between them
• The JMM says the result is undefined — stale reads, torn reads, impossible states
• Classic example: unsynchronized count++ across threads

Race condition — logic-level concept about correctness

• The program's correctness depends on accidental interleaving of operations
• Every individual operation can be thread-safe, yet the composite can be wrong
• The JMM has no opinion — this is about program design

The most interview-worthy example: race condition WITHOUT data race

• ConcurrentHashMap — every single operation is thread-safe
• if (!cache.containsKey(id)) { val = load(); cache.put(id, val); }
• No data race (all accesses synchronized inside ConcurrentHashMap)
• Yes race condition: two threads both see missing → both load from DB → duplicate work
• Fix: cache.computeIfAbsent(id, k -> load(k)) — atomic check-and-insert

Check-then-act is the family of bugs to watch for

• if (!list.contains) list.add — duplicate adds
• if (balance > 0) withdraw(amount) — overdraft
• if (instance == null) instance = new... — multiple instances
• if (!file.exists()) file.create() — two processes both create
• Fix: compound atomic methods like putIfAbsent, computeIfAbsent, merge, compute, or wrap the whole sequence in a lock

Data race WITHOUT race condition is possible but rare — the benign race

• Unsynchronized read of a flag where the worst outcome is an extra slow-path check
• Works on x86 (strong memory model) but may break on ARM
• Still a bug under strict JMM interpretation
• Always fix with volatile — cheap and portable

How to detect each

• Data races: static analyzers (Error Prone, SpotBugs), Java Thread Sanitizer (Java 21+), stress tests on ARM
• Race conditions: code review focusing on composite operations, deep correctness testing, formal verification in critical code

Practical fixes in modern Java

• For counters and simple state: AtomicInteger, AtomicLong, AtomicReference, LongAdder
• For maps: ConcurrentHashMap.computeIfAbsent, merge, compute
• For complex state: synchronized, ReentrantLock, or immutable state + AtomicReference.updateAndGet
• For cross-service invariants: database transactions

Recommendation: When reviewing concurrent code, first scan for data races — any field accessed by multiple threads without volatile, synchronized, or an atomic wrapper is suspect. Fix those first with the right synchronization primitive. Then scan for race conditions — anywhere you see containsKey + put, get + set, if (null) create — that's a composite operation that needs to be atomic. Replace with computeIfAbsent, putIfAbsent, or wrap in a lock. Remember: a data-race-free program can still have race conditions, and fixing race conditions often requires atomic composite operations rather than just more synchronization.