Atomic variables and concurrent collections: Java Programming (Core to Spring Boot) (Expert)

Atomic variables

An atomic variable performs read-modify-write operations as one indivisible step using special CPU instructions (compare-and-swap), without locks. It is the simplest fix for shared counters and statistics.

java

AtomicInteger requests = new AtomicInteger();
requests.incrementAndGet();            // safe from any number of threads
requests.addAndGet(5);
int now = requests.get();
AtomicLong totalPaise = new AtomicLong();
totalPaise.addAndGet(49_900);
requests.updateAndGet(n -> Math.min(n, 1000));   // atomic update with a function

ConcurrentHashMap

A plain HashMap used by several threads can lose entries or even corrupt itself. ConcurrentHashMap is designed for many readers and writers at once. Its compound methods (merge, compute, computeIfAbsent, putIfAbsent) are atomic, so counting per key is safe.

java

ConcurrentHashMap<String, Integer> hitsByCity = new ConcurrentHashMap<>();
// called from many request threads at the same time:
hitsByCity.merge("Pune", 1, Integer::sum);              // atomic per key
hitsByCity.computeIfAbsent("Goa", k -> 0);

// WRONG with any map shared between threads (check-then-act race):
// if (!map.containsKey(k)) map.put(k, 1); else map.put(k, map.get(k) + 1);

Other concurrent collections

Class	Use when
ConcurrentHashMap	A shared map with frequent reads and writes
CopyOnWriteArrayList	A list read very often, changed rarely (listeners, configuration)
ArrayBlockingQueue / LinkedBlockingQueue	Producer-consumer hand-off between threads
ConcurrentLinkedQueue	A non-blocking shared queue
Collections.synchronizedList	Old style: one lock for everything; usually slower

Producer-consumer with BlockingQueue

java

BlockingQueue<String> smsQueue = new ArrayBlockingQueue<>(100);

Thread producer = new Thread(() -> {
    for (int i = 1; i <= 5; i++) {
        try { smsQueue.put("OTP for user " + i); } catch (InterruptedException e) { return; }   // waits if full
    }
});
Thread consumer = new Thread(() -> {
    try {
        while (true) System.out.println("Sending " + smsQueue.take());   // waits if empty
    } catch (InterruptedException e) { /* stop */ }
});

CountDownLatch

java

CountDownLatch ready = new CountDownLatch(3);           // wait for 3 services
for (String svc : List.of("db", "cache", "payments")) {
    new Thread(() -> { connect(svc); ready.countDown(); }).start();
}
ready.await();                                          // main waits until the count reaches 0
System.out.println("All services connected, accepting traffic");

Immutability: the simplest thread safety

An object that never changes (final fields, no setters: records, String, LocalDate, List.of) can be shared by any number of threads with no locks at all. Designing most data as immutable and keeping mutable shared state small is the most reliable concurrency strategy.

Careful: Iterating a ConcurrentHashMap is safe but "weakly consistent": you may or may not see updates made during the loop, and size() is only an estimate under concurrent change. Do not build logic that needs an exact snapshot from a constantly changing map; take a copy or use proper synchronisation.

Think of it like this: An AtomicInteger is like a token-number machine at a bank: any number of people can press the button at the same moment, and each still gets a unique number. A BlockingQueue is like a conveyor belt between the kitchen and the delivery desk: the cook waits if the belt is full, and the packer waits if it is empty.

Tip: Before writing synchronized code, ask: can I use an atomic, a ConcurrentHashMap, a BlockingQueue, or an immutable object instead? Usually yes.

Atomic variables and concurrent collections

Explanation