Скачать или смотреть Atomically Update 2 Long Values in Java without synchronized

Discover how to update two Long values in Java atomically while avoiding synchronized blocks using immutable and unmodifiable records!
---
This video is based on the question https://stackoverflow.com/q/63622311/ asked by the user 'Adwait Kumar' ( https://stackoverflow.com/u/1432247/ ) and on the answer https://stackoverflow.com/a/63622385/ provided by the user 'Louis Wasserman' ( https://stackoverflow.com/u/869736/ ) at 'Stack Overflow' website. Thanks to these great users and Stackexchange community for their contributions.

Visit these links for original content and any more details, such as alternate solutions, latest updates/developments on topic, comments, revision history etc. For example, the original title of the Question was: Atomically update 2 Long values

Also, Content (except music) licensed under CC BY-SA https://meta.stackexchange.com/help/l...
The original Question post is licensed under the 'CC BY-SA 4.0' ( https://creativecommons.org/licenses/... ) license, and the original Answer post is licensed under the 'CC BY-SA 4.0' ( https://creativecommons.org/licenses/... ) license.

If anything seems off to you, please feel free to write me at vlogize [AT] gmail [DOT] com.
---
Atomically Update 2 Long Values in Java without synchronized

When developing multithreaded applications in Java, ensuring that shared resources are updated correctly without encountering race conditions can be a tricky task. In this post, we will explore how to atomically update two Long values in a Java class without relying on the synchronized keyword. This is a common requirement when working with concurrent data structures like ConcurrentHashMap.

The Problem: Updating Records Safely

Consider the following Record class which contains three fields: name, count, and repeat. The task is to ensure thread-safe updates to these fields within a ConcurrentHashMap while maintaining performance in a multithreaded environment. Here’s the initial implementation of our Record class and an update function:

[[See Video to Reveal this Text or Code Snippet]]

In this implementation, the update method is synchronized, which can lead to performance bottlenecks as it restricts concurrent access. Let’s look at how to implement a more efficient solution.

The Solution: Using Immutable Records

One effective way to avoid using the synchronized keyword is to make the Record class immutable and unmodifiable. This approach allows multiple threads to operate without conflicts since immutable objects cannot be altered after their creation. Here’s how the redesigned Record class looks:

[[See Video to Reveal this Text or Code Snippet]]

Key Changes Made

Immutability: All fields in the Record class are declared as final, ensuring that once a Record object is created, its state cannot change.

Combine Method: Instead of an update method that alters the state, there's a combine method that creates a new Record by combining values from two Record instances.

Updating the Records

Now that we have an immutable Record class, we can change the update function as follows:

[[See Video to Reveal this Text or Code Snippet]]

Explanation of the updateRecords Method:

Merge Functionality: The merge function in ConcurrentHashMap is designed to handle simultaneous updates safely. It takes three arguments: the key, the value (record), and a remapping function (in this case, Record::combine).

Thread Safety: With this approach, there's no need for explicit synchronization since the immutability of Record ensures consistent state.

Conclusion

By redesigning the Record class to be immutable, we have successfully created a thread-safe update mechanism for our ConcurrentHashMap without the use of synchronized. This not only improves performance but also makes our code cleaner and easier to manage.

If you're facing similar challenges in multithreading scenarios, consider leveraging immutability for a safer and more efficient design.

Feel free to try this out in your project and enhance the robustness of your concurrent updates!