Are regular Queues inappropriate to use when multithreading in Java?

I am trying to add asynchronous output to a my program.

Currently, I have an eventManager class that gets notified each frame of the position of any of the moveable objects currently present in the main loop (It's rendering a scene; some objects change from frame to frame, others are static and present in every frame). I am looking to record the state of each frame so I can add in the functionality to replay the scene.

This means that I need to store the changing information from frame to frame, and either hold it in memory or write it to disk for later retrieval and parsing.

I've done some timing experiments, and recording the state of each object to memory increased the time per frame by about 25% (not to mention the possibility of eventually hitting a memory limit). Directly writing each frame to disk takes (predictably) even longer, close to twice as long as not recording the fr开发者_开发百科ames at all.

Needless to say, I'd like to implement multithreading so that I won't lose frames per second in my main rendering loop because the process is constantly writing to disk.

I was wondering whether it was okay to use a regular queue for this task, or if I needed something more dedicated like the queues discussed in this question.

In my situation, there is only one producer (the main thread), and one consumer (the thread I want to asynchronously write to disk). The producer will never remove from the queue, and the consumer will never add to it - so do I need a specialized queue at all?

Is there an advantage to using a more specialized queue anyway?

Yes, a regular Queue is inappropriate. Since you have two threads you need to worry about boundary conditions like an empty queue, full queue (assuming you need to bound it for memory considerations), or anomalies like visibility.

A LinkedBlockingQueue is best suited for your application. The put and take methods use different locks so you will not have lock contention. The take method will automatically block the consumer writing to disk if it somehow magically caught up with the producer rendering frames.

It sounds like you don't need a special queue, but if you want the thread removing from the queue to wait until there's something to get, try the BlockingQueue. It's in the java.util.concurrent package, so it's threadsafe for sure. Here are some relevant quotes from that page:

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.

...

BlockingQueue implementations are designed to be used primarily for producer-consumer queues, but additionally support the Collection interface.

...

BlockingQueue implementations are thread-safe.

As long as you're already profiling your code, try dropping a BlockingQueue in there and see what happens!

Good luck!

I don't think it will matter much.

If you have 25% overhead serializing a state in memory, that will still be there with a queue. Disk will be even more expensive. The queue blocking mechanism will be cheap in comparison.

One thing to watch for is your queue growing out of control: disk is slow no matter what, if it can't consume queue events fast enough you're in trouble.