views:

44

answers:

2

Hi,

I have a question that is related to possible overhead of ExecutorServices in Java.

The present implementation has ExecutorService A with a capacity of 5 threads.

  • It runs threads of type A.
  • type A threads do some database reading and writing.

Now, a thread of type B will run after some threads of type A has finished.

  • The number of type B threads that will run is different from time to time.
  • type B threads do some filesystem IO (not database).

So should I

  • add a new ExecutorService to handle type B threads
  • or should I increase the capacity of ExecutorService A and run type B threads with that one as well?

I'm thinking that there might be some extra overhead for Java to have two ExecutorServices, but on the other hand the total number of threads will increase either way. Does it matter at all?

+1  A: 

If you're talking about 5 threads, and you're not exhausting your thread pool capacity, I would tend to say that the overhead woulld be insignificant either way, and you should just go whatever you deem to be the simplest route.

Dave Markle
that reasoning makes sense. I will do another ExecutorService because it feels like cleaner code in general.
Lars Andren
+3  A: 

I will recommend two ExecutorServices, then you can take advantage of the different ExecutorServices provided by the java.util.concurrent package.

It makes the code easier and the overhead is ignorable.

  • ExecutorService a with a fixed thread pool set to five threads.
  • ExecutorService b with a cached thread pool.
Espen
I'll try out the cached threadpool, thanks!
Lars Andren