All 15 Concurrency & Threads questions
More in Concurrency & Threads
What is the difference between calling Thread.start() and Thread.run() directly, and why is calling run() directly a common beginner mistake? What is the synchronized keyword, and how does it use Java's intrinsic (monitor) locks to prevent race conditions on shared mutable state? What is the ExecutorService framework, and why is it generally preferred over manually creating and managing individual Thread objects? What causes a deadlock in multithreaded Java code, and what is the classic "lock ordering" strategy for preventing it? What is thread starvation, and how can thread priority misuse or unfair lock scheduling contribute to it? What is the difference between wait()/notify()/notifyAll() (Object's intrinsic monitor methods) and the newer java.util.concurrent tools, and why are the older methods considered error-prone? What is a race condition, and how does it differ conceptually from a deadlock as two distinct categories of concurrency bugs? How does java.util.concurrent's ReentrantLock differ from the synchronized keyword, and what additional capabilities does it provide (tryLock, fairness, interruptible locking)? How do CompletableFuture's composition methods (thenApply, thenCompose, thenCombine) enable building asynchronous pipelines, and what's the difference between thenApply and thenCompose? How does the Java Memory Model's happens-before relationship formally define when changes made by one thread are guaranteed to be visible to another thread, and what role does the volatile keyword play?
Advertisement
Back to results for “JRE & Memory”
Java › Concurrency & Threads

What are the atomic classes in java.util.concurrent.atomic (AtomicInteger, AtomicLong, AtomicReference), and how do they achieve thread-safe operations without traditional locking?

Intermediate

Answer

Atomic classes use hardware-level compare-and-swap (CAS) instructions (a single atomic CPU operation that conditionally updates a value only if it still matches an expected prior value) to implement thread-safe increment/update operations without acquiring a traditional lock -- this lock-free approach avoids the overhead and contention of synchronized/ReentrantLock for simple single-variable atomic operations, generally performing better under moderate contention, though CAS-based operations can spin-retry under very high contention (many threads simultaneously attempting to update the same atomic variable), at which point traditional locking might actually perform comparably or better.
private final AtomicInteger counter = new AtomicInteger(0);

public void increment() {
    counter.incrementAndGet();  // atomic, thread-safe, no explicit lock needed
}

public int compareAndUpdate(int expected, int newValue) {
    return counter.compareAndSet(expected, newValue) ? newValue : counter.get();
}
Real-world example A high-throughput metrics collection system tracking a shared request counter across many concurrent request-handling threads uses AtomicLong instead of a synchronized increment method, achieving better throughput under the metrics system's specific access pattern by avoiding traditional lock acquisition/release overhead entirely for this simple counting operation.

Common follow-ups: How does compare-and-swap (CAS) work at the CPU instruction level to achieve atomicity without a traditional lock?;Under what contention conditions might a CAS-based atomic actually perform worse than a traditional lock?

Diagnostics & Performance;JVM JRE & Memory
All 15 Concurrency & Threads questions