shutdown and awaitTermination which first call have any difference?
Master System Design with Codemia
Enhance your system design skills with over 120 practice problems, detailed solutions, and hands-on exercises.
Introduction
Yes, the call order matters. The normal sequence is shutdown() first and awaitTermination() second, because awaitTermination() only waits for an executor that is already in the process of terminating or has already terminated.
What shutdown() Does
shutdown() tells the ExecutorService to stop accepting new tasks while allowing already submitted tasks to finish.
After shutdown(), the executor is still running if tasks are in progress. It is simply moving toward termination.
What awaitTermination() Does
awaitTermination(timeout, unit) blocks the current thread until one of these things happens:
- the executor terminates
- the timeout expires
- the waiting thread is interrupted
It does not initiate shutdown by itself.
If you call awaitTermination() before shutdown(), the executor is usually still active and not even trying to terminate. In that case, the wait often lasts until the timeout expires and returns false.
The Correct Order
The common pattern is:
This is the practical sequence:
- stop accepting new tasks
- wait for current tasks to finish
- force interruption only if the graceful wait fails
What Happens If You Reverse The Calls
Suppose you do this:
That is usually pointless. awaitTermination() is waiting for a termination process that has not started yet. Unless some other thread already called shutdown() or shutdownNow(), the executor has no reason to terminate.
So yes, the order makes a real difference.
There is one narrow exception: if another part of the program already initiated shutdown, then awaitTermination() can be called by a different thread to wait for completion. But in the normal single-owner pattern, shutdown() should come first.
shutdown() Versus shutdownNow()
It is also important not to confuse shutdown() with shutdownNow().
- '
shutdown()is orderly and lets submitted tasks finish.' - '
shutdownNow()tries to interrupt running tasks and returns tasks that never started.'
A common lifecycle is graceful first, forceful second:
That sequence gives tasks a chance to complete cleanly while still preventing the application from hanging forever.
Why The Pattern Includes Interrupted Handling
If the waiting thread is interrupted while blocked in awaitTermination(), the method throws InterruptedException. Good code restores the interrupt flag after doing cleanup.
Failing to restore the interrupt flag can hide cancellation signals from higher-level code.
A Small Timing Example
Here is a simple program that shows the behavior clearly.
The first wait typically prints false because the executor is still active and has not been told to terminate. The second wait can print true because shutdown has begun and the task finishes within the timeout.
Common Pitfalls
- Calling
awaitTermination()beforeshutdown()and expecting it to initiate shutdown. - Using
shutdownNow()immediately when a graceful shutdown would be sufficient. - Ignoring
InterruptedExceptioninstead of restoring the interrupt flag. - Submitting more tasks after
shutdown()and being surprised by rejection. - Forgetting that
awaitTermination()can returnfalseafter timing out.
Summary
- The normal order is
shutdown()first, thenawaitTermination(). - '
awaitTermination()waits for termination; it does not start termination.' - Calling
awaitTermination()first usually just waits until timeout. - A common pattern is graceful shutdown followed by
shutdownNow()only if needed. - Handle interruption properly by restoring the thread's interrupt status.

