EasyπŸ‘€ 0-2 yearsπŸ‘€ 3-5 years 3 min read Updated Aug 24, 2026

What Is a Daemon Thread, and Why Does the JVM Exit With Them Still Running?

Asked inInfosysTCSCognizant
#daemon thread#setdaemon#jvm exit#background threads
Report issue

⚑ Short Answer

The JVM keeps running as long as any non-daemon (user) thread is alive, and exits the instant the last one finishes β€” regardless of whether daemon threads are still running. Daemon threads are simply terminated at that point, mid-instruction, with no finally blocks guaranteed to run. Set via thread.setDaemon(true), called before start(). They're meant for background housekeeping (cache eviction, metrics collection) that shouldn't itself keep the process alive β€” never put work that must complete, like flushing a buffer or releasing an external lock, on a daemon thread.

β˜•Coffee Chat Question

Concept Made Simple

β€œWhat is a daemon thread, and why does the JVM exit even while daemon threads are still running?”

🧠Mind Map Answer

Remember It Faster

Every thread is either a user thread or a daemon thread. The JVM stays alive as long as at least one user thread is running; the moment the last user thread finishes, the JVM exits immediately β€” and any daemon threads still executing are simply terminated, mid-instruction, with no finally block guaranteed to run and no cleanup performed.

User thread→JVM waits for these before exiting
Daemon thread→does NOT keep the JVM alive; killed abruptly on exit
Set via→thread.setDaemon(true) — must be called BEFORE start()
Typical use→background housekeeping, not work that must complete
java
Thread housekeeper = new Thread(() -> evictExpiredEntries());
housekeeper.setDaemon(true);   // must be set before start()
housekeeper.start();

// If this is the last other thread running, main() returning ends
// the JVM immediately - housekeeper is killed mid-eviction, no warning.

Key takeaway: the classic bug is making a thread daemon so it 'doesn't block shutdown,' then quietly relying on it to finish something that matters β€” flushing a write buffer, releasing an external lock, closing a file handle. Because daemon threads offer zero cleanup guarantee, that work may simply never happen. If completion matters, either use a user thread and shut it down explicitly (signal it, then join with a timeout), or accept that the work is genuinely disposable.

πŸ”₯What If?

Think Beyond the Expected

A background metrics-uploader is a daemon thread, and on shutdown the last few seconds of metrics are sometimes missing β€” why?

Because it's a daemon thread, the JVM doesn't wait for it β€” if the last user thread finishes first, the uploader is killed mid-upload with no chance to flush. Add a shutdown hook that explicitly signals the uploader to flush and join()s it with a timeout, or make it a non-daemon thread with a proper, explicit stop mechanism instead of relying on daemon semantics.

πŸ˜‚Real World

Scheduled background workers β€” cache evictors, metrics collectors, connection-pool reapers β€” are usually daemon threads by design, precisely because they shouldn't hold the process open on their own. The bug shows up when someone assumes 'daemon' just means 'runs quietly in the background' and forgets it also means 'can be killed at literally any instant with zero warning.'

πŸ—£οΈReal Talk from Guru

When I see setDaemon(true) in a review, my first question is always 'what happens if this thread is killed mid-line, right now?' If the honest answer involves lost data or an unreleased resource, it shouldn't be a daemon thread β€” or it needs an explicit shutdown-hook-driven stop, not an assumption that it'll get to finish.

🎯Interviewer's Expectation

Keywords they're listening for:

βœ“ JVM exits once the last non-daemon thread finishesβœ“ daemon threads are killed abruptly with no cleanup guaranteedβœ“ setDaemon(true) must be called before start()βœ“ never rely on a daemon thread to complete must-finish work

⚠️Common Mistakes

  • βœ—Calling setDaemon(true) after start() (throws IllegalThreadStateException)
  • βœ—Relying on a daemon thread to complete cleanup or flush work during shutdown
  • βœ—Assuming ExecutorService threads are daemon by default β€” they're user threads unless you supply a custom ThreadFactory

βœ…Best Practices

  • βœ“Use daemon threads only for genuinely disposable background work
  • βœ“For work that must complete, use a shutdown hook to explicitly signal and join with a timeout
  • βœ“Set daemon status before start(), never after

πŸ”Follow-up Questions

  • 1What happens if you call setDaemon(true) after the thread has already started?
  • 2Are the worker threads in a default ExecutorService pool daemon or user threads?
  • 3How do you cleanly stop a background daemon thread instead of relying on it being killed?
  • 4Why is the garbage collector's own thread a daemon thread?

🧩Related Technologies

Thread.setDaemonJVM exitshutdown hookExecutorService ThreadFactory

Continue Learning with AI

Take this question deeper with your favourite AI assistant. Pick a depth, copy the prompt, or open it directly β€” AI is your learning companion, not a shortcut.

Plain-language foundations

I'm preparing for a software engineering interview and want to understand this from scratch, as a beginner.

Topic: Fundamentals (Multithreading)
Interview question: "What is a daemon thread, and why does the JVM exit even while daemon threads are still running?"

Please:
1. Explain the core idea in simple, plain language, using an everyday analogy.
2. Define any technical terms you use.
3. Walk through one small, concrete example.
4. Finish with a single sentence I can easily remember.

Keep the tone friendly and assume I'm new to this topic.

Was this answer helpful?

Support our platform by exploring our recommended products.

As an Amazon affiliate, purchases through these links may earn us a small commission β€” at no extra cost to you. It helps keep Full Stack Interview Guru free.

Related Questions