JSR 166 Snapshot Introduction.
by Doug Lea
To join a mailing list discussing this JSR, go to:
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest .
Disclaimer - This prototype is experimental code developed as part of
JCP JSR166 and made available to the developer community for use
as-is. It is not a supported product. Use it at your own risk. The
specification, language and implementation are subject to change as a
result of your feedback. Because these features have not yet been
approved for addition to the Java language, there is no schedule for
their inclusion in a product.
Package java.util.concurrent contains utility classes commonly
useful in concurrent programming. Like package java.util, it includes
a few small standardized extensible frameworks, as well as some
classes that provide useful functionality and are otherwise tedious or
difficult to implement. JSR166 also includes a few changes and
additions in packages outside of java.util.concurrent: java.lang, to
address uncaught exceptions, and java.util to better integrate with
collections. Since the target release is JDK1.5, many APIs use
generics to parameterize on types. Here are brief descriptions of the
main components.
Executors
{@link java.util.concurrent.Executor} is a simple standardized
interface for defining custom thread-like subsystems, including thread
pools, asynch-IO, and lightweight task frameworks. Depending on which
concrete Executor class is being used, tasks may execute in a newly
created thread, an existing task-execution thread, or the thread
calling execute(), and may execute sequentially or
concurrently. Executors also standardize ways of calling threads that
compute functions returning results, via a {@link
java.util.concurrent.Future}. This is supported in part by defining
interface {@link java.util.concurrent.Callable}, the argument/result
analog of Runnable.
{@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 styles of Executors, as well as
a few utilities methods for using them.
Queues
A basic (nonblocking) {@link java.util.Queue} interface extending
java.util.Collection is introduced into java.util. Existing class
java.util.LinkedList is adapted to support Queue, and a new
non-thread-safe {@link java.util.PriorityQueue}
is added. The java.util.concurrent {@link
java.util.concurrent.LinkedQueue} class supplies an efficient
thread-safe non-blocking queue.
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}.
Locks
The {@link java.util.concurrent.Lock} interface supports locking
disciplines that differ in semantics (reentrant, fair, etc), and that
can be used in non-block-structured contexts including hand-over-hand
and lock reordering algorithms. This flexibility comes at the price of
more awkward syntax. Implementations include {@link
java.util.concurrent.ReentrantLock} and {@link
java.util.concurrent.FairReentrantLock}.
The {@link java.util.concurrent.Locks} class additionally supports
some common trylock-designs using builtin locks.
The {@link java.util.concurrent.ReadWriteLock} interface similarly
defines locks that may be shared among readers but are exclusive to
writers. Only a single implementation, {@link
java.util.concurrent.ReentrantReadWriteLock}, is provided, since it
covers all standard usage contexts. But programmers may create their
own implementations to cover nonstandard requirements.
Conditions
The {@link java.util.concurrent.Condition} interface describes the
kinds of condition variables associated with monitors in other
concurrent languages, as well as pthreads-style condvars. Their
support reduces the need for tricky and/or inefficient solutions to
many classic concurrent problems. To avoid compatibility problems,
the names of Condition methods are different than Object versions.
Atomics
The atomic subpackage includes a small library of classes, including
AtomicInteger, AtomicLong, and AtomicReference that support
compareAndSet (CAS) and related atomic operations.
Timing
The {@link java.util.concurrent.TimeUnit} class provides multiple
granularities (including nanoseconds) for both accessing time and
performing time-out based operations.
Synchronizers
Five classes aid common special-purpose synchronization idioms.
{@link java.util.concurrent.Semaphore} and {@link
java.util.concurrent.FairSemaphore} are classic concurrency tools.
{@link java.util.concurrent.CountDownLatch} is very simple yet very
common utility for blocking until a single signal, event, or condition
holds. A {@link java.util.concurrent.CyclicBarrier} is a resettable multiway
synchronization point common in some styles of parallel
programming. An {@link java.util.concurrent.Exchanger} allows two
threads to exchange objects at a rendezvous point.
Concurrent Collections
This package supplies a few Collection implementations designed for
use in multithreaded contexts: {@link
java.util.concurrent.ConcurrentHashMap}, {@link
java.util.concurrent.CopyOnWriteArrayList}, and {@link
java.util.concurrent.CopyOnWriteArraySet}.
Most concurrent Collection implementations (including most Queues)
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.
Uncaught Exception Handlers
The java.lang.Thread class is modified to allow per-thread
installation of handlers for uncaught exceptions. Ths optionally
disassociates these handlers from ThreadGroups, which has proven to be
too inflexible in many multithreaded programs. (Note that the
combination of features in JSR166 make ThreadGroups even less likely
to be used in most programs. Perhaps they will eventually be
deprecated.)
Additionally, java.lang.ThreadLocal now supports a means to remove
a ThreadLocal, which is needed in some thread-pool and worker-thread
designs.
Doug Lea