Utility classes commonly useful in concurrent programming. This package includes a few small standardized extensible frameworks, as well as some classes that provide useful functionality and are otherwise tedious or difficult to implement. Here are brief descriptions of the main components. See also the locks and atomic packages.
{@link java.util.concurrent.ExecutorService} provides a more complete framework for executing Runnables. An ExecutorService manages queueing and scheduling of tasks, and allows controlled shutdown. The two primary implementations of ExecutorService are {@link java.util.concurrent.ThreadPoolExecutor}, a highly tunable and flexible thread pool and {@link java.util.concurrent.ScheduledExecutor}, which adds support for delayed and periodic task execution. These, and other Executors can be used in conjunction with a {@link java.util.concurrent.FutureTask} to asynchronously start a potentially long-running computation and query the FutureTask to determine if its execution has completed, or cancel it.
The {@link java.util.concurrent.Executors} class provides factory methods for the most common kinds and configurations of Executors, as well as a few utility methods for using them.
Five implementations in java.util.concurrent support the extended {@link java.util.concurrent.BlockingQueue} interface, that defines blocking versions of put and take: {@link java.util.concurrent.LinkedBlockingQueue}, {@link java.util.concurrent.ArrayBlockingQueue}, {@link java.util.concurrent.SynchronousQueue}, {@link java.util.concurrent.PriorityBlockingQueue}, and {@link java.util.concurrent.DelayQueue}. The different classes cover the most common usage contexts for producer-consumer, messaging, parallel tasking, and related concurrent designs.
In all cases that time-outs are used, the time-out specifies the minimum time that the method should wait before indicating that it timed-out. The virtual machine should make a "best effort" to detect time-outs as soon as possible after they occur. Regardless of the efforts of the virtual machine, the normal scheduling mechanisms, and the need to re-acquire locks in many cases, can lead to an indefinite amount of time elapsing between a time-out being detected and a thread actually executing again after that time-out.
The "Concurrent" prefix for classes is a shorthand indicating several differences from similar "synchronized" classes. For example java.util.Hashtable and Collections.synchronizedMap(new HashMap()) are synchronized. But {@link java.util.concurrent.ConcurrentHashMap} is "concurrent". A concurrent collection (among other kinds of classes) is thread-safe, but not governed by a single exclusion lock. So, in the particular case of ConcurrentHashMap, it safely permits any number of concurrent reads as well as a tunable number of concurrent writes. There may still be a role for "synchronized" classes in some multithreaded programs -- they can sometimes be useful when you need to prevent ALL access to a collection via a single lock, at the expense of much poor scalability. In all other cases, "concurrent" versions are normally preferable.
Most concurrent Collection implementations (including most Queues) also differ from the usual java.util conventions in that their Iterators provide weakly consistent rather than fast-fail traversal. A weakly consistent iterator is thread-safe, but does not necessarily freeze the collection while iterating, so it may (or may not) reflect any updates since the iterator was created.