Taming Tiger: Concurrent Collections

What began as author Doug Lea's util.concurrent package has morphed into JSR-166 and into the Tiger release of the J2SE platform. What the new library provides is a set of utilities commonly needed in concurrent programs. If you are interested in optimizing multithreaded access to your collections, you've come to the right place. Share your thoughts on this article with the author, John Zukowski, and other readers in the accompanying discussion forum.

In the early days of Java programming, a professor from the State University of New York (SUNY) College at Oswego decided to create a simple library to help developers build applications that were better able to handle multithreaded situations. This isn't to say you couldn't get by with the existing libraries, but just like having a standard networking library, it was easier to do multithreading yourself with a debugged, trusted library. With the help of a related book from Addison-Wesley, over time this library became popular. Eventually, the author, Doug Lea, decided to pursue making it a standard part of the Java platform as JSR-166. What that library has morphed into is the java.util.concurrent package of the Tiger release. In this Taming Tiger tip, you'll explore the new Queue interface in the Collections Framework, the non-concurrent and concurrent implementations of that interface, a concurrent Map implementation, and special-purpose concurrent List and Set implementations for when read operations heavily exceed write operations.

Introducing the Queue interface

The java.util package offers a new base interface for collections: java.util.Queue. While you certainly can treat a java.util.List as a queue by adding and removing from opposite ends, what the new Queue interface offers is additional methods to support adding, removing, and inspecting the collection, as shown below:

public boolean offer(Object element)
public Object remove()
public Object poll()
public Object element()
public Object peek()

Basically, a queue is a first-in, first-out (FIFO) data structure. Some queues are restricted in size, so when you want to add a new item to a full queue, the additional item is rejected. That's where the new offer method comes into play. Instead of throwing an unchecked exception with a call to the add() method, you just get false returned by offer(). The remove() and poll() methods are both for removing the first element (head) of the queue. While remove() behaves like the Collection interface version, instead of throwing an exception when called with an empty collection, the new poll() method just returns null. The newer methods are thus more for when the exceptional condition is the norm. The last two methods, element() and peek(), are for querying the element at the head of the queue. Like the remove() method, element() throws an exception when the queue is empty, whereas peek() returns null.