Daemon Threads in Java — Background Workers That Don't Block Shutdown
Fast recall
Quick revision
Core answer
Understanding of JVM shutdown behavior and the role of daemon threads in background processing
Calling setDaemon(true) after start() — this throws IllegalThreadStateException. Also assuming daemon threads will complete their finally blocks on JVM exit.
Mention that the GC is a daemon thread, that child threads inherit daemon status from their parent, and that daemon threads should never hold resources that require cleanup (file handles, database connections) because they can be killed mid-operation.
Interview-ready guide
Interview answer
The JVM exits when all non-daemon threads finish — daemon threads are killed immediately without running finally blocks or cleanup.
Appropriate uses:
- Background housekeeping: cache eviction, heartbeat pings, metrics collection
- Tasks where incomplete execution is harmless to data integrity
Danger:
- A daemon thread killed mid-database-write leaves the transaction inconsistent — no exception, no log, no indication of failure
setDaemon(true)must be called beforestart()— after throwsIllegalThreadStateException- Threads inherit daemon status from their creator
For tasks that must complete:
- User threads with
ExecutorService.shutdown()andawaitTermination()for graceful draining Runtime.addShutdownHook()for JVM shutdown coordination
I recommend daemon threads only for pure monitoring and housekeeping. For anything involving data persistence or state, use user threads with explicit shutdown coordination.
Daemon Threads in Java — Background Workers That Don't Block Shutdown
Direct Answer
Daemon threads are background threads that do not prevent JVM shutdown. When all user (non-daemon) threads finish, the JVM exits immediately — killing all remaining daemon threads without running their finally blocks. The garbage collector is the most well-known daemon thread.
Deep Dive & Architecture
A thread is an independent path of execution within a JVM process, sharing heap memory but having its own stack and program counter.
Java threads are 1:1 mapped to OS native threads on all mainstream JVMs (HotSpot, OpenJ9) — each platform thread costs ~0.5–1 MB of stack memory and is scheduled by the OS.
You create them by implementing Runnable (preferred — preserves your single inheritance slot and works with ExecutorService) or extending Thread (legacy). Multithreading pays off for three workloads: CPU-bound parallelism (dividing work across cores), I/O concurrency (overlapping waits), and responsiveness (keeping UI/event loops free). As of Java 21, virtual threads (Project Loom) give you millions of cheap, JVM-scheduled threads ideal for I/O-bound servers.
Thinking threads have separate memory — they share heap. Calling thread.run() instead of thread.start() and wondering why everything runs on the main thread
Common Mistakes & Pitfalls
Calling setDaemon(true) after start() — this throws IllegalThreadStateException. Also assuming daemon threads will complete their finally blocks on JVM exit.
Check your understanding
Answer these without looking back at the article.
- What are the different states in a Java thread's lifecycle?
- How does thread interruption work in Java? Explain `interrupt()`, `isInterrupted()`, and `interrupted()`, and the correct way to respond to interrupts.
- What is a thread in Java? Explain the `Thread` class vs `Runnable`, how threads map to OS threads, and when multithreading pays off.
Related interview prep categories
2Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.