How does ExecutorService + newFixedThreadPool "reuse" threads?

[tropico]

Hello,

I'm trying to fully understand how ExecutorService + newFixedThreadPool work. I understand the example on the Java API, and have made a few test applications of my own... but what I don't understand is how they are able to reuse threads.

In a test application of my own, I made an instance of newFixedThreadPool with a pool size of 3. I then ran about 10000 small Callables through it. Through the use of println()'s and observation through jconsole, I was able to confirm that the pool did in fact only create 3 threads to run through all the callables I was sending it.

From what I understand about threads, isn't a thread tied to a single Runnable? Therefore, how are the same 3 threads being reused to run 10000 callables?

Any insight is appreciated, this is really bugging me :)

[JosAH]

Read the example in the API documentation for the ExecutorService interface. A thread pool creates its own threads and supplies its own clever little Runnables for those threads. Those Runnables never end but synchronize on a queue (they wait()) until a Callable is present in that queue; they are notified when that happens and their Runnable runs the Callable from the queue and the entire scenario repeats itself again.

As you can see in the example the Runnable has an infite loop where it executes stuff from a queue. The pool manages the threads (it creates more of them if allowed etc.)

kind regards,

Jos

[tropico]

Yeah shortly after I posted started this Thread (pun intended), it kind of "ticked" in my head what actually must be going on. The threads in the pool aren't being created with the Callables being submitted into the pool for execution, but rather using a Runnable internally specified by the thread pool that wraps around an internal queue built up with the Callables.

Thanks for the reply!

[JosAH]

Yeah shortly after I posted started this Thread (pun intended), it kind of "ticked" in my head what actually must be going on. The threads in the pool aren't being created with the Callables being submitted into the pool for execution, but rather using a Runnable internally specified by the thread pool that wraps around an internal queue built up with the Callables.

Thanks for the reply!

Yep, that Doug Lea, the author of the entire 'concurrent' package is a genius. I used to be an old diehard for wait() and notify() and do everything myself until I started using this package.

kind regards,

Jos

[dharma]

Hi Friend,

I have one doubt.

say i have 100 runnables, but only 3 threads in pool.
my question is how these 3 threads are picking the 100 runnable one after the other.

see what i know is once a thread is created with one runnable, it will die once it is finished.
then how the thread is able to pick the next runnable.

is there any way to setRunnable to the existing thread,

Expecting your comments on the same.

Read the example in the API documentation for the ExecutorService interface. A thread pool creates its own threads and supplies its own clever little Runnables for those threads. Those Runnables never end but synchronize on a queue (they wait()) until a Callable is present in that queue; they are notified when that happens and their Runnable runs the Callable from the queue and the entire scenario repeats itself again.

As you can see in the example the Runnable has an infite loop where it executes stuff from a queue. The pool manages the threads (it creates more of them if allowed etc.)

kind regards,

Jos

[kjkrum]

Dharma: you just quoted Jos answering your question!

Jos: Doug Lea also wrote a really great book, Concurrent Programming in Java: Design Principles and Patterns. Best Java book I ever read.