How do I use Atomic variables from java.util.concurrent.atomic?

By I Wayan Saryada in Cryptography, Util Package 0 Comment

Atomic variables in java.util.concurrent.atomic are designed for lock-free, thread-safe operations on single variables. They leverage low-level CPU instructions like Compare-And-Swap (CAS) to ensure data consistency without the overhead of synchronized blocks.

Here’s a guide on how to use the most common atomic classes.

1. AtomicInteger and AtomicLong

These are used for numeric counters or IDs. Instead of using ++ (which is not atomic), you use methods like incrementAndGet().

package org.kodejava.util.concurrent;

import java.util.concurrent.atomic.AtomicInteger;

public class CounterExample {
    private final AtomicInteger counter = new AtomicInteger(0);

    public void increment() {
        // Atomically increments by one and returns the new value
        int newValue = counter.incrementAndGet();
        System.out.println("Current Value: " + newValue);
    }

    public int getValue() {
        return counter.get();
    }
}

2. AtomicBoolean

Useful for flags that need to be checked and updated across threads, such as a “running” state.

package org.kodejava.util.concurrent;

import java.util.concurrent.atomic.AtomicBoolean;

public class Worker {
    private final AtomicBoolean initialized = new AtomicBoolean(false);

    public void init() {
        // compareAndSet(expectedValue, newValue)
        // Only sets to true if it was currently false
        if (initialized.compareAndSet(false, true)) {
            System.out.println("Performing one-time initialization...");
        }
    }
}

3. AtomicReference

Used to wrap any object reference. This is great for implementing non-blocking algorithms where you need to update an entire object state atomically.

package org.kodejava.util.concurrent;

import java.util.concurrent.atomic.AtomicReference;

public class StateManager {
    private final AtomicReference<String> status = new AtomicReference<>("IDLE");

    public void updateStatus(String oldStatus, String newStatus) {
        boolean success = status.compareAndSet(oldStatus, newStatus);
        if (success) {
            System.out.println("Status changed to: " + newStatus);
        }
    }
}

4. Advanced Accumulators (LongAdder)

If you have a very high-contention environment (many threads constantly updating a sum), LongAdder is generally faster than AtomicLong because it maintains internal cells to reduce contention.

package org.kodejava.util.concurrent;

import java.util.concurrent.atomic.LongAdder;

public class HighContentionCounter {
    private final LongAdder adder = new LongAdder();

    public void add() {
        adder.increment();
    }

    public long getTotal() {
        return adder.sum();
    }
}

Key Methods to Remember

  • get() / set(): Read or write the value (similar to volatile).
  • lazySet(): Eventually sets the value; faster but doesn’t guarantee immediate visibility to other threads.
  • compareAndSet(expect, update): The heart of atomic variables. Updates only if the current value matches expect.
  • getAndAccumulate(delta, accumulatorFunction): (Java 8+) Allows complex atomic updates using a Lambda.

When to use them?

  • Use them for simple counters, sequence generators, or flags.
  • Avoid them if you need to update multiple dependent variables at once; in that case, a ReentrantLock or synchronized block is safer to ensure the entire operation is atomic.

How do I use ReentrantLock vs synchronized?

By I Wayan Saryada in Concurrency, Util Package 0 Comment

In Java, both synchronized and ReentrantLock are used to manage thread safety, but they offer different levels of control and flexibility.

1. synchronized Keyword

The synchronized keyword is the built-in mechanism in Java for mutual exclusion. It is simpler to use because the JVM automatically handles acquiring and releasing the lock.

  • Usage: Can be applied to methods or used as a block.
  • Automatic Release: The lock is automatically released when the thread exits the block or method, even if an exception occurs.
  • Performance: In modern JVMs, synchronized is highly optimized (biased locking, lightweight locking) and often performs just as well as ReentrantLock.

Example:

package org.kodejava.util.concurrent;

public class Counter {
    private int count = 0;

    public synchronized void increment() {
        count++;
    }

    public void incrementBlock() {
        synchronized (this) {
            count++;
        }
    }
}

2. ReentrantLock Class

ReentrantLock (from java.util.concurrent.locks) is an explicit lock implementation that provides advanced features not available with synchronized.

  • Manual Control: You must explicitly call lock() and unlock(). It is critical to use a try-finally block to ensure the lock is released.
  • Fairness: You can create a “fair” lock that gives preference to the longest-waiting thread.
  • Try Lock: tryLock() allows a thread to attempt to acquire the lock without blocking indefinitely.
  • Interruptible: A thread waiting for a ReentrantLock can be interrupted via lockInterruptibly().

Example:

package org.kodejava.util.concurrent;

import java.util.concurrent.locks.ReentrantLock;

public class LockCounter {
    private final ReentrantLock lock = new ReentrantLock();
    private int count = 0;

    public void increment() {
        lock.lock();
        try {
            count++;
        } finally {
            // Always unlock in finally to prevent deadlocks
            lock.unlock();
        }
    }
}

Key Differences

Feature synchronized ReentrantLock
Ease of Use Very easy; handled by JVM. Requires manual try-finally.
Fairness Not supported. Supported (optional constructor parameter).
Flexibility Rigid block structure. Highly flexible (can lock in one method, unlock in another).
Non-blocking No (thread always waits). Yes, via tryLock().
Interruptibility No. Yes, via lockInterruptibly().

Which should you choose?

  • Use synchronized by default. It’s cleaner, less error-prone, and sufficient for most basic thread-safety needs.
  • Use ReentrantLock when you need advanced features like:
    • Timing out while waiting for a lock (tryLock(timeout)).
    • Allowing the lock attempt to be interrupted.
    • Using a “Fair” lock strategy.
    • Complex locking structures that aren’t strictly nested.

If you are debugging concurrency issues, IntelliJ IDEA provides tools to inspect thread states and detect blocked monitors [1]. You can also use the Threads tab in the Debugger to see which thread owns a monitor or is waiting for one [2].

How do I use CountDownLatch for coordination?

By I Wayan Saryada in Concurrency, Util Package 0 Comment

A CountDownLatch is a synchronization aid that allows one or more threads to wait until a set of operations being performed in other threads completes. It’s initialized with a given count, and the await() methods block until the current count reaches zero due to invocations of the countDown() method.

Here is a practical guide on how to coordinate threads using CountDownLatch.

1. Basic Coordination Pattern

The most common use case is having a main thread wait for several worker threads to finish their tasks.

package org.kodejava.util.concurrent;

import java.util.concurrent.CountDownLatch;

public class LatchCoordination {
    public static void main(String[] args) throws InterruptedException {
        int numberOfWorkers = 3;
        // 1. Initialize with the number of events to wait for
        CountDownLatch latch = new CountDownLatch(numberOfWorkers);

        for (int i = 0; i < numberOfWorkers; i++) {
            new Thread(new Worker(latch, "Worker-" + i)).start();
        }

        System.out.println("Main thread is waiting...");
        // 2. Wait until the count reaches zero
        latch.await();

        System.out.println("All workers finished. Main thread proceeding.");
    }
}

class Worker implements Runnable {
    private final CountDownLatch latch;
    private final String name;

    Worker(CountDownLatch latch, String name) {
        this.latch = latch;
        this.name = name;
    }

    @Override
    public void run() {
        try {
            System.out.println(name + " is performing work...");
            Thread.sleep(1000); // Simulate work
        } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
        } finally {
            // 3. Crucial: Always decrement the count in a finally block
            latch.countDown();
            System.out.println(name + " finished. Remaining: " + latch.getCount());
        }
    }
}

2. Key Methods to Remember

  • new CountDownLatch(int count): Sets the initial count. This count cannot be reset. If you need to reset the count, consider using a CyclicBarrier.
  • countDown(): Decrements the count of the latch, releasing all waiting threads if the count reaches zero.
  • await(): Causes the current thread to wait until the latch has counted down to zero, unless the thread is interrupted.
  • await(long timeout, TimeUnit unit): A safer version that waits for a specific duration. It returns true if the count reached zero and false if the waiting time elapsed before the count reached zero.

3. Advanced Use: The “Starting Gun”

You can also use a CountDownLatch with a count of 1 as a “starting gun” to release many threads at the exact same moment (useful for load testing).

CountDownLatch startSignal = new CountDownLatch(1);

for (int i = 0; i < 10; i++) {
    new Thread(() -> {
        try {
            startSignal.await(); // All threads stall here
            // Do concurrent work...
        } catch (InterruptedException e) { /* handle */ }
    }).start();
}

// All threads start simultaneously when this is called
startSignal.countDown();

Best Practices

  • Always use finally: Place countDown() inside a finally block to ensure the latch is decremented even if a worker thread encounters an exception. Otherwise, the waiting thread might block indefinitely.
  • Don’t reuse: Once a CountDownLatch reaches zero, it cannot be reused. If your algorithm requires repeating the synchronization point, use a CyclicBarrier or Phaser.
  • Check the count: You can use latch.getCount() for debugging or monitoring, but don’t use it to make control flow decisions in production code as it is volatile.

How do I use CyclicBarrier for synchronization?

By I Wayan Saryada in Concurrency, Util Package 0 Comment

In Java’s concurrency utilities, CyclicBarrier is a synchronization aid that allows a set of threads to all wait for each other to reach a common barrier point. It is called “cyclic” because it can be re-used after the waiting threads are released.

Here is a breakdown of how to use it effectively.

1. Basic Concepts

  • Parties: The number of threads that must invoke await() before the barrier is tripped.
  • Barrier Action: An optional Runnable that is executed once per barrier point, after the last thread arrives, but before any threads are released.
  • await(): The core method threads call to wait. It blocks until all parties have arrived.

2. Implementation Steps

Create the Barrier

You initialize it with the number of participating threads.

import java.util.concurrent.CyclicBarrier;

// ...
int parties = 3;
CyclicBarrier barrier = new CyclicBarrier(parties, () -> {
    // This runs once all threads reach the barrier
    System.out.println("Barrier reached! Processing combined results...");
});

Define the Worker

Each thread performs its task and then calls barrier.await().

package org.kodejava.util.concurrent;

import java.util.concurrent.CyclicBarrier;

class Task implements Runnable {
    private final CyclicBarrier barrier;

    Task(CyclicBarrier barrier) {
        this.barrier = barrier;
    }

    @Override
    public void run() {
        try {
            System.out.println(Thread.currentThread().getName() + " is working...");
            // Simulate work
            Thread.sleep(1000);

            System.out.println(Thread.currentThread().getName() + " waiting at barrier.");
            barrier.await(); // Thread blocks here

            System.out.println(Thread.currentThread().getName() + " passed the barrier!");
        } catch (Exception e) {
            e.printStackTrace();
        }
    }
}

3. Key Differences from CountDownLatch

While both coordinate threads, they have distinct use cases:

  • Reusability: A CyclicBarrier can be reset and used again (hence “cyclic”). A CountDownLatch count cannot be reset once it reaches zero.
  • Waiting Mechanism: In a CyclicBarrier, the workers wait for each other. In a CountDownLatch, a main thread typically waits for workers to finish (workers don’t necessarily block).
  • Barrier Action: CyclicBarrier supports a custom action when the barrier trips; CountDownLatch does not.

4. Handling Broken Barriers

If a thread leaves the barrier prematurely (due to interruption, timeout, or failure), the barrier is considered “broken.” Any other threads waiting at the barrier will receive a BrokenBarrierException. You can check this status using barrier.isBroken().

Example Use Case

CyclicBarrier is ideal for parallel algorithms that involve multiple phases (iterative methods), where each phase must be completed by all threads before anyone starts the next phase.

How do I use Semaphore for resource control?

By I Wayan Saryada in Concurrency, Util Package 0 Comment

Semaphore is an advanced synchronization mechanism used to control access to a shared resource by multiple threads. It can maintain a set of permits, restricting how many threads can concurrently access a critical section or shared resource. If the permits are exhausted, additional threads will block until permits are released.

How to Use Semaphore for Resource Control

Here are the key steps for using a Semaphore:

1. Initialization

  • Permits: When creating Semaphore, specify the number of permits. This determines the maximum number of threads that can access the resource simultaneously.
  • Fairness: Optionally, you can specify a fairness policy (true for FIFO access to permits, false for default behavior).

    Example:

    Semaphore semaphore = new Semaphore(2, true); // 2 permits, FIFO fairness

2. Acquiring Permits

Threads must acquire permits before accessing the shared resource. The acquire() method blocks the thread if no permits are available.

  • Interruptible Acquire: acquire() blocks until a permit becomes available. 
    semaphore.acquire();
  • Immediate Acquire: tryAcquire() attempts to acquire and doesn’t block. Returns true if successful, false otherwise. 
    if (semaphore.tryAcquire()) {
    // Acquired permit
}
  • Timed Acquire: tryAcquire(timeout, TimeUnit) waits for a permit for a specified amount of time before giving up. 
    if (semaphore.tryAcquire(2, TimeUnit.SECONDS)) {
    // Acquired permit
}

3. Using the Shared Resource

After acquiring a permit, the thread performs its task within the critical section or accesses the shared resource.

Example:

// Critical section
System.out.println(Thread.currentThread().getName() + " is using the resource");

4. Releasing Permits

After completing the task, the thread should release the permit it acquired. This allows other threads to proceed.

  • Use release() to give up the permit: 
    semaphore.release();

If a thread fails to release its permit due to an exception or oversight, other threads might starve waiting for permits.

Example of Semaphore in Practice

Here’s a practical example:

package org.kodejava.util.concurrent;

import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
import java.util.concurrent.Semaphore;

public class SemaphoreExample {

    // Semaphore initialized with 2 permits (only 2 threads can access simultaneously).
    private static final Semaphore semaphore = new Semaphore(2);

    public static void main(String[] args) {
        // Create a thread pool with 5 threads
        try (ExecutorService executorService = Executors.newFixedThreadPool(5)) {

            // Let each thread try to acquire a permit and access a shared resource
            for (int i = 1; i <= 5; i++) {
                final int threadId = i;
                executorService.submit(() -> {
                    try {
                        System.out.println("Thread " + threadId + " is trying to acquire a permit.");
                        semaphore.acquire();

                        System.out.println("Thread " + threadId + " has acquired a permit.");
                        Thread.sleep(2000);  // Simulate using the shared resource

                    } catch (InterruptedException e) {
                        Thread.currentThread().interrupt();
                    } finally {
                        System.out.println("Thread " + threadId + " is releasing the permit.");
                        semaphore.release();
                    }
                });
            }
        }
    }
}

Key Concepts of Semaphores

  1. Permits:
    • Semaphore tracks the number of remaining permits.
    • Initial permits are specified at the time of creation.
  2. Blocking vs Non-blocking Acquire:
    • Threads may block (acquire()), attempt immediate access (tryAcquire()), or timeout (tryAcquire(timeout)).
  3. Fairness:
    • Semaphore fairness ensures FIFO granting of permits if fairness is enabled.
  4. Common Usage Scenarios:
    • Throttling: Limit the number of threads accessing resources like database connections or file IO simultaneously.
    • Rate Limiting: Control the frequency of tasks or API calls.
  5. Thread-Safe: The semaphore internally ensures thread-safety using synchronization primitives.

By using these steps, you can effectively use semaphore to control access to a shared resource, ensuring both mutual exclusion and efficient resource utilization.