Volatile boolean vs AtomicBoolean
The Atomic* classes wrap a volatile primitive of the same type. From the source:
public class AtomicLong extends Number implements java.io.Serializable {
...
private volatile long value;
...
public final long get() {
return value;
}
...
public final void set(long newValue) {
value = newValue;
}
So if all you are doing is getting and setting a Atomic* then you might as well just have a volatile field instead.
What does AtomicBoolean do that a volatile boolean cannot achieve?
Atomic* classes give you methods that provide more advanced functionality such as incrementAndGet() for numbers, compareAndSet() for booleans, and other methods that implement multiple operations (get/increment/set, test/set) without locking. That's why the Atomic* classes are so powerful.
For example, if multiple threads are using the following code using ++, there will be race conditions because ++ is actually: get, increment, and set.
private volatile value;
...
// race conditions here
value++;
However, the following code will work in a multi-threaded environment safely without locks:
private final AtomicLong value = new AtomicLong();
...
value.incrementAndGet();
It's also important to note that wrapping your volatile field using Atomic* class is a good way to encapsulate the critical shared resource from an object standpoint. This means that developers can't just deal with the field assuming it is not shared possibly injecting problems with a field++; or other code that introducing race conditions.