非volatile成员执行compareAndSwap操作的内存语义探讨——基于JDK1.8 AbstractQueuedSynchronizer的疑问

Great question—let’s break this down clearly, since the interaction between CAS operations and memory semantics is a common point of confusion when digging into AQS.

Question 1: Does CAS on a non-volatile field still have volatile read/write semantics? #

Short answer: Yes, it does.

The Unsafe.compareAndSwapInt method (and other CAS variants in Unsafe) inherently provides the same memory semantics as a volatile read followed by a conditional volatile write—regardless of whether the target field is marked volatile.

Here’s why:

• At the hardware level, CAS operations (like the LOCK CMPXCHG instruction on x86) enforce cache coherence. The LOCK prefix ensures that the read-modify-write operation is atomic and flushes any cached values to main memory, making the update visible to all threads immediately.
• From the Java Memory Model (JMM) perspective, the JDK specifies that Unsafe's CAS operations act as volatile memory barriers. The read of the current field value is a volatile read (so it sees the latest value from main memory), and if the swap succeeds, the write is a volatile write (so all threads will see the updated value).

This means even if you run CAS on a regular non-volatile int field, that specific CAS operation will have the same memory visibility guarantees as if the field was volatile.

Question 2: What would the memory semantics of compareAndSetState be if state was non-volatile? #

If the state field in AQS was not marked volatile, the compareAndSetState method would still retain its volatile read/write semantics—because those semantics come from the underlying Unsafe.compareAndSwapInt call, not the state field's volatility.

However, there’s a critical caveat:

• Direct reads of the non-volatile state field (like a simple return state in a hypothetical non-volatile getState method) would not have volatile read semantics. Threads might see stale cached values of state unless they use CAS or another memory barrier operation to access it.
• Direct writes to state (like state = newValue without CAS) would also lack volatile write semantics, so updates wouldn’t be immediately visible to other threads.

In AQS, the state field is marked volatile precisely so that all accesses (not just CAS operations) have consistent volatile memory semantics. This ensures that even simple reads/writes of state (like checking if the lock is held) are thread-safe and visible across threads.

内容的提问来源于stack exchange，提问作者liuchiself