AtomicInteger and equals / Comparable
As you may have noticed, two
AtomicBoolean) are never equal:
AtomicInteger i1 = new AtomicInteger(0);
AtomicInteger i2 = new AtomicInteger(0);
System.out.println(i1.equals(i2)); // false
This is because
AtomicInteger doesn't override
equals, which means it inherits the behavior from
Object.equals which has the same semantics as
Same story for
So why is that?
The package summary states that this is an explicit design decision:
These classes are not general purpose replacements for
java.lang.Integerand related classes. They do not define methods such as
compareTo. Because atomic variables are expected to be mutated, they are poor choices for hash table keys.
Here's what Doug Lea, the principal author of the
java.util.concurrent package, wrote on the matter (source):
While I can't think offhand of any application where I'd use AtomicIntegers as keys in a hash table (HashMap, Hashtable, ConcurrentHashMap), if I did, I would surely want to be able to find them even if they changed value. Using the default identity-based hashCode and equals methods provides this; so normal usages would almost always be correct, while with value-based versions, they almost never would be. And given this, because you aren't supposed to define a compareTo that returns 0 (equals) in different cases than when equals returns true, the only option is not to provide it. Doug Lea
It also doesn't implement
Comparable as you may expect when comparing it with the
The reason for this is covered in the same email thread as mentioned above (source).
Dawid KurzyniecBecause you cannot rely on the result of the comparison anyway, since the values may be immediately changed by other threads after you compare but before you use the comparison result. To avoid this, you would have to use locking, and those classes exist precisely to avoid locking. In particular, comparable suggests that you can sort objects of this type, and the sort operation assumes that these objects are constant (at least for some time), which is clearly the opposite of why those classes are to be used. Again, you would have to lock to make sure that the values do not change at least _during_ sorting.