Question

i have a ScheduledExecutorService that gets tasks for periodically execution:

scheduler = Executors.newScheduledThreadPool( what size? );

public addTask(ScheduledFuture<?> myTask, delay, interval) {
    myTask = scheduler.scheduleAtFixedRate(new Runnable() {
          // doing work here
     },
          delay,
          interval,
          TimeUnit.MILLISECONDS );
}

The number of tasks the scheduler gets depends solely on the user of my program. Normaly it should be a good idea, afaik, to make the ThreadPoolSize #number_of_Cpu_Threads, so that each CPU or CPU Thread executes one Task at a time, cause this should give the fastest throughput. But what should i do if the Tasks involve I/O (as they do in my program)? The tasks in my program are grabbing data from a server on the internet and saving them in a db. So that means most of the time they are waiting for the data to come in (aka idle). So what would be the best solution for this problem?

Answer 1

It really depends on the exact context:

• How many tasks will be added? (You’ve said it’s up to the user, but do you have any idea? Do you know this before you need to create the pool?)
• How long does each of them take?
• Will they be doing any intensive work?
• If they’re all saving to the same database, is there any concurrency issue there? (Perhaps you want to have several threads fetching from different servers and putting items in a queue, but only one thread actually storing data in the database?)
• So long as you don’t get “behind”, how important is the performance anyway?

Ultimately I strongly suspect you’ll need to benchmark this yourself – it’s impossible to give general guidance without more information, and even with specific numbers it would be mostly guesswork. Hard data is much more useful 🙂

Note that the argument to newScheduledThreadPool only specifies the number of core threads to keep in the thread pool if threads are idle – so it’s going to be doing a certain amount of balancing itself.