[concurrency-interest] DefaultThreadFactory implementation questions

Tim Peierls tim at peierls.net
Wed Jan 14 11:50:41 EST 2009

Regarding (2), this doesn't seem like something that should be in the
standard library, since folks would disagree on the precise format of the
prefixed thread name and others would want custom *suffixes*. And it's very
easy to write your own ThreadFactory decorator that arranges for custom
thread name prefixing:

 public static ThreadFactory prefixedThreadName(final ThreadFactory
threadFactory, final String prefix) {
     return new ThreadFactory() {
         public Thread newThread(Runnable runnable) {
             Thread t = threadFactory.newThread(runnable);
             t.setName(prefix + t.getName()); // or with a hyphen, or
replacing "pool" with prefix, or ...
             return t;


 ThreadFactory myThreadFactory = prefixedThreadName(defaultThreadFactory(),

The explicit use of ThreadGroup in the DefaultThreadFactory constructor is
to make sure that if a SecurityManager exists then threads created by the
factory will be in that SecurityManager's thread group. This might only be
relevant to the PrivilegedThreadFactory subclass.


On Wed, Jan 14, 2009 at 10:52 AM, Roel Spilker <R.Spilker at topdesk.com>wrote:

>  L.S.,
> In the class j.u.c.Executors, there is a package private static class
> DefaultThreadFactory. This class synthesizes a name for all created threads.
> For debugging and monitoring purposes, I would like to be able to provide a
> custom namePrefix. This has lead me to two questions:
> 1) Is there a reason the ThreadGroup is determined in the constructor and
> the later used to create a new Thread? As far as I can see, Thread also has
> a constructor that takes a Runnable and a String name that would use similar
> code to determine the ThreadGroup.
> 2) Do other people also feel the need to provide a name? Or is there
> another way to provide more debugging and monitoring information? If so, is
> it appropriate to add some API to do so?
> I think the API changes could be small. The smallest change would be to add
> two static methods to Executors:
> public static ThreadFactory defaultThreadFactory(String namePrefix);
> public static ThreadFactory privilagedThreadFactory(String namePrefix);
> This would be enough, since the code in j.u.g that call defaultThreadFactory
> also have a counterpart that accepts a provided ThreadFactory.
> A more complete API would be to also add:
> public static ExecutorService newFixedThreadPool(int nThreads, String
> namePrefix);
> public static ExecutorService newSingleThreadExecutor(String namePrefix);
> public static ExecutorService newCachedThreadPool(String namePrefix);
> ... and probably the same for the ScheduledExecutorService factory methods.
> Also, ThreadPoolExecutor could get two extra constructors that accept a
> namePrefix.
> The changes in the code would, for as far as I can see, be very small.
> Roel Spilker
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20090114/0b97214e/attachment.html>

More information about the Concurrency-interest mailing list