The previous four chapters focused on Java’s low-level support for threads. This chapter switches that focus to Java’s high-level thread support, which is known as the concurrency utilities. Think of the concurrency utilities as being analogous to writing applications in a high-level language and its low-level thread support as being analogous to writing applications in assembly language. After briefly introducing you to these utilities, I take you on a tour of executors. The next three chapters will cover other subsets of the various concurrency utilities.

Introducing the Concurrency Utilities

Java’s low-level threads support lets you create multithreaded applications that offer better performance and responsiveness over their single-threaded counterparts. However, there are problems:

• Low-level concurrency primitives such as synchronized and wait()/notify() are often hard to use correctly. Incorrect use of these primitives can result in race conditions, thread starvation, deadlock, and other hazards, which can be hard to detect and debug.
• Too much reliance on the synchronized primitive can lead to performance issues, which affect an application’s scalability. This is a significant problem for highly-threaded applications such as web servers.
• Developers often need higher-level constructs such as thread pools and semaphores. Because these constructs aren’t included with Java’s low-level thread support, developers have been forced to build their own, which is a time-consuming and error-prone activity.

To address these problems, Java 5 introduced the concurrency utilities, a powerful and extensible framework of high-performance threading utilities such as thread pools and blocking queues. This framework consists of various types in the following packages:

• java.util.concurrent: Utility types that are often used in concurrent programming, for example, executors.
• java.util.concurrent.atomic: Utility classes that support lock-free thread-safe programming on single variables.
• java.util.concurrent.locks: Utility types that lock and wait on conditions (objects that let threads suspend execution [wait] until notified by other threads that some boolean state may now be true). Locking and waiting via these types is more performant and flexible than doing so via Java’s monitor-based synchronization and wait/notification mechanisms.

This framework also introduces a long nanoTime() method to the java.lang.System class, which lets you access a nanosecond-granularity time source for making relative time measurements.

The concurrency utilities can be classified as executors, synchronizers, a locking framework, and more. I explore executors in the next section and these other categories in subsequent chapters.

Exploring Executors

The Threads API lets you execute runnable tasks via expressions such as new java.lang.Thread(new RunnableTask()).start();. These expressions tightly couple task submission with the task’s execution mechanics (run on the current thread, a new thread, or a thread arbitrarily chosen from a pool [group] of threads).

The concurrency utilities include executors as a high-level alternative to low-level thread expressions for executing runnable tasks. An executor is an object whose class directly or indirectly implements the java.util.concurrent.Executor interface, which decouples task submission from task-execution mechanics.

Executor declares a solitary void execute(Runnable runnable) method that executes the runnable task named runnable at some point in the future. execute() throws java.lang.NullPointerException when runnable is null and java.util.concurrent.RejectedExecutionException when it cannot execute runnable.

The following example presents the Executor equivalent of the aforementioned new Thread(new RunnableTask()).start(); expression:

Executor executor = ...; //  ... represents some executor creation
executor.execute(new RunnableTask());

Although Executor is easy to use, this interface is limited in various ways:

• Executor focuses exclusively on Runnable. Because Runnable’s run() method doesn’t return a value, there’s no easy way for a runnable task to return a value to its caller.
• Executor doesn’t provide a way to track the progress of runnable tasks that are executing, cancel an executing runnable task, or determine when the runnable task finishes execution.
• Executor cannot execute a collection of runnable tasks.
• Executor doesn’t provide a way for an application to shut down an executor (much less properly shut down an executor).

These limitations are addressed by the java.util.concurrent.ExecutorService interface, which extends Executor and whose implementation is typically a thread pool. Table 5-1 describes ExecutorService’s methods.

Table 5-1 refers to java.util.concurrent.TimeUnit, an enum that represents time durations at given units of granularity: DAYS, HOURS, MICROSECONDS, MILLISECONDS, MINUTES, NANOSECONDS, and SECONDS. Furthermore, TimeUnit declares methods for converting across units (such as long toHours(long duration)), and for performing timing and delay operations (such as void sleep(long timeout)) in these units.

Table 5-1 also refers to callable tasks. Unlike Runnable, whose void run() method cannot return a value and throw checked exceptions, Callable<V>’s V call() method returns a value and can throw checked exceptions because it’s declared with a throws Exception clause.

Finally, Table 5-1 refers to the Future interface, which represents the result of an asynchronous computation. The result is known as a future because it typically will not be available until some moment in the future. Future, whose generic type is Future<V>, provides methods for canceling a task, for returning a task’s value, and for determining whether or not the task has finished. Table 5-2 describes Future’s methods.

Suppose you intend to write an application whose graphical user interface lets the user enter a word. After the user enters the word, the application presents this word to several online dictionaries and obtains each dictionary’s entry. These entries are subsequently displayed to the user.

Because online access can be slow, and because the user interface should remain responsive (perhaps the user might want to end the application), you offload the “obtain word entries” task to an executor that runs this task on a separate thread. The following example uses ExecutorService, Callable, and Future to accomplish this objective:

ExecutorService executor = ...; // ... represents some executor creation
Future<String[]> taskFuture =
   executor.submit(new Callable<String[]>()
                   {
                      @Override
                      public String[] call()
                      {
                         String[] entries = ...;
                         // Access online dictionaries
                         // with search word and populate
                         // entries with their resulting
                         // entries.
                         return entries;
                      }
                   });
// Do stuff.
String entries = taskFuture.get();

After obtaining an executor in some manner (you will learn how shortly), the example’s thread submits a callable task to the executor. The submit() method immediately returns with a reference to a Future object for controlling task execution and accessing results. The thread ultimately calls this object’s get() method to get these results.

Although you could create your own Executor, ExecutorService, and ScheduledExecutorService implementations (such as class DirectExecutor implements Executor { @Override public void execute(Runnable r) { r.run(); } }—run executor directly on the calling thread), there’s a simpler alternative: java.util.concurrent.Executors.

The Executors utility class declares several class methods that return instances of various ExecutorService and ScheduledExecutorService implementations (and other kinds of instances). This class’s static methods accomplish the following tasks:

• Create and return an ExecutorService instance that’s configured with commonly used configuration settings.
• Create and return a ScheduledExecutorService instance that’s configured with commonly used configuration settings.
• Create and return a “wrapped” ExecutorService or ScheduledExecutorService instance that disables reconfiguration of the executor service by making implementation-specific methods inaccessible.
• Create and return a java.util.concurrent.ThreadFactory instance (that is, an instance of a class that implements the ThreadFactory interface) for creating new Thread objects.
• Create and return a Callable instance out of other closure-like forms so that it can be used in execution methods that require Callable arguments (such as ExecutorService’s submit(Callable) method). Wikipedia’s “Closure (computer science)” entry at http://en.wikipedia.org/wiki/Closure_(computer_science) introduces the topic of closures.

For example, static ExecutorService newFixedThreadPool(int nThreads) creates a thread pool that reuses a fixed number of threads operating off of a shared unbounded queue. At most, nThreads threads are actively processing tasks. If additional tasks are submitted when all threads are active, they wait in the queue for an available thread.

If any thread terminates because of a failure during execution before the executor shuts down, a new thread will take its place when needed to execute subsequent tasks. The threads in the pool will exist until the executor is explicitly shut down. This method throws IllegalArgumentException when you pass zero or a negative value to nThreads.

You would commonly use executors, runnables, callables, and futures in file and network input/output contexts. Performing a lengthy calculation offers another scenario where you could use these types. For example, Listing 5-1 uses an executor, a callable, and a future in a calculation context of Euler’s number e (2.71828...).

import java.math.BigDecimal;
import java.math.MathContext;
import java.math.RoundingMode;

import java.util.concurrent.Callable;
import java.util.concurrent.ExecutionException;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
import java.util.concurrent.Future;

public class CalculateE
{
   final static int LASTITER = 17;

   public static void main(String[] args)
   {
      ExecutorService executor = Executors.newFixedThreadPool(1);
      Callable<BigDecimal> callable;
      callable = new Callable<BigDecimal>()
                 {
                    @Override
                    public BigDecimal call()
                    {
                       MathContext mc =
                         new MathContext(100, RoundingMode.HALF_UP);
                       BigDecimal result = BigDecimal.ZERO;
                       for (int i = 0; i <= LASTITER; i++)
                       {
                          BigDecimal factorial =
                             factorial(new BigDecimal(i));
                          BigDecimal res = BigDecimal.ONE.divide(factorial,
                                                                 mc);
                          result = result.add(res);
                       }
                       return result;
                    }

                    public BigDecimal factorial(BigDecimal n)
                    {
                       if (n.equals(BigDecimal.ZERO))
                          return BigDecimal.ONE;
                       else
                          return n.multiply(factorial(n.
                                   subtract(BigDecimal.ONE)));
                    }
                 };
      Future<BigDecimal> taskFuture = executor.submit(callable);
      try
      {
         while (!taskFuture.isDone())
            System.out.println("waiting");
         System.out.println(taskFuture.get());
      }
      catch(ExecutionException ee)
      {
         System.err.println("task threw an exception");
         System.err.println(ee);
      }
      catch(InterruptedException ie)
      {
         System.err.println("interrupted while waiting");
      }
      executor.shutdownNow();
   }
}

The default main thread that executes main() first obtains an executor by calling Executors’ newFixedThreadPool() method. It then instantiates an anonymous class that implements the Callable interface and submits this task to the executor, receiving a Future instance in response.

After submitting a task, a thread typically does some other work until it requires the task’s result. I simulate this work by having the main thread repeatedly output a waiting message until the Future instance’s isDone() method returns true. (In a realistic application, I would avoid this looping.) At this point, the main thread calls the instance’s get() method to obtain the result, which is then output. The main thread then shuts down the executor.

The callable’s call() method calculates e by evaluating the mathematical power series e = 1 / 0! + 1 / 1! + 1 / 2! + . . . . This series can be evaluated by summing 1 / n!, where n ranges from 0 to infinity (and ! stands for factorial).

call() first instantiates java.math.MathContext to encapsulate a precision (number of digits) and a rounding mode. I chose 100 as an upper limit on e’s precision, and I also chose HALF_UP as the rounding mode.

call() next initializes a java.math.BigDecimal local variable named result to BigDecimal.ZERO. It then enters a loop that calculates a factorial, divides BigDecimal.ONE by the factorial, and adds the division result to result.

The divide() method takes the MathContext instance as its second argument to provide rounding information. (If I specified 0 as the precision for the math context and a nonterminating decimal expansion [the quotient result of the division cannot be represented exactly—0.3333333..., for example] occurred, java.lang.ArithmeticException would be thrown to alert the caller to the fact that the quotient cannot be represented exactly. The executor would rethrow this exception as ExecutionException.)

Compile Listing 5-1 as follows:

javac CalculateE.java

Run the resulting application as follows:

java CalculateE

You should observe output that’s similar to the following (you’ll probably observe more waiting messages):

waiting
waiting
waiting
waiting
waiting
2.718281828459045070516047795848605061178979635251032698900735004065225042504843314055887974344245741730039454062711

Summary

Java’s low-level thread capabilities let you create multithreaded applications that offer better performance and responsiveness over their single-threaded counterparts. However, performance issues that affect an application’s scalability and other problems resulted in Java 5’s introduction of the concurrency utilities.

The concurrency utilities organize various types into three packages: java.util.concurrent, java.util.concurrent.atomic, and java.util.concurrent.locks. Basic types for executors, thread pools, concurrent hashmaps, and other high-level concurrency constructs are stored in java.util.concurrent; classes that support lock-free, thread-safe programming on single variables are stored in java.util.concurrent.atomic; and types for locking and waiting on conditions are stored in java.util.concurrent.locks.

An executor decouples task submission from task-execution mechanics and is described by the Executor, ExecutorService, and ScheduledExecutorService interfaces. You obtain an executor by calling one of the utility methods in the Executors class. Executors are associated with callables and futures.

Chapter 6 presents synchronizers.