When is it preferable to use volatile boolean in Java rather than AtomicBoolean? [duplicate]

Question

I've looked at the other volatile vs. Atomicxxxx questions in SO (including this one) and have read the description of java.util.current.atomic, and I am not quite satisfied with the nuances.

If I'm trying to decide between using volatile boolean and AtomicBoolean, are there practical differences besides the atomic read-modify-write operations offered by AtomicBoolean? (e.g. compareAndSet() and getAndSet())

Suppose I have

volatile boolean flag; 

Then one or more threads set the flag (but not clear it). If I have one thread that reads the flag, and if set, does an action, and then clears the flag, is volatile adequate?

Is there a higher cost to AtomicBoolean than volatile boolean, in terms of

• memory space
• performance hit (volatile boolean appears to require memory fencing, AtomicBoolean appears to require memory fencing + some minor locking on CAS operations as per the java.util.current.atomic description)

My gut call is to just go with AtomicBoolean and be safe, but I want to understand if there's ever a situation to use volatile boolean instead (e.g. if I had thousands of instances of them and performance were an issue).

Answer 1

The main difference between AtomicBoolean and volatile from a practical point of view is that the compare-and-set operation isn't atomic with volatile variables.

 volatile boolean b;   void foo() {    if( b ) {      //Here another thread might have already changed the value of b to false      b = false;    }  } 

But seeing as all your concurrent writes are idempotent and you only read from one thread, this shouldn't be a problem.