— The Foundation Most Developers Skip

When developers talk about Java concurrency, the conversation usually jumps straight into thread pools, synchronized, locks, volatile, Executors, CompletableFuture, or even reactive programming.

But before diving into high-level concurrency tools, there’s something more fundamental to understand:

How concurrency works at the operating system level.

Because before Java manages threads…
before the JVM allocates memory…
before your application creates an ExecutorService…

the operating system is already in control.

And everything starts with one critical distinction:

Process vs Thread

If you truly understand this difference, many “mysterious” concurrency behaviors in Java suddenly become logical.

---

Step 1: What Happens When You Run a Java Application?

When you execute:

java MyApplication

You are not “just running Java code.”

The operating system creates a new process.

Inside that process, the JVM (Java Virtual Machine) starts running.

From that point forward:

• The OS manages the process.
• The JVM manages memory and threads inside the process.
• Your application runs inside the JVM.

So the layering looks like this:

Operating System
→ Process
→ JVM
→ Java Threads
→ Your Code

Understanding this stack is essential.

---

What Is a Process?

A process is an independent execution unit created by the operating system.

When the OS creates a process, it provides:

• A completely separate virtual memory space
• Dedicated memory mappings
• Its own file descriptors
• Its own resource handles
• A strong isolation boundary from other processes

This isolation is critical.

One process cannot directly access the memory of another process.

That’s why:

• A crash in one process doesn’t automatically crash others.
• A memory leak in one process doesn’t corrupt another.
• Security boundaries are enforced at the process level.

In the case of Java:

When you run a Java app, the OS creates a process that hosts the JVM.
Inside that process, the JVM sets up:

• The Java heap
• The method area (or metaspace)
• Static variables
• Native memory structures
• Thread stacks

All of that memory belongs to that one process.

No other process can directly touch it.

---

Why Is Process Switching Expensive?

The operating system can run multiple processes on a single CPU core by switching between them rapidly.

This is called context switching.

When switching between processes, the OS must:

• Save the entire CPU state of the current process
• Switch memory mappings
• Update page tables
• Restore the CPU state of the next process

Because each process has its own memory space, the CPU must change its memory view entirely.

This is heavy.

Process context switching is expensive because:

• Memory mappings change
• CPU cache may be invalidated
• Page tables are switched
• Isolation must be maintained

Processes give you isolation and safety, but they come with overhead.

---

What Is a Thread?

Now let’s move inside the process.

A thread is a smaller unit of execution that lives within a process.

When your Java application creates a new thread:

new Thread(() -> {
    // do something
}).start();

The OS does not create a new process.

Instead:

• A new thread is created inside the same process.
• That thread shares the process memory.
• Only certain parts are separate.

---

What Do Threads Share?

Threads inside the same process share:

• The same heap
• The same static variables
• The same code
• The same class metadata
• The same memory mappings

This is extremely important.

Because shared memory is both powerful… and dangerous.

---

What Is Unique Per Thread?

Each thread has its own:

• Stack
• Program counter
• CPU registers

That means:

• Local variables live on the stack → thread-safe
• Objects live on the heap → shared
• Static variables live on the heap → shared

This explains many concurrency issues in Java.

If two threads modify the same object, they are touching shared heap memory.

And that’s where race conditions begin.

---

Why Is Thread Switching Cheaper?

When the OS switches between threads of the same process:

• Memory mapping stays the same
• Page tables remain unchanged
• The heap remains the same
• Only registers and stack pointers are updated

This is much lighter than switching processes.

That’s why threads are preferred for concurrency inside applications.

Threads give you:

• Better performance
• Faster context switching
• Shared memory communication
• Lower overhead

But they also give you…

Shared state problems.

---

The Core Tradeoff

Now we can summarize the fundamental difference:

Processes

• Strong isolation
• Memory safety
• Independent resource ownership
• Expensive context switching

Threads

• Shared memory
• Lightweight switching
• High performance
• Requires synchronization

This tradeoff is at the heart of Java concurrency.

---

Why Shared Memory Is Both Powerful and Dangerous

Shared memory allows threads to:

• Access the same objects
• Update shared data
• Communicate efficiently

But it also introduces:

• Race conditions
• Visibility problems
• Deadlocks
• Memory consistency issues

For example:

If Thread A updates a field and Thread B reads it, there is no guarantee Thread B immediately sees the updated value unless proper synchronization is used.

That’s why Java provides:

• synchronized
• volatile
• Lock APIs
• Atomic classes
• Concurrent collections

All of these exist because threads share memory.

---

The JVM and Native Threads

In modern JVM implementations, Java threads map closely to OS threads.

This means:

• Each Java thread consumes native resources.
• Each thread has a stack in native memory.
• Creating thousands of threads consumes real OS memory.

This is why traditional thread-per-request models can struggle at scale.

And this is also why features like virtual threads (Project Loom) are such a big deal—they change how Java manages concurrency internally while still respecting OS constraints.

But that’s a deeper topic.

---

Why This Matters for Backend Engineers

If you’re building:

• High-traffic REST APIs
• Microservices
• Event-driven systems
• Messaging consumers
• Database-heavy systems

You are working with threads constantly.

Understanding process vs thread helps you reason about:

• Why shared objects cause race conditions
• Why static variables are risky
• Why synchronization affects performance
• Why blocking operations limit scalability
• Why thread pools must be tuned

Without this foundation, concurrency becomes trial and error.

With this foundation, concurrency becomes logical.

---

A Practical Example

Imagine a Java web server handling requests.

If it used processes for each request:

• Every request would have isolated memory.
• No race conditions.
• But massive overhead.
• Slow context switching.
• High memory consumption.

Instead, it uses threads:

• Each request handled by a thread.
• Shared heap for caching and configuration.
• Fast switching.
• Lower memory footprint.

But now you must ensure shared data structures are thread-safe.

That’s the tradeoff in action.

---

The Bigger Architectural Perspective

At a systems level:

Processes optimize for isolation.

Threads optimize for performance.

Java concurrency is built on top of this reality.

When you use:

• Thread pools
• Executors
• CompletableFuture
• Parallel streams
• Virtual threads

You are working with abstractions over OS threads.

But underneath it all:

It’s still about shared memory inside a process.

---

Final Thoughts

Before learning advanced concurrency tools, understand this:

When you run a Java application, you are inside a process.

Inside that process live threads.

Processes give you isolation and safety.

Threads give you performance and shared memory.

And shared memory requires coordination.

Once you understand this tradeoff, everything else in Java concurrency—locks, atomics, visibility rules, memory models—starts to make sense.

Because concurrency isn’t magic.

It’s the careful balancing of isolation and performance.