Multithreading in Java: Process vs Thread

I struggled with this topic for a long time. I read dozens of articles, watched videos, and still felt like I didn’t truly get it. I could repeat the definitions, but the mental model was missing.

I could understand higher-level multithreading concepts, but the moment the interviewer asked “What’s the difference between a process and a thread?”, I froze.

Until now.

After exhausting ChatGPT, Grok, and Gemini for explanations, I finally built a mental model that sticks.

Process (container) vs Thread (execution unit)

Process

Think of your house, an isolated entity which has its own rooms, furniture, layout, and utilities. Nothing outside the house can randomly walk in and touch your stuff. It does not depend on outer things.

Process is similar to your house. It is a fully isolated container with its own:

• Code Segment
• Heap
• Stack
• Data Segment
• It’s own resources like: File handles, network connections, OS objects, environment variables.
• Its own runtime context: CPU registers, Program counter, OS-level PCB (Process Control Block)

And no other process can touch it directly. This isolation is what makes security & stability possible.

Let’s also look at the key properties of process:

Heavyweight → Takes more OS time to create.

Full isolation → One process crashing usually doesn’t kill others.

Interprocess communication (IPC) is needed for communication:

• Pipes
• Sockets
• Shared memory
• Message queues

Thread

A thread is a smaller execution unit that lives inside a process. I think of it like a worker inside the house who shares all the rooms and furniture.

Every process must have at least one thread -> the “main” thread.

All the threads in same process share things with each other like:

• Same heap memory
• Same static variables
• Same open files
• Same network sockets
• Same code

But each thread also gets its own:

• Thread stack
• Program counter
• CPU register state
• Local variables

This is why:

• One thread crashing can kill the whole process
• But one thread blocking doesn’t stop others

Why do threads exist?

Threads allow:

1. Parallel execution (multi-core CPUs)
   Each thread can run on a different core.
2. Concurrency
   Multiple tasks appear to run at once, even on single-core CPUs via time slicing.
3. Faster context switching
   Switching between threads is cheaper than switching between processes.
4. Shared memory communication
   Threads share data instantly, unlike isolated processes.

Real-world example

Imagine you use a browser:

Get Mayank Pant’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

🟥 Process = Chrome
🟨 Threads =

• 1 thread renders the page
• 1 thread fetches data
• 1 thread handles input
• 1 thread runs JS engine

All share memory → fast
If one misbehaves → can crash tab

CPU Scheduling Difference

Process scheduling

• Context switch is heavy
• OS saves & restores entire memory context
• Expensive for the CPU

Thread scheduling

• Lightweight
• Only a small CPU register set + program counter needs switching
• Very fast

Safety & Race Conditions

Because threads share memory, they can conflict:

Thread A reads x
Thread B writes x
Thread A writes x
Thread B writes x

This leads to:

• Race conditions
• Inconsistent state
• Lost updates

Hence we need:

• synchronized
• locks
• volatile
• atomic variables
• CAS

Conclusion

Once you understand this mental model: Process = container; Thread = worker, all of Java multithreading starts making sense.
It becomes clear why threads are faster, why they share memory, and why synchronization problems exist.