[concurrency-interest] On-demand Construction of Threads in ThreadPoolExecutor

Joe Bowbeer joe.bowbeer at gmail.com
Tue Jan 17 10:57:03 EST 2012

In short, because that's the way it has always been done :-)  See the old
dl.util.concurrent classes for more history.

As a benefit, lazy construction enables implementations like
newCachedThreadPool(), which are on-demand thread pools.

Note that all of these j.u.c. Executors are created by various parameters
of the ThreadPoolExecutor constructor.  Executors, which hides
ThreadPoolExecutor behind factory methods was added fairly late in the
j.u.c. process.

If your question is about starting threads in a constructor, then I'd
answer that none of the EG members consider that proper design, and (as
FindBugs will point out) is particularly problematic for classes intended
to be subclassed.

There are many attributes of ThreadPoolExecutor that are meant to be
configurable before the first thread is started.  (If TPE were redesigned
from scratch, perhaps a Builder pattern would be employed now?)

The fundamental question remains as to whether TPE should be more on-demand
or less on-demand.  In my perspective, it started out entirely on-demand
but has been inching toward less to satisfy different users and uses.


On Tue, Jan 17, 2012 at 7:03 AM, Dr Heinz M. Kabutz wrote:

> **
> A quick historical question.  What was the thinking behind constructing
> the threads in the ThreadPoolExecutor lazily?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20120117/c682c0c7/attachment-0001.html>

More information about the Concurrency-interest mailing list