I have used AtomicLong many times but I have never needed to use AtomicReference
It seems that AtomicReference does either (I copied this code from another stackoverflow
question):
public synchronized boolean compareAndSet(List<Object> oldValue, List<Object> newValue) {
if (this.someList == oldValue) {
// someList could be changed by another thread after that compare,
// and before this set
this.someList = newValue;
return true;
}
return false;
}
Or
public synchronized boolean compareAndSet(List<Object> oldValue, List<Object> newValue) {
if (this.someList == oldValue || this.someList.equals(oldValue)) {
// someList could be changed by another thread after that compare,
// and before this set
this.someList = newValue;
return true;
}
return false;
}
Assume this.someList is marked volatile.
I’m not sure really which one it is because the javadoc and the code for that class are not clear if .equals is used.
Seeing how the above methods are not exactly that hard to write has anyone ever used AtomicReference?
It’s a reference, so that’s what is compared. The documentation makes it very clear that it’s an identity comparison, even using the
==operation in its description.I use
AtomicReferenceand other atomic classes very frequently. Profiling shows that they perform better than the equivalent methods using synchronization. For example, aget()operation on anAtomicReferencerequires only a fetch from main memory, while a similar operation usingsynchronizedmust first flush any values cached by threads to main memory and then perform its fetch.The
AtomicXXXclasses provide access to native support for compare-and-swap (CAS) operations. If the underlying system supports it, CAS will be faster than any scheme cooked up withsynchronizedblocks in pure Java.