Threads & Processes - Learning Module

Loading content...

0/246

Thread Lifecycle

The Journey of a Thread

Every thread has a story—a journey from non-existence, through creation, execution, waiting, and ultimately termination. Understanding this lifecycle isn't just academic knowledge; it's operational necessity.

Why Thread Lifecycle Matters:

Resource Management — Threads consume system resources (memory, kernel structures). Understanding when threads are created and destroyed helps you manage these resources.
Debugging — When applications hang, understanding thread states helps diagnose whether threads are deadlocked, starved, or simply waiting.
Performance — Thread state transitions have costs. Knowing when transitions occur helps you minimize overhead.
Correctness — Many bugs arise from incorrect assumptions about thread state. A thread might not be running when you think it is.

What You Will Master

By the end of this page, you will understand the complete lifecycle of a thread—every state it can occupy, every transition it can make, and the triggers that cause each transition. You'll be able to reason about thread behavior in complex concurrent systems and diagnose lifecycle-related issues.

Thread States: The Complete Picture

A thread moves through a finite set of states during its lifetime. While different operating systems and languages may name these states differently, the underlying model is consistent across platforms.

Converting Mermaid diagram...

Complete Thread State Descriptions
State	Description	CPU Usage	Typical Duration
NEW	Thread object exists but start() not called. No OS thread allocated yet.	None	Application dependent
RUNNABLE	Thread is eligible to run. May be running or waiting for CPU in ready queue.	Ready for CPU	Depends on scheduling
RUNNING	Thread is actively executing instructions on a CPU core.	Active	Time slice (~1-10ms)
BLOCKED	Thread is waiting to acquire a monitor lock held by another thread.	None	Until lock released
WAITING	Thread waits indefinitely for another thread to perform an action.	None	Indefinite
TIMED_WAITING	Thread waits for a specified time period or until notified.	None	Until timeout/notify
TERMINATED	Thread has completed execution. Cannot be restarted.	None	N/A

RUNNABLE vs RUNNING

Many thread APIs (like Java's Thread.State) combine RUNNABLE and RUNNING into a single RUNNABLE state because the distinction is managed by the OS scheduler, not the language runtime. A RUNNABLE thread is either currently running or ready to run—the application cannot directly control which.

Thread Creation: The NEW State

A thread begins its lifecycle in the NEW state. At this point, the thread object exists in your program's memory, but the operating system has not yet allocated the resources needed for execution.

What Happens During Thread Creation:

Memory Allocation — Space is allocated for the thread object (in your language's heap)
State Initialization — Thread state is set to NEW, internal structures initialized
Configuration — Thread name, priority, daemon status can be set
Stack Size Planning — Stack size may be specified (or default used)

At this point, no OS-level thread exists. The thread cannot run. The NEW state is a preparation phase.

Java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
import java.lang.Thread.State;
 
public class ThreadCreationDemo {
    public static void main(String[] args) {
        // Method 1: Extend Thread class
        Thread thread1 = new Thread() {
            @Override
            public void run() {
                System.out.println("Thread 1 running");
            }
        };
        
        // Method 2: Implement Runnable interface (preferred)
        Runnable task = () -> {
            System.out.println("Thread 2 running");
        };
        Thread thread2 = new Thread(task, "WorkerThread");
        
        // Thread is in NEW state - OS thread not created yet
        System.out.println("Thread 1 state: " + thread1.getState()); // NEW
        System.out.println("Thread 2 state: " + thread2.getState()); // NEW
        
        // Configure before starting
        thread2.setPriority(Thread.MAX_PRIORITY);
        thread2.setDaemon(false);
        
        // Transition to RUNNABLE - this creates OS thread
        thread1.start();
        thread2.start();
        
        System.out.println("Thread 1 state: " + thread1.getState()); // RUNNABLE
        System.out.println("Thread 2 state: " + thread2.getState()); // RUNNABLE
    }
}

Common Pitfall: Calling run() Instead of start()

A frequent beginner mistake is calling thread.run() instead of thread.start(). The run() method executes the thread's code in the CURRENT thread—no new thread is created. Only start() triggers the NEW → RUNNABLE transition and creates an actual OS thread.

Thread Execution: RUNNABLE and RUNNING

When start() is called, the thread transitions from NEW to RUNNABLE. The operating system allocates the actual thread resources—stack memory, kernel data structures, thread ID—and places the thread in the scheduler's ready queue.

The RUNNABLE → RUNNING → RUNNABLE Cycle:

A RUNNABLE thread is not necessarily running at any given moment. The OS scheduler manages which threads actually execute. The cycle works as follows:

RUNNABLE threads wait in the ready queue — They're eligible to run but waiting for CPU availability
Scheduler selects a thread — Based on priority, fairness, processor affinity, and scheduling policy
Context switch occurs — The selected thread's state is loaded into CPU registers
Thread enters RUNNING state — Instructions are actively executed
Time slice expires or thread yields — Thread returns to RUNNABLE, another is selected

scheduling-cycle.txt
┌─────────────────────────────────────────────────────────────────────┐
│                         SCHEDULER OVERVIEW                           │
└─────────────────────────────────────────────────────────────────────┘
 
                    ┌─────────────────────────────┐
                    │       READY QUEUE           │
                    │  ┌─────┬─────┬─────┬─────┐  │
                    │  │ T1  │ T3  │ T5  │ T8  │  │  RUNNABLE threads
                    │  │     │     │     │     │  │  waiting for CPU
                    │  └─────┴─────┴─────┴─────┘  │
                    └──────────────┬──────────────┘
                                   │
                                   ▼ Scheduler dispatch
                    ┌─────────────────────────────┐
                    │         CPU CORE            │
                    │                             │
                    │   ┌─────────────────────┐   │
                    │   │     Thread T3       │   │  RUNNING
                    │   │   (executing code)  │   │  (active execution)
                    │   └─────────────────────┘   │
                    │                             │
                    └──────────────┬──────────────┘
                                   │
          ┌────────────────────────┼────────────────────────┐
          │                        │                        │
          ▼                        ▼                        ▼
   ┌──────────────┐        ┌──────────────┐        ┌──────────────┐
   │   RUNNABLE   │        │   BLOCKED/   │        │  TERMINATED  │
   │ (back to     │        │   WAITING    │        │   (exit)     │
   │  ready queue)│        │ (removed from│        │              │
   │              │        │  scheduling) │        │              │
   └──────────────┘        └──────────────┘        └──────────────┘
   
   Time slice          I/O, lock, wait()        run() returns
   expired, yield()                              or exception
 
─────────────────────────────────────────────────────────────────────
SCHEDULING TRIGGERS:
 
  → Time Quantum Expiry: Thread runs for its allocated time slice
                         (typically 1-10ms), then preempted
  
  → Voluntary Yield:     Thread calls yield() or sleep() to
                         give up remaining time slice
  
  → Priority Preemption: Higher-priority thread becomes runnable,
                         may preempt lower-priority running thread
  
  → Blocking Operation:  Thread enters BLOCKED/WAITING state,
                         immediately context-switches to next thread

Key Scheduling Concepts

•Time Slice (Quantum) — Each thread gets a fixed time slice (typically 1-10ms). When it expires, the thread is preempted and returned to the ready queue, even if it's not finished.
•Preemptive Scheduling — The OS can interrupt a running thread at any tim to give CPU to another thread. The interrupted thread doesn't choose when to stop.
•Context Switch — Saving the current thread's registers/state, loading the next thread's state. Costs ~1-10 μs but disrupts CPU caches.
•Yielding — A thread can voluntarily give up its remaining time slice via yield(). Useful for cooperative threading or reducing latency for other threads.
•CPU Affinity — Threads can be bound to specific CPU cores to improve cache locality and reduce cross-core migration costs.

The Illusion of Parallelism

On a single-core CPU, threads don't actually run in parallel—they rapidly switch, creating the illusion of simultaneous execution. Even on multi-core systems, if you have more runnable threads than cores, not all threads run at once. The scheduler time-slices among them to create apparent concurrency.

Blocked, Waiting, and Timed Waiting States

Threads don't spend their entire lifecycle executing. Much of the time, threads are waiting—for locks, for I/O, for other threads, or for time to pass. Understanding these waiting states is crucial for diagnosing performance issues and deadlocks.

Thread Waiting States Comparison
State	Entered By	Exited By	Key Characteristic
BLOCKED	Attempting to enter synchronized block/method when lock is held by another thread	Lock becomes available and this thread acquires it	Waiting for monitor lock only; cannot be interrupted from blocking on lock
WAITING	Object.wait(), Thread.join(), LockSupport.park()	Object.notify(), notifyAll(), thread completes (join), unpark()	Indefinite wait; requires explicit wake-up signal
TIMED_WAITING	Thread.sleep(ms), Object.wait(ms), Thread.join(ms), LockSupport.parkNanos()	Timeout expires OR notify/unpark/join-thread-completes	Has a deadline; will eventually return to RUNNABLE

waiting-states-demo.ts
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
/**
 * Demonstrating different ways threads enter waiting states
 */
import { Worker, isMainThread, parentPort, workerData } from 'worker_threads';
import { setTimeout } from 'timers/promises';
 
// ============================================
// TIMED_WAITING: Sleep for a specified duration
// ============================================
async function timedWaitingExample(): Promise<void> {
    console.log('[TIMED_WAITING] Starting sleep...');
    
    // Thread enters TIMED_WAITING state
    // Will automatically return to RUNNABLE after 2000ms
    await setTimeout(2000);
    
    console.log('[TIMED_WAITING] Woke up after 2 seconds');
}
 
// ============================================
// WAITING: Wait for an event (simulated with Promise)
// ============================================
async function waitingExample(signal: AbortSignal): Promise<void> {
    console.log('[WAITING] Waiting for signal...');
    
    return new Promise((resolve, reject) => {
        // Thread conceptually WAITING indefinitely
        // Will only proceed when abort signal fires
        signal.addEventListener('abort', () => {
            console.log('[WAITING] Received signal, resuming');
            resolve();
        });
    });
}
 
// ============================================
// BLOCKED: Waiting for exclusive resource (mutex simulation)
// ============================================
class MutualExclusionExample {
    private locked = false;
    private queue: Array<() => void> = [];
    
    async acquire(): Promise<void> {
        if (this.locked) {
            // Thread enters BLOCKED state conceptually
            // Waiting for the lock to be released
            console.log('[BLOCKED] Lock is held, waiting...');
            
            await new Promise<void>((resolve) => {
                this.queue.push(resolve);
            });
            
            console.log('[BLOCKED] Lock acquired after waiting');
        }
        
        this.locked = true;
        console.log('[BLOCKED] Lock acquired immediately');
    }
    
    release(): void {
        if (this.queue.length > 0) {
            // Wake up next waiting thread
            const next = this.queue.shift()!;
            next(); // BLOCKED → RUNNABLE transition
        } else {
            this.locked = false;
        }
        console.log('[BLOCKED] Lock released');
    }
}
 
// ============================================
// Example: Thread join (waiting for another thread)
// ============================================
if (isMainThread) {
    async function joinExample(): Promise<void> {
        console.log('[JOIN] Main thread creating worker...');
        
        const worker = new Worker(`
            const { parentPort } = require('worker_threads');
            console.log('[JOIN] Worker thread starting work...');
            
            // Simulate work
            let sum = 0;
            for (let i = 0; i < 1e8; i++) {
                sum += i;
            }
            
            console.log('[JOIN] Worker thread completed');
            parentPort.postMessage({ result: sum });
        `, { eval: true });
        
        // Main thread enters WAITING state
        // Will resume when worker thread completes
        await new Promise<void>((resolve) => {
            worker.on('message', (msg) => {
                console.log('[JOIN] Worker result:', msg.result);
                resolve();
            });
        });
        
        console.log('[JOIN] Main thread resumed after worker completed');
    }
}
 
// ============================================
// Visualizing state transitions during execution
// ============================================
/*
Timeline of thread states:
 
Time │ Thread Action                    │ State Transition
─────┼──────────────────────────────────┼──────────────────────
t0   │ Thread created                   │ NEW
t1   │ thread.start() called            │ NEW → RUNNABLE
t2   │ Scheduler picks thread           │ RUNNABLE → RUNNING
t3   │ Thread calls sleep(1000)         │ RUNNING → TIMED_WAITING
t4   │ 1000ms elapsed                   │ TIMED_WAITING → RUNNABLE
t5   │ Scheduler picks thread           │ RUNNABLE → RUNNING
t6   │ Thread tries to enter sync block │ RUNNING → BLOCKED
                                         │ (if lock held by other)
t7   │ Lock released by other thread    │ BLOCKED → RUNNABLE
t8   │ Thread calls wait()              │ RUNNING → WAITING
t9   │ notify() called by other thread  │ WAITING → RUNNABLE
t10  │ run() method returns             │ RUNNING → TERMINATED
*/

BLOCKED vs WAITING: The Critical Difference

BLOCKED threads are waiting to acquire a lock—they will automatically proceed once the lock is available. WAITING threads are waiting for an explicit signal—notify(), interrupt(), or similar. If no signal ever comes, WAITING threads wait forever. This distinction matters for debugging: BLOCKED threads indicate contention; WAITING threads may indicate missing notifications (potential deadlock).

Thread Termination: Ending the Lifecycle

A thread reaches the TERMINATED state when its execution completes. This can happen in several ways:

Normal Completion — The run() method returns normally
Uncaught Exception — An exception propagates out of run()
External Termination — The thread is stopped (deprecated/dangerous) or the process exits

Once terminated, a thread cannot be restarted. Calling start() on a terminated thread throws an exception.

Proper Termination Patterns

•Return from run() — Let the thread complete its work and return naturally
•Check interruption flag — Periodically check Thread.interrupted() and exit gracefully
•Use volatile boolean flag — Set a 'shouldStop' flag that the thread checks
•Executor shutdown — Use ExecutorService.shutdown() which handles thread lifecycle
•Join with timeout — Wait for thread completion with a timeout to avoid indefinite blocking

Dangerous Termination Anti-Patterns

•Thread.stop() — Deprecated; releases locks without cleanup, corrupts data invariants
•Thread.destroy() — Never implemented; would cause deadlocks
•System.exit() — Kills all threads abruptly; no cleanup opportunity
•Ignoring InterruptedException — Swallowing the exception loses the cancellation signal
•Killing from outside — External kill signals may leave resources unreleased

graceful-termination.ts
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
import { Worker, isMainThread, parentPort } from 'worker_threads';
 
/**
 * Pattern: Cooperative Cancellation
 * 
 * Threads should check for cancellation requests and clean up gracefully,
 * rather than being forcefully terminated.
 */
 
// ============================================
// Pattern 1: Using AbortController/AbortSignal
// ============================================
class CancellableTask {
    private abortController: AbortController;
    
    constructor() {
        this.abortController = new AbortController();
    }
    
    async run(): Promise<void> {
        const signal = this.abortController.signal;
        
        try {
            while (!signal.aborted) {
                // Do a unit of work
                await this.doWorkUnit();
                
                // Check cancellation between units
                if (signal.aborted) {
                    console.log('Cancellation detected, cleaning up...');
                    break;
                }
            }
        } finally {
            // Always cleanup, whether cancelled or completed
            await this.cleanup();
        }
        
        console.log('Task terminated gracefully');
    }
    
    cancel(): void {
        console.log('Cancellation requested');
        this.abortController.abort();
    }
    
    private async doWorkUnit(): Promise<void> {
        // Simulate work
        await new Promise(resolve => setTimeout(resolve, 100));
    }
    
    private async cleanup(): Promise<void> {
        console.log('Releasing resources...');
        // Close files, connections, release locks
    }
}
 
// ============================================
// Pattern 2: Volatile stop flag (conceptual)
// ============================================
class StoppableWorker {
    private shouldStop = false; // Would be volatile/atomic in real threading
    
    async run(): Promise<void> {
        console.log('Worker started');
        
        let iterationCount = 0;
        
        while (!this.shouldStop) {
            iterationCount++;
            
            // Perform work
            await this.processItem(iterationCount);
            
            // Periodically check stop flag (already in while condition)
        }
        
        console.log(`Worker stopped after ${iterationCount} iterations`);
    }
    
    requestStop(): void {
        this.shouldStop = true;
    }
    
    private async processItem(id: number): Promise<void> {
        console.log(`Processing item ${id}`);
        await new Promise(r => setTimeout(r, 200));
    }
}
 
// ============================================
// Pattern 3: Worker thread with message-based shutdown
// ============================================
if (isMainThread) {
    async function runWithGracefulShutdown(): Promise<void> {
        const worker = new Worker(`
            const { parentPort } = require('worker_threads');
            
            let running = true;
            let processedCount = 0;
            
            // Listen for shutdown command
            parentPort.on('message', (msg) => {
                if (msg.type === 'shutdown') {
                    console.log('[Worker] Shutdown requested');
                    running = false;
                }
            });
            
            async function main() {
                while (running) {
                    // Process work
                    processedCount++;
                    await new Promise(r => setTimeout(r, 100));
                    
                    // Report progress
                    parentPort.postMessage({ 
                        type: 'progress', 
                        count: processedCount 
                    });
                }
                
                // Cleanup and report final state
                console.log('[Worker] Cleaning up...');
                parentPort.postMessage({ 
                    type: 'shutdown_complete',
                    finalCount: processedCount
                });
            }
            
            main();
        `, { eval: true });
        
        // Let worker run for 1 second
        await new Promise(r => setTimeout(r, 1000));
        
        // Request graceful shutdown
        worker.postMessage({ type: 'shutdown' });
        
        // Wait for shutdown confirmation
        await new Promise<void>((resolve) => {
            worker.on('message', (msg) => {
                if (msg.type === 'shutdown_complete') {
                    console.log(`[Main] Worker completed: ${msg.finalCount} items`);
                    resolve();
                }
            });
        });
        
        await worker.terminate();
    }
}

The Cooperative Termination Principle

Threads should terminate themselves in response to requests, not be terminated externally. This allows cleanup code to run, resources to be released, and invariants to be maintained. Design your threads with cancellation checkpoints and cleanup logic from the start.

Thread Coordination: Waiting for Completion

A crucial aspect of thread lifecycle management is coordination—knowing when threads have finished their work and collecting their results. The primary mechanism for this is the join operation.

thread-join-patterns.ts
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
import { Worker, isMainThread } from 'worker_threads';
 
/**
 * Thread Join Operations
 * 
 * join() causes the calling thread to wait until the target thread terminates.
 * This is essential for:
 * - Ensuring work is complete before proceeding
 * - Collecting results from worker threads
 * - Proper resource cleanup
 */
 
// ============================================
// Pattern 1: Sequential Join (wait for each)
// ============================================
async function sequentialJoin(): Promise<void> {
    const workers: Worker[] = [];
    const results: number[] = [];
    
    // Create multiple workers
    for (let i = 0; i < 4; i++) {
        const worker = new Worker(/* worker code */, { workerData: i });
        workers.push(worker);
    }
    
    // Wait for each worker sequentially
    // Total time = sum of all worker times
    for (const worker of workers) {
        const result = await new Promise<number>((resolve) => {
            worker.on('message', resolve);
        });
        results.push(result);
        await worker.terminate();
    }
    
    console.log('All workers complete:', results);
}
 
// ============================================
// Pattern 2: Parallel Join (wait for all)
// ============================================
async function parallelJoin(): Promise<void> {
    const workerPromises: Promise<number>[] = [];
    
    // Create workers and capture their completion promises
    for (let i = 0; i < 4; i++) {
        const promise = new Promise<number>((resolve, reject) => {
            const worker = new Worker(/* worker code */, { workerData: i });
            
            worker.on('message', (result) => {
                worker.terminate();
                resolve(result);
            });
            
            worker.on('error', reject);
        });
        
        workerPromises.push(promise);
    }
    
    // Wait for ALL workers concurrently
    // Total time = max of all worker times (not sum)
    const results = await Promise.all(workerPromises);
    
    console.log('All workers complete:', results);
}
 
// ============================================
// Pattern 3: Join with Timeout
// ============================================
async function joinWithTimeout(
    worker: Worker, 
    timeoutMs: number
): Promise<{ success: boolean; result?: unknown }> {
    
    return new Promise((resolve) => {
        const timer = setTimeout(() => {
            console.log('Join timed out, terminating worker');
            worker.terminate();
            resolve({ success: false });
        }, timeoutMs);
        
        worker.on('message', (result) => {
            clearTimeout(timer);
            worker.terminate();
            resolve({ success: true, result });
        });
        
        worker.on('error', (err) => {
            clearTimeout(timer);
            worker.terminate();
            resolve({ success: false });
        });
    });
}
 
// ============================================
// Pattern 4: Race - First Completion Wins
// ============================================
async function raceWorkers(): Promise<unknown> {
    const workers: Worker[] = [];
    
    // Start multiple workers doing the same task
    for (let i = 0; i < 3; i++) {
        const worker = new Worker(/* worker code */, { workerData: i });
        workers.push(worker);
    }
    
    // Wait for FIRST worker to complete
    const result = await Promise.race(
        workers.map((worker, index) => 
            new Promise((resolve) => {
                worker.on('message', (result) => {
                    resolve({ workerIndex: index, result });
                });
            })
        )
    );
    
    // Terminate remaining workers
    for (const worker of workers) {
        worker.terminate();
    }
    
    console.log('First worker won:', result);
    return result;
}
 
// ============================================
// Lifecycle diagram with join
// ============================================
/*
Main Thread          Worker Thread 1       Worker Thread 2
     │                     │                      │
     │ create              │                      │
     ├────────────────────►│                      │
     │                     │ [RUNNABLE]           │
     │ create              │                      │
     ├────────────────────────────────────────────►
     │                     │                      │ [RUNNABLE]
     │                     │                      │
     │ join(worker1)       │                      │
     │ [WAITING]           │ (executing)          │ (executing)
     │     ·               │                      │
     │     ·               │ [TERMINATED]         │
     ├─────────────────────┘                      │
     │ [RUNNABLE]                                 │
     │                                            │
     │ join(worker2)                              │
     │ [WAITING]                                  │ (executing)
     │     ·                                      │
     │     ·                                      │ [TERMINATED]
     ├────────────────────────────────────────────┘
     │ [RUNNABLE]
     │
     │ (continue processing)
     ▼
*/

Join and Thread Safety

After a successful join(), the thread is guaranteed to be TERMINATED. All writes made by the terminated thread are visible to the joining thread—this is called the 'join happens-before relationship.' This memory visibility guarantee is crucial for safely reading results computed by worker threads.

Daemon vs User Threads

Threads are classified into two categories based on their relationship to process lifetime: user threads (foreground) and daemon threads (background).

User Threads vs Daemon Threads
Aspect	User Thread (Foreground)	Daemon Thread (Background)
Default	Yes - threads are user threads by default	Must explicitly set daemon=true before start()
Process lifetime	JVM/process waits for all user threads to complete	JVM/process can exit even if daemon threads are running
Exit behavior	Thread must complete or be explicitly terminated	Abruptly stopped when the last user thread exits
Cleanup	Finally blocks execute; resources can be released	Finally blocks may NOT execute; resources may leak
Use cases	Main application logic, critical operations	Background services, monitoring, GC, housekeeping
Examples	Request handlers, business logic, main thread	GC threads, timer threads, monitoring agents

daemon-threads.ts
Java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
import java.util.concurrent.*;
 
public class DaemonThreadDemo {
    
    public static void main(String[] args) throws InterruptedException {
        // Create a daemon thread for background work
        Thread daemonThread = new Thread(() -> {
            try {
                while (true) {
                    System.out.println("[Daemon] Background cleanup running...");
                    Thread.sleep(500);
                    
                    // Perform periodic maintenance
                    performBackgroundCleanup();
                }
            } finally {
                // WARNING: This finally block may never execute!
                // Daemon threads are killed abruptly when JVM exits
                System.out.println("[Daemon] Cleanup - THIS MAY NOT PRINT!");
            }
        });
        
        // MUST set daemon before start()
        daemonThread.setDaemon(true);
        daemonThread.start();
        
        // Create user (foreground) thread for main work
        Thread userThread = new Thread(() -> {
            try {
                System.out.println("[User] Starting main work...");
                Thread.sleep(2000);
                System.out.println("[User] Main work complete");
            } catch (InterruptedException e) {
                Thread.currentThread().interrupt();
            } finally {
                // This finally block WILL execute
                System.out.println("[User] Cleanup completed");
            }
        });
        
        userThread.start();
        
        // Main thread waits for user thread
        userThread.join();
        
        System.out.println("[Main] User thread done, exiting...");
        // At this point, main thread is the only remaining user thread
        // When main() returns, JVM will:
        // 1. Wait for other user threads (none remaining)
        // 2. Terminate daemon threads abruptly
        // 3. Exit the process
    }
    
    private static void performBackgroundCleanup() {
        // Log rotation, temp file cleanup, cache expiration, etc.
    }
}
 
/*
Output:
[Daemon] Background cleanup running...
[User] Starting main work...
[Daemon] Background cleanup running...
[Daemon] Background cleanup running...
[Daemon] Background cleanup running...
[User] Main work complete
[User] Cleanup completed
[Main] User thread done, exiting...
 
Note: "[Daemon] Cleanup - THIS MAY NOT PRINT!" never appears!
The daemon thread was killed mid-execution.
*/

Daemon Thread Danger

Never use daemon threads for operations that must complete (like writing files, sending network data, or updating databases). Daemon threads can be terminated at any point in their execution—even in the middle of a write operation—leaving data corrupted or transactions incomplete.

Summary: Mastering Thread Lifecycle

We've thoroughly explored the complete lifecycle of a thread—every state, transition, and management pattern. Let's consolidate the essential knowledge:

Key Takeaways

•Threads follow a defined state machine — NEW → RUNNABLE → RUNNING → (BLOCKED/WAITING/TIMED_WAITING) → TERMINATED.
•Creation is separate from starting — A thread object in NEW state has no OS resources; start() triggers actual thread creation.
•RUNNABLE means eligible, not running — The scheduler controls when RUNNABLE threads actually execute on CPU.
•Three distinct waiting states — BLOCKED (monitor lock), WAITING (indefinite), TIMED_WAITING (with timeout)—each with different exit conditions.
•Graceful termination is essential — Threads should cooperatively terminate via flags or interruption, not be forcefully stopped.
•Join coordinates completion — join() allows one thread to wait for another to terminate, with memory visibility guarantees.
•Daemon threads die with the process — Use for background tasks only; never for critical operations that must complete.

What's Next:

With thread lifecycle mastered, we're ready to explore the practical skills of creating and managing threads. We'll examine thread pools, executor services, thread factories, and thread management patterns that are used in production systems.

Page Complete

You now understand the complete lifecycle of threads—how they're created, scheduled, how they wait, and how they terminate. This lifecycle knowledge is essential for debugging concurrency issues, managing resources, and designing robust concurrent applications.