An agent's injected code uses `invocationCount.get()` followed by `invocationCount.set(newValue)` on an `AtomicInteger`. Why is this still a potential race condition?
Java interview question for Advanced practice.
Answer
The sequence of individual atomic operations (get, then set) is not atomic as a whole.
Explanation
The problem is that simply using an AtomicInteger is not enough; the code that interacts with it must use its atomic methods correctly. A get() is atomic, and a set() is atomic, but the sequence of performing a get, calculating a new value, and then performing a set is not an atomic transaction. This creates a classic check-then-act race condition where two threads can read the same value before either has a chance to write the new value back, leading to lost updates. The fix is to inject bytecode that calls a single, truly atomic method like invocationCount.incrementAndGet().