From its creation, Java has supported key concurrency concepts such as threads and locks. This guide helps Java developers working with multi-threaded programs to understand the core concurrency concepts and how to apply them. Topics covered in this guide include builtin Java language features like Thread, synchronized, and volatile, as well as new constructs added in JavaSE 5 such as Locks, Atomics, concurrent collections, thread coordination abstraction, and Executors. Using these building blocks, developers can build highly concurrent and thread-safe Java applications.

This section describes key Java Concurrency concepts that are used throughout this DZone Refcard.

Table 1: Java Concurrency Concepts

Writing thread-safe Java programs requires a developer to use proper locking when modifying shared data. Locking establishes the orderings needed to satisfy the Java Memory Model and guarantee the visibility of changes to other threads.

Synchronized

Every object instance has a monitor that can be locked by one thread at a time. The synchronized keyword can be specified on a method or in block form to lock the monitor. Modifying a field while synchronized on an object guarantees that subsequent reads from any other thread synchronized on the same object will see the updated value. It is important to note that writes outside synchronization or synchronized on a different object than the read are not necessarily ever visible to other threads.

The synchronized keyword can be specified on a method or in block form on a particular object instance. If specified on a non-static method, the this reference is used as the instance. In a synchronized static method, the Class defining the method is used as the instance.

Lock

The java.util.concurrent.locks package has a standard Lock interface. The ReentrantLock implementation duplicates the functionality of the synchronized keyword but also provides additional functionality such as obtaining information about the state of the lock, non-blocking tryLock(), and interruptible locking.

Example of using an explicit ReentrantLock instance:

public class Counter {
  private final Lock lock = new ReentrantLock();
  private int value = 0;
  public int increment() {
   lock.lock();
   try {
    return ++value;
   } finally {
    lock.unlock();
   }
  }
}

ReadWriteLock

The java.util.concurrent.locks package also contains a ReadWriteLock interface (and ReentrantReadWriteLock implementation) which is defined by a pair of locks for reading and writing, typically allowing multiple concurrent readers but only one writer. Example of using an explicit ReentrantReadWriteLock to allow multiple concurrent readers:

public class Statistic {
  private final ReadWriteLock lock = new ReentrantReadWriteLock();
  private int value;
  public void increment() {
   lock.writeLock().lock();
   try {
     value++;
   } finally {
     lock.writeLock().unlock();
   }
  }
  public int current() {
    lock.readLock().lock();
    try {
      return value;
   } finally {
     lock.readLock().unlock();
   }
  }
}

Volatile

The volatile modifier can be used to mark a field and indicate that changes to that field must be seen by all subsequent reads by other threads, regardless of synchronization. Thus, volatile provides visibility just like synchronization but scoped only to each read or write of the field. Before Java SE 5, the implementation of volatile was inconsistent between JVM implementations and architectures and could not be relied upon. The Java Memory Model now explicitly defines volatile’s behavior.

An example of using volatile as a signaling flag:

public class Processor implements Runnable {
  private volatile boolean stop;
  public void stopProcessing() {
   stop = true;

   }
   public void run() {
    while(! stop) {
      // .. do processing
    }
  }
}

Atomic Classes

One shortcoming of volatile is that while it provides visibility guarantees, you cannot both check and update a volatile field in a single atomic call. The java.util.concurrent.atomic package contains a set of classes that support atomic compound actions on a single value in a lock-free manner similar to volatile.

public class Counter {
  private AtomicInteger value = new AtomicInteger();
    public int next() {
   return value.incrementAndGet();
  }
}

The incrementAndGet method is just one example of a compound action available on the Atomic classes. Atomic classes are provided for booleans, integers, longs, and object references as well as arrays of integers, longs, and object references.

ThreadLocal

One way to contain data within a thread and make locking unnecessary is to use ThreadLocal storage. Conceptually a ThreadLocal acts as if there is a variable with its own version in every Thread. ThreadLocals are commonly used for stashing per-Thread values like the “current transaction” or other resources. Also, they are used to maintain per-thread counters, statistics, or ID generators.

public class TransactionManager {
  private static final ThreadLocal<Transaction> currentTransaction =
    new ThreadLocal<Transaction>() {
     @Override
     protected Transaction initialValue() {
       return new NullTransaction();
     }
    };
   public Transaction currentTransaction() {
     Transaction current = currentTransaction.get();
     if(current.isNull()) {
       current = new TransactionImpl();
       currentTransaction.put(current);
     }
     return current;
  }
}

Concurrent Collections

A key technique for properly protecting shared data is to encapsulate the synchronization mechanism with the class holding the data. This technique makes it impossible to improperly access the data as all usage must conform to the synchronization protocol. The java.util.concurrent package holds many data structures designed for concurrent use. Generally, the use of these data structures yields far better performance than using a synchronized wrapper around an unsynchronized collection.

Concurrent Lists and Sets

The java.util.concurrent package contains three concurrent List and Set implementations described in Table 2.

Concurrent Maps

The java.util.concurrent package contains an extension to the Map interface called ConcurrentMap, which provides some extra methods described in Table 3. All of these methods perform a set of actions in the scope of a single atomic action. Performing this set of actions outside the map would introduce race conditions due to making multiple (non-atomic) calls on the map.

Table 3: ConcurrentMap methods

There are two ConcurrentMap implementations available as s hown in Table 4.

Table 4: ConcurrentMap implementations

Queues

Queues act as pipes between “producers” and “consumers”. Items are put in one end of the pipe and emerge from the other end of the pipe in the same “first-in first-out” (FIFO) order.

The Queue interface was added to java.util in Java SE 5 and while it can be used in single-threaded scenarios, it is primarily used with multiple producers or one or more consumers, all writing and reading from the same queue.

The BlockingQueue interface is in java.util.concurrent and extends Queue to provide additional choices of how to handle the scenario where a queue may be full (when a producer adds an item) or empty (when a consumer reads or removes an item).

In these cases, BlockingQueue provides methods that either block forever or block for a specified time period, waiting for the condition to change due to the actions of another thread. Table 5 demonstrates the Queue and BlockingQueue methods in terms of key operations and the strategy for dealing with these special conditions.

Table 5: Queue and BlockingQueue methods

Several Queue implementations are provided by the JDK and their relationships are discribed in Table 6.

Table 6: Queue Implementations

Deques

A double-ended queue or Deque (pronounced “deck”) was added in Java SE 6. Deques support not just adding from one end and removing from the other but adding and removing items from both ends. Similarly to BlockingQueue, there is a BlockingDeque interface that provides methods for blocking and timeout in the case of special conditions. Table 7 shows the Deque and BlockingDeque methods. Because Deque extends Queue and BlockingDeque extends BlockingQueue, all of those methods are also available for use.

Table 7: Deque and BlockingDeque methods

One special use case for a Deque is when add, remove, and examine operations all take place on only one end of the pipe. This special case is just a stack (first-in-last-out retrieval order). The Deque interface actually provides methods that use the terminology of a stack: push(), pop(), and peek(). These methods map to addFirst(), removeFirst(), and peekFirst() methods in the Deque interface and allow you to use any Deque implementation as a stack. Table 8 describes the Deque and BlockingDeque implementations in the JDK. Note that Deque extends Queue and BlockingDeque extends BlockingQueue

Table 8: Deques

In Java, the java.lang.Thread class is used to represent an application or JVM thread. Code is always being executed in the context of some Thread class (use Thread.currentThread() to obtain your own Thread).

Thread Communication

The most obvious way to communicate between threads is for one thread to directly call a method on another Thread object. Table 9 shows methods on Thread that can be used for direct interaction across threads.

Table 9: Thread coordination methods

Uncaught Exception Handlers

Threads can specify an UncaughtExceptionHandler that will receive notification of any uncaught exception that cause a thread to abruptly terminate.

Thread t = new Thread(runnable);
t.setUncaughtExceptionHandler(new Thread.
  UncaughtExceptionHandler() {
    void uncaughtException(Thread t, Throwable e) {
      // get Logger and log uncaught exception
    }
  });
t.start();

Deadlock

A deadlock occurs when there is more than one thread, each waiting for a resource held by another, such that a cycle of resources and acquiring threads is formed. The most obvious kind of resource is an object monitor but any resource that causes blocking (such as wait / notify) can qualify.

Many recent JVMs can detect monitor deadlocks and will print deadlock information in thread dumps produced from a signal, jstack, or other thread dump tool.

In addition to deadlock, some other threading situations are starvation and livelock. Starvation occurs when threads hold a lock for long periods such that some threads “starve” without making progress. Livelock occurs when threads spend all of their time negotiating access to a resource or detecting and avoiding deadlock such that no thread actually makes progress.

Wait/Notify

The wait/notify idiom is appropriate whenever one thread needs to signal to another that a condition has been met, especially as an alternative to sleeping in a loop and polling the condition. For example, one thread might wait for a queue to contain an item to process. Another thread can signal the waiting threads when an item is added to the queue.

The canonical usage pattern for wait and notify is as follows:

public class Latch {
  private final Object lock = new Object();
  private volatile boolean flag = false;
  public void waitTillChange() {
   synchronized(lock) {
    while(! flag) {
     try {
      lock.wait();
     } catch(InterruptedException e) {
    }
   }
  }
}
public void change() {
  synchronized(lock) {
    flag = true;
     lock.notifyAll();
    }
  }
}

Some important things to note about this code:

• • Always call wait, notify, and notifyAll inside a synchronized lock or an IllegalMonitorStateException will be thrown.
• Always wait inside a loop that checks the condition being waited on – this addresses the timing issue if another thread satisfies the condition before the wait begins. Also, it protects your code from spurious wake-ups that can (and do) occur.
• Always ensure that you satisfy the waiting condition before calling notify or notifyAll. Failing to do so will cause a notification but no thread will ever be able to escape its wait loop.

Condition

In Java SE 5, a new java.util.concurrent.locks.Condition class was added. Condition implements the wait/notify semantics in an API but with several additional features such as the ability to create multiple Conditions per Lock, interruptible waiting, access to statistics, etc. Conditions are obtained from a Lock instance as follows:

public class LatchCondition {
  private final Lock lock = new ReentrantLock();
  private final Condition condition = lock.newCondition();
  private volatile boolean flag = false;
  public void waitTillChange() {
    lock.lock();
        try {
          while(! flag) {
           condition.await();
         }
        } finally {
     lock.unlock();
        }
  }
  public void change() {
    lock.lock();
    try {

flag = true;
          condition.signalAll();
    } finally {
     lock.unlock();
    }
  }
}

Coordination Classes

The java.util.concurrent package contains several classes pre-built for common forms of multi-thread communication. These coordination classes cover most common scenarios where wait/notify and Condition might be used and are strongly perferred for their safety and ease of use.

CyclicBarrier

The CyclicBarrier is initialized with a participant count. Participants call await() and block until the count is reached, at which point an optional barrier task is executed by the last arriving thread, and all threads are released. The barrier can be reused indefinitely. Used to coordinate the start and stop of groups of threads.

CountDownLatch

The CountDownLatch is initialized with a count. Threads may call await() to wait for the count to reach 0. Other threads (or same) may call countDown() to reduce count. Not reusable once the count has reached 0. Used to trigger an unknown set of threads once some number of actions has occurred.

Semaphore

A Semaphore manages a set of “permits” that can be checked out with acquire() which will block until one is available. Threads call release() to return the permit. A semaphore with one permit is equivalent to a mutual exclusion block.

Exchanger

An Exchanger waits for threads to meet at the exchange() method and swap values atomically. This is similar to using a SynchronousQueue but data values pass in both directions.

Many concurrent Java programs need a pool of workers executing tasks from a queue. The java.util.concurrent package provides a solid foundation for this style of work management.

ExecutorService

The Executor and more expansive ExecutorService interfaces define the contract for a component that can execute tasks. Users of these interfaces can get a wide variety of implementation behaviors behind a common interface.

The most generic Executor interface accepts jobs only in the form of Runnables:

• void execute(Runnable command)

The ExecutorService extends Executor to add methods that take both Runnable and Callable task and collections of tasks:

• Future<?> submit(Runnable task)
• Future<T> submit(Callable<T> task)
• Future<T> submit(Runnable task, T result)
• List<Future<T> invokeAll(Collection<? extends Callable<T> tasks)
• List<Future<T> invokeAll(Collection<? extends Callable<T>> tasks, long timeout, TimeUnit unit)
• T invokeAny(Collection<? extends Callable<T>> tasks)
• T invokeAny(Collection<? extends Callable<T>> tasks, long timeout, TimeUnit unit)

Callable and Future

A Callable is like the familiar Runnable but can return a result and throw an exception:

• V call() throws Exception;

It is common in the executor framework to submit a Callable and receive a Future. A Future is a marker representing a result that will be available at some point in the future. The Future has methods that allow you to either poll or block while waiting for the result to be ready. You can also cancel the task before or while it’s executing through methods on Future.

If you need the functionality of a Future where only Runnables are supported (as in Executor), you can use FutureTask as a bridge. FutureTask implements both Future and Runnable so that you can submit the task as a Runnable and use the task itself as a Future in the caller.

ExecutorService Implementations

The primary implementation of ExecutorService is ThreadPoolExecutor. This implementation class provides a wide variety of configurable features:

• Thread pool – specify “core” thread count (optionally prestarted), and max thread count
• Thread factory – generate threads with custom characteristics such as a custom name
• Work queue – specify the queue implementation, which must be blocking, but can be bounded or unbounded
• Rejected tasks – specify the policy for tasks that cannot be accepted due to a full input queue or unavailable worker
• Lifecycle hooks – overridden to extend to override key points in the lifecycle like before or after task execution
• Shutdown – stop incoming tasks and wait for executing tasks to complete

ScheduledThreadPoolExecutor is an extension of ThreadPoolExecutor that provides the ability to schedule tasks for completion rather than using FIFO semantics. For cases where java.util.Timer is not sophisticated enough, the ScheduledThreadPoolExecutor often provides sufficient flexibility.

The Executors class contains many static methods (see Table 10) for creating prepackaged ExecutorService and ScheduledExecutorService instances that will cover a wide variety of common use cases.

Table 10: Executors factory methods

The following example creates a fixed thread pool and submits a long-running task to it:

int processors = Runtime.getRuntime().availableProcessors();
ExecutorService executor = Executors.
   newFixedThreadPool(processors);
Future<Integer> futureResult = executor.submit(
  new Callable<Integer>() {
   public Integer call() {
    // long running computation that returns an integer
   }
  });
Integer result = futureResult.get(); // block for result

In this example the call that submits the task to the executor will not block but return immediately. The last line will block on the get() call until the result is available.

ExecutorService covers almost all situations where you would previously create Thread objects or thread pools. Any time your code is constructing a Thread directly, consider whether you could accomplish the same goal with an ExecutorService produced by one of the Executor factory methods; often this will be simpler and more flexible.

CompletionService

Beyond the common pattern of a pool of workers and an input queue, it is common for each task to produce a result that must be accumulated for further processing. The CompletionService interface allows a user to submit Callable and Runnable tasks but also to take or poll for results from the results queue:

• Future<V> take() – take if available
• Future<V> poll() – block until available
• Future<V> poll(long timeout, TimeUnit unit) – block until timeout ends

The ExecutorCompletionService is the standard implementation of CompletionService. It is constructed with an Executor that provides the input queue and worker thread pool.