2

All available ScheduledThreadPoolExecutor constructors require a corePoolsize argument. But I am not sure how many do I actually need?

I plan on using it in a class where one instance of it will only use 1 scheduled task. So it is pointless to set the pool size to anything else but 1? Or should I create a static ScheduledThreadPoolExecutor instance to be shared between all instances of my own class?

Justas S
  • 584
  • 4
  • 12
  • 34

2 Answers2

1

If you only plan to schedule one task per instance of your class you do not need to use more than 1 thread in your pool. Even if you use scheduleAtFixedRate, if you only schedule one task it will never run concurrently even if it runs longer than its period. Hence, if you only schedule one task, you only need one thread.

Creating a shared instance of the executor might be a good idea if it makes sense in your program. You will get some better performance when not having to create the executors and threads for each instance. However, you must take care to set corePoolSize to at least the maximum number of expected concurrent tasks. Otherwise tasks might be delayed.

K Erlandsson
  • 13,408
  • 6
  • 51
  • 67
-2

It is best to use number of cores available on the machine your program runs as value for this parameter.

Example:

int cores = Runtime.getRuntime().availableProcessors();
kosa
  • 65,990
  • 13
  • 130
  • 167
  • Care to explain this guideline? I don't think it is a good guideline, expecially for the OP's case. – K Erlandsson Jun 22 '15 at 20:49
  • Based on my understanding OP looking for pool size while creating ScheduledThreadPoolExecutor. At any given point a machine/CPU can process only N number of threads, where N is number of cores available. For example if machine is Quad core, that means only 4 threads can be run in parallel, so it doesn't make sense to create a pool with larger size. Pool with number of cores + 2 (to help with context switching) might be good enough to get good performance. – kosa Jun 22 '15 at 20:56
  • 1
    In many cases it *does* make a lot of sense to create more threads than number of CPUs. The most common case is when you want to parallelize IO. You can have a lot of threads waiting for IO on a single core... If you run 100% CPU bound tasks I tend to agree with your line of thought, but that is quite an assumption to make. – K Erlandsson Jun 22 '15 at 20:59
  • What is the use if they are waiting? Isn't it waste of resources? and overhead in maintaining the context switching? I agree with having more (may be double), but not something like 20 when you have quad core.http://stackoverflow.com/questions/12951112/what-is-optimum-thread-pool-size-for-simple-program-running-cpu-based-tasks-in-j – kosa Jun 22 '15 at 21:01
  • @Nambari, The original purpose of threading was _not_ to make parallel programming possible: Threads were in wide-spread use long before multi-processor computers escaped from the lab. The original purpose of threads was to facilitate event-driven programs, and especially; time-triggered, real-time, embedded software. Instead of having one massive event loop that polled N different event sources, a multi-threaded program would have N different threads, each one of which waited for one kind of event--a much cleaner design. – Solomon Slow Jun 22 '15 at 21:38
  • @jameslarge: I am not denying the fact that threads are not just for parallel processing, I am talking about what count would be efficient. What is the use of pools if we can have N threads? – kosa Jun 23 '15 at 01:59
  • In my opinion these concepts evolved as programming languages evolved. – kosa Jun 23 '15 at 02:06
  • We could from now 'till November about what is "efficient" and when/why/whether/how/to whom is it important, but I have work to do. – Solomon Slow Jun 23 '15 at 12:57
  • @jameslarge: Well, everyone has work to do. If we can't look for efficiency in our code (we will have lot more to do), not sure what else you can look for. Just create 1000 threads because we have 1000 tasks? any way good luck to OP and everyone – kosa Jun 23 '15 at 14:00