Control flow- CounterService has a private int counter initialized to 0.- increment() reads counter, adds 1, and writes it back.- getAndReset() reads counter into local, sets counter = 0, returns the saved value.Thread-safety issue / race conditions- counter is a plain int; increment() and getAndReset() are non-atomic composite operations. Concurrent threads can interleave: - Lost increments: two threads executing counter += 1 can read same value and write same result. - Race on reset: getAndReset() may read a stale or partial value while increments are happening; increments can be lost if they occur concurrently with the reset.- No visibility guarantees: without synchronization or volatility, one thread’s write may not be visible to another.Two possible fixes1) Use synchronization (simple, correct)java
public class CounterService {
private int counter = 0;
public synchronized void increment() {
counter += 1;
}
public synchronized int getAndReset() {
int current = counter;
counter = 0;
return current;
}
}
java
import java.util.concurrent.atomic.AtomicInteger;
public class CounterService {
private final AtomicInteger counter = new AtomicInteger(0);
public void increment() {
counter.incrementAndGet(); // atomic increment
}
public int getAndReset() {
return counter.getAndSet(0); // atomically returns old value and sets to 0
}
}
java
import java.util.concurrent.atomic.LongAdder;
public class CounterService {
private final LongAdder counter = new LongAdder();
public void increment() {
counter.increment();
}
public long getAndReset() {
return counter.sumThenReset(); // atomic for LongAdder
}
}
