看JUC工具源码突然发现没用volatile关键字修饰这些变量，哼哼，有点意思。你是在诱惑我小叮当。
为什么count不需要使用volatile修饰，如何保证其可见性？
我们知道AQS实现的锁可见性依赖于对volatile state变量的读写触发内存屏障来保证。
究其原因，是count变量由default修饰，count只对当前类或package中子类方法可见。即，对count的读写方法中都触发了内存屏障操作，也因此得以保证count变量对当前线程可见。
究其原理请听我娓娓道来。
试一试
我们根据上述的理论来编写代码，以验证我们的猜想。
在此之前，你应该知道：
- 以下示例代码都可运行。
- Java内存模型的规则。
例1，volatile变量具有可见性！！！
public static volatile boolean b = true;
new Thread(() -> {
try {Thread.sleep(100);} catch (InterruptedException e) {}
b = false;
}, "线程2").start();
new Thread(() ->{
while (b) { // 可见线程1对b的修改
}
}, "线程2").start();
线程对volatile修饰的变量进行写：
（1）将工作内存修改了的缓存（不仅仅是该变量的缓存）都强制刷新回主内存。
（2）把其他CPU对应缓存行标记为invalid状态，那么在读取这一部分缓存时，必须回主内存读取。这样也
就保证了线程间的可见性。
例2，lock与unlock之间的变量被修改后，仍旧对其它线程不可见！！！（文末解释）
例如：
public static boolean b = true;
new Thread(() -> {
try {Thread.sleep(100);} catch (InterruptedException e) {} // 先让线程2启动并缓存变量b
lock.lock();
b = false; // 如果变量b不是volatile，这里修改解锁后，仍然对其它线程（"线程2"）不可见
lock.unlock(); // 解锁之后，线程2仍然会继续运行
}, "线程1").start();
new Thread(() ->{
while (b) { // 线程2人就使用缓存中的b变量
}
}, "线程2").start(); // 线程死循环
使用JUC的锁（ReentrantLock）、synchronized都不能保证加解锁范围内的非volatile变量对其它线程可见，需要显示地将变量声明为volatile，或其它线程显示的使用锁或CAS强制读取最新值。
例3，lock与unlock之间的变量被修改后，对有lock与unlock操作的线程可见！！！
例如：
public static boolean b = true;
new Thread(() -> {
try {Thread.sleep(100);} catch (InterruptedException e) {}
lock.lock();
b = false; // 如果变量b不是volatile，这里修改解锁后，仍然对其它线程（"线程2"）不可见
lock.unlock();
}, "线程1").start();
new Thread(() ->{
while (b) {
lock.lock(); // 单纯的加锁与解锁，就能保证变量b的可见性
lock.unlock(); // 解锁后，在下一次循环当前线程能读到b的最新值
}
}, "线程2").start();
A类的成员变量b，线程1在lock块中修改A.b，在lock块离开前触发volatile的修改，会把修改的值从工作内存flush到主内存中，然后当线程2在lock块中读取A.b，工作内存会被设置无效，所以从主内存中读取它的实际值，这样完成了A.b的可见性。
例4，变量被修改后，对有lock与unlock操作的线程可见！！！
public static boolean b = true;
ReentrantLock lock = new ReentrantLock();
new Thread(() -> {
try {Thread.sleep(100);} catch (InterruptedException e) {}
b = false; // 未使用锁对b进行修改
}).start();
new Thread(() ->{
while (b) { // 脏读，b=true
lock.lock(); // 从主存最新读
lock.unlock();
}
}).start();
在进入锁时，会去主存中读取此时的最新数据，退出锁时将当前更新刷新到主存中。
Java volatile
字节码层面如何处理volatile？
编译源码（javac xxx）：
public volatile int a = 0; // Java API volatile
public int b = 0;
反编译（javap -v xxx）：
public volatile int a;
descriptor: I
flags: (0x0041) ACC_PUBLIC, ACC_VOLATILE
public int b;
descriptor: I
flags: (0x0001) ACC_PUBLIC
注意：若需要反编译查看ACC_VOLATILE，必须使用非private修饰变量，不然反编译信息会忽略该部分字节码信息。
因此，我们可以得出，字节码层面使用ACC_VOLATILE来表示volatile变量。
JVM层面如何处理volatile？
我们知道 volatile 提供可见性与有序性支持，即内存读和内存写与禁止编译重排序。
可见性，有硬件提供的内存读写屏障：
- Load：内存读，也就是加载操作(load)，从内存读到寄存器。
- Store：到内存写，也就是存储操作(store)，直接从寄存器写入到内存。
JVM 为了避免编译器和处理器对代码或指令进行重排序，保证 as-if-serial 语义，于是使用了内存屏障。为了保证并发，在简单的硬件屏障读写上进行了细化：
- LoadLoad：操作序列 Load1, LoadLoad, Load2，保证 1、2 顺序读如缓存。
- StoreStore：操作序列 Store1, StoreStore, Store2，保证 1、2 顺序写到内存。
- LoadStore：操作序列 Load1, LoadStore, Store2，保证 1、2 顺序读入缓存再写入内存。
- StoreLoad：操作序列 Store1, StoreLoad, Load2，保证 1、2 顺序写入内存再内存读入缓存。
接着看看 JVM 层面是如何实现 Load Barrier 和 Store Barrier 的：
OpenJDK的/src/hotspot/share/interpreter/bytecodeInterpreter.cpp。
...
CASE(_getfield):
CASE(_getstatic):
{
u2 index;
ConstantPoolCacheEntry* cache;
index = Bytes::get_native_u2(pc+1);
cache = cp->entry_at(index);
...
if (cache->is_volatile()) {
if (support_IRIW_for_not_multiple_copy_atomic_cpu) {
OrderAccess::fence(); // 读之前插入万能内初屏障
}
switch (tos_type) { // 根据字段类型进行读
...
}
}
...
}
CASE(_putfield):
CASE(_putstatic):
{
u2 index = Bytes::get_native_u2(pc+1);
ConstantPoolCacheEntry* cache = cp->entry_at(index);
...
if (cache->is_volatile()) {
if (cache->is_volatile()) {
switch (tos_type) { // 根据字段类型进行写
...
}
}
...
OrderAccess::storeload(); // 写之后插入万能内存屏障
}
...
}
根据OrderAccess::fence()的实现，我们可以看到：针对不同架构的处理器，OpenJDK 中提供了不同平台对 OrderAccess::fence() 的代码实现，屏蔽了底层硬件的差异，为 JVM 提供了统一的 CPP 层面的 API。
我们任意找一个 OrderAccess 的实现，比如来看Linux_x86上的实现：
#ifndef OS_CPU_LINUX_X86_ORDERACCESS_LINUX_X86_HPP
#define OS_CPU_LINUX_X86_ORDERACCESS_LINUX_X86_HPP
static inline void compiler_barrier() {
// 内嵌汇编，格式：__asm__ (汇编语句模板: 输出部分: 输入部分: 破坏描述部分)
__asm__ volatile ("" : : : "memory"); // 编译屏障
// volatile ：告诉GCC编译器，禁止重排序
// ("" : : : "memory")：告诉GCC编译器，禁止"memory"前后代码重排序、缓存作废，需要时再内存读
}
inline void OrderAccess::loadload() { compiler_barrier(); }
inline void OrderAccess::storestore() { compiler_barrier(); }
inline void OrderAccess::loadstore() { compiler_barrier(); }
inline void OrderAccess::storeload() { fence(); }
inline void OrderAccess::acquire() { compiler_barrier(); }
inline void OrderAccess::release() { compiler_barrier(); }
inline void OrderAccess::fence() {
// always use locked addl since mfence is sometimes expensive 内存屏障消耗的资源大于locked指令
#ifdef AMD64
__asm__ volatile ("lock; addl $0,0(%%rsp)" : : : "cc", "memory");
#else
// StoreLoad 屏障
// 对指定寄存器+0，空操作，为了使用lock而使用
// x84平台，基于MESI，致使该缓存行中数据在其他CPU中失效
__asm__ volatile ("lock; addl $0,0(%%esp)" : : : "cc", "memory");
#endif
compiler_barrier();
}
inline void OrderAccess::cross_modify_fence_impl() {
if (VM_Version::supports_serialize()) {
__asm__ volatile (".byte 0x0f, 0x01, 0xe8\n\t" : : :); //serialize
} else {
int idx = 0;
#ifdef AMD64
__asm__ volatile ("cpuid " : "+a" (idx) : : "ebx", "ecx", "edx", "memory");
#else
// On some x86 systems EBX is a reserved register that cannot be
// clobbered, so we must protect it around the CPUID.
__asm__ volatile ("xchg %%esi, %%ebx; cpuid; xchg %%esi, %%ebx " : "+a" (idx) : : "esi", "ecx", "edx", "memory");
#endif
}
}
#endif // OS_CPU_LINUX_X86_ORDERACCESS_LINUX_X86_HPP
综上，我们便知道 storeload 开销是四种屏障中最大的，且在大多数处理器的实现中，这个屏障是个万能屏障，兼具其它三种内存屏障的功能（见代码）。
Java CAS
Java层面CAS API，Unsafe#CAS
JVM层面CAS
UNSAFE_ENTRY(jboolean, Unsafe_CompareAndSwapInt(JNIEnv *env, jobject unsafe, jobject obj, jlong offset, jint e, jint x))
Atomic::cmpxchg(x, addr, e)
Linux_x86_JVM平台中对CAS接口C++的实现：
#define LOCK_IF_MP(mp) "cmp $0, " #mp "; je 1f; lock; 1: "
inline jint Atomic::cmpxchg (jint exchange_value, volatile jint* dest, jint compare_value) {
int mp = os::is_MP(); // multi processor的缩写，mp核心数
// 内嵌汇编
// volatile：禁用GCC编译优化
// LOCK_IF_MP：判断当前系统是否为多核处理器决定是否为cmpxchg指令添加lock前缀
// cmpxchgl：CPU原语，实现原子CAS功能
asm volatile (LOCK_IF_MP(%4) "cmpxchgl %1,(%3)"
: "=a" (exchange_value)
: "r" (exchange_value), "a" (compare_value), "r" (dest), "r" (mp)
: "cc", "memory"); // 同上内存屏障的实现
return exchange_value;
}
可以得出结论，x86中Java CAS是通过lock+cmpxchg两条指令实现的。使得CAS兼具volatile读写的内存语义与原子性，即我们在前文中所说的CAS保证可见性与原子性。
Java CAS的缺陷
-
ABA问题
介绍的文章较多，也比较基础，不再赘述。
-
没有编译支持（对例2的解释）
我们观察C++中Atomic::cmpxchg实现便可知，多核CPU中光用lock+cmpxchg指令来保证原子、可见和禁止重排序是不够的，还需要C++在asm后紧跟volatile提供禁止GCC重排序功能。而Java volatile与Java CAS相比，Java CAS还缺失了Java volatile具有的禁止重排序功能，为什么？？？Java CAS用到了C++的volatile吗？没错，至少在JVM的C++层面实现是相同的，但是Java属于编译+解释型语言，Java在编译具有volatile的属性get/set时会自动添加能触发内存屏障的指令！！！而对于Java CAS操作的变量，你就只能每次都手动触发内存屏障！！！使用CAS操作属性，稍有疏漏，必将埋下BUG，如例2。因此，我们Java CAS总是和volatile搭配使用，以获得Java层面的编译支持，提供完整的JMM happens-before语义。
如果你运行过例2的代码后，想必你会发现一些问题：例2中"线程2"一直死循环。
疑问：聪明的你应该会想起，ReentrantLock加解锁中涉及了CAS操作，而CAS操作会清除工作区域的缓存，然而为什么对"线程2"来说却无效呢？
动手试一试：将"线程1"中换成CAS来修改变量b，"线程2"同样不可见b。
主要原因："线程2"中并没有涉及到任何内存屏障操作，于是"线程2"对变量b便一直缓存读，这也就是导致"线程2"一直循环的原因。也就是说，被CAS操作的变量，以及lock~unlock之间的变量，编译器在编译时是没有额外增加内存屏障操作的。如果读取被CAS修改的变量或lock~unlock之间的变量，且读取线程也没有触发对内存屏障的操作，那么这部分被读取的变量对该线程来说是不具备可见性的。
解决方法：volatile具有编译支持，编译器会对volatile变量的读写自动添加内存屏障，对这部分变量我们对齐添加volatile修饰，也就是CAS要与volatile结合使用。
或者通过其它方式在读取线程手动触发一次内存屏障的操作。比如，lock|unlock、synchronized、CAS等。
——附——
C++ volatile
-
与外部硬件交流（比如 DMA 或 MMIO）——引用设备寄存器的变量时使用，避免编译优化器无意删除重要的访问。
-
禁止编译重排序。
参考：https://docs.oracle.com/cd/E36784_01/html/E36860/codingpractices-1.html
asm volatile (“” : : : “memory”)
给 GCC 内嵌汇编加上一个内存破坏性描述符，禁止优化、禁止缓存读。
-
编译内存屏障：这条语句后面的语句不能被编译器优化到前面去，前面的不能被优化到后面去——这是所有内嵌汇编都具有的效果。
-
禁止所在函数被inline：不管开多高的优化等级， 这也是所有内嵌汇编都具有的效果。但是这一点目前也渐渐被gcc新版本打脸了。。
-
强制内存读：重点，这条语句之后，函数返回前的所有流程（也就是包括了循环语句 跳转到这条语句前面去的场景），对所有地址的访问（包括局部变量地址）都必须去内存里去 load，而不能使用这条语句前寄存器缓存的结果（当然，某些寄存器的结果编译器还是认为还是有效的，例如堆栈寄存器，不然代码没法走下去了）。
参考：https://www.zhihu.com/question/66896665/answer/249586507
lock指令
Intel手册——LOCK前缀使得cache写入内存，同时使得其它核的cache无效化。
- 将当前处理器缓存行的数据写回主存。
- 缓存一致性协议生效：在其他处理器缓存了该数据的缓存行的无效化。
参考：https://stackoverflow.com/questions/27837731/is-x86-cmpxchg-atomic-if-so-why-does-it-need-lock/44273130#44273130
Java volatile
在Java中的语义是：变量读写原子性（例：64 Long）、禁止指令重排序（编译与处理）、跨线程内存可见性（Happens-Before）。
由 C++ volatile、asm volatile (“” : : : “memory”) 和 lock 联合实现，因此 Java volatile 也就实现了：
- （弱）原子性（lock：锁总线），32 位机器上的 long | double 读写原子（64 无需），且不能保证 Java 层面的原子性。观察 x84_64 的实现可以发现，volatile 甚至连单条字节码的读写原子都不能保证（即，用 i++ 生成 3 条字节码举例是错误的❌），只能保证底层代码执行时的单次读写可见性。例如字节码 putfield | getfield 操作 volatile 变量中，C++用了大段落代码来实现，且并未加锁！这期间完全有可能与其它线程并发执行，因此 volatile 想要得到完整的原子性支持必须搭配 synchronized 使用！synchronized 基于互斥锁思想，提供线程安全的临界点。且 synchronized 与 volatile 互补，synchronized 不能为临界区中非 volatile 变量提供编译支持，volatile 能提供编译支持，保证线程之间对该变量的读写可见。
- 禁止重排序（fence：lock+compiler_barrier、compiler_barrier：asm、volatile）。
- 可见性（lock + 【MESI，MOSI，Synapse，Firefly 及 DragonProtocol等】），通过总线锁 + 缓存一致性协议实现。
642
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
