Reviewed by Aditya Kumar · Last reviewed 2026-03-24
**Why Synchronization:** Multiple threads accessing shared mutable state cause race conditions. synchronized guarantees mutual exclusion; ReentrantLock offers finer control (tryLock, fairness). **Scalability:** synchronized is coarse—contention becomes bottleneck. Prefer: (1)...
Why Synchronization: Multiple threads accessing shared mutable state cause race conditions. synchronized guarantees mutual exclusion; ReentrantLock offers finer control (tryLock, fairness).
Scalability: synchronized is coarse—contention becomes bottleneck. Prefer: (1) ConcurrentHashMap for concurrent maps. (2) AtomicInteger/Long for counters. (3) Lock-free structures where possible. (4) Partition state: each thread owns a shard—no contention.
Cost: Context switching and lock contention under high concurrency. At Walmart-scale ingestion, we use ExecutorService with bounded pool and ConcurrentHashMap for in-memory aggregation—avoids lock contention on shared counter.
ExecutorService executor = Executors.newFixedThreadPool(4);
ConcurrentHashMap<String,AtomicLong> counts = new ConcurrentHashMap<>();
executor.submit(() -> counts.computeIfAbsent(k, v->new AtomicLong(0)).incrementAndGet());
Red Flag: Using synchronized on every increment—bottleneck. Pro-Move: 'We use striped locks (N locks, hash(key) % N) for per-key parallelism with minimal contention.'
According to DataEngPrep.tech, this is one of the most frequently asked Python/Coding interview questions, reported at 1 company. DataEngPrep.tech maintains an editor-reviewed database of 1,863 data engineering interview questions across 7 categories.