Thinking in Threads — Part 5 | ~14 min read

1. The Shared Room

Picture a records room inside a busy office.

Important documents live there. Financial reports. Employee contracts. Client data. Multiple people need access throughout the day — some to read, some to update.

Reading is fine. Ten people can read the same document simultaneously. No conflict. No corruption.

But updating is different. If two people pick up the same contract and start making changes at the same time — one person’s edits overwrite the other’s. The document ends up in an inconsistent state. Nobody’s fault. No malicious intent. Just two people, one shared resource, no coordination.

The solution is obvious. Put a lock on the door.

One person enters at a time. They do their work. They leave. The next person enters.

The documents are now safe. Not because access was removed — people still need to get in. But because uncontrolled access was replaced with coordinated access.

“The problem was never access. It was uncontrolled access.”

This is exactly what synchronized does in Java.

2. From the Room to Java

The mapping is direct:

• The shared room = your shared object on the heap

• The people = your threads

• The lock on the door = synchronized

public class RecordsRoom {
    private int documentVersion = 1; // shared data — the "room"

    public synchronized void updateDocument(int newVersion) {
        // only one thread enters here at a time
        documentVersion = newVersion;
    }
}

The moment you add synchronized — Java puts a lock on the door. One thread enters. The others wait outside. When the first thread finishes and leaves, the next one enters.

No two threads are ever inside simultaneously. The shared state is protected.

But before we go further — there are three terms you will hear used interchangeably for this mechanism. Let’s clear them up once and move on.

3. Three Names. One Idea.

When developers talk about how synchronized works under the hood, they use three terms:

• Intrinsic lock — the lock built into every Java object by default

• Monitor — another name for the same lock, from the formal concurrency theory

• Object lock — same thing, named from a practical Java perspective

“Different names. Same idea.”

Every object in Java — every single one — carries an intrinsic lock. You don’t create it. You don’t declare it. It is just there, attached to the object, waiting to be used.

synchronized is the keyword that tells Java: use that built-in lock.

public class RecordsRoom {
    // this object has an intrinsic lock
    // synchronized uses it automatically
    public synchronized void updateDocument(int version) {
        documentVersion = version;
    }
}

When Thread A calls updateDocument(), it acquires the intrinsic lock on the RecordsRoom object.

Thread B tries to call the same method — it cannot acquire the lock because Thread A holds it.

Thread B waits. Thread A finishes, releases the lock. Thread B acquires it and proceeds.

One at a time. Coordinated. Safe.

4. The Critical Section — The Only Part That Needs Protection

Here is the most important concept in this entire blog.

You do not protect your entire method. You protect the critical section — the specific lines of code that read and modify shared state.

“You don’t lock the house. You lock the room that has valuables.”

A method can have many lines. Most of them may be pure logic — validation, computation, logging — that touches no shared state and needs no protection. Protecting those lines is waste. It forces threads to queue up for work that could safely run in parallel.

The critical section is the minimum necessary region:

public class VisitorCounter {
    private int count = 0; // shared state

    public void recordVisit(String visitorName) {
        // not shared state — safe to run in parallel
        validateName(visitorName);
        logVisitAttempt(visitorName);

        // ✅ critical section — this is the only part that needs protection
        synchronized (this) {
            count++; // read + modify + write on shared state
        }

        // not shared state — safe to run in parallel
        sendWelcomeNotification(visitorName);
    }
}

validateName(), logVisitAttempt(), sendWelcomeNotification() — all running freely in parallel. No lock needed. No thread waiting unnecessarily.

Only count++ — the one line that touches shared state — is inside the synchronized block.

That is surgical locking. That is the goal.

5. Synchronized Method vs Synchronized Block

Java gives you two ways to use synchronized. They are not the same. Knowing the difference is the difference between a developer who uses concurrency and one who understands it.

Method-Level Synchronization — Easy, but Broad

public class BankAccount {
    private int balance = 10000;
    private String ownerName = "Priya";

    // entire method is locked
    public synchronized void deposit(int amount) {
        validateAmount(amount);      // ← doesn't need lock
        logTransaction(amount);      // ← doesn't need lock
        balance += amount;           // ← needs lock
        sendConfirmation(amount);    // ← doesn't need lock
    }
}

When Thread A enters deposit(), it holds the lock for the entire method duration — including validateAmount(), logTransaction(), and sendConfirmation().

Thread B waits through all of that. Even the parts that could safely run in parallel.

“Method-level is easy. Block-level is precise.”

Block-Level Synchronization — Precise, Performant

public class BankAccount {
    private int balance = 10000;
    private final Object lock = new Object();

    public void deposit(int amount) {
        validateAmount(amount);   // runs freely in parallel ✅
        logTransaction(amount);   // runs freely in parallel ✅

        synchronized (lock) {
            balance += amount;    // only this is protected 🔒
        }

        sendConfirmation(amount); // runs freely in parallel ✅
    }
}

Threads only queue for the one line that actually needs protection. Everything else runs in parallel. This is the correct mental model.

Method-level — when the entire method touches shared state, or when simplicity matters more than performance.

Block-level — when only part of the method touches shared state. Almost always the better choice.

6. Object Lock vs Class Lock — Interview Gold

Not all synchronized locks are the same. This is one of the most common interview topics — and one of the most commonly misunderstood.

Instance method synchronization → locks the object

public class Counter {
    private int count = 0;

    public synchronized void increment() {
        count++; // locks THIS specific Counter instance
    }
}

Counter counterA = new Counter();
Counter counterB = new Counter();

// Thread 1 locks counterA → Thread 2 can still access counterB freely
// They are different objects with different intrinsic locks

Two different Counter objects — two different locks. Threads operating on different instances never block each other.

Static method synchronization → locks the Class

public class Counter {
    private static int totalCount = 0; // shared across ALL instances

    public static synchronized void incrementTotal() {
        totalCount++; // locks the Counter CLASS itself
    }
}

// Thread 1 and Thread 2 both call Counter.incrementTotal()
// They share ONE class-level lock — they must take turns
// regardless of which instance they came from

Static synchronization locks the Class object — one lock shared across every instance of that class, across the entire JVM.

“Not all locks are the same. It depends on what you are locking.”

• Instance state → instance lock.

• Static/class state → class lock.

Match the lock to the data it protects.

7. The Big Mistake — Over-Synchronization

You now understand what synchronized does. Here is the most expensive mistake you can make with it.

// ❌ Over-synchronized — locking everything
public class UserService {
    private List<String> activeUsers = new ArrayList<>();

    public synchronized void addUser(String user) { ... }
    public synchronized void removeUser(String user) { ... }
    public synchronized String getUserCount() { ... }      // read-only
    public synchronized void sendWelcomeEmail(String user) { ... } // no shared state
    public synchronized void logActivity(String user) { ... }      // no shared state
}

sendWelcomeEmail() touches no shared state. Neither does logActivity(). But because they are synchronized, every thread calling them must acquire the same object lock — and wait for every other synchronized method to finish first.

The result: a queue. One thread doing email sending holds the lock. A thread trying to add a user waits. A thread trying to log activity waits. Everyone waits for everyone.

“You locked the entire building when only one drawer needed protection.”

Fifteen chefs. One spoon. Nobody is cooking.

8. Why This Kills Performance

The damage from over-synchronization is not hypothetical. It is measurable and severe.

• 🔴 Threads blocked — waiting to acquire a lock they don’t actually need

• 🔴 CPU underutilized — cores sitting idle while threads wait in line

• 🔴 Throughput collapses — under load, the queue grows faster than it drains

• 🔴 Latency spikes — requests that should take milliseconds now wait seconds

// Scenario: 1000 threads calling UserService simultaneously

// With over-synchronization:
// → all 1000 threads queue on the same lock
// → throughput: effectively single-threaded
// → latency: 1000x worse than necessary

// With precise synchronization:
// → only the threads modifying shared state queue
// → threads doing email, logging run freely in parallel
// → throughput: genuinely concurrent

“A poorly synchronized program is just a slow single-threaded program.”

You introduced threads to gain speed. Over-synchronization takes that speed away — silently, under load, in production.

9. The Right Way to Think About Locking

There is a simple mental checklist before you place any synchronized:

• ✅ Does this code access shared state on the heap?

• ✅ Does it modify that state — not just read it?

• ✅ Can another thread be doing the same thing simultaneously?

If yes to all three — protect it. Precisely. With a block, not the whole method if avoidable.

If no to any one — leave it alone. Let it run free. That is where your performance lives.

“Thread safety is not about maximum locking. It is about minimum necessary locking.”

// The right mental model in code
public void processOrder(Order order) {
    // pure logic — no shared state — run free
    validateOrder(order);
    calculatePricing(order);

    // shared state modification — protect precisely
    synchronized (inventoryLock) {
        inventory.deduct(order.getItems());
    }

    // no shared state — run free
    sendOrderConfirmation(order);
    logOrderProcessed(order);
}

Small lock. Targeted lock. Everything else parallel.

10. What synchronized Actually Guarantees

This is worth being precise about — because Blog 6 and 7 will build on it.

synchronized gives you two guarantees, not one:

Mutual exclusion — only one thread can hold the lock and execute the critical section at a time. This fixes the lost update from Blog 4.

Visibility — when a thread releases a lock, all writes it made are flushed to main memory. When another thread acquires the same lock, it sees those writes. This fixes the stale read from Blog 4.

synchronized (lock) {
    // entering: guaranteed to see all writes made by the
    // last thread that held this lock

    balance += amount;

    // exiting: all writes made here are guaranteed to be
    // visible to the next thread that acquires this lock
}

One keyword. Two guarantees. Both the atomicity failure and the visibility failure from Blog 4 — solved together.

This is why synchronized is the foundational tool. Everything else in the concurrency toolkit is either a refinement of it or a solution to the new problems it creates.

11. Connecting the Whole Map

Let’s place this precisely in the journey so far:

• Blog 1 → shared state needs surgical protection, not blanket locking

• Blog 2 → shared state lives on the heap, accessible to all threads

• Blog 3 → race conditions happen when threads access shared heap state simultaneously

• Blog 4 → race conditions produce lost updates (atomicity) and stale reads (visibility)

• Blog 5 → synchronized closes the critical section, provides mutual exclusion and visibility

“Race conditions happen when critical sections are unprotected. Synchronized protects them.”

The problem was always the unprotected gap. synchronized closes that gap. But only if placed correctly, sized precisely, and used with understanding — not fear.

12. One Line to Remember

“Locks don’t make your program safe. Correctly placed locks do.”

A lock in the wrong place is not neutral. It slows your program down. It creates new coordination problems. It can even cause deadlocks — which is exactly where this series goes next.

Let’s Connect

If this was useful, consider sharing it with someone who’s on the same journey.

Subscribe now

Let’s keep learning together!

Have a question or a topic you’d like me to cover? Drop a comment below — I read every one.

Leave a comment

Nitin
Hashnode | Substack | LinkedIn | Youtube | Instagram | GIT | Topmate

Share Level Up Your Programming with Nitin

Series: Thinking in Threads — Part 4 | ~13 min read

1. The Morning the Numbers Stopped Making Sense

It is 9 AM. The support team opens a ticket.

A user transferred ₹5,000 to a friend last night. The money left their account.

• It never arrived.

• No error was shown.

• No failure was logged.

• The transaction marked itself as successful.

The money didn’t go anywhere wrong. It simply — vanished. Updated into nothing.

• You open the codebase.

• The transfer logic is correct.

• The database write is there.

• The logs show success on both ends.

And yet — the balance on the receiving end never changed.

This is not a logic bug. This is not a network failure. This is a lost update — one of the two bugs this blog is about. And it is sitting in perfectly readable, logically correct Java code, completely invisible until the damage is done.

2. Two Bugs. One Root. Completely Different Symptoms.

Blog 3 introduced race conditions — the general category of problem that happens when threads access shared state without coordination.

Blog 4 goes one level deeper. Inside the world of race conditions, there are two specific bugs that developers encounter constantly and almost never correctly diagnose:

• The Lost Update — a write that gets overwritten before anyone sees it

• The Stale Read — a read that sees old data, long after the truth has changed

They feel different. They show up differently. They confuse you in different ways.

But they share one root cause — unprotected shared state on the heap.

Let’s meet them one at a time.

3. The Lost Update — Your Write Never Happened

The Story

Imagine a shared Google Doc. Two editors, working simultaneously.

• Editor A opens the document. It reads: “Meeting at 3 PM.”

• Editor B opens the same document at the same moment. Also reads: “Meeting at 3 PM.”

• Editor A changes it to: “Meeting at 4 PM.” Saves.

• Editor B changes it to: “Meeting cancelled.” Saves.

• Editor B’s save overwrites Editor A’s change completely.

• Editor A’s update — gone. Lost. As if it never happened.

Nobody deleted it intentionally. Nobody made a mistake. Two writers, one shared document, no coordination. One update lost forever.

In Java

public class SharedDocument {
    private String content = "Meeting at 3 PM"; // shared state on heap

    public void update(String newContent) {
        // step 1: read (implicit — we just overwrite)
        content = newContent; // step 2: write
    }
}

SharedDocument doc = new SharedDocument();

Thread editorA = new Thread(() -> doc.update("Meeting at 4 PM"));
Thread editorB = new Thread(() -> doc.update("Meeting cancelled"));

editorA.start();
editorB.start();

Whichever thread writes last — wins. The other update is gone.

Now make it slightly more realistic — a counter instead of a string:

public class VisitorCounter {
    private int count = 0;

    public void recordVisit() {
        int current = count;   // READ
        count = current + 1;   // WRITE
    }
}

Thread A reads count = 100
Thread B reads count = 100
Thread A writes count = 101
Thread B writes count = 101  ← Thread A's increment is lost

Two visits recorded. Counter moved by one. One update lost.

No exception. No log. Just a number that is quietly, consistently wrong — and getting more wrong with every lost update.

What Makes It a Lost Update Specifically

The lost update is an atomicity failure.

The operation — read, then write — must happen as one uninterrupted unit. When another thread steps into the gap between the read and the write, the first thread’s work is erased.

// This is NOT atomic — it is three steps with gaps between them
count++;

// Broken down:
int temp = count;      // gap here ← another thread can step in
temp = temp + 1;
count = temp;          // gap here ← another thread can overwrite this

The fix requires making the read-modify-write sequence atomic — uninterruptible. But that is Blog 5. For now, understand the shape of the problem.

4. The Stale Read — Seeing a World That No Longer Exists

The Story

You check the weather app at 7 AM. It says sunny. ☀️ ☀️ ☀️ ☀️ ☀️

You leave the house without an umbrella.

At noon it is raining. 🌧️ 🌧️ 🌧️ 🌧️

The weather changed at 9 AM. Your app — due to a caching issue — never fetched the update. You made a real-world decision based on data that was accurate once but had since become a lie.

That is a stale read. You read a value. The value was true when you read it. By the time you acted on it — it was wrong.

In Java

public class FeatureFlag {
    private boolean featureEnabled = false; // shared state on heap

    public void enable() {
        featureEnabled = true; // Thread B writes this
    }

    public void processRequest() {
        if (featureEnabled) { // Thread A reads this
            runNewFeature();
        } else {
            runOldFeature(); // Thread A keeps running old feature
        }                    // even after Thread B enabled the new one
    }
}

• Thread B calls enable(). Sets featureEnabled = true.

• Thread A calls processRequest(). Reads featureEnabled. Sees false.

• But — Thread B already set it to true. How is Thread A still seeing false?

Welcome to the visibility problem.

Why Thread A Sees Stale Data — The CPU Cache Problem

This is where the stale read gets genuinely interesting — and where most explanations stop being honest.

Modern CPUs don’t read directly from main memory on every operation. That would be too slow. Instead, each CPU core has its own cache — a small, fast local copy of memory values it has recently used.

Main Memory:   featureEnabled = true   ← Thread B wrote this

CPU Core 1 cache:  featureEnabled = false  ← Thread A reads THIS
CPU Core 2 cache:  featureEnabled = true   ← Thread B wrote here first

• Thread B runs on Core 2. Updates featureEnabled to true in Core 2’s cache. Eventually flushes to main memory.

• Thread A runs on Core 1. Has its own cached copy — still false. Never told to refresh it.

• Thread A reads stale data. Not because of a timing gap between steps. But because the update was never made visible to it.

This is a visibility failure — a completely different category from the lost update.

// Thread B sets this to true
private boolean featureEnabled = false;

// Thread A may never see the update
// because the JVM and CPU are not required
// to make writes visible across threads
// without explicit coordination

5. Atomicity Failure vs Visibility Failure — The Distinction That Matters

Most developers lump these together. They are not the same problem. They do not have the same solution.

// Atomicity failure — two threads, one shared counter
public void increment() {
    count++; // read-modify-write — not atomic — lost updates possible
}

// Visibility failure — one thread writes, another never sees it
private boolean running = true;

// Thread A:
while (running) { doWork(); } // may loop forever — never sees Thread B's write

// Thread B:
running = false; // written to cache, may never reach Thread A's view

Two different bugs. Both silent. Both produce wrong results. Both hide in plain sight.

6. Why They Feel Like Ghost Bugs 👻

Lost updates and stale reads share one brutal characteristic — they leave no evidence.

The lost update:

• No exception thrown

• No write failed — it succeeded, it just got overwritten

• Logs show the operation completed

• The data is just quietly wrong

The stale read:

• No exception thrown

• The read succeeded — it returned a value

• The value was accurate at some point in time

• The thread just never got the memo that reality changed

// This loop may run forever in production
// Works fine in single-threaded tests
// Works fine with certain JVM flags
// Breaks silently under specific CPU + JVM combinations

private boolean shutdown = false;

public void run() {
    while (!shutdown) { // reads stale 'false' forever
        processNextTask();
    }
}

public void stop() {
    shutdown = true; // written — but Thread A may never see it
}

You test this. It works. You ship it. A month later, under specific load on specific hardware, a thread refuses to stop. Support escalates. You add logs. The thread stops — because the log statement changed the timing. You conclude it was a fluke.

It was not a fluke.

“Ghost bugs are not random. They are deterministic bugs with non-deterministic triggers.”

7. Why These Bugs Survive Code Review

Here is the uncomfortable truth — these bugs are invisible to code review.

A reviewer reads this:

public void recordVisit() {
    count = count + 1;
}

The logic is correct. Addition is correct. The reviewer approves.

What the reviewer cannot see by reading:

• That count is on the heap

• That another thread is calling this simultaneously

• That the read and write are not atomic

• That one update will be lost under load

And this:

while (!shutdown) {
    processNextTask();
}

The logic is correct. The loop condition makes sense. The reviewer approves.

What the reviewer cannot see:

• That shutdown may be cached on a different CPU core

• That the write from another thread may never reach this thread’s view

• That this loop may never terminate

Code review catches logic bugs. It cannot catch timing bugs. It cannot catch visibility bugs. That is why these two live in production for months.

8. Connecting the Dots — Blog 1, 2, 3, 4

Let’s place this precisely in the map we have been building:

• Blog 1 — Thread safety is about protecting shared state at the moment of modification

• Blog 2 — Shared state lives on the heap. The stack is private and safe.

• Blog 3 — Race conditions happen when threads access shared heap state without coordination

• Blog 4 — Race conditions produce two specific bugs: lost updates (atomicity failure) and stale reads (visibility failure)

Shared heap state
       │
       ├── Multiple threads access without coordination
       │              │
       │    ┌─────────┴──────────┐
       │    │                    │
       │  Gap between          Write not
       │  read & write         made visible
       │    │                    │
       │  Lost Update          Stale Read
       │  (Atomicity)          (Visibility)

Every concurrency tool you will learn from Blog 5 onwards — synchronized, volatile, AtomicInteger, locks — is ultimately solving one or both of these two problems.

Understanding what you are solving before you reach for the tool is what separates a developer who uses concurrency from one who understands it.

9. No Fix Yet — Still Intentional

Three blogs in a row now. No solution introduced.

That is by design.

• The lost update needs atomicity — the guarantee that a compound operation completes without interruption.

• The stale read needs visibility — the guarantee that a write made by one thread becomes visible to other threads.

• These are two distinct guarantees. They require different tools.

• Using the wrong tool for the wrong problem is how developers create new bugs while trying to fix old ones.

Blog 5 introduces synchronized — what it actually guarantees, what it does not, and precisely which of these two problems it solves and how.

“Name the problem before you name the solution. Always.”

Let’s Connect

If this was useful, consider sharing it with someone who’s on the same journey.

Subscribe now

Let’s keep learning together!

Have a question or a topic you’d like me to cover? Drop a comment below — I read every one.

Leave a comment

Nitin
Hashnode | Substack | LinkedIn | Youtube | Instagram | GIT | Topmate

Share Level Up Your Programming with Nitin

Series: Thinking in Threads — Part 3 | ~13 min read

Subscribe now

1. The Illusion of Correctness

The code works.

• Tests pass.

• Green across the board.

• Logs look clean.

• No exceptions.

• No warnings.

• You deploy.

• You move on.

And then — three days later — a number is wrong somewhere.

• A record is missing.

• A balance doesn’t add up.

• Someone files a ticket.

• You open the code.

• You read it line by line.

• The logic is correct.

• You run it locally.

• It works perfectly.

• You close the ticket.

• Mark it as “cannot reproduce.”

It happens again.

The most dangerous bugs are not the ones that fail every time — but the ones that fail only sometimes.

This is what a race condition feels like from the outside. Not a crash. Not an error. Just a quiet, occasional wrongness that makes you question your own code — and sometimes your own sanity.

2. Let’s Count to Ten — Together

No Java yet. Just two people and a whiteboard.

A number is written on the whiteboard: 0

Nitin and Shikha are both tasked with incrementing that number — each of them ten times. Simple job. Expected result: 20.

Here is what each increment actually involves:

• Read the current value from the whiteboard

• Add 1 to it in your head

• Write the new value back to the whiteboard

Nitin walks up. Reads 0. Computes 1. Writes 1. ✅

Shikha walks up. Reads 1. Computes 2. Writes 2. ✅

So far so good. But now — they both walk up at the same time.

• Nitin reads 14. Shikha reads 14.

• Nitin computes 15. Shikha computes 15.

• Nitin writes 15. Shikha writes 15.

Two increments happened. The whiteboard moved by one.

They finish all twenty increments. The whiteboard shows 17. Sometimes 16. Sometimes 18. Never reliably 20.

• Nobody made an arithmetic mistake.

• The logic was correct.

• The result is wrong.

This is a race condition.

3. What Just Happened?

“No one made a mistake. And yet the result is wrong.”

This is the part that makes race conditions so disorienting.

• You look at the code — the logic is sound.

• You look at the result — it is broken.

The gap between those two realities is where the race condition lives.

Here is the same story in Java:

public class Counter {
    private int count = 0; // shared state — lives on the heap

    public void increment() {
        count++; // looks like one operation. it is not.
    }

    public int getCount() {
        return count;
    }
}

public class Main {
    public static void main(String[] args) throws InterruptedException {
        Counter counter = new Counter();

        Thread nitin  = new Thread(() ->  {
            for (int i = 0; i < 10; i++) 
                 counter.increment();
        });
        Thread shikha = new Thread(() -> {
            for (int i = 0; i < 10; i++) 
                 counter.increment();
        });

        nitin.start();
        shikha.start();
        nitin.join();
        shikha.join();

        System.out.println("Final count: " + counter.getCount());
        // Expected: 20
        // Actual:   17? 18? 19? Depends on the day.
    }
}

Run this. Run it again. Run it ten times. You will get different answers. Same code. Same input. Different results.

That is a race condition. And that single line — count++ — is where it lives.

If you run this locally and always get 20 — increase the loop count to 100,000. With only 10 iterations, threads finish too fast to collide. The race condition exists, it just needs more pressure to show itself. That is exactly what makes it dangerous in production.

4. The Core Problem — The Gap Between Steps

count++ looks like one operation. In your source code, it is one line.

At the bytecode level, it is three separate steps:

1. READ  — load current value of count from heap into thread's working memory
2. MODIFY — add 1 to the loaded value
3. WRITE  — store the updated value back to heap

// What you write:
count++;

// What actually happens: under the hood
int temp = count;      // step 1: READ
temp = temp + 1;       // step 2: MODIFY
count = temp;          // step 3: WRITE

“The problem is not in the steps — but in the gap between them.”

Another thread can step in between any of these three steps. It can read the old value before the write happens. It can overwrite a result that another thread just computed. The window is tiny — microseconds — but at scale, with thousands of operations per second, it gets hit constantly.

5. Two Classic Patterns — Interview Gold

Race conditions always fall into one of two patterns.

Learn these. You will see them everywhere.

🔹 Read-Modify-Write

Read a value. Change it. Write it back.

// counter++ is the textbook example
count++;

// So is this:
balance = balance + deposit;

// And this:
retryCount = retryCount + 1;

Any operation that reads shared state, computes something, and writes back — is a read-modify-write. If two threads do this simultaneously without coordination, one update gets lost.

“These operations look atomic but They are not.”

🔹 Check-Then-Act

Check a condition. Assume it is still true. Act on it.

// Looks safe. Is not.
if (balance > 0) {
    withdraw(amount); // another thread may have withdrawn between the check and this line
}

// Another classic:
if (!map.containsKey(key)) {
    map.put(key, value); // another thread may have inserted the same key already
}

The check and the act are two separate steps. Another thread can change the world between them. By the time you act, the condition you checked is no longer true.

“The gap between checking and acting is where the race lives.”

6. Why It Is Non-Deterministic

Here is what makes race conditions genuinely hard to reason about:

• Threads run independently

• The CPU scheduler decides which thread runs when

• That decision changes based on system load, available cores, OS state

• You have zero control over it

The same code, on the same machine, with the same input — can produce different results on different runs.

// Monday morning, low load:
Final count: 19  ✅ (close enough, you don't notice)

// Friday afternoon, heavy load:
Final count: 14  ❌ (someone notices)

// During a demo:
Final count: 20  ✅ (of course it works now)

The race condition was always there. The timing just didn’t expose it until it did.

This is why race conditions survive code review. The reviewer reads the logic — the logic is correct. Nobody is reading for timing gaps. Nobody is imagining two threads stepping on each other between lines.

7. Why You Cannot Reproduce It Easily

This is the section every senior developer will nod at.

“It works on my machine.”

Of course it does. Locally, you have one or two threads. The load is low. The operations complete so fast the window for collision almost never opens. The race condition exists — it just rarely gets triggered.

In production:

• Hundreds of threads, running simultaneously

• High load, slower operations, longer gaps between steps

• The collision window opens constantly

And then — you try to debug it.

You add a log statement:

public void increment() {
    System.out.println("before: " + count); // added for debugging
    count++;
    System.out.println("after: " + count);
}

The bug disappears. ✨

Not because the log fixed anything. Because logging slows the thread down. The extra time spent writing to the log changes the timing. The collision window closes. The threads stop stepping on each other.

You remove the log. Bug comes back.

“The act of observing the bug changes its behavior.”

This is not mysticism. It is physics. Every tool you use to observe the system — logging, breakpoints, profilers — changes the thread scheduling. The bug hides. The moment you stop looking, it returns.

8. Why This Is Dangerous ☠️

Let’s be precise about what makes this category of bug genuinely serious:

• ❌ No exception is thrown

• ❌ No crash occurs

• ❌ Nothing appears in your logs

• ❌ Your monitoring shows green

• ✅ The data is silently, consistently wrong

A NullPointerException is a good bug. It tells you where it happened, when it happened, and what caused it. You fix it in an hour.

A race condition is a ghost. It corrupts data quietly. It leaves no evidence. The damage accumulates — wrong balances, duplicate records, missed updates — until someone manually checks the numbers and realizes something is deeply wrong.

By then, the cause is buried under millions of subsequent operations.

This is what Blog 1 meant by:

“Your program is lying to you — and you don’t even know it.”

9. What Developers Do Wrong

When a race condition is suspected, the instinct is almost always wrong:

• Add more logs — changes the timing, bug hides, you conclude its fixed

• Add retry logic — retrying a corrupt operation just corrupts it more reliably

• Blame the environment — “must be a network issue,” “staging behaves differently”

• Add a sleep() — this one is special. It sometimes works. Which makes it worse — you’ve hidden the bug under a timing band-aid that will fail under different load.

// Please never do this
public void increment() {
    Thread.sleep(10); // "fixed" the race condition by hoping threads don't overlap
    count++;
}

“You cannot fix a race condition by observing it. You fix it by understanding it.”

The only real path forward is understanding exactly what is racing, where the gap is, and what coordination mechanism closes it.

That coordination — the fix — is not this blog.

This blog’s job is to make the problem undeniable.

10. No Fix Yet — And That Is Intentional

This blog deliberately ends without a solution.

No synchronized. No locks. No AtomicInteger. Nothing.

Because before you reach for a tool, you need to see the problem with absolute clarity. Developers who jump to synchronized without understanding race conditions add it in the wrong places, miss the actual critical section, and create new problems — deadlocks, performance collapse, false safety.

“Before you control the system, you must first see the problem clearly.”

The fix comes in Blog 5. Between now and then — sit with the discomfort. That discomfort is the beginning of real understanding.

11. Connecting Back — Stack, Heap, Race

From Blog 2 — the heap is shared territory. The stack is private.

Race conditions only happen on the heap:

public void increment() {
    int temp = count;  // 'temp' → stack → private → safe
    temp = temp + 1;   // computation → stack → safe
    count = temp;      // 'count' → heap → shared → THIS is where the race happens
}

The stack operations are completely safe. Each thread has its own temp. No conflict possible there.

The single write back to count on the heap — that is the entire problem.

“Threads don’t race over logic. They race over shared data.”

Every race condition you will ever encounter traces back to this: shared mutable state on the heap, accessed by multiple threads, with a gap between the read and the write.

12. One Line to Remember

“Race conditions are not bugs in your logic — they are bugs in your timing.”

Your logic can be perfectly correct. Your algorithm can be sound. And your program can still produce wrong results — because the order in which threads execute those correct steps is unpredictable.

That is the nature of the race. And that is why it deserves its own blog before any solution is introduced.

💼 Crack the Interview 🎯

Q: What is a race condition?

A race condition occurs when the correctness of a program depends on the relative timing or interleaving of multiple threads. When two or more threads access shared state simultaneously — and at least one of them modifies it — the outcome varies depending on which thread executes first. The result is non-deterministic and often incorrect.

Q: Why is a race condition non-deterministic?

Because thread scheduling is controlled by the operating system and the JVM, not by your code. The order in which threads execute their operations changes based on system load, available CPU cores, and OS scheduling decisions. The same code, with the same input, can produce different results on different runs — or even on the same run at different times.

Q: What is the difference between check-then-act and read-modify-write?

Both are compound operations that appear atomic but are not:

• Read-modify-write — read a value, change it, write it back. Example: count++. The danger is that another thread can read the old value between the read and the write.

• Check-then-act — check a condition, then act based on it. Example: if (balance > 0) withdraw(). The danger is that another thread can change the state between the check and the action.

Both patterns create a gap — a window in time — where another thread can step in and corrupt the result.

Q: Why are race conditions hard to debug?

Three reasons:

• They are non-deterministic — they don’t fail consistently, so they’re hard to trigger on demand

• They are observer-sensitive — adding logs, breakpoints, or profilers changes thread timing and hides the bug

• They leave no evidence — no exception, no crash, just silently wrong data

The very act of trying to observe the bug changes its behavior, making traditional debugging techniques ineffective.

Let’s Connect

If this was useful, consider sharing it with someone who’s on the same journey.

Subscribe now

Let’s keep learning together!

Have a question or a topic you’d like me to cover? Drop a comment below — I read every one.

Leave a comment

Nitin
Hashnode | Substack | LinkedIn | Youtube | Instagram | GIT | Topmate

Share Level Up Your Programming with Nitin

The Moment I Realised I Had Been Thinking About It Wrong

Twelve years into software engineering, I thought I understood threading.

I had used synchronized. I had written thread pools. I had debugged race conditions at 2 AM in production. I had read articles, watched talks, followed tutorials. I could answer the standard interview questions without hesitation.

And yet — something always felt incomplete.

Every resource I found said the same things. Use synchronized. Use volatile. Use ReentrantLock. Here is the syntax. Here is an example. Here is a quiz.

Nobody was explaining why.

Why does a race condition happen in the first place? Not the definition — the actual mechanical reason.

What is physically happening inside the JVM when two threads corrupt shared data? Why does volatile not give you thread safety even though it sounds like it should?

Why does synchronizing everything make things worse instead of better?

I kept finding answers to what. Nobody was giving me answers to why.

So I went deeper. I read the papers. I read the specs. I read the book that the entire Java concurrency ecosystem quietly considers its bible — Java Concurrency in Practice by Brian Goetz. Dense, precise, uncompromising. The kind of book that rewards patience with permanent clarity.

And something clicked.

Threading is not about locks. Threading is not about synchronized. Threading is not about any keyword or API.

Threading is about state. And who can touch it. And when.

Everything else — every keyword, every tool, every pattern — is just a consequence of that one idea. Once that idea is clear, the entire landscape of Java concurrency stops being a collection of rules to memorise and becomes a single coherent system to understand.

That realisation took me years to reach.

This series is my attempt to give it to you in fifteen blogs.

Why Most Concurrency Content Fails You

Search for Java threading content. You will find the same ten topics, explained the same way, on every platform.

• “Here is how synchronized works.”

• “Here is the difference between wait() and notify().”

• “Here is how to use a thread pool.”

Useful. Accurate. And completely insufficient.

Because they all start in the middle of the story.

They teach you the tools before you understand the problem. They show you synchronized before you truly feel why unprotected shared state is dangerous. They explain volatile before you understand CPU caches and why a write on one core might never reach another. They introduce locks before you have felt the weight of what happens when coordination goes wrong.

The result is developers who can use the tools but cannot reason about them. Developers who add synchronized to a method and feel safe — without knowing whether they protected the right thing. Developers who reach for volatile because it sounds like it should help — without understanding that it solves a visibility problem but does nothing for atomicity. Developers who over-synchronize everything and then wonder why their concurrent program is slower than the sequential one it replaced.

I was that developer for longer than I would like to admit.

The problem is not intelligence. The problem is sequence. Concurrency concepts taught out of order produce confusion that looks like understanding.

“You cannot use a tool correctly if you do not understand what problem it was designed to solve.”

What This Series Does Differently

This series starts at the beginning. The actual beginning.

Not with synchronized. Not with thread pools. Not with any API at all.

It starts with a question: why does sequential thinking break the modern world? And it builds from there — one concept at a time, each one earning its place by solving a problem the previous blog created.

By the time you reach the tools, you will understand what they are solving. By the time you see synchronized, you will have felt the race condition it prevents. By the time you see volatile, you will have understood CPU caches and why visibility is a separate problem from atomicity. By the time you reach CompletableFuture, you will understand the entire chain of limitations that made it necessary.

This is the series I wish had existed when I started.

The Philosophy Behind Every Blog

Three principles guide every word written here.

Feeling before fixing.

Every problem in this series is introduced before its solution. You will spend three blogs understanding race conditions, lost updates, and stale reads — before a single fix is shown. This is intentional. A solution without a felt problem is just syntax. A solution that follows genuine understanding becomes intuition.

Analogy before abstraction.

Every technical concept in this series is grounded in a real-world story first. Not because the technical details don’t matter — they do, deeply — but because the human brain understands new ideas by mapping them to things it already knows. The analogy is not a simplification. It is the fastest path to the abstraction.

Precision over completeness.

This series does not cover everything. It covers what matters — in the right order, with the right depth, without the noise. Twelve years of software engineering has taught me that clarity is harder than comprehensiveness. Anyone can write an exhaustive reference. The harder thing is knowing what to leave out.

A Word About the Book That Influenced This Series

There is one book in the Java ecosystem that stands apart from everything else written about concurrency.

Java Concurrency in Practice — written by Brian Goetz and a team of engineers who actually built parts of the Java concurrency library — is the most precise, honest, and complete treatment of this subject that exists. It does not simplify. It does not hand-hold. It treats the reader as an engineer capable of handling the full truth.

I have learned more about threading from that book than from any other single source in my career.

This series is not that book. It does not try to be. JCIP is the definitive reference — thorough, dense, and written for engineers who are ready for that level of rigor.

This series is the bridge that makes you ready for it.

If JCIP is the mountain — this series is the trail that gets you to base camp. From there, the summit is yours to climb.

I owe that book a debt this series can only partially repay.

Who This Is For

This series is for the Java developer who:

• Has used threading but never fully understood it

• Can write synchronized but is not sure if they are putting it in the right place

• Has debugged a race condition by adding a log statement — and watched the bug disappear

• Has read about volatile three times and still is not confident about when to use it

• Is preparing for a senior engineering interview and wants to actually understand concurrency, not just memorise answers

• Has been in software for years and suspects there is a cleaner mental model underneath all the rules — and wants to find it

If any of that resonates — this series was written for you.

What Twelve Years Taught Me About Threading

I have worked across systems of very different scales. Small services. High-throughput pipelines. Real-time systems where a missed update costs money. Systems where a stale read caused a wrong decision that took days to trace back to its source.

Threading problems do not care how senior you are. They do not care how carefully you wrote the code. They care about one thing: did you understand what you were protecting, and did you protect it correctly?

Most threading bugs are not caused by ignorance of the tools. They are caused by a misunderstanding of the problem. A developer who does not know about synchronized will not use it — and the bug is obvious. A developer who knows about synchronized but does not understand what to protect will use it in the wrong place — and the bug is invisible.

The invisible bugs are the dangerous ones.

“The most expensive bugs in concurrent programming are the ones written by developers who thought they understood threading.”

This series is about closing the gap between thinking you understand threading and actually understanding it. Not through intimidation. Not through exhaustive coverage of every edge case. But through a careful, patient build — from the first question to the complete mental model.

Twelve years of experience distilled into fifteen blogs.

No filler. No hand-waving. No false confidence.

Just the concepts, in the right order, explained the right way.

The Map — What We Will Cover

Here is the journey, in order:

• Blog 1 — The Need: Why Sequential Thinking Breaks the Modern World What is multithreading, why Java needs it, what is thread safety, why thread safety is needed, state vs behavior, stale data, stack-per-thread insight, the synchronized myth.

• Blog 2 — The Battlefield: Heap, Stack, and Why Threads Fight Over Memory Deep dive into JVM memory model — what lives on the stack, what lives on the heap, why shared heap is the root of all concurrency problems. Visualized through story.

• Blog 3 — Race to Disaster: Understanding Race Conditions What is a race condition, how it happens, real-life analogies, why it is non-deterministic, why it is hard to reproduce. No fix yet — just deep understanding of the problem.

• Blog 4 — The Lost Update and the Stale Read: Two Bugs That Hide in Plain Sight Lost updates, stale data, visibility problems. The difference between atomicity failures and visibility failures. Why they feel like ghost bugs.

• Blog 5 — The Lock on the Door: Synchronized, Intrinsic Locks, and Critical Sections What synchronized means, what an intrinsic lock is, what a critical section is, synchronized method vs synchronized block, the performance trap of over-synchronization. All terms introduced and used interchangeably here.

• Blog 6 — The Deadlock Trap: When Threads Wait Forever What is deadlock, the four conditions that cause it, real-life story analogy, how to recognize it, how to avoid it. Livelock and starvation introduced here too.

• Blog 7 — Volatile: The Keyword Nobody Explains Properly CPU caches, memory visibility, what volatile guarantees, what it does not guarantee, when to use it, when not to. Common misconceptions cleared.

• Blog 8 — Atomic Operations: When You Need More Than Volatile What atomicity means, why volatile is not enough for compound operations, AtomicInteger, AtomicReference, compare-and-swap explained through analogy.

• Blog 9 — The Wait and Notify Dance: Thread Communication the Old Way wait(), notify(), notifyAll(), the producer-consumer problem, why this mechanism exists, why it is tricky to use correctly.

• Blog 10 — Stop Creating Threads Like Objects: The Thread Pool Philosophy Cost of raw thread creation, what a thread pool is, ExecutorService, fixed vs cached pools, why pooling is the real-world standard.

• Blog 11 — Callable, Future, and the Art of Getting Something Back Runnable vs Callable, what Future is, blocking with get(), timeouts, limitations of Future, real-life token analogy.

• Blog 12 — Locks Grown Up: ReentrantLock, ReadWriteLock, and Friends java.util.concurrent.locks, ReentrantLock vs synchronized, fairness, tryLock, ReadWriteLock for read-heavy scenarios. When to graduate from synchronized.

• Blog 13 — Counting Down to Action: CountDownLatch, CyclicBarrier, and Semaphore What coordination utilities are, CountDownLatch explained through story, CyclicBarrier, Semaphore, Phaser introduced. Real-world use cases for each.

• Blog 14 — CompletableFuture: Writing Async Code That Reads Like a Story CompletableFuture, thenApply, thenCompose, exceptionally, async pipelines, why this is the modern way to write non-blocking code.

• Blog 15 — The Full Mental Model: Everything You Need to Ace the Interview Room Complete recap, mental decision framework, when to use what, the most common interview questions mapped back to concepts from every blog, Gumroad-ready summary.

Each blog builds on the last. Reading them out of order is possible. Reading them in order is better.

One Last Thing Before Blog 1

Threading is one of those topics where partial understanding is more dangerous than no understanding.

A developer who knows nothing about threading will write single-threaded code. It will be slow. But it will be correct.

A developer who knows a little about threading will add locks and threads without a complete mental model. The code will be concurrent — and occasionally, unpredictably, silently wrong.

A developer who truly understands threading will write code that is both concurrent and correct. Not by following rules — but by understanding the system well enough to reason about it from first principles.

That third developer is who this series is trying to build.

It will take fifteen blogs. It will take patience. It will take the willingness to sit with a problem before reaching for a solution.

But at the end — you will not just know how to use Java’s concurrency tools. You will understand why they exist, what problems they solve, and exactly when and how to use them correctly.

That understanding is what separates a developer who has used concurrency from one who commands it.

Let’s begin.

— Nitin

Hashnode | Substack | LinkedIn | Youtube | Instagram | GIT | Topmate

Blog 1: The Need: Why Sequential Thinking Breaks the Modern World

Series: Thinking in Threads | Blog: 2 | Read time: ~16 min

1. The Battlefield You Never See

A busy railway control room. Two signal operators, working independently at their stations.

Operator A checks the track status board — it reads “clear.” He approves Train 1 to proceed.

At the exact same moment, Operator B checks the same board — it also reads “clear.” She approves Train 2 to proceed.

Both operators followed procedure perfectly. Both read the correct status. Both made the right call — based on what they saw.

Two trains. One track. No error thrown by either operator.

Nobody made a mistake. Nobody cut corners. The system failed — because two independent workers read and acted on the same shared data simultaneously, with no coordination between them.

This is exactly what happens inside your JVM the moment two threads access the same object.

2. Pause and Ask the Right Question

Here is a thought most developers skip past:

If threads are independent workers… why do they conflict at all?

The answer is not about threads. It is not about speed. It is not about scheduling.

The problem is memory.

Specifically — where your data lives, and who can reach it.

Shift your mental model here. Stop thinking about threads as the problem. Start thinking about memory as the battlefield. Threads are just the soldiers. The heap is where the war happens.

3. Where Data Actually Lives

When your Java program runs, the JVM carves up memory into regions. You don’t need to know all of them. You need to know two:

• The Stack — private, per thread, fast

• The Heap — shared, global, dangerous when unprotected

Everything else is detail. These two are the entire story of thread safety.

4. The Stack — Your Private Workspace

Every thread in Java gets its own stack. Completely private. Completely isolated.

Think of it like a personal notepad that each worker carries. Whatever they write on it — nobody else can see it, touch it, or overwrite it.

What lives on the stack:

• Method calls — every time you call a method, a new frame is pushed onto the stack

• Local variables — any variable declared inside a method

• Return addresses — where to go after a method finishes

public void processPayment(int amount) {
    int tax = calculateTax(amount); // 'tax' lives on THIS thread's stack
    int total = amount + tax;       // 'total' lives on THIS thread's stack
    System.out.println(total);
    // method ends → stack frame is popped → tax and total are gone
}

tax and total are born on the stack. They die when the method ends. No other thread can see them during their entire lifetime.

The insight: This is exactly why local variables are naturally thread-safe. There is no sharing happening. There is nothing to protect.

Two threads can call processPayment() simultaneously — each thread works on its own copy of tax and total on its own private stack. They never collide.

5. The Heap — The Shared Battlefield

Now here is where everything changes.

When you create an object in Java — any object — it goes on the heap. Not your stack. Not any one thread’s private space. The shared heap. Accessible by every thread in your program.

public class BankAccount {
    private int balance; // instance variable → lives on the HEAP
    private String owner; // instance variable → lives on the HEAP
}

// Somewhere in your application
BankAccount account = new BankAccount(); // object created on the HEAP

What lives on the heap:

• All objects you create with new

• Instance variables — the fields inside those objects

• Static variables — shared across the entire application

The moment that BankAccount object sits on the heap, every thread that holds a reference to it can walk in and read or modify balance freely.

No permission needed. No check. No warning. Just open access.

This is where all concurrency problems begin. Not in your methods. Not in your logic. In the heap — the shared territory that every thread can touch.

6. Why Threads Fight — Step by Step

Let’s make this concrete. No hand-waving.

Here is a BankAccount with a shared balance on the heap:

public class BankAccount {
    private int balance = 10000; // on the heap — shared
    
    public void deposit(int amount) {
        int current = balance;          // step 1: READ from heap
        int updated = current + amount; // step 2: COMPUTE (on stack)
        balance = updated;              // step 3: WRITE back to heap
    }
}

Now two threads call deposit() simultaneously — Thread A deposits 2000, Thread B deposits 3000:

Thread A → step 1: reads balance = 10000
Thread B → step 1: reads balance = 10000  ← both read the OLD value

Thread A → step 2: computes 10000 + 2000 = 12000
Thread B → step 2: computes 10000 + 3000 = 13000

Thread A → step 3: writes balance = 12000
Thread B → step 3: writes balance = 13000  ← overwrites Thread A's update

Final balance: ₹13,000 Correct balance: ₹15,000 Lost forever: ₹2,000

• What did Java throw? Nothing.

• What crashed? Nothing.

• What was logged? Nothing.

Just a silently wrong number sitting in your database. This is the nature of concurrency bugs — they don’t announce themselves. They hide.

7. Thread-Local vs Shared Data

This is the line that cuts through all confusion:

Stack → thread-local → private → safe
Heap → shared → accessed by all threads → needs protection

public class PaymentProcessor {
    private int transactionCount = 0; // HEAP — shared — needs protection

    public void process(double amount) {
        double fee = amount * 0.02;   // STACK — local — already safe
        double total = amount + fee;  // STACK — local — already safe

        transactionCount++;           // HEAP — shared — danger zone
    }
}

fee and total — born on the stack, private to this thread call, zero risk.

transactionCount — lives on the heap, every thread touches the same variable, race condition waiting to happen.

Thread safety is only ever about shared data. Nothing else.
If data is not shared, you don’t have a thread safety problem. Full stop.

8. Connecting Back to Blog 1

In Blog 1, we talked about state and behavior.

Now you know exactly where each one lives:

• Behavior — your methods, your logic, your algorithms.
  These execute on the stack. Each thread gets its own execution context.
  No sharing. No conflict.

  This is why behavior alone is safe.

• State — your instance variables, static variables, your object fields.
  These live on the heap and are shared across threads that access them.

  This is where conflict lives.

“Threads don’t fight over logic. They fight over data.”

When a thread calls a method, it is not fighting over the method itself. It is fighting over the heap data that method touches. The method is just the path that leads to the battlefield.

This single distinction — stack for execution, heap for shared state — is the foundation that every concurrency concept in this series builds on.

9. The Real Root Cause

Let’s be precise about what the actual problem is — because most developers misdiagnose it.

The problem is NOT:

• Threads existing

• Threads running fast

• Threads being scheduled unpredictably

The problem IS:

• Shared mutable state sitting on the heap with no coordination around who reads and writes it

Remove shared mutable state — the problem disappears. That is why stateless classes are always thread-safe. That is why local variables are always safe. That is why immutable objects are safe.

The thread is not your enemy. Unprotected shared state is.

10. The Mistake Most Developers Make

When developers first hit a concurrency bug, the instinct is to control the threads.

“Maybe I should slow them down.” “Maybe I should use fewer threads.” “Maybe I should change the thread priority.”

Wrong direction entirely.

The threads are not the problem. Trying to control threads to fix a memory problem is like rearranging traffic signals to fix a broken road. The road is what needs fixing.

Control memory access — not threads.

Decide who can read shared data, when, and under what conditions. That is the entire discipline of concurrent programming, distilled.

Everything — synchronized, volatile, locks, atomic variables — every tool this series will cover is ultimately a tool for controlling access to shared heap memory. Not for controlling threads.

“Everything still comes back to shared state.”

You will see this pattern repeat across every blog in this series. Every concurrency problem, every solution, every tool — traced back to this one root: shared mutable data on the heap, accessed by multiple threads without coordination.

Let’s Stay Connected

If you found this helpful, stay connected — Through Level Up Your Programming with Nitin, I share guides, insights, and live coding sessions to help you grow as a developer.
Let’s keep learning together!

Feel free to like, comment, or share your thoughts below — I’d love to hear how your Java journey is going.

Nitin
Hashnode | Substack | LinkedIn | Youtube | Instagram | GIT | Topmate

Prev — The Battlefield: Heap, Stack, and Why Threads Fight Over Memory — Next

Series: Thinking in Threads | Blog: 1 | Read time: ~14 min

TL;DR — Read This First

• A thread is one independent path of execution. Multithreading means many paths running simultaneously.

• Thread safety is not about locking everything. It is about protecting shared data at the exact moment it is modified.

• The real danger lives on the heap — shared objects that multiple threads can read and write at the same time.

• Local variables on the stack are already safe. You don’t need to protect them.

• Making everything synchronized doesn’t make your program safer — it makes it slower. Sometimes broken in new ways.

• The correct instinct is surgical, not sweeping.

You wear a helmet while riding — not bubble wrap

You wear a helmet while riding — not because the road is dangerous every second, but because when an accident happens, your head needs to be protected at that exact moment of impact.

That is road safety. Not wrapping yourself in bubble wrap before leaving the house. Not refusing to ride at all. Just protecting the right thing, at the right moment.

Thread safety in Java works exactly the same way.

And yet, the most common advice you will hear is this:

“Just add synchronized to your methods and you’re safe.”

Most developers follow that advice without questioning it. Most of them don’t realize what they are actually supposed to be protecting.

Here is the precise rule:

• ✅ Protect class level variables — the class-level state that lives on the heap and is shared between threads

• ✅ Protect them at the exact moment they are being modified

• ❌ Don’t protect local variables — they live on each thread’s own private stack and are already safe

• ❌ Don’t protect the entire method — methods are behavior, not data

synchronized is not a safety blanket. It is a surgical tool. Used in the wrong place, it doesn’t make your program safer — it makes it slower, harder to reason about, and in some cases, broken in entirely new ways.

This series is about learning to use that tool correctly.

1. First, Feel the Problem

It is a warm afternoon. A classroom. Forty students, one teacher.

She is brilliant. She cares. She answers every question fully, then moves to the next student. One at a time. No shortcuts.

By the time she reaches student twenty-eight, the question has gone cold. Student thirty-five has already moved on — possibly with the wrong understanding. Student forty has stopped paying attention entirely.

The teacher did nothing wrong. The system failed her.

One worker. Sequential flow. A world that doesn’t wait.

Sound familiar? That teacher is your Java program. Those forty students are your users. And in production, your users don’t wait politely in a queue.

2. Sequential Execution Is a Lie We Tell Beginners

When you learn to code, you’re taught that a program runs top to bottom. One line, then the next. One method, then the next. Neat, orderly, predictable.

That model is true. It is also dangerously incomplete.

It works for:

• A script that reads a file and prints a result

• A utility that processes one record and exits

• A hello-world program you submit for grading

It breaks completely the moment your program has to:

• Serve ten thousand users simultaneously

• Process hundreds of transactions per second

• Keep a UI alive while something heavy runs in the background

Sequential execution in the real world isn’t careful —
it’s slow. And in production, slow is just another form of broken.

3. What Multithreading Actually Is

No jargon. Three lines:

• A thread is a single path of execution. One worker, following instructions from start to finish.

• A single-threaded program has one path. One worker. Everything waits for everything else.

• A multithreaded program has many paths. Many workers. Each moves forward independently.

Think about a restaurant kitchen during dinner service. The pasta is boiling. The sauce is reducing. The garnish is being plated. Three different hands, three different tasks, all moving simultaneously. Nobody waits for anyone else to finish before they begin.

That is multithreading. Your program becomes the kitchen instead of the lone cook.

Here is what that looks like in Java — the simplest possible thread creation:

// Single-threaded: everything runs on main thread
public class SingleThreaded {
    public static void main(String[] args) {
        cookPasta();   // waits to finish
        makeSauce();   // waits to finish
        plateGarnish();// waits to finish
    }
}

// Multithreaded: tasks run simultaneously
public class MultiThreaded {
    public static void main(String[] args) throws InterruptedException {
        Thread pastaThread   = new Thread(() -> cookPasta());
        Thread sauceThread   = new Thread(() -> makeSauce());
        Thread garnishThread = new Thread(() -> plateGarnish());

        pastaThread.start();
        sauceThread.start();
        garnishThread.start();

        pastaThread.join();
        sauceThread.join();
        garnishThread.join();

        System.out.println("Dinner is served.");
    }
}

Notice: .start() launches the thread. .join() waits for it to finish. Three workers, moving in parallel.

4. Why Java Specifically Needs This

Three reasons. Each more important than the last.

Performance — use the hardware you already have

• Your machine has multiple CPU cores. A single-threaded program uses one. The rest sit idle.

• You bought an eight-burner stove and you are cooking on one flame.

• A task that takes 8 seconds on one core can take ~1 second split intelligently across eight.

Responsiveness — never freeze the user again

• Without multithreading, one slow operation freezes everything.

• A file download freezes the UI. A database call freezes the server.

• With threads, slow operations move to the background while everything stays alive.

Modern systems demand it — there is no alternative

• A server handling thousands of simultaneous requests cannot queue them one at a time.

• A message broker consuming events from multiple topics cannot stop and wait.

• Build without concurrency and you haven’t built a slower version of the right thing. You’ve built the wrong thing.

// Without multithreading — UI freezes during file download
public void downloadFile() {
    // This blocks the main thread. Nothing else can run.
    byte[] data = fetchFromServer(); // could take 10 seconds
    saveToFile(data);
}

// With multithreading — UI stays alive
public void downloadFileAsync() {
    new Thread(() -> {
        byte[] data = fetchFromServer();
        saveToFile(data);
        System.out.println("Download complete.");
    }).start();
    // Main thread is free immediately. UI responds. User is happy.
}

5. And Then Everything Gets Complicated

The moment two threads need to touch the same data — the same variable, the same object, the same piece of memory — something fundamental breaks.

Not always. Not predictably. Sometimes. Randomly. Silently.

And that is what makes it dangerous.

6. The Notebook Story You Won’t Forget

Forget Java for a moment.

Priya and Arjun share a notebook. Inside it, one number — ₹10,000. Their joint account balance.

One afternoon:

• Priya opens the notebook. Reads ₹10,000. She needs to add ₹2,000. She does the math in her head: ₹12,000.

• At the exact same moment, Arjun opens the same notebook. Reads ₹10,000. He needs to add ₹3,000. His math: ₹13,000.

• Priya writes ₹12,000.

• Arjun writes ₹13,000.

One write erases the other. The notebook shows either ₹12,000 or ₹13,000 — depending purely on who wrote last.

The correct answer is ₹15,000.

Nobody made an arithmetic mistake. Nobody acted carelessly. Two workers. Same data. No coordination. One update lost forever.

Now read this Java code and notice — it is the exact same story:

public class BankAccount {
    private int balance = 10000; // shared state — lives on the heap

    public void deposit(int amount) {
        int current = balance;       // step 1: read
        int updated = current + amount; // step 2: compute
        balance = updated;           // step 3: write
    }
}

When Thread A (Priya, +2000) and Thread B (Arjun, +3000) call deposit() simultaneously:

Thread A reads  balance = 10000
Thread B reads  balance = 10000   ← both read the same old value
Thread A writes balance = 12000
Thread B writes balance = 13000   ← Thread A's update is gone

Final balance: ₹13,000. Lost ₹2,000. No exception. No stack trace. The program moves on.

This is a race condition. This is why thread safety exists.

7. What Thread Safety Actually Means

Not this: “my code has no bugs.” Not this: “my code won’t crash.”

This, specifically:

Your code produces correct results even when multiple threads are running and touching shared data at the same time.

That is the entire definition. Keep it.

8. The Trap That Kills Performance

When developers first understand the race condition problem, the instinct is immediate — and completely wrong:

“Fine. I’ll just make everything synchronized. One thread at a time. Problem solved.”

This is the most common and most costly mistake in concurrent Java programming.

Here is what over-synchronization looks like:

// ❌ Wrong approach — synchronizing everything
public class BankAccount {
    private int balance = 10000;

    public synchronized int getBalance() { return balance; }
    public synchronized String getOwnerName() { return ownerName; } // doesn't touch balance!
    public synchronized void printStatement() { ... }               // read-only, no conflict!
    public synchronized void deposit(int amount) { balance += amount; }
}

getOwnerName() and printStatement() don’t touch shared mutable state. But now every thread has to queue up to call them, waiting for each other’s locks.

The result:

• You do not have a multithreaded program anymore

• You have a single-threaded program with the overhead of multithreading on top

• The kitchen with fifteen chefs, all forced to take turns with a single spoon

You haven’t solved the problem. You’ve traded one failure mode for another — and this one is harder to see, because the code still works. It just works slowly, under load, in ways you won’t catch until production is burning.

9. The Distinction That Changes Everything

There are two things inside any Java class. Most developers treat them the same. They are not.

Here is the most important code example in this entire blog:

// ✅ Behavior only — completely thread-safe, no protection needed
public class MathUtil {
    // No instance variables. Nothing shared. Nothing to corrupt.
    public int add(int a, int b) {
        return a + b; // lives entirely on this thread's stack
    }
}

// ⚠️ State + Behavior — the deposit method touches shared state
public class BankAccount {
    private int balance; // instance variable = shared state = danger zone

    public void deposit(int amount) {
        balance += amount; // reading AND writing shared state — needs protection
    }

    public int getBalance() {
        return balance; // reading shared state — may need protection depending on context
    }
}

MathUtil.add() can be called from a million threads simultaneously. Safe. Zero conflict. Each thread does its own math and leaves.

BankAccount.deposit() called from multiple threads simultaneously without protection? Corrupted balance. Silent. No error thrown.

The method isn’t the problem. The shared state inside it is.

So your question should never be:

“Is this method thread-safe?”

Your question should be:

“Does this method touch shared state — and if so, is that access protected?”

10. Why the Heap Makes This Unavoidable

Every thread in Java has its own call stack — a private scratchpad for:

• Local variables

• Method call history

• Return addresses

Completely private. Thread A cannot see Thread B’s stack. No conflict possible there.

But every thread shares the same heap. The heap is where objects live. When you create a BankAccount, a UserSession, a ShoppingCart — those objects sit on the heap. Every thread that holds a reference to that object can read and modify it freely.

public class Main {
    public static void main(String[] args) {
        BankAccount account = new BankAccount(10000); // lives on the HEAP

        Thread priya = new Thread(() -> account.deposit(2000)); // both threads
        Thread arjun = new Thread(() -> account.deposit(3000)); // share same object

        priya.start();
        arjun.start();
    }
}

Here is the exact setup for disaster:

1. Thread A reads balance from the shared object on the heap → sees 10,000

2. Before it finishes computing and writes back → Thread B reads the same balance → also sees 10,000

3. Both compute their update. Both write back.

4. One write erases the other. Data is wrong.

5. No error is thrown. The program moves on.

The heap is shared territory. Without coordination at the right moments, it quietly breaks.

11. Protect the Modification — Not the Method

This is the correct mental model. Read it slowly.

You don’t need to protect your entire methods. You need to protect the specific moment when shared state is being read and then modified as one uninterrupted sequence.

Think of a shared whiteboard in an office:

• Multiple people can read it simultaneously — no problem

• The conflict only happens when someone picks up a marker

• That moment — reading and rewriting together — is what needs protection

In Java, that narrow region of code is called the critical section.

public class BankAccount {
    private int balance;
    private final Object lock = new Object();

    public void deposit(int amount) {
        // Non-critical: pure logic, no shared state touched
        validateAmount(amount);
        logDepositAttempt(amount);

        // ✅ Critical section — protect only this
        synchronized (lock) {
            balance += amount; // read + modify + write = must be atomic
        }

        // Non-critical: this runs freely in parallel
        sendDepositNotification(amount);
    }
}

Notice what is outside the synchronized block:

• validateAmount() — pure logic, no shared state

• logDepositAttempt() — can run in parallel safely

• sendDepositNotification() — no shared data touched

Only the actual modification is protected. Everything else runs free. That is where your performance lives.

Protect the critical section. Not the whole method. Not every line. Just the place where shared state changes.

12. One Special Case: The Stateless Class

Here is something most developers never stop to think about:

A stateless object is always thread-safe. Always.

A class with no instance variables — nothing to store, no shared data — can be called by a thousand threads simultaneously and nothing will ever go wrong. Because there is nothing shared to corrupt.

// ✅ Always thread-safe — no instance variables, no shared state
public class TaxCalculator {
    public double calculate(double income, double rate) {
        return income * rate; // everything lives on this thread's stack
    }
}

// ✅ Typical Servlet — stateless, always thread-safe
public class PaymentServlet extends HttpServlet {
    // No instance variables here = no shared state = no thread safety concern
    protected void doPost(HttpServletRequest req, HttpServletResponse res) {
        String amount = req.getParameter("amount"); // local variable = stack = safe
        processPayment(amount);
    }
}

A thousand HTTP requests hit PaymentServlet simultaneously. Each thread runs doPost() with its own local variables on its own stack. Zero conflict. Zero synchronization needed.

The moment you add an instance variable to that Servlet — a counter, a cache, a shared list — you have introduced shared state. And now you have a thread safety problem to solve.

13. Before You Move On — Hold These Three Thoughts

1. Multithreading is not optional in modern Java. It is the difference between software that scales and software that collapses under load.

2. Thread safety is not about locking everything. It is about identifying shared state and protecting the exact moment it is modified — nothing more, nothing less.

3. The biggest trap is not ignoring thread safety. The biggest trap is over-protecting it — turning a concurrent program back into a sequential one wearing a disguise.

The correct instinct is surgical, not sweeping. Find the shared state. Find the modification. Protect that. Let everything else breathe.

If this was useful, share it with one developer who still thinks synchronized on every method is fine. It might save them a production incident

Share Level Up Your Programming with Nitin

If this was useful, consider sharing it with someone who’s on the same journey.

I write every week about System Design, Java Backend Engineering, Distributed Systems, and Developer Career Growth — the stuff that actually matters for growing from fresher to senior engineer.

[Subscribe now] — it’s free, and you can unsubscribe anytime.

Subscribe now

Let’s keep learning together. 🚀

If you have questions, a topic you’d like me to cover, or just want to share how your journey is going — drop a comment below. I read every one.

Find me here: LinkedIn · YouTube · Instagram · GitHub · Hashnode · Topmate

Prev The Need: Why Sequential Thinking Breaks the Modern World Next