On 2/13/13 3:25 PM, bob smith wrote:
I'm looking at this method in the Executors class:
public static ExecutorService newFixedThreadPool(int nThreads)
Creates a thread pool that reuses a fixed set of threads operating off a shared unbounded queue. If any thread terminates due to a failure during execution prior to shutdown, a new one will take its place if needed to execute subsequent tasks.
How much is too much in terms of me telling it how many threads I want? Is it okay to ask for 100 threads? What about 256?
As you have read in the rest of this thread, the answer is "it depends".
You can ask for many many threads (thousands). The real question is "how
many threads *should* I for task X?"
Which, of course, depends on the task.
A rule of thumb I use for CPU bound tasks (ray-tracing for example) is
N+1 where N is the number of CPU cores. The +1 is to have an extra
thread available to pick up slack if any one of the other threads ends
up blocked by something, such as synchronization, paging, etc...
For IO bound tasks, I tend not to use a fixed pool, but use a pool that
automatically adjusts its size to meet demand. You also need to be aware
of the effect that you might have down-stream. If your IO is all local
disk access on a spinning media (eg, non SDD hard disk), too many
threads *might* cause undue head shifting, slowing down the overall
For Memory (or other allocated resource) Intensive tasks, you want to
have an upper bound of threads that prevents any thread from failing due
to running out of resources.
For mixed tasks (some tasks which block on IO for a portion of time,
then process the result in a CPU intensive manor), you'll have to make a
guess and then fine-tune to each machine. Provide sensible defaults but
let the end-user configure it.
As a matter of fact, many applications have configuration options for
thread-pool size. Let the end-user (or administrator at least)
decide/figure out what is best for their particular use-cases,
workflows, and systems.