IAtomicReference
The IAtomicLong
is very useful if you need to deal with a long,
but in some cases you need to deal with a reference. That is why Hazelcast
also supports the IAtomicReference
which is the distributed version of
the java.util.concurrent.atomic.AtomicReference
.
This data structure is a member of the CP Subsystem. By default, the CP Subsystem is in unsafe mode, which provides weaker consistency guarantees. You can enable the CP Subsystem in the member configuration. |
Here is an IAtomicReference example.
Config config = new Config();
HazelcastInstance hz = Hazelcast.newHazelcastInstance(config);
IAtomicReference<String> ref = hz.getCPSubsystem().getAtomicReference("reference");
ref.set("foo");
System.out.println(ref.get());
ref.destroy();
System.exit(0);
When you execute the above example, the output is as follows:
foo
IAtomicReference s are not automatically removed. If a reference is not used anymore, Hazelcast
does not automatically perform garbage collection in it.
This can lead to an OutOfMemoryError . If you create IAtomicReference s on the fly,
make sure they are destroyed. See Destroying Objects
and CP Data Structures.
|
Sending Functions to IAtomicReference
Just like IAtomicLong
, IAtomicReference
has methods that accept a
'function' as an argument, such as alter
, alterAndGet
, getAndAlter
and apply
.
There are two big advantages of using these methods:
-
From a performance point of view, it is better to send the function to the data than the data to the function. Often the function is a lot smaller than the data and therefore cheaper to send over the line. Also the function only needs to be transferred once to the target machine and the data needs to be transferred twice.
-
You do not need to deal with concurrency control. If you would perform a load, transform, store, you could run into a data race since another thread might have updated the value you are about to overwrite.
Using IAtomicReference
The following are some considerations you need to know when you use IAtomicReference:
-
IAtomicReference
works based on the byte-content and not on the object-reference. If you use thecompareAndSet
method, do not change to the original value because its serialized content will then be different. It is also important to know that if you rely on Java serialization, sometimes (especially with hashmaps) the same object can result in different binary content. -
All methods returning an object return a private copy. You can modify the private copy, but the rest of the world is shielded from your changes. If you want these changes to be visible to the rest of the world, you need to write the change back to the
IAtomicReference
; but be careful about introducing a data-race. -
The 'in-memory format' of an
IAtomicReference
isbinary
. The receiving side does not need to have the class definition available unless it needs to be deserialized on the other side, e.g., because a method like 'alter' is executed. This deserialization is done for every call that needs to have the object instead of the binary content, so be careful with expensive object graphs that need to be deserialized. -
If you have an object with many fields or an object graph and you only need to calculate some information or need a subset of fields, you can use the
apply
method. With theapply
method, the whole object does not need to be sent over the line; only the information that is relevant is sent.