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.
{@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.
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.
Additionally, java.lang.ThreadLocal now supports a means to remove a ThreadLocal, which is needed in some thread-pool and worker-thread designs.