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

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