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

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

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

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.

The garbage collector's own threads are daemon threads, and that's the cleanest example of the rule: GC exists to serve the running application, so it should never be the reason the JVM refuses to exit. The moment the last real (user) thread finishes, the GC thread is torn down along with everything else — nobody wants a process that can't shut down because garbage collection is 'still busy.' Contrast that with ExecutorService worker threads, which default to non-daemon unless you supply a custom ThreadFactory — that's exactly why a forgotten executor.shutdown() is one of the most common reasons a Java process hangs on exit instead of terminating: those threads are user threads by default, so the JVM waits for them.

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.'

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

• ✗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

• ✓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

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

• Thread.setDaemon
• JVM exit
• shutdown hook
• ExecutorService ThreadFactory