Java concurrency - Better to have list of threads with lock or one thread with list of requests?

Question

I'm just starting to dip into concurrency so bear with me if I ask some obvious/dumb things. I'm trying to take the first steps to revamp a model I have to take advantage of Java currency. Without getting into specifics, I have a portion of the model that loads some file and then when given requests it returns some corresponding data on the file. My challenge is to make this run on it's own thread now, so that while it still only processes one request at a time, it can queue up requests made other parts of the code running on their own threads.

After trying to teach myself concurrency through the great tutorials at jenkov.com I used what I learned and basically created something a lot like a BlockingQueue where there's an object that acts as a lock where requests go in as threads that queue up, and when the current thread is finished processing it unlocks for the next in line. So threads are continually being created, put into wait, started, then eventually destroyed, as each request is a new thread.

What I thought of now though, is instead doing it more like what I originally pictured, where there is only one thread that waits for instructions, then processes those instructions. So instead of requests coming in as threads, there's some singular thread that waits until it has a request, processes that, processes any other requests that have queued up, and if there's no more, waits again. The (supposed) advantage being that requests come in as variables/instructors and threads aren't continually being created/destroyed.

So the question being is there an advantage to rewriting it to be more like that? I know creating/destroying threads probably doesn't create a whole lot of overhead (as long as I'm using the wait/notify functions instead of say a busy wait) but this is a type of model that has to run literally millions of iterations sometimes and even marginal gains would multiply in situations like that.

Answer 1

Don't create a bunch of Threads; use an ExecutorService, initialize it with a SingleThreadExecutor, and give your users (client classes) an API they can call to submit jobs to the Executor. This gives you a lot of future flexibility by just replacing (or specializing) your executor.

Here's a second vote for the comment: Go read "Java Concurrency In Practice" by Brian Goetz - I cannot recommend this highly enough.

While you are waiting for your book to arrive:

http://docs.oracle.com/javase/tutorial/essential/concurrency/executors.html http://tutorials.jenkov.com/java-util-concurrent/executorservice.html