Processes vs threads

For this lesson, we'll build the model every later concurrency topic leans on: what the OS creates when you launch Java, what threads share and keep private, and how the CPU runs them. Interviewers love it because it looks like a warm-up and then turns into "where do static fields live?" and "what happens with 20 threads on 2 cores?". The follow-ups are where people run out of road.

01Picture it first: two kitchens, many cooks

Picture two restaurant kitchens in separate buildings, each with its own fridge and recipe binder. A cook in kitchen A can't open kitchen B's fridge; to coordinate, somebody phones across. That's a process: a sealed space whose walls the OS enforces.

Inside one kitchen, several cooks work at once. They share the fridge and the binder, but each has a personal notepad and a finger on "the line I'm on right now". Those cooks are threads. When two of them reach for the last egg at the same moment, you get the classic multithreading bug.

Here's that picture with real Java names on it: two java commands, two processes, one JVM each, and the OS underneath both.

Fig. 1

Two separate java commands create two isolated processes, each with its own JVM, heap, Metaspace, code cache and threads, running on the same operating system kernel

Notice the heap lives inside each process box. There's no machine-wide "JVM heap" that processes carve slices from, a wrong answer I hear often.

02What a process is, and who creates it

Let's walk through the moment you launch something:

javac OrderService.java        # produces OrderService.class (bytecode)
java -Xms256m -Xmx2g OrderService

The java launcher is a normal native program. Your shell asks the OS to start it (fork/exec on Linux and macOS, CreateProcess on Windows), so the OS creates the process, not the JVM. The process gets a PID, a private virtual address space and one initial thread, and the launcher loads the JVM into it. One process, one JVM. Run the command twice and you have two independent JVMs.

Isolation is the defining property. The OS maps each process's virtual addresses to different physical memory, so a bug in process A can't scribble over process B's objects. The price: processes can't talk through shared variables. They use sockets, pipes, files or OS shared-memory APIs, all slower and clumsier than reading a field.

What each JVM process gets: its own heap

Each JVM reserves its own heap when it starts. You size it per process:

• -Xms256m: initial heap of 256 MB.
• -Xmx2g: maximum heap of 2 GB. If live objects need more, this process throws OutOfMemoryError: Java heap space, even if the machine has 30 GB free.

Without flags, Java 21 picks an initial heap of 1/64 and a max of 1/4 of physical memory (in a container, of the container's limit, so a 2 GB pod gets about 512 MB). Each thread's stack is sized by -Xss: 1 MB on Linux/x64, 2 MB on Linux/AArch64 and macOS/AArch64.

03What a thread is, and why main is never alone

A thread is an independent sequence of instructions with its own position in the code and its own call stack. The OS schedules threads, not processes: a process with zero runnable threads uses no CPU.

When the JVM starts, it runs your main method on a thread named main. Other threads appear only when code calls Thread.start() (directly or through a pool or server library). The JVM doesn't analyse your program upfront to decide how many threads it "needs"; they're created at runtime, one start() at a time.

And main is never alone. Before your first line runs, HotSpot has started its own helpers: GC threads, JIT compiler threads (C1 CompilerThread0, C2 CompilerThread0), Reference Handler, Finalizer, Signal Dispatcher and more. jcmd shows them:

jcmd                              # lists running JVMs and their PIDs
jcmd 4101 Thread.print            # full thread dump of PID 4101

A trimmed dump looks like this (exact names vary by JDK version and GC):

"main" #1 prio=5 ...
"Reference Handler" #9 daemon prio=10 ...
"Finalizer" #10 daemon prio=8 ...
"Signal Dispatcher" #11 daemon prio=9 ...
"C2 CompilerThread0" #14 daemon prio=9 ...
"C1 CompilerThread0" #17 daemon prio=9 ...
"VM Thread" ...
"GC Thread#0" ...
"G1 Main Marker" ...

04Under the hood: one process, three threads

Here's the smallest program I use to make this concrete. It runs on Java 21:

import java.util.Comparator;

public class ProcessAndThreads {

    public static void main(String[] args) throws InterruptedException {
        long pid = ProcessHandle.current().pid();
        System.out.println("PID " + pid + ", running on: " + Thread.currentThread().getName());

        Runnable work = () -> {
            int local = 42; // lives in this thread's own stack frame
            System.out.println("  hello from " + Thread.currentThread().getName()
                    + " in PID " + ProcessHandle.current().pid() + ", local=" + local);
        };

        Thread a = new Thread(work, "worker-a");
        Thread b = new Thread(work, "worker-b");
        a.start();
        b.start();
        a.join();
        b.join();

        System.out.println("Java-visible threads in this JVM:");
        Thread.getAllStackTraces().keySet().stream()
                .sorted(Comparator.comparing(Thread::getName))
                .forEach(t -> System.out.println("  " + t.getName()
                        + (t.isDaemon() ? " (daemon)" : "")));
        System.out.println("Cores: " + Runtime.getRuntime().availableProcessors()
                + ", max heap: " + Runtime.getRuntime().maxMemory() / (1024 * 1024) + " MB");
    }
}

One run on my laptop printed:

PID 7347, running on: main
  hello from worker-b in PID 7347, local=42
  hello from worker-a in PID 7347, local=42
Java-visible threads in this JVM:
  Common-Cleaner (daemon)
  Finalizer (daemon)
  Notification Thread (daemon)
  Reference Handler (daemon)
  Signal Dispatcher (daemon)
  main
Cores: 14, max heap: 12288 MB

Notice four things:

1. Same PID everywhere. All three threads live in one process. Rerun it and the PID changes: new process.
2. Order isn't guaranteed. worker-b printed first although worker-a started first. The OS scheduler decides.
3. local is per thread. Each worker has its own copy in its own stack frame, so there's nothing to race on.
4. getAllStackTraces() shows only Java threads. GC and JIT threads are internal VM threads; use jcmd Thread.print for those. Rerun with -Xmx256m and the last line says max heap: 256 MB: heap size is per process.

05What threads share, and what each keeps private

Textbooks draw a process as four segments: code (read-only instructions), data (globals and statics), heap and one stack per thread. That's the C and OS view. A JVM process still has those segments for the JVM's own native code, but your Java program's state lives in the run-time areas the JVM spec defines, so let's map them honestly.

Here's the same split as a picture of one JVM process with three threads.

Fig. 2

Inside one JVM process, the heap, Metaspace and code cache are shared by all threads, while each thread owns a pc register, a JVM stack and a native stack

Interviewers probe three details here:

• Static fields are on the heap. The JLS says instance fields, static fields and array elements live in shared heap memory, while locals and parameters are never shared. Metaspace holds the class's description (methods, bytecode, constant pool), not static values. More in Metaspace: where classes live.
• The pc register holds the address of the bytecode instruction the thread is executing, and is undefined inside native methods. In JIT-compiled code the CPU's instruction pointer does that job, and the OS saves it on every switch.
• Primitive locals live in the frame; primitive fields live inside their object on the heap. An int count local is private. An int count field on a shared object is not.

Because the heap is shared, two threads writing the same field need coordination. That's the whole reason locks, volatile and atomics exist.

06One run, end to end

Let's put the pieces in order for a Main that starts two worker threads:

1. Compile. javac Main.java writes Main.class. Nothing is running yet.
2. Launch. java -Xmx1g Main. The OS creates a process: new PID, new address space, one initial thread.
3. JVM boots. It reserves up to 1 GB of heap, sets up Metaspace and the code cache, and starts its GC, JIT and housekeeping threads.
4. Classes load. Main's metadata and bytecode go into Metaspace; its static fields go in the heap.
5. main runs. The main thread gets a JVM stack and pc register and starts in the interpreter. Hot methods get JIT-compiled into the code cache.
6. Threads are born at runtime. t1.start() asks the OS for a new native thread with its own stack, starting at run(). Same for t2.
7. The OS schedules them all. main, t1, t2 and the JVM's helpers compete for cores, sharing code and heap, each from its own position.
8. Exit. When the last non-daemon thread ends (or System.exit runs), the JVM shuts down and the OS reclaims the process's memory in one go.

07How the CPU actually runs threads

The CPU executes the code, and the OS scheduler decides which thread gets which core. Java platform threads are thin wrappers around OS threads, one to one, so to the scheduler a Java thread is an OS thread.

One core: time slicing and context switches

With one core and three runnable threads, only one instruction stream runs at any instant. The scheduler gives each thread a time slice (typically milliseconds, depending on the OS and load) and then switches. A thread can also give up the core early by blocking on I/O, a lock or sleep.

A context switch looks like this:

1. An interrupt or a blocking call enters the kernel.
2. The kernel saves the outgoing thread's CPU registers, including the instruction pointer and stack pointer, into that thread's kernel structure (often called the thread control block).
3. The scheduler picks the next runnable thread.
4. The kernel restores that thread's saved registers and returns to user mode, so it resumes exactly where it stopped.

The saved registers plus the thread's own stack are what let it resume mid-method as if nothing happened.

N cores: real parallelism, plus time slicing for the rest

With N cores, up to N threads execute at the same physical instant. The figure below compares three threads on one core with the same three threads on two cores.

Fig. 3

On one core three threads take turns with a context switch between each slice, while on two cores two threads run at the same instant and the third is time-sliced in

So with 2 cores and 20 runnable threads, 2 run truly in parallel at every instant and 18 wait: parallelism and time slicing together. With 4 cores and 3 runnable threads, each can keep its own core (other processes and JVM helper threads may still cut in).

Concurrency vs parallelism

• Concurrency is about structure: several tasks are in progress during the same period, and their steps may interleave. One core is enough.
• Parallelism is about execution: several tasks run at the same instant on different cores. It needs more than one core.

A concurrent program on one core is still concurrent. It is never parallel.

08Real world

09Benefits and challenges of multithreading

Multithreading means one program running several threads that share its resources. The benefits:

• Parallel speed-up. Split CPU-bound work across threads and N cores can work on it at once. One thread on an 8-core box leaves 7 cores idle.
• Responsiveness. A slow database call on one thread doesn't freeze the others.
• Cheap sharing. Threads read the same objects directly, with no serialising across a pipe.

The challenges come from that same sharing:

• Data races and lost updates. Two threads doing count++ on a shared field can both read 5 and both write 6.
• Coordination costs. Locks and synchronized blocks fix races but add waiting, and lock ordering mistakes cause deadlocks. See wait(), notify() and notifyAll() and the synchronization interview questions.
• Visibility. Without a happens-before edge, one thread may not see another's write at all.
• Hard to test. Timing-dependent bugs hide on your laptop and surface under load. The concurrency reference article covers the toolbox.

My default: start with no shared mutable state (a thread pool passing immutable data), and add shared state and locks only where you've measured a need.

10Advanced: costs, misconceptions and comparisons

Some depth that separates strong answers:

• Thread switch vs process switch. Threads of one process share an address space, so switching between them keeps page tables; a process switch swaps them. That's largely why threads are "lightweight".
• Stack memory is reserved, not always committed. -Xss1m reserves 1 MB of address space per thread and the OS commits pages as the stack grows. Thousands of platform threads still add up, and the OS caps threads per process.
• Container awareness. Since JDK 10 (backported to 8u191), HotSpot reads cgroup limits, so availableProcessors() and the default heap reflect the container, not the host.
• Virtual threads (Java 21). JEP 444 changes the 1:1 mapping: many virtual threads run on a small pool of carrier OS threads. They get their own lesson.

Multitasking vs multithreading

11How to say it in the interview

When I ask this question, I'm listening for three things. Do you know the OS creates the process and that each JVM process owns its own heap? Can you list shared versus private correctly, including where static fields live? And can you explain context switching and the cores-versus-threads question without saying "it's all an illusion"?

Here's how this might look if you sketch it on the whiteboard:

Interview questions for this topicComing soon