I have 2 threads � a producer and a consumer. The producer is expected to produce faster than the consumer can consume � although it is not always the case.
In order to make sure that the consumer consumes the messages in order (FIFO), I plan to use a queue. I am happy that Java 1.5 has introduced a bunch of Queue classes and interfaces into its group of Collection classes and interfaces.
However, there are so many queue implementation classes � which one should I use ?
Should I use a blocking queue ? Is there a way to prevent the consumer from keep on checking on the contents of the queue ? Will the �blocking� feature address this ? How do I make sure that my queue is accessed in a thread safe way ? Or is it already thread-safe by default ?
> Is there a way to prevent the consumer from keep on checking on the contents of the queue ? Will the �blocking� feature address this ?
Yes. Quote from the API documentation: A Queue that additionally supports operations that wait for the queue to become non-empty when retrieving an element, and wait for space to become available in the queue when storing an element.
> How do I make sure that my queue is accessed in a thread safe way ? Or is it already thread-safe by default ?
Again, from the API documentation: BlockingQueue implementations are thread-safe. All queuing methods achieve their effects atomically using internal locks or other forms of concurrency control. However, the bulk Collection operations addAll, containsAll, retainAll and removeAll are not necessarily performed atomically unless specified otherwise in an implementation. So it is possible, for example, for addAll(c) to fail (throwing an exception) after adding only some of the elements in c.
And another quote: BlockingQueue implementations are designed to be used primarily for producer-consumer queues, ...
Which implementation of interface BlockingQueue: Have a look at ArrayBlockingQueue or LinkedBlockingQueue. The first one is bounded (i.e. has a fixed maximum capacity), the second one is optionally bounded. [ October 11, 2005: Message edited by: Jesper de Jong ]