Race Condition in Java (Why Thread Safety Matters)

A Race Condition occurs in a multithreaded program when two or more threads access and modify shared data simultaneously, and the final result depends on the order in which the threads execute.

Because thread scheduling is controlled by the JVM and the operating system, the execution order is unpredictable, which can lead to incorrect, inconsistent, or corrupted results.

---

Why It Is Called a Race Condition

Threads are said to be “racing” to read and update the same shared resource.

• If one thread executes first → one result
• If another thread executes first → a different result

As a result, the output may change every time the program runs.

---

Java Example Demonstrating Race Condition

classCounter {
intcount=0;

voidincrement() {
        count++;// NOT thread-safe
    }
}

publicclassRaceConditionDemo {
publicstaticvoidmain(String[] args)throws InterruptedException {
Countercounter=newCounter();

Threadt1=newThread(() -> {
for (inti=0; i <1000; i++) {
                counter.increment();
            }
        });

Threadt2=newThread(() -> {
for (inti=0; i <1000; i++) {
                counter.increment();
            }
        });

        t1.start();
        t2.start();

        t1.join();
        t2.join();

        System.out.println("Final Count: " + counter.count);
    }
}

Expected Output

Final Count:2000

Actual Output (varies each run)

Final Count:1873
Final Count:1932

---

Why Race Condition Happens

The operation count++ is not atomic.

It internally performs three separate steps:

1. Read the current value of count
2. Increment the value
3. Write the updated value back to memory

When multiple threads execute these steps at the same time, updates can be lost, causing incorrect results.

---

Conditions Required for a Race Condition

A race condition occurs when all of the following are true:

• Shared mutable data exists
• Multiple threads access the data concurrently
• At least one thread modifies the data
• No proper synchronization is applied

---

Why Thread Safety Matters

Without thread safety, race conditions can cause:

• Incorrect calculations
• Data inconsistency or corruption
• Unpredictable program behavior
• Hard-to-debug production issues
• Financial and data integrity losses in real systems

Thread safety ensures that shared data remains consistent, regardless of how many threads access it.

---

How to Prevent Race Condition (Ensure Thread Safety)

1. Using synchronized

synchronizedvoidincrement() {
    count++;
}

Ensures that only one thread can execute the critical section at a time.

---

2. Using Atomic Classes

AtomicIntegercount=newAtomicInteger(0);
count.incrementAndGet();

Provides lock-free, high-performance thread safety for counters and simple operations.

---

3. Using Locks (ReentrantLock)

lock.lock();
try {
    count++;
}finally {
    lock.unlock();
}

Used when fine-grained control, fairness, or advanced locking features are required.

---

Real-Life Example

Two ATM machines withdraw money from the same bank account at the same time:

• Balance = ₹10,000
• Both withdraw ₹5,000
• Correct balance should be ₹0
• System shows ₹5,000

This happens due to unsynchronized access to shared data — a classic race condition.

---

Race Condition vs Thread Safety

Aspect	Race Condition	Thread Safety
Nature	A problem that arises when multiple threads access and modify shared data without proper coordination. It is an undesired concurrent behavior.	A solution that ensures shared data is accessed and modified safely in a concurrent environment. It is a desired behavior for correctness.
Result / Outcome	Leads to incorrect, inconsistent, or corrupted data. Program behavior becomes unpredictable and may vary across runs.	Guarantees correct, consistent, and predictable data. Program behaves reliably regardless of thread scheduling.
Cause / Root Reason	Occurs due to lack of synchronization, non-atomic operations, and unsafely shared mutable data.	Achieved through proper synchronization, atomic operations, or concurrency controls that prevent simultaneous unsafe access.
Behavior / Execution	Non-deterministic: The output can change every run depending on which thread executes first.	Deterministic: The outcome is consistent and independent of the execution order of threads.
Impact on Application	Can cause bugs that are hard to detect and reproduce, data corruption, or system failures, especially in critical systems like banking or ticketing.	Ensures reliable and stable program execution, prevents data corruption, and makes multithreaded code safe for production.
Example	Two threads increment a shared counter without locks → final count varies.	Two threads increment a shared counter using synchronized or AtomicInteger → final count is always correct.
Detection Difficulty	Often hard to detect because issues appear intermittently and depend on thread timing.	Easy to reason about since proper thread safety eliminates timing-related inconsistencies.
Developer Responsibility	Requires careful attention to shared resources; failure to handle properly causes unpredictable bugs.	Requires correct use of synchronization mechanisms; ensures safe access and avoids concurrency issues.

---

Critical Section

A Critical Section is the part of code where shared data is accessed or modified.

count++;// critical section

If multiple threads enter the critical section at the same time without synchronization, a race condition occurs.

? Thread safety means protecting the critical section.

---

Memory Visibility Problem

Race conditions are not only about atomicity but also about visibility.

• Threads may cache variables in CPU memory
• One thread’s update may not be immediately visible to others
• This can cause threads to work with stale data

Synchronization and atomic classes ensure:

• Atomicity
• Visibility
• Ordering (happens-before relationship)

---

When Race Condition Does NOT Occur

Race conditions do not occur when:

• Data is immutable
• Each thread works on its own local data
• Shared data is properly synchronized
• Only one thread accesses the resource

---

Best Practices to Avoid Race Conditions

• Minimize shared mutable state
• Keep critical sections small
• Prefer atomic classes for counters
• Avoid unnecessary synchronization
• Design immutable objects whenever possible

Conclusion

• A race condition occurs due to concurrent, unsynchronized access to shared data
• Results become unpredictable and unreliable
• Thread safety prevents race conditions
• Use synchronized, atomic classes, or locks to protect critical sections
• Essential for building correct, stable, and reliable multithreaded applications