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. - -
{@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. +
JSR166 introduces package java.util.concurrent containing 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. Descriptions of the main +components may be found in the associated package documentation. + +
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. Here +are brief descriptions.
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 {@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. - -
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. +non-thread-safe {@link java.util.PriorityQueue} is added.