In the world of concurrent programming in Java, ensuring thread safety and data consistency is paramount. Understanding the nuances of atomic, volatile, and synchronized keywords is crucial for building robust and reliable multi-threaded applications. These keywords offer different mechanisms for managing access to shared data, each with its own strengths and limitations. Choosing the right approach depends heavily on the specific scenario and desired level of concurrency control. This post will delve into the distinctions between these keywords, providing clear examples and best practices for their effective utilization.

Atomic Operations

Atomic operations provide a way to perform single, indivisible actions on variables. This indivisibility is key in multi-threaded environments, preventing race conditions where multiple threads attempt to modify a shared variable simultaneously, leading to unpredictable results. Java’s java.util.concurrent.atomic package offers a range of classes, such as AtomicInteger, AtomicLong, and AtomicBoolean, to facilitate atomic operations. These classes utilize low-level hardware instructions like compare-and-swap (CAS) for efficient and thread-safe modifications.

For instance, incrementing a counter in a multi-threaded environment without atomic operations could lead to lost updates. Imagine multiple threads attempting to increment the counter simultaneously. If two threads read the current value (e.g., 5), both increment it to 6, and then both write the new value back, the final result would be 6 instead of the expected 7. Using AtomicInteger guarantees that the increment operation is completed as a single, uninterruptible action, preventing such data inconsistencies.

Volatile Keyword

The volatile keyword in Java ensures that changes made to a variable are immediately visible to all other threads. This is particularly important in scenarios where a variable is frequently read but infrequently written, such as a flag indicating program termination. Without volatile, a thread might cache the value of a variable, leading to stale data being used.

volatile doesn’t provide atomicity. It only guarantees visibility, not mutual exclusion. Therefore, it’s not suitable for complex operations involving multiple steps. For example, volatile wouldn’t prevent the lost update problem mentioned earlier when incrementing a counter because the increment operation itself involves multiple steps (read, increment, write). In such cases, atomic operations are required.

Consider a scenario where a flag variable is used to signal a thread to stop. If the flag is not declared volatile, a thread might continue running even after the flag is set to true by another thread, as it might be working with a cached, stale value.

Synchronized Keyword

The synchronized keyword provides the most robust form of concurrency control in Java. It ensures that only one thread can access a synchronized block of code or a synchronized method at a time, preventing race conditions and maintaining data consistency. synchronized achieves this by acquiring a lock on the object or method it’s associated with. Other threads attempting to access the synchronized block or method must wait until the lock is released.

Synchronization, however, comes with performance overhead due to lock acquisition and release. Overuse of synchronized can lead to contention and reduced throughput. It’s crucial to choose the right granularity of synchronization. Synchronizing large blocks of code can unnecessarily restrict concurrency, while synchronizing too small a block might not provide adequate protection.

A classic example of synchronized usage is protecting a shared data structure like a list. If multiple threads access the list concurrently without synchronization, operations like adding or removing elements could lead to data corruption or exceptions. Synchronizing access to the list ensures that only one thread can modify the list at any given time, preventing such issues.

Choosing the Right Approach

Selecting the appropriate concurrency control mechanism depends on the specific needs of the application. For simple operations like incrementing a counter or setting a flag, atomic operations or volatile may suffice. For more complex operations involving shared data structures or critical sections of code, synchronized offers the necessary protection, albeit with a potential performance impact.

Understanding the characteristics of each approach is key. Atomic operations provide efficient atomicity for simple operations. Volatile ensures visibility of changes but doesn’t guarantee atomicity. Synchronized offers mutual exclusion and data consistency but introduces performance overhead.

Here’s a quick summary:

• Atomic: For atomic, indivisible operations on single variables.
• Volatile: For ensuring visibility of changes across threads.
• Synchronized: For mutual exclusion and protecting critical sections.

Choosing the right strategy involves carefully analyzing the access patterns and concurrency requirements of your application to strike a balance between thread safety and performance. Learn more about concurrent programming in Java on this helpful resource.

FAQ

Q: What is the difference between volatile and synchronized in Java?

A: volatile ensures that changes made to a variable are immediately visible to all threads, while synchronized provides mutual exclusion, allowing only one thread to access a synchronized block at a time.

[Infographic comparing atomic, volatile, and synchronized]

The optimal choice depends heavily on the specific concurrency needs. For simple operations on shared variables, atomic operations often provide the best performance. When visibility is paramount and atomicity isn’t required, volatile is a lightweight solution. For complex operations involving shared mutable state, synchronized guarantees data integrity. By carefully considering the trade-offs between performance and safety, developers can effectively leverage these tools to build robust and efficient concurrent applications. Explore additional resources like Oracle’s concurrency tutorial and Baeldung’s guide on volatile to deepen your understanding. Also, check out Stack Overflow for practical examples and discussions on these important Java keywords. Remember, mastering concurrency control is essential for creating high-performing and reliable Java applications.

Question & Answer :
How do atomic / volatile / synchronized work internally?

What is the difference between the following code blocks?

Code 1

private int counter; public int getNextUniqueIndex() { return counter++; } 

Code 2

private AtomicInteger counter; public int getNextUniqueIndex() { return counter.getAndIncrement(); } 

Code 3

private volatile int counter; public int getNextUniqueIndex() { return counter++; } 

Does volatile work in the following way? Is

volatile int i = 0; void incIBy5() { i += 5; } 

equivalent to

Integer i = 5; void incIBy5() { int temp; synchronized(i) { temp = i } synchronized(i) { i = temp + 5 } } 

I think that two threads cannot enter a synchronized block at the same time… am I right? If this is true then how does atomic.incrementAndGet() work without synchronized? And is it thread-safe?

And what is the difference between internal reading and writing to volatile variables / atomic variables? I read in some article that the thread has a local copy of the variables - what is that?

You are specifically asking about how they internally work, so here you are:

No synchronization

private int counter; public int getNextUniqueIndex() { return counter++; } 

It basically reads value from memory, increments it and puts back to memory. This works in single thread but nowadays, in the era of multi-core, multi-CPU, multi-level caches it won’t work correctly. First of all it introduces race condition (several threads can read the value at the same time), but also visibility problems. The value might only be stored in “local” CPU memory (some cache) and not be visible for other CPUs/cores (and thus - threads). This is why many refer to local copy of a variable in a thread. It is very unsafe. Consider this popular but broken thread-stopping code:

private boolean stopped; public void run() { while(!stopped) { //do some work } } public void pleaseStop() { stopped = true; } 

Add volatile to stopped variable and it works fine - if any other thread modifies stopped variable via pleaseStop() method, you are guaranteed to see that change immediately in working thread’s while(!stopped) loop. BTW this is not a good way to interrupt a thread either, see: How to stop a thread that is running forever without any use and Stopping a specific java thread.

AtomicInteger

private AtomicInteger counter = new AtomicInteger(); public int getNextUniqueIndex() { return counter.getAndIncrement(); } 

The AtomicInteger class uses CAS (compare-and-swap) low-level CPU operations (no synchronization needed!) They allow you to modify a particular variable only if the present value is equal to something else (and is returned successfully). So when you execute getAndIncrement() it actually runs in a loop (simplified real implementation):

int current; do { current = get(); } while(!compareAndSet(current, current + 1)); 

So basically: read; try to store incremented value; if not successful (the value is no longer equal to current), read and try again. The compareAndSet() is implemented in native code (assembly).

volatile without synchronization

private volatile int counter; public int getNextUniqueIndex() { return counter++; } 

This code is not correct. It fixes the visibility issue (volatile makes sure other threads can see change made to counter) but still has a race condition. This has been explained multiple times: pre/post-incrementation is not atomic.

The only side effect of volatile is “flushing” caches so that all other parties see the freshest version of the data. This is too strict in most situations; that is why volatile is not default.

volatile without synchronization (2)

volatile int i = 0; void incIBy5() { i += 5; } 

The same problem as above, but even worse because i is not private. The race condition is still present. Why is it a problem? If, say, two threads run this code simultaneously, the output might be + 5 or + 10. However, you are guaranteed to see the change.

Multiple independent synchronized

void incIBy5() { int temp; synchronized(i) { temp = i } synchronized(i) { i = temp + 5 } } 

Surprise, this code is incorrect as well. In fact, it is completely wrong. First of all you are synchronizing on i, which is about to be changed (moreover, i is a primitive, so I guess you are synchronizing on a temporary Integer created via autoboxing…) Completely flawed. You could also write:

synchronized(new Object()) { //thread-safe, SRSLy? } 

No two threads can enter the same synchronized block with the same lock. In this case (and similarly in your code) the lock object changes upon every execution, so synchronized effectively has no effect.

Even if you have used a final variable (or this) for synchronization, the code is still incorrect. Two threads can first read i to temp synchronously (having the same value locally in temp), then the first assigns a new value to i (say, from 1 to 6) and the other one does the same thing (from 1 to 6).

The synchronization must span from reading to assigning a value. Your first synchronization has no effect (reading an int is atomic) and the second as well. In my opinion, these are the correct forms:

void synchronized incIBy5() { i += 5 } void incIBy5() { synchronized(this) { i += 5 } } void incIBy5() { synchronized(this) { int temp = i; i = temp + 5; } }