Threads vs Processes
Fast recall
Quick revision
Core answer
Whether you understand the isolation-vs-sharing trade-off: processes are isolated (safe but heavy); threads share memory (light but need synchronization).
Saying 'threads are smaller processes' without naming the shared-memory consequence (need synchronization) and isolation difference.
Processes have separate memory (isolated, heavy, IPC); threads share a process's memory (light, easy sharing, need synchronization, not isolated). Trade-off: isolation vs sharing.
Interview-ready guide
Interview answer
A process is an instance of a running program with its own private memory space, and a thread is a unit of execution within a process that shares that process's memory with other threads.
Processes are isolated — one crashing doesn't affect another — which makes them safe but heavy to create and communicate between, requiring IPC like pipes, sockets, or shared files.
Threads are lightweight, fast to create and context-switch, and share memory, which makes data sharing easy but means they're not isolated — one thread's crash can bring down the whole process — and they need synchronization, like locks or atomics, to avoid races. The fundamental trade-off is isolation versus lightweight sharing.
A common mistake is saying a thread is a small process, which misses the shared-memory consequence that threads need synchronization, and assuming threads are isolated like processes, which they're not — one thread's crash can kill the whole process.
Threads vs Processes
Direct Answer
A process is an instance of a running program with its own memory space; a thread is a unit of execution within a process that shares that process's memory with other threads. Processes are isolated (one crashing doesn't affect another) but heavy to create and communicate between (IPC). Threads are lightweight, fast to create and switch, and share memory (easy data sharing) but are not isolated (one thread's crash can bring down the process) and need synchronization to avoid races. The trade-off: isolation vs lightweight sharing.
Code Example
// PROCESS: separate memory. Two JVMs don't share heap objects.
// Process A: java -jar app.jar <- its own heap
// Process B: java -jar app.jar <- its own heap; no shared objects
// To share data they need IPC (sockets, files, queues).
// THREAD: shares the process's memory (heap).
Runnable shared = () -> {
// runs on a new thread but sees the SAME `list` as the main thread.
list.add("from thread " + Thread.currentThread().getName());
};
new Thread(shared).start();
list.add("from main");
// Easy sharing, but list is not thread-safe -> needs synchronization.
Common Mistakes & Pitfalls
- Saying 'a thread is a small process' — missing the shared-memory consequence (needs synchronization).
- Forgetting that shared memory is fast but unsafe without synchronization (races).
- Assuming threads are isolated like processes — they're not; one crash can kill the process.
Check your understanding
Answer these without looking back at the article.
- What memory does a process have vs a thread (separate vs shared)?
- What's the isolation difference, and why does it matter (crash safety)?
- Why are threads lighter, and what's the cost of shared memory (synchronization)?
- How do processes communicate vs threads (IPC vs shared memory)?
Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.