Take the 2-minute tour ×

Using Java and App Server I deploy application that has a thread executer.

During un-deploy I request the executer to shutdown. This successfully cancels all the tasks. However via VisualVM I can still see a thread that represents the executer itself and it is in the wait sate. I don't keep any references to the executer as the whole application get undeployed. So if i repeat the deployment-undeployment cycle multiple times I can see how the threads number grows.

How do I get rid of them?


code example

here is the code:

public void startScheduler()
    if (scheduledExecutor == null)
        scheduledExecutor = Executors.newSingleThreadScheduledExecutor(new NamedThreadFactory("My ScheduledExecutor"));
        processFuture = scheduledExecutor.scheduleAtFixedRate(new Runnable()
                public void run()
            }, 0, 84600, TimeUnit.SECONDS);

public void stopScheduler()

    if (processFuture != null)
        processFuture = null;

    if (scheduledExecutor != null)
            scheduledExecutor.awaitTermination(10, TimeUnit.SECONDS);
        catch (InterruptedException ignored)
            scheduledExecutor = null;

share|improve this question
what is the specific Executor class that you use? And what is the exact shutdown method that you call? –  richs Jan 21 '11 at 17:48
Executors.newSingleThreadScheduledExecutor and shutdownNow() –  user567068 Jan 21 '11 at 18:16
this code is correct. if the executor is shutdown, then the problem lies elsewhere. –  jtahlborn Jan 21 '11 at 21:34

2 Answers 2

up vote 2 down vote accepted

Could you please elaborate what you mean with "a thread that represents the executer itself". What is it's name/id/threadgroup? I don't think executor service creates such a thread.

Executors create new threads (using the configurable ThreadFactory). A Thread automatically inherits some properties of its parent, that is the Thread.currentThread(). The most problematic part of this behavior in a web application scenario with deploy/undeploy cycles however is the Thread's ContextClassLoader, which is inherited from the parent's thread. If your ContextClassLoader holds on to classes from within your web application archive, then the spawned Executors Thread will also have a reference to this ClassLoader. If the code which is executed by the Executor has e.g. ThreadLocals with classes from the WebappClassLoader, you may experience a ClassLoader leak problem.

share|improve this answer
updated the code. startScheduler() called when I deploy, stopScheduler() when un-deploy. In the VisualVM i see "My ScheduledExecutor" thread. I think you must be right and it is leakage of some sort because we use home made app loader that take some of responsibilities of the container. (such as loading classes). Does the shutdown code looks right? Or is there anything else that can be done like maybe de-registering the reference to CalssLoader somehow... Thanks! –  user567068 Jan 21 '11 at 20:26
Executor code looks good, I verified with test case. To find your leak, perform many redeployments and take a heap dump. Then, look for the paths to the GC root from all the Thread("My ScheduledExecutor") objects. I bet you will find the WebappClassLoaders. Use Eclipse MAT and "Group By ClassLoader". –  mhaller Jan 21 '11 at 22:07

The Executor needs to be stopped explicitly, using the method shutdown, otherwise it will hang around like you have found out. You can see from the javadoc for Executors.newSingleThreadExecutor that it includes a worker thread.

The javadoc for shutdownNow says:

There are no guarantees beyond best-effort attempts to stop processing actively executing tasks. For example, typical implementations will cancel via Thread.interrupt(), so if any tasks mask or fail to respond to interrupts, they may never terminate.

If the task being executed doesn't respond to interrupts (swallows InterruptedExceptions without ever exiting), then that would cause your executor to never get shutdown. Any non-daemon threads that don't get shutdown explicitly will hang around and keep the JVM from exiting. That can be a fun one to debug.

share|improve this answer
I do use shutdownNow and even wait for it a little bit... –  user567068 Jan 21 '11 at 20:27
By the time I un-deploy the application the thread is in waiting state so there should be now any "swallowing" of InterruptedExceptions, that would prevent it from properly shutting down. –  user567068 Jan 21 '11 at 21:02

Your Answer


