Thread Safety in Java
A class is thread-safe when its behavior remains correct and its invariants remain valid even when multiple threads use it concurrently according to its contract.
Thread safety is not a single keyword or feature. It is a design property. You achieve it through techniques such as immutability, synchronization, atomic operations, safe publication, confinement, concurrent collections, and carefully designed locking.
Core idea: Thread safety means that concurrent access cannot cause the object to enter an invalid state or produce incorrect results when used according to its intended contract.
Why Thread Safety Matters
Consider an application serving thousands of users. A web server may process many requests concurrently, and several requests may access the same service object or shared resource at the same time.
If that shared component stores mutable state without proper coordination, one request can interfere with another.
class Counter {
private int count = 0;
public void increment() {
count++;
}
}
If several threads call increment() concurrently, updates can be lost because the operation is not automatically atomic.
A thread-safe design must ensure that concurrent usage preserves the intended behavior.
Real-World Analogy
Imagine a shared notebook containing the current inventory of a warehouse. Several employees are allowed to update it simultaneously.
If two employees independently read the same stock value and overwrite each other's changes, the notebook becomes incorrect.
A thread-safe design is like introducing rules for accessing the notebook: perhaps only one employee can update it at a time, or each employee works with immutable records and a controlled update mechanism.
The important part is not simply "one person at a time." The important part is preserving the correctness of the inventory data.
Thread Safety and Shared Mutable State
Shared mutable state is one of the biggest sources of concurrency problems.
class UserSession {
private String username;
public void setUsername(String username) {
this.username = username;
}
public String getUsername() {
return username;
}
}
If the same UserSession instance is accessed by multiple threads, the design must consider how reads and writes are coordinated and whether the class's state can be observed consistently.
A useful architectural principle is simple: reduce shared mutable state whenever practical.
Making a Class Thread-Safe with synchronized
One common approach is to protect shared mutable state using synchronization.
class Counter {
private int count = 0;
public synchronized void increment() {
count++;
}
public synchronized int getCount() {
return count;
}
}
The synchronized methods use the same object's monitor, ensuring that competing calls on the same Counter instance are coordinated.
This is appropriate when the class's state transitions genuinely require mutual exclusion.
Thread Safety with a Synchronized Block
Instead of synchronizing an entire method, a class can synchronize only the critical section.
class Counter {
private int count = 0;
public void increment() {
synchronized (this) {
count++;
}
}
public int getCount() {
synchronized (this) {
return count;
}
}
}
The benefit is greater control over the synchronization boundary. Code that does not access the protected state can remain outside the critical section.
Thread Safety Through Immutability
One of the strongest ways to simplify thread safety is to make an object immutable.
An immutable object does not change its state after construction. If multiple threads only read the same immutable object, they do not need to coordinate modifications because there are no modifications to coordinate.
final class User {
private final String name;
private final int age;
public User(String name, int age) {
this.name = name;
this.age = age;
}
public String getName() {
return name;
}
public int getAge() {
return age;
}
}
The fields are final, there are no setters, and the object's state cannot be changed through the exposed API after construction.
Design insight: Immutability often removes the synchronization problem instead of requiring you to solve it afterward.
Thread Safety with Atomic Variables
For simple shared state such as counters, Java provides atomic classes in the java.util.concurrent.atomic package.
import java.util.concurrent.atomic.AtomicInteger;
class Counter {
private final AtomicInteger count =
new AtomicInteger();
public void increment() {
count.incrementAndGet();
}
public int getCount() {
return count.get();
}
}
The atomic operation ensures that the increment is performed safely with respect to other atomic operations on the same variable.
Atomic classes are especially useful when the state operation fits the atomic abstraction. They are not a replacement for every form of synchronization.
Thread Confinement
Another way to achieve thread safety is to ensure that mutable state belongs exclusively to one thread.
Thread worker = new Thread(() -> {
int localCounter = 0;
for (int i = 0; i < 1000; i++) {
localCounter++;
}
System.out.println(
localCounter
);
});
worker.start();
The local variable belongs to the executing thread. Other threads cannot directly access that local variable.
This approach is called thread confinement. Instead of synchronizing access to shared mutable state, you avoid sharing that state in the first place.
Safe Publication
Creating a thread-safe class is not enough if its objects are published to other threads incorrectly.
Safe publication means making an object visible to other threads in a way that ensures they see a properly constructed and appropriately visible state.
Java provides several mechanisms that can establish the necessary visibility guarantees, including synchronization, volatile fields for suitable use cases, final-field semantics, and concurrent utilities.
Important: Thread safety involves more than protecting individual methods. You must consider object construction, publication, mutation, visibility, and the complete lifecycle of shared state.
Example: Unsafe Check-Then-Act
Consider a shared cache:
class Cache {
private Object value;
public void initialize() {
if (value == null) {
value = createValue();
}
}
private Object createValue() {
return new Object();
}
}
If multiple threads call initialize() concurrently, they may both observe value == null and both create a value.
Whether that is a correctness problem depends on the application's requirements, but the important lesson is that check-then-act sequences need careful concurrency design.
Protecting the Entire State Transition
class Cache {
private Object value;
public synchronized void initialize() {
if (value == null) {
value = createValue();
}
}
private Object createValue() {
return new Object();
}
}
Now the check and the update occur within the same synchronization boundary.
This illustrates a broader principle: when multiple steps together represent one logical operation, those steps may need to be protected as one unit.
Thread-Safe Collections
Java provides concurrency-oriented collections designed for multithreaded environments. Examples include ConcurrentHashMap, CopyOnWriteArrayList, and BlockingQueue.
import java.util.concurrent.ConcurrentHashMap;
ConcurrentHashMap<String, Integer> scores =
new ConcurrentHashMap<>();
scores.put("Java", 95);
scores.put("SQL", 90);
System.out.println(
scores.get("Java")
);
These classes are designed around specific concurrent access patterns and can provide better scalability and clearer intent than manually synchronizing an ordinary collection.
Practical rule: When Java already provides a concurrency-focused collection for your use case, prefer understanding and using that abstraction instead of building a custom synchronization scheme unnecessarily.
Thread Safety Is Not the Same as Immutable
Immutability is one excellent way to achieve thread-safe behavior, but the terms are not interchangeable.
| Concept | Meaning |
|---|---|
| Immutable | Object state cannot change after construction. |
| Thread-safe | Concurrent use remains correct according to the object's contract. |
An immutable object can be naturally thread-safe, but a mutable object can also be thread-safe if its state transitions are correctly coordinated.
Thread Safety vs Thread-Compatible Design
Not every class needs to be independently thread-safe. Some classes are intentionally designed to be used by one thread at a time or to be externally synchronized by their caller.
For example, an ordinary mutable collection may be perfectly suitable when it is confined to one thread. Problems arise when its usage assumptions are violated.
This is why developers should understand a component's thread-safety contract rather than assuming that every object must internally synchronize every operation.
Thread Safety and Atomicity
Atomicity means an operation behaves as one indivisible unit from the perspective of the relevant concurrent interactions.
count++; // // Read count // Add 1 // Write count //
This compound operation is not automatically atomic just because the code appears on one line.
A thread-safe design must identify which operations need to be atomic and choose an appropriate mechanism to provide that guarantee.
Thread Safety and Visibility
Suppose one thread changes a shared variable and another thread reads it. Correct concurrent behavior requires more than simply having both operations in the source code.
The threads need appropriate visibility guarantees so that updates become observable according to Java's memory model.
Synchronization, volatile fields in appropriate scenarios, atomic classes, and concurrent utilities can establish different forms of visibility and ordering guarantees.
Thread Safety and Compound Operations
Even when individual operations are thread-safe, a sequence of operations may not be thread-safe as a whole.
if (!map.containsKey("Java")) {
map.put("Java", 100);
}
The individual map operations may have concurrency guarantees depending on the collection being used, but the entire check-then-insert sequence is a separate logical operation.
A concurrent design must therefore consider the complete operation rather than assuming that thread-safe individual methods automatically make every combination of those methods atomic.
Example: Thread-Safe Counter Options
| Approach | Suitable When |
|---|---|
| synchronized | A critical section needs mutual exclusion and visibility. |
| AtomicInteger | A counter or similar atomic variable operation is required. |
| Immutable object | State can be fixed after construction. |
| Thread confinement | Mutable state can remain owned by one thread. |
| Concurrent collection | Multiple threads need safe access to a collection designed for concurrency. |
Common Beginner Mistakes
- Assuming that a class is thread-safe merely because it uses one synchronized method.
- Assuming volatile makes compound operations atomic.
- Synchronizing individual statements without protecting the complete logical state transition.
- Sharing mutable objects unnecessarily.
- Using ordinary collections concurrently without understanding their thread-safety characteristics.
- Assuming thread-safe individual methods automatically make a sequence of operations atomic.
- Ignoring safe publication and visibility when sharing objects between threads.
Best Practices
- Prefer immutable objects whenever the design permits.
- Minimize shared mutable state.
- Use synchronization to protect complete invariants and state transitions.
- Use atomic classes for operations they are designed to handle efficiently.
- Use concurrent collections for appropriate concurrent data-access patterns.
- Document the thread-safety expectations of reusable classes.
- Avoid unnecessary locking, but never remove synchronization merely for performance without proving that the required correctness guarantees remain intact.
Interview Insights
Question: What does thread-safe mean?
It means that a component behaves correctly when accessed concurrently according to its intended contract, without allowing unsafe concurrent interactions to violate its invariants.
Question: How can you make a class thread-safe?
Possible approaches include immutability, synchronization, atomic variables, confinement, concurrent collections, safe publication, and carefully designed locking.
Question: Is volatile enough to make a class thread-safe?
Not generally. Volatile can provide visibility and ordering guarantees for a suitable field, but it does not automatically make compound operations atomic or protect complex invariants.
Question: Is an immutable object thread-safe?
An appropriately designed immutable object is naturally safe to share between threads because its state cannot be modified after construction.
Question: Are all methods of a thread-safe class automatically atomic?
No. Thread safety does not mean every method or combination of methods is one indivisible operation. The class contract must define what concurrent operations are guaranteed to do.
Quick Revision
| Concept | Key Point |
|---|---|
| Thread Safety | Concurrent use remains correct according to the component's contract. |
| Immutability | Prevents state changes after construction and can greatly simplify concurrency. |
| Synchronization | Provides mutual exclusion and important visibility guarantees. |
| Atomic Classes | Provide atomic operations for suitable shared-state use cases. |
| Thread Confinement | Keeps mutable state owned by one thread instead of sharing it. |
| Concurrent Collections | Provide concurrency-oriented data structures for appropriate access patterns. |
| Safe Publication | Ensures shared objects become visible to other threads correctly. |
| Compound Operations | Must be analyzed as complete logical actions, not merely as individual method calls. |
Thread safety is the point where all the major multithreading concepts come together. Race conditions show what can go wrong, synchronization provides one way to coordinate access, atomic classes handle suitable indivisible operations, immutability removes many shared-state problems entirely, and concurrent collections provide specialized solutions for common patterns. The strongest concurrent designs do not simply add locks everywhere; they deliberately control ownership, visibility, mutation, and coordination so that correctness is built into the architecture.