Why Thread Safety Fails in Java and How to Ensure It

Interview series article continuously updated, focusing on common Java interview topics such as thread safety.

In concurrent programming, the most feared phrase is “thread‑unsafe,” which means data reads or writes may become inaccurate during execution.

The root cause of thread‑unsafe issues is variable sharing across multiple threads.

Developers often encounter code conflicts when pulling or committing code with git, as shown in the following diagram.

These conflicts arise because each engineer has a local copy of the code; when one pushes changes, others may still be working on outdated versions, leading to overlapping modifications.

Similarly, if a variable is shared among multiple Java threads, thread‑unsafe situations occur.

Which Java variables are not shared?

Understanding the Java Virtual Machine (JVM) memory model clarifies which variables are shared and which are thread‑local.

The JVM runtime data area is divided into a shared region (accessible by all threads) and a thread‑isolated region (each thread’s private area).

Each thread has its own stack space, independent of others, allowing methods to be invoked with different parameters without affecting other threads.

A stack frame stores local variables, operand stack, dynamic linking, and return address information.

During method execution, the call chain looks like method1->method2->method3; when a method returns, its stack frame is popped.

Where are variables stored in a stack frame?

They reside in the local variable table.

The local variable table holds method parameters and locally defined variables, which can be primitive types or object references.

Although primitive locals reside in the stack, object instances created with new Object() live in the heap, a shared area. However, the reference to that object is stored in the thread’s stack, making the reference thread‑local.

Each thread’s created object is only reachable by that thread, eliminating shared‑variable problems and ensuring thread safety.

One practical solution is to give each thread its own private instance of a needed object, as illustrated below.

By creating a separate Object for each thread, sharing is avoided, but managing these instances manually can be cumbersome.

A proxy object can hide the details of obtaining each thread’s private instance, providing a cleaner API while preserving thread‑local semantics.

In summary, thread‑unsafe behavior stems from shared variables; keeping variables thread‑local—either by using stack‑stored primitives, thread‑local object references, or proxy patterns—effectively resolves the issue.