AtomicInteger.

Hook: Interviewers love AtomicInteger because it tests whether you know how to update shared state safely without accidentally turning your multithreaded code into a traffic jam.

Question: What is AtomicInteger in Java?

Answer: AtomicInteger is a thread-safe integer wrapper from java.util.concurrent.atomic. It lets multiple threads read and update the same number without using a full synchronized block for every change. The main benefit is atomic operations like incrementAndGet() and compareAndSet(), which means the update happens as one indivisible action.

Interview-Ready Answer: I use AtomicInteger when I need a shared counter or state value that many threads update concurrently. It gives me lock-free atomic operations such as get(), set(), and compareAndSet(), so I avoid race conditions without paying the heavier cost of a synchronized lock on every increment. A key detail is that it is great for simple numeric state, but for more complex multi-field invariants I would usually still need locks or another coordination strategy.

What it is

AtomicInteger is an object that stores one int and provides atomic methods to read, write, and update it. Atomic means “all at once” from the perspective of other threads: no other thread can observe a half-finished update. It lives in java.util.concurrent.atomic and is built on low-level CPU support and JVM mechanics such as compare-and-swap, often shortened to CAS (compare-and-swap, a hardware-assisted “update only if the value is still what I expected” operation).

How it works under the hood

1. A thread reads the current value, say 5.
2. It computes the new value, say 6.
3. It tries a CAS operation: “change 5 to 6 only if nobody changed it first.”
4. If another thread already changed the value, CAS fails.
5. The method retries with the newest value until it succeeds.

This retry loop is why atomic classes are often called lock-free: they do not use an OS-style lock for the basic update. However, “lock-free” does not mean “free” — under heavy contention, many retries can happen, and performance can drop.

When and why to use it

Use AtomicInteger when you need a single shared number such as:

• a request counter
• a unique sequence number
• a small state flag encoded as an integer
• a metrics tally in a concurrent service

It is ideal when the operation is simple and local to one variable. If you need to update several fields together as one rule, such as “balance and transaction count must always match,” an atomic integer alone is not enough.

AtomicInteger vs alternatives

volatile is a common trap: it makes changes visible across threads, but it does not make compound actions like increment atomic. The expression count++ is really read, add, write — three separate steps — so two threads can overwrite each other.

Performance and complexity

For a successful atomic update, the average work is usually O(1), but under contention the retry loop can make it feel much slower because failed CAS attempts repeat work. In real systems, a low-contention atomic counter may be extremely fast, while a very hot counter with dozens of threads can become a bottleneck. That is where LongAdder often wins, because it spreads updates across multiple cells and combines them later.

Important edge cases

• Not a magic shield: it protects one integer, not a whole object graph.
• ABA-style thinking: CAS checks that the value is what you expected, but if a value changes from A to B and back to A, a simple CAS may not notice. This is more common in complex lock-free algorithms than in basic counters.
• Compound logic: if (atomic.get() < limit) atomic.incrementAndGet(); is not atomic as a whole. Another thread can change the value between the check and the increment.
• Initialization: default value is 0 if you use the no-arg constructor.

Memory hook: think of AtomicInteger as a bulletproof ticket counter: each thread can only stamp the next number if nobody else grabbed that ticket first.

Real-world story

Imagine a checkout service in an e-commerce platform that records how many orders were placed in the last minute. Many request threads call the same metric counter. If the team used a plain int with ++, the count would randomly drift lower than reality because updates get lost during races. With AtomicInteger, each order increments safely, so dashboards and alerting stay accurate.

What goes wrong when misunderstood: A team uses volatile int for “thread safety” and sees counter values that are lower than the true number of requests. Logs show normal traffic, but the dashboard under-reports load, causing autoscaling to trigger late. Users then experience slow responses during peak traffic because the system thought it was less busy than it really was.

• Symptoms: inconsistent counts, flaky tests, missing increments.
• Logs: request volume and recorded volume do not match.
• User impact: delayed scaling, bad rate-limit decisions, inaccurate metrics.

Follow-up & Tricky Questions:

• How is AtomicInteger different from volatile int? volatile gives visibility, meaning other threads see the latest write, but it does not make ++ atomic. AtomicInteger gives both visibility and atomic update methods.
• When would you choose LongAdder instead? Use LongAdder for extremely hot counters with lots of concurrent increments, such as request metrics. It usually scales better under contention, but exact point-in-time reads are less straightforward than with AtomicInteger.
• Is AtomicInteger always faster than synchronized? No. Under low contention, both can be fine; under high contention, atomics avoid blocking, but repeated CAS retries can still become expensive. The real answer depends on workload and contention level.
• Can I use it to make a whole class thread-safe? No. It only protects the single integer it wraps. If your invariant spans multiple variables, you need stronger coordination like a lock or a higher-level concurrent design.
• What does compareAndSet actually help with? It lets you implement safe “update only if unchanged” logic, which is the basis of many non-blocking algorithms. It is especially useful when you need optimistic updates and want to retry rather than block.

• Gotcha: Is count++ on an AtomicInteger atomic? Yes, if you use incrementAndGet() or getAndIncrement(). But writing counter.set(counter.get() + 1) is not atomic because it splits the operation into two separate calls.
• Gotcha: Does AtomicInteger solve all race conditions? No. It solves races for one integer value only. You can still have races around surrounding business logic or across multiple fields.
• Gotcha: Can a CAS operation fail even when no bug exists? Yes. A failure just means another thread won the race and changed the value first; the method retries as designed.

Common Mistakes:

• Mistake: Using volatile int for counters. Correction: Use AtomicInteger or another atomic/concurrent counter because ++ is not atomic.
• Mistake: Assuming a check-then-act block is atomic. Correction: Combine logic carefully or protect the whole sequence with a lock.
• Mistake: Replacing every lock with atomics. Correction: Atomics are best for simple single-value updates; locks are still appropriate for multi-step invariants.
• Mistake: Ignoring contention. Correction: For very hot counters, consider LongAdder or redesign to reduce sharing.

Memory Hook: AtomicInteger is a turnstile with one seat: one thread updates the number at a time, and everyone else retries until they get through safely.

Cheat Sheet:

• AtomicInteger = thread-safe wrapper around one int.
• Use it for counters, IDs, and simple shared state.
• incrementAndGet() and compareAndSet() are the key methods.
• volatile is not enough for ++.
• Good under moderate contention; LongAdder may scale better for very hot metrics.
• Does not make multiple variables or whole business rules atomic.

Practice Tasks:

• Write a small program where 10 threads increment an AtomicInteger and verify the final count.
• Replace AtomicInteger with volatile int and observe the wrong result under concurrency.
• Implement a simple “only let the first 3 threads pass” gate using compareAndSet.