Take the 2-minute tour ×

This question is a followup on this one.

Essentially what I am doing is declaring a ThreadPoolExecutor with just one thread. I am overriding the beforeExecute() method to put a sleep so that each of my tasks are executed with some delay among themselves. This is basically to give away the CPU to other threads since my thread is kind of thrashing.

So the expected behavior is:

For each new task in the ThreadPoolExecutor, it calls the before execute function before executing the task and hence it sleeps for say 20s before it executes the task.

However this is what I see:

For each new task submitted:

  1. It executes the task
  2. Calls the beforeExecute method
  3. sleeps for say 20s
  4. RE-EXECUTE the task!

The order of 1. & 2. is not the same all the time.

Here are my questions:

  1. It is appearing that a new thread comes in after/during sleeping and goes ahead and executes my task right away while the actual thread is sleeping.
    So does the ThreadPoolExecutor spawn a new thread as soon as an existing thread sleeps [thinking that the thread is terminated]?? I tried to put the keepAliveTime > sleeptime ..so that in case the above assertion is true .. it atleast waits for more than sleep time to spawn a new thread ...[hoping in the mean time the sleeping thread would be awake and the ThreadPoolExecutor would dump the idea of spawning a new thread
  2. Even if it does spawn a new thread and execute my task right away, why would the task be re-executed after the sleeping thread wakes up !! Shouldn't the task be taken out of task Queue before that ??
  3. Am I missing something here ? Any other way to debug this scenario ?

=> An alternative method I was thinking to do the desired task [and not solve the peoblem] was to wrap the runnable with one more runnable and sleep the outer runnable before calling the inner one.

share|improve this question

2 Answers 2

I think what you're looking for is a ScheduledExecutorService

From what I understand of your question, scheduleAtFixedRate(...) should do the deal:


Creates and executes a periodic action that becomes enabled first after the given initial delay, and subsequently with the given period; that is executions will commence after initialDelay then initialDelay+period, then initialDelay + 2 * period, and so on.

share|improve this answer
Thnx for pointing that..This is something close but not exactly what i want. Basically here the next task is scheduled based on time = 0. So the new task gets kicked in irrespective the time of execution of my prev task. [In multi-threading env there is no guarantee if this would be equally spaced] .............................. It would be nice to have a new task kicked off only after some delay after the prev one has finished .. However I might give this a shot later .. –  codeObserver Oct 7 '10 at 18:41
I notice there is a method scheduleWithFixedDelay which might suit me.. –  codeObserver Oct 7 '10 at 18:51
  1. No, that is not how it works. The ThreadPoolExecutor knows it has a worker thread, even if that worker is RUNNABLE, WAITING, BLOCKED, or any other state.
  2. The task is removed from the BlockingQueue long before the beforeExecute method is invoked.
  3. You can look at the code for the API yourself and determine what it is doing. Every Java JDK installation includes a "src.zip" file which contains the entire Java Library. If yu haven't already, you can attach this source in eclipse and then while debugging in eclipse diving into a library method will show you source instead of just the class file.
share|improve this answer

Your Answer


