Multi Threading Part1:Your CPU Is Bored — And Your Single-Threaded App Is to Blame

Processes, threads, multitasking, multithreading — what they actually mean, and why the difference matters more than you think

Here’s a scenario you’ve probably lived through. Your Java app is waiting — waiting for a database query, waiting for user input, waiting for a file to load. And while it waits, it does absolutely nothing. Your CPU is sitting there at 0%, twiddling its digital thumbs, while your users stare at a frozen screen.

That’s not a resource problem. That’s an architecture problem. And multithreading is the fix.

But before you write a single line of concurrent code, you need to be crystal clear on terminology. Process, thread, multitasking, multithreading, multiprogramming — these words get thrown around interchangeably in interviews and tutorials, and almost always incorrectly. Let’s fix that right now.

The Building Block: What Is a Process?

A process is an independent program in execution. It lives in its own isolated memory space — its own heap, its own stack, its own file handles. Two processes cannot see each other’s memory. When you open Chrome and IntelliJ IDEA at the same time, you are running two separate processes. They do not share anything.

Switching between processes (called a context switch) is expensive — the OS has to swap out the entire memory map, save registers, load a new one. It takes time and resources.

Threads: Lightweight Workers Inside a Process

A thread is an independent path of execution within a process. Multiple threads live inside one process and share its memory — heap, code, data. That’s what makes them lightweight. Switching between threads is far cheaper than switching between processes because there’s no memory map to swap.

Think of MS Word. One thread handles your typing, another runs auto-save in the background, another checks your spelling in real time. One program — three parallel tasks. That’s threads in action.

Key rule: threads within the same process share memory (heap + code). They each have their own stack and program counter. This shared memory is exactly what makes multithreading powerful — and exactly what makes it dangerous if you’re not careful.

The Big Four — Cleared Up Once and For All

Here’s where most tutorials lose people. Let’s define all four terms precisely:

🟠 Multiprogramming An OS-level technique where multiple programs are loaded in RAM simultaneously. When Program A waits for I/O, the CPU switches to Program B instead of sitting idle. This isn’t true parallelism — it’s just keeping the CPU from being wasted.

Think: one chef, multiple orders queued up — they work on the next dish while the pasta boils.

🟡 Multitasking An extension of multiprogramming where the OS gives each process a small time slice (milliseconds) of CPU time, switching between them so rapidly that to you it looks like everything is running at once.

Your music plays while you type a document. That’s multitasking.

🔵 Multithreading Multitasking at the thread level, inside a single application. Instead of multiple programs, you have multiple threads of the same program running concurrently — sharing data, sharing code, taking full advantage of idle CPU cycles.

🟢 Thread The actual unit of concurrent execution. It’s the individual worker. In Java, every thread has its own stack but shares the heap with all other threads in the same JVM process.

Why Bother with Multithreading?

In a single-threaded environment, only one task runs at a time. If that task blocks — waiting for a DB response, reading a file, waiting for a network call — your entire application freezes. The CPU sits idle. Your user waits. This is unacceptable in any real-world application.

Multithreading solves this by putting that idle CPU time to work:

• While Thread A waits for a DB query, Thread B can process the previous result
• While Thread A waits for user input, Thread B can auto-save in the background
• On multi-core machines, threads can run truly in parallel — one per core

The Main Thread in Java

Every Java program starts with exactly one thread — the main thread — which is the one that runs your main() method. Every other thread in your program is spawned (created) from this thread. The JVM will not shut down as long as any user thread is still alive, even if main() has already finished and exited.

public class MainThreadDemo {
    public static void main(String[] args) {
        // main() itself runs on a thread — the main thread
        Thread t = Thread.currentThread();
        System.out.println("Name:     " + t.getName());     // main
        System.out.println("ID:       " + t.getId());       // 1
        System.out.println("Priority: " + t.getPriority()); // 5 (default NORM_PRIORITY)
        System.out.println("Daemon?   " + t.isDaemon());    // false
    }
}

User Threads vs Daemon Threads

Java threads come in exactly two flavors:

User threads — Your application’s working threads. The JVM stays alive until every user thread has finished. This is the default type for any thread you create.

Daemon threads — Background service threads. The JVM kills them automatically the moment all user threads are done — it doesn’t wait for them to finish. The most famous daemon thread is the Garbage Collector. It runs silently in the background your entire program, and the JVM never waits for it before shutting down.

To make a thread a daemon, call setDaemon(true) — but you must do it before calling start(). After that, it’s too late.

Thread logger = new Thread(() -> {
    while (true) {
        System.out.println("Background logger running...");
        try { Thread.sleep(500); } catch (InterruptedException e) { break; }
    }
});

logger.setDaemon(true); // MUST be before start()
logger.start();
System.out.println("Main thread finishing...");
// JVM exits here - logger thread is killed automatically
// No waiting, no cleanup, just gone

Think of daemon threads as the cleaning crew in a cinema hall. They do their job quietly in the background. But the moment the last moviegoer (user thread) walks out, the hall closes — whether the crew is done or not.

Wrapping Up Part 1

You now have a rock-solid mental model before writing any concurrent code. Here’s the quick recap:

• A process is an isolated program with its own memory
• A thread is a lightweight unit of execution inside a process, sharing its heap
• Multithreading = multiple threads in one application, sharing memory
• Every Java program starts with a main thread — all others are children of it
• User threads keep the JVM alive; Daemon threads die when user threads do
• Idle CPU time = wasted money. Multithreading fixes that.

In Part 2, we get hands-on — writing your first threads two different ways, running them together, and understanding the critical difference between start() and run().

Found this helpful? Drop a 👏 and follow for the rest of the series. Part 2 drops next — we write real code.