synchronized

1.为什么要使用锁

内存1 当前值2 期待值3

悲观锁: 我觉得你这一次的修改会造成线程问题: 来个锁:我在修改某个值的时候,别人不能对它进行任何修改操作,通过枷锁,

乐观锁: 我觉得你这一次的修改不会造成线程问题:我在改某个值的时候,你也可以来改,

public class SynchronizedTest {

 

    public static volatile int race = 0;

 

    private static CountDownLatch countDownLatch = new CountDownLatch(2);

 

    public static void main(String[] args) throws InterruptedException {

        // 循环开启2个线程来计数

        for (int i = 0; i < 2; i++) {

            new Thread(() -> {

                // 每个线程累加1万次

                for (int j = 0; j < 10000; j++) {

                    race++;

                }

                countDownLatch.countDown();

            }).start();

        }

        // 等待，直到所有线程处理结束才放行

        countDownLatch.await();

        // 期望输出 2万（2*1万）

        System.out.println(race);

    }

}

每个线程自增1万次，预期的结果是2万，但是实际运行结果总是一个小于等于2万的数字

为了得到正确的结果，此时我们可以将 race++ 使用 synchronized 来修饰，如下：

synchronized (SynchronizedTest.class) {

    race++;

}

加了 synchronized 后，只有抢占到锁才能对 race 进行操作，此时的流程会变成如下：

2.synchronized 各种加锁场景

1）作用于非静态方法，锁住的是对象实例（this），每一个对象实例有一个锁。

public synchronized void method() {}

2）作用于静态方法，锁住的是类的 Class 对象，Class 对象全局只有一份，因此静态方法锁相当于类的一个全局锁，会锁所有调用该方法的线程。

public static synchronized void method() {}

3）作用于 Lock.class，锁住的是 Lock(类名) 的 Class 对象，也是全局只有一个。

synchronized (Lock.class) {}

4）作用于 this，锁住的是对象实例，每一个对象实例有一个锁。

synchronized (this) {}

5）作用于静态成员变量，锁住的是该静态成员变量对象，由于是静态变量，因此全局只有一个。

public static Object monitor = new Object();  

synchronized (monitor) {}

记住以下两点：

1）必须有“对象”来充当“锁”的角色。

2）对于同一个类来说，通常只有两种对象来充当锁：实例对象、Class 对象（一个类全局只有一份）。

Class 对象：静态相关的都是属于 Class 对象，还有一种直接指定 Lock.class。

实例对象：非静态相关的都是属于实例对象。

3.Object 的 wait/notify/notifyAll 方法

“sleep 和 wait 的区别”非常重要的一项是：“wait会释放对象锁，sleep不会”，既然要释放锁，那必然要先获取锁。究其原因，因为这3个方法都会操作锁对象，所以需要先获取锁对象，而加 synchronized 锁可以让我们获取到锁对象。

来看一个例子：

public class SynchronizedTest {

 

    private static final Object lock = new Object();

 

    public static void testWait() throws InterruptedException {

        lock.wait();

    }

 

    public static void testNotify() throws InterruptedException {

        lock.notify();

    }

}

在这个例子中，wait 会释放 lock 锁对象，notify/notifyAll 会唤醒其他正在等待获取 lock 锁对象的线程来抢占 lock 锁对象。

既然你想要操作 lock 锁对象，那必然你就得先获取 lock 锁对象。就像你想把苹果让给其他同学，那你必须先拿到苹果。

再来看一个反例：

public class SynchronizedTest {

 

    private static final Object lock = new Object();

 

    public static synchronized void getLock() throws InterruptedException {

        lock.wait();

    }

}

该方法运行后会抛出 IllegalMonitorStateException

因为在 getLock 静态方法中加 synchronized 方法获取到的是 SynchronizedTest.class 的锁对象，而我们的 wait() 方法是要释放 lock 的锁对象。

这就相当于你想让给其他同学一个苹果（lock），但是你只有一个梨子（SynchronizedTest.class）。

synchronized 锁，那当某个线程调用了 wait 的时候明明还在 synchronized 块里，其他线程怎么进入到 synchronized 里去执行 notify 的

当线程进入 synchronized 时，需要获取 lock 锁，但是在调用 lock.wait() 的时候，此时虽然线程还在 synchronized 块里，但是其实已经释放掉了 lock 锁。

所以，其他线程此时可以获取 lock 锁进入到 synchronized 块，从而去执行 lock.notify()。

public class SynchronizedTest {

 

    private static final Object lock = new Object();

 

    public static void testWait() throws InterruptedException {

        synchronized (lock) {

            // 阻塞住，被唤醒之前不会输出aa，也就是还没离开synchronized

            lock.wait();

            System.out.println("aa");

        }

    }

 

    public static void testNotify() throws InterruptedException {

        synchronized (lock) {

            lock.notify();

            System.out.println("bb");

        }

    }

}

4.阻塞

synchronized 底层对应的 JVM 模型为 objectMonitor，使用了3个双向链表来存放被阻塞的线程： _cxq（Contention queue）、_EntryList（EntryList）、_WaitSet（WaitSet）

当线程获取锁失败进入阻塞后，首先会被加入到 _cxq 链表，_cxq 链表的节点会在某个时刻被进一步转移到 _EntryList 链表。

当持有锁的线程释放锁后，_EntryList 链表头结点的线程会被唤醒，该线程称为 successor（假定继承者），然后该线程会尝试抢占锁。

当我们调用 wait() 时，线程会被放入 _WaitSet，直到调用了 notify()/notifyAll() 后，线程才被重新放入 _cxq 或 _EntryList，默认放入 _cxq 链表头部。

objectMonitor 的整体流程如下图：

被唤醒的线程并不是就一定获取到锁了，该线程仍然需要去竞争锁，而且可能会失败，所以该线程并不是就一定会成为锁的“继承者”，而只是有机会成为，所以我们称它为假定的。

这也是 synchronized 为什么是非公平锁的一个原因。

非公平体现在

1）当持有锁的线程释放锁时，该线程会执行以下两个重要操作：

先将锁的持有者 owner 属性赋值为 null
唤醒等待链表中的一个线程（假定继承者）。

在1和2之间，如果有其他线程刚好在尝试获取锁（例如自旋），则可以马上获取到锁。

2）当线程尝试获取锁失败，进入阻塞时，放入链表的顺序，和最终被唤醒的顺序是不一致的，也就是说你先进入链表，不代表你就会先被唤醒。

进入 wait 状态后，线程调用 notify 唤醒顺序

调用 wait 时，节点进入_WaitSet 链表的尾部。

调用 notify 时，根据不同的策略，节点可能被移动到 cxq 头部、cxq 尾部、EntryList 头部、EntryList 尾部等多种情况。

所以，唤醒的顺序并不一定是进入 wait 时的顺序。

notifyAll 是怎么实现全唤起

nofity 是获取 WaitSet 的头结点，执行唤起操作。

nofityAll 的流程，简单的理解为就是循环遍历 WaitSet 的所有节点，对每个节点执行 notify 操作。

cxq 链表和 _EntryList 链表的排队策略

可以认为是在持有锁的线程释放锁时，该线程需要去唤醒链表中的下一个线程节点，此时如果检查到 _EntryList 为空，并且 _cxq 不为空时，会将 _cxq 链表的节点转移到 _EntryList 中。

不过也不全是这样，_cxq 链表和 _EntryList 链表的排队策略的排队策略（QMode）和执行顺序如下：

1）当 QMode = 2 时，此时 _cxq 比 EntryList 优先级更高，如果此时 _cxq 不为空，则会首先唤醒 _cxq 链表的头结点。除了 QMode = 2 之外，其他模式都是唤醒 _EntryList 的头结点。

2）当 QMode = 3 时，无论 _EntryList 是否为空，都会直接将 _cxq 链表中的节点转移到 _EntryList 链表的末尾。

3）当 QMode = 4 时，无论 _EntryList 是否为空，都会直接将 _cxq 链表中的节点转移到 _EntryList 链表的头部。

4）执行到这边，如果 _EntryList 不为空，则直接唤醒 _EntryList 的头结点并返回，如果此时 _EntryList 为空，则继续执行。

5）执行到这边，代表此时 _EntryList 为空。

6）当 QMode = 1 时，将 _cxq 链表的节点转移到 _EntryList 中，并且调换顺序，也就是原来在_cxq 头部，会变到 _EntryList 尾部。

7）剩余情况，将 _cxq 链表的节点转移到 _EntryList 中，并且节点顺序一致。

8）如果此时 _EntryList 不为空，则唤醒 _EntryList 的头结点。

5.锁的4种状态

无锁，不锁住资源，多个线程只有一个能修改资源成功，其他线程会重试；

偏向锁，同一个线程获取同步资源时，没有别人竞争时，去掉所有同步操作，相当于没锁；

只有一个线程可以得到偏向锁

轻量级锁，多个线程抢夺同步资源时，没有获得锁的线程使用CAS自旋等待锁的释放；

重量级锁，多个线程抢夺同步资源时，使用操作系统的互斥量进行同步，没有获得锁的线程阻塞等待唤醒；

锁的不同状态，就是存在对象头中的Mark Word区域中

锁的升级过程：无锁-》偏向锁-》轻量级锁-》重量级锁。注意，升级并不一定是一级级升的，有可能跨级别，比如由无锁状态，直接升级为轻量级锁。

1、无锁状态：

步骤说明：

1.synchronized锁的object对象头部markword区域，最开始锁状态标志位，默认值就是001，也就是无锁状态。

2、偏向锁状态：

某刻，线程1执行到同步代码块，虚拟机会使用CAS尝试修改状态标志位，修改为偏向锁状态，并且把线程1的线程ID记录到markword区域的23bit位，进入偏向锁状态，如下图：

进入偏向锁状态后，如果没有其他线程竞争，线程1后续再次访问同步代码块时，犹如没有锁一样，jvm不会再进行CAS加锁、解锁等步骤，直接运行同步块代码。直到线程1执行完毕后，jvm会释放偏向锁。

3、轻量级锁状态：

线程1在持有偏向锁期间，线程2来了，下图右侧部分是线程2执行过程：

线程2访问同步代码块，尝试获取锁；此时jvm会检查线程1的状态，因为线程1还持有锁，jvm不能撤销线程1的锁，此时，jvm就会把锁升级为轻量级锁，也就是这个23bit区域存了线程1的地址，指向线程1的线程栈中的某块区域；同时线程栈的这块内存也保存了指向markword的引用，相当于两块区域互换了内容。

上文中描述的过程，是由无锁，然后变为偏向锁，然后是轻量级锁；

但是有些场景，锁会直接由无锁升级为轻量级锁，比如下图过程：

上图中，某一时刻，同时有两个线程执行到同步代码块，但实际肯定只能有一个线程先进入，假如是线程1，那么此时就会直接进轻量级锁状态。

4、重量级锁状态：

轻量级锁阶段并没有自旋操作，在轻量级锁阶段，只要发生竞争，就是直接膨胀成重量级锁。

而在重量级锁阶段，如果获取锁失败，则会尝试自旋去获取锁。如果多次尝试后还是失败，则将该线程封装成 ObjectWaiter，插入到 cxq 链表中，当前线程进入阻塞状态

线程1执行完同步代码块，jvm尝试释放锁，修改markword为初始的无锁状态，在释放锁的时候，发现已经是重量锁了，说明有其他线程竞争，并且其他线程肯定已经进入了阻塞状态，那么jvm在释放锁之后，还会唤醒其他进入阻塞状态的线程。

为什么要引入偏向锁和轻量级锁？为什么重量级锁开销大？

重量级锁底层依赖于系统的同步函数来实现，在 linux 中使用 pthread_mutex_t（互斥锁）来实现。

这些底层的同步函数操作会涉及到：操作系统用户态和内核态的切换、进程的上下文切换，而这些操作都是比较耗时的，因此重量级锁操作的开销比较大。

而在很多情况下，可能获取锁时只有一个线程，或者是多个线程交替获取锁，在这种情况下，使用重量级锁就不划算了，因此引入了偏向锁和轻量级锁来降低没有并发竞争时的锁开销。

偏向锁有撤销、膨胀，性能损耗这么大为什么要用呢

偏向锁的好处是在只有一个线程获取锁的情况下，只需要通过一次 CAS 操作修改 markword ，之后每次进行简单的判断即可，避免了轻量级锁每次获取释放锁时的 CAS 操作。

如果确定同步代码块会被多个线程访问或者竞争较大，可以通过 -XX:-UseBiasedLocking 参数关闭偏向锁。

1）偏向锁

适用于只有一个线程获取锁。当第二个线程尝试获取锁时，即使此时第一个线程已经释放了锁，此时还是会升级为轻量级锁。但是有一种特例，如果出现偏向锁的重偏向，则此时第二个线程可以尝试获取偏向锁。

2）轻量级锁

适用于多个线程交替获取锁。跟偏向锁的区别在于可以有多个线程来获取锁，但是必须没有竞争，如果有则会升级会重量级锁。

3）重量级锁

适用于多个线程同时获取锁。

为什么要设计自旋操作

因为重量级锁的挂起开销太大。

一般来说，同步代码块内的代码应该很快就执行结束，这时候竞争锁的线程自旋一段时间是很容易拿到锁的，这样就可以节省了重量级锁挂起的开销。

自适应自旋

自适应自旋锁有自旋次数限制，范围在：1000~5000。

如果当次自旋获取锁成功，则会奖励自旋次数100次，如果当次自旋获取锁失败，则会惩罚扣掉次数200次。

所以如果自旋一直成功，则JVM认为自旋的成功率很高，值得多自旋几次，因此增加了自旋的尝试次数。

相反的，如果自旋一直失败，则JVM认为自旋只是在浪费时间，则尽量减少自旋。

synchronized 锁降级

答案是可以的。

具体的触发时机：在全局安全点（safepoint）中，执行清理任务的时候会触发尝试降级锁。

当锁降级时，主要进行了以下操作：

1）恢复锁对象的 markword 对象头；

2）重置 ObjectMonitor，然后将该 ObjectMonitor 放入全局空闲列表，等待后续使用。

匿名偏向

所谓的匿名偏向是指该锁从未被获取过，也就是第一次偏向，此时的特点是锁对象 markword 的线程 ID 为0。

当第一个线程获取偏向锁后，线程ID会从0修改为该线程的 ID，之后该线程 ID 就不会为0了，因为释放偏向锁不会修改线程 ID。

这也是为什么说偏向锁适用于：只有一个线程获取锁的场景。

偏向锁模式下 hashCode 存放在哪里

偏向锁状态下是没有地方存放 hashCode 的。

因此，当一个对象已经计算过 hashCode 之后，就再也无法进入偏向锁状态了。

如果一个对象当前正处于偏向锁状态，收到需要计算其 hashCode 的请求时（Object::hashCode()或者System::identityHashCode（Object）方法的调用），它的偏向锁状态就会立即被撤销。

6.启发式算法

当只有一个线程获取锁时，偏向锁只需在第一次进入同步块时执行一次 CAS 操作，之后每次进入只需要简单的判断即可，此时的开销基本可以忽略。因此在只有一个线程获取锁的场景中，偏向锁的性能提升是非常可观的。

但是如果有其他线程尝试获得锁时，此时需要将偏向锁撤销为无锁状态或者升级为轻量级锁。偏向锁的撤销是有一定成本的，如果我们的使用场景存在多线程竞争导致大量偏向锁撤销，那偏向锁反而会导致性能下降。

观点1：对于某些对象，偏向锁显然是无益的。例如涉及两个或更多线程的生产者-消费者队列。这样的对象必然有锁竞争，而且在程序执行过程中可能会分配许多这样的对象。

该观点描述的是锁竞争比较多的场景，对这种场景，一种简单粗暴的方法是直接禁用偏向锁，但是这种方式并不是最优的。

因为在整个服务中，可能只有一小部分是这种场景，因为这一小部分场景而直接放弃偏向锁的优化，显然是不划算的。最理想的情况下是能够识别这样的对象，并只为它们禁用偏向锁。

观点2： 在某些情况下，将一组对象重新偏向另一个线程是有好处的。特别是当一个线程分配了许多对象并对每个对象执行了初始同步操作，但另一个线程对它们执行了后续工作。

批量重偏向

JVM 选择以 class 为粒度，为每一个 class 维护了一个偏向锁撤销计数器。每当该 class 的对象发生偏向锁撤销的时候，计数器值+1。

当计数器的值超过批量重偏向的阈值（默认20）的时候，JVM 认为此时命中了上述的场景2，就会对整个 class 进行批量重偏向。

每个 class 都会有 markword，当处于偏向锁状态时，markword 会有 epoch 属性，当创建该 class 的实例对象时，实例对象的 epoch 值会赋值为 class 的 epoch 值，也就是说正常情况下，实例对象的 epoch 和 class 的 epoch 是相等的。

当发生批量重偏向时，首先会将 class 的 epoch 值+1，接着遍历所有当前存活的线程的栈，找到该 class 所有正处于偏向锁状态的锁实例对象，将其 epoch 值修改为新值。

而那些当前没有被任何线程持有的锁实例对象，其 epoch 值则没有得到更新，此时会比 class 的 epoch 值小1。在下一次其他线程准备获取该锁对象的时候，不会因为该锁对象的线程ID不为0（也就是曾经被其他线程获取过），而直接升级为轻量级锁，而是使用 CAS 来尝试获取偏向锁，从而达到批量重偏向的优化效果。

批量撤销

批量撤销是批量重偏向的后续流程，同样是以 class 为粒度，同样使用偏向撤销计数器。

当批量重偏向后，每次进行偏向撤销时，会计算本次撤销时间和上一次撤销时间的间隔，如果两次撤销时间的间隔超过指定时间（25秒），则此时 JVM 会认为批量重偏向是有效果的，因为此时偏向撤销的频率很低，所以会将偏向撤销计数器重置为0。

而当批量重偏向后，偏向计数器的值继续快速增加（25秒内），当计数器的值超过批量撤销的阈值（默认40）时，JVM 认为该 class 的实例对象存在明显的锁竞争，不适合使用偏向锁，则会触发批量撤销操作。

批量撤销：将 class 的 markword 修改为不可偏向无锁状态，也就是偏向标记位为0，锁标记位为01。接着遍历所有当前存活的线程的栈，找到该 class 所有正处于偏向锁状态的锁实例对象，执行偏向锁的撤销操作。

这样当线程后续尝试获取该 class 的锁实例对象时，会发现锁对象的 class 的 markword 不是偏向锁状态，知道该 class 已经被禁用偏向锁，从而直接进入轻量级锁流程。

volatile

缓存一致性问题： 对于某个共享变量，每个操作单元都缓存一个该变量的副本。当一个操作单元更新其副本时，其他的操作单元可能没有及时发现，进而产生缓存一致性问题。

在Java中也有这样的案例。假设有一个变量a=1，它被3个线程所共享。Jvm在运行时，每个线程都会在自己的工作空间（高速缓存保存的副本，不是栈区）保存一份变量a的副本。如下图。

某个时刻，线程t1需要更新a=0。与此同时，线程t2需要读a的值，线程t3需要读a的值。由于这三个“动作”是并发进行的，很可能出现下面的结果：线程t2和线程t3仍然读到a=1。而我们希望的结果是，线程t2和线程t3读到a=0。但是，线程t2和线程t3何时再次从主内存中读取变量a的值是不受控制的。可能很快，也可能很慢。



package Test;



public class Test {



    /**

 * main 方法作为一个主线程

 */

 public static void main(String[] args) {

        MyThread myThread = new MyThread();

        // 开启线程

        myThread.start();



        // 主线程执行

        for (;  ; ) {

            if (myThread.isFlag()) {

                System.out.println("主线程访问到 flag 变量");

            }

        }

    }



}



 /**

 * 子线程类

 */

class MyThread extends Thread {



    private  boolean flag = false;



    @Override

    public void run() {

        try {

            Thread.sleep(1000);//保证主线程第一次读取是未修改的

        } catch (InterruptedException e) {

            e.printStackTrace();

        }

        // 修改变量值

        flag = true;

        System.out.println("flag = " + flag);

    }



    public boolean isFlag() {

        return flag;

    }



    public void setFlag(boolean flag) {

        this.flag = flag;

    }

}

Java 内存模型

JMM（Java Memory Model）：Java 内存模型，是 Java 虚拟机规范中所定义的一种内存模型，Java 内存模型是标准化的，屏蔽掉了底层不同计算机的区别。也就是说，JMM 是 ****JVM 中定义的一种并发编程的底层模型机制。

JMM 定义了线程和主内存之间的抽象关系：线程之间的共享变量存储在主内存中，每个线程都有一个私有的本地内存，本地内存中存储了该线程以读/写共享变量的副本。

JMM 的规定：

所有的共享变量都存储于主内存。这里所说的变量指的是实例变量和类变量，不包含局部变量，因为局部变量是线程私有的，因此不存在竞争问题。

每一个线程还存在自己的工作内存，线程的工作内存，保留了被线程使用的变量的工作副本。

线程对变量的所有的操作（读，取）都必须在工作内存中完成，而不能直接读写主内存中的变量。

不同线程之间也不能直接访问对方工作内存中的变量，线程间变量的值的传递需要通过主内存中转来完成。

JMM 的抽象示意图：

然而，JMM 这样的规定可能会导致线程对共享变量的修改没有即时更新到主内存，或者线程没能够即时将共享变量的最新值同步到工作内存中，从而使得线程在使用共享变量的值时，该值并不是最新的。

可见性问题的解决方案

两种方案：加锁 (synchronizer )和 使用 volatile 关键字。

因为当一个线程进入 synchronizer 代码块后，线程获取到锁，会清空本地内存，然后从主内存中拷贝共享变量的最新值到本地内存作为副本，执行代码，又将修改后的副本值刷新到主内存中，最后线程释放锁。

这里除了 synchronizer 外，其它锁也能保证变量的内存可见性。

使用 volatile 修饰共享变量后，每个线程要操作变量时会从主内存中将变量拷贝到本地内存作为副本，当线程操作变量副本并写回主内存后，会通过 CPU 总线嗅探机制告知其他线程该变量副本已经失效，需要重新从主内存中读取。

volatile 保证了不同线程对共享变量操作的可见性，也就是说一个线程修改了 volatile 修饰的变量，当修改后的变量写回主内存时，其他线程能立即看到最新值。

总线嗅探机制

在现代计算机中，CPU 的速度是极高的，如果 CPU 需要存取数据时都直接与内存打交道，在存取过程中，CPU 将一直空闲，这是一种极大的浪费，所以，为了提高处理速度，CPU 不直接和内存进行通信，而是在 CPU 与内存之间加入很多寄存器，多级缓存，它们比内存的存取速度高得多，这样就解决了 CPU 运算速度和内存读取速度不一致问题。

由于 CPU 与内存之间加入了缓存，在进行数据操作时，先将数据从内存拷贝到缓存中，CPU 直接操作的是缓存中的数据。但在多处理器下，将可能导致各自的缓存数据不一致（这也是可见性问题的由来），为了保证各个处理器的缓存是一致的，就会实现缓存一致性协议，而嗅探是实现缓存一致性的常见机制。

注意，缓存的一致性问题，不是多处理器导致，而是多缓存导致的。

嗅探机制工作原理：每个处理器通过监听在总线上传播的数据来检查自己的缓存值是不是过期了，如果处理器发现自己缓存行对应的内存地址修改，就会将当前处理器的缓存行设置无效状态，当处理器对这个数据进行修改操作的时候，会重新从主内存中把数据读到处理器缓存中。

注意：基于 CPU 缓存一致性协议，JVM 实现了 volatile 的可见性，但由于总线嗅探机制，会不断的监听总线，如果大量使用 volatile 会引起总线风暴。所以，volatile 的使用要适合具体场景。

volatile 的原子性问题

所谓的原子性是指在一次操作或者多次操作中，要么所有的操作全部都得到了执行并且不会受到任何因素的干扰而中断，要么所有的操作都不执行。

在多线程环境下，volatile 关键字可以保证共享数据的可见性，但是并不能保证对数据操作的原子性。也就是说，多线程环境下，使用 volatile 修饰的变量是线程不安全的。

要解决这个问题，可以使用锁机制，或者使用原子类（如 AtomicInteger）。

这里特别说一下，对任意单个使用 volatile 修饰的变量的读 / 写是具有原子性，但类似于 flag = !flag 这种复合操作不具有原子性。简单地说就是，单纯的赋值操作是原子性的。



package Test;

public class Test {

    public volatile int inc = 0;



    public  void increase() {

        inc++;

    }



    public static void main(String[] args) {

        final Test test = new Test();

        for(int i=0;i<10;i++){

            new Thread(){

                public void run() {

                    for(int j=0;j<1000;j++)

                        test.increase();

                };

            }.start();

        }



        while(Thread.activeCount()>2)  //保证前面的线程都执行完

            Thread.yield();

        System.out.println(test.inc);

    }

}

假如某个时刻变量inc的值为10，

线程1对变量进行自增操作，线程1先读取了变量inc的原始值，然后线程1被阻塞了；

然后线程2对变量进行自增操作，线程2也去读取变量inc的原始值，由于线程1只是对变量inc进行读取操作，而没有对变量进行修改操作，所以不会导致线程2的工作内存中缓存变量inc的缓存行无效，所以线程2会直接去主存读取inc的值，发现inc的值时10，然后进行加1操作，并把11写入工作内存，最后写入主存。

然后线程1接着进行加1操作，由于已经读取了inc的值，注意此时在线程1的工作内存中inc的值仍然为10，所以线程1对inc进行加1操作后inc的值为11，然后将11写入工作内存，最后写入主存。

那么两个线程分别进行了一次自增操作后，inc只增加了1。

解释到这里，可能有朋友会有疑问，不对啊，前面不是保证一个变量在修改volatile变量时，会让缓存行无效吗？然后其他线程去读就会读到新的值，对，这个没错。这个就是上面的happens-before规则中的volatile变量规则，但是要注意，线程1对变量进行读取操作之后，被阻塞了的话，并没有对inc值进行修改。然后虽然volatile能保证线程2对变量inc的值读取是从内存中读取的，但是线程1没有进行修改，所以线程2根本就不会看到修改的值。

禁止指令重排序

为了提高性能，在遵守 as-if-serial 语义（即不管怎么重排序，单线程下程序的执行结果不能被改变。编译器，runtime 和处理器都必须遵守。）的情况下，编译器和处理器常常会对指令做重排序。

一般重排序可以分为如下三种类型：

编译器优化重排序。编译器在不改变单线程程序语义的前提下，可以重新安排语句的执行顺序。

指令级并行重排序。现代处理器采用了指令级并行技术来将多条指令重叠执行。如果不存在数据依赖性，处理器可以改变语句对应机器指令的执行顺序。

内存系统重排序。由于处理器使用缓存和读 / 写缓冲区，这使得加载和存储操作看上去可能是在乱序执行。

数据依赖性：如果两个操作访问同一个变量，且这两个操作中有一个为写操作，此时这两个操作之间就存在数据依赖性。这里所说的数据依赖性仅针对单个处理器中执行的指令序列和单个线程中执行的操作，不同处理器之间和不同线程之间的数据依赖性不被编译器和处理器考虑。

int a = 0;

// 线程 A

a = 1;           // 1

flag = true;     // 2



// 线程 B

if (flag) { // 3

  int i = a; // 4

}

单看上面的程序好像没有问题，最后 i 的值是 1。但是为了提高性能，编译器和处理器常常会在不改变数据依赖的情况下对指令做重排序。假设线程 A 在执行时被重排序成先执行代码 2，再执行代码 1；而线程 B 在线程 A 执行完代码 2 后，读取了 flag 变量。由于条件判断为真，线程 B 将读取变量 a。此时，变量 a 还根本没有被线程 A 写入，那么 i 最后的值是 0，导致执行结果不正确。那么如何程序执行结果正确呢？这里仍然可以使用 volatile 关键字。

那么使用 volatile 修饰 flag 变量后，在线程 A 中，保证了代码 1 的执行顺序一定在代码 2 之前。

内存屏障指令

volatile 重排序规则

使用 volatile 修饰变量时，根据 volatile 重排序规则表，Java 编译器在生成字节码时，会在指令序列中插入内存屏障指令来禁止特定类型的处理器重排序。

内存屏障是一组处理器指令，它的作用是禁止指令重排序和解决内存可见性的问题。

JMM 把内存屏障指令分为下列四类：

StoreLoad 屏障是一个全能型的屏障，它同时具有其他三个屏障的效果。所以执行该屏障开销会很大，因为它使处理器要把缓存中的数据全部刷新到内存中。

从上图，我们可以知道 volatile 读 / 写插入内存屏障规则：

在每个 volatile 读操作的后面插入 LoadLoad 屏障和 LoadStore 屏障。

在每个 volatile 写操作的前后分别插入一个 StoreStore 屏障和一个 StoreLoad 屏障。

也就是说，编译器不会对 volatile 读与 volatile 读后面的任意内存操作重排序；编译器不会对 volatile 写与 volatile 写前面的任意内存操作重排序。

happens-before

上面我们讲述了重排序原则，为了提高处理速度， JVM 会对代码进行编译优化，也就是指令重排序优化，但是并发编程下指令重排序也会带来一些安全隐患：如指令重排序导致的多个线程操作之间的不可见性。

从 JDK5 开始，提出了 happens-before 的概念，通过这个概念来阐述操作之间的内存可见性。如果一个操作执行的结果需要对另一个操作可见，那么这两个操作之间必须存在 happens-before 关系。这里提到的两个操作既可以是在一个线程之内，也可以是在不同线程之间。

happens-before 规则如下：

程序次序规则（Program Order Rule）：在一个线程内，按照控制流顺序，书写在前面的操作先行

发生于书写在后面的操作。注意，这里说的是控制流顺序而不是程序代码顺序，因为要考虑分支、循环等结构。

管程锁定规则（M onitor Lock Rule）：一个unlock操作先行发生于后面对同一个锁的lock操作。这

里必须强调的是“同一个锁”，而“后面”是指时间上的先后。

volatile变量规则（Volatile Variable Rule）：对一个volatile变量的写操作先行于后面对这个变量

的读操作，这里的“后面”同样是指时间上的先后。

线程启动规则（Thread Start Rule）：Thread对象的start()方法先行发生于此线程的每一个动作。

线程终止规则（Thread Termination Rule）：线程中的所有操作都先行发生于对此线程的终止检

测，我们可以通过Thread::join()方法是否结束、Thread::isAlive()的返回值等手段检测线程是否已经终止执行。

线程中断规则（Thread Interruption Rule）：对线程interrupt()方法的调用先行发生于被中断线程

的代码检测到中断事件的发生，可以通过Thread::interrupted()方法检测到是否有中断发生。

对象终结规则（Finalizer Rule）：一个对象的初始化完成（构造函数执行结束）先行发生于它的

finalize()方法的开始。

传递性（Transitivity）：如果操作A先行发生于操作B，操作B先行发生于操作C，那就可以得出

操作A先行发生于操作C的结论

happens-before 规则不是描述实际操作的先后顺序，它是用来描述可见性的一种规则。

从 happens-before 的 volatile 变量规则可知，如果线程 A 写入了 volatile 修饰的变量 V，接着线程 B 读取了变量 V，那么，线程 A 写入变量 V 及之前的写操作都对线程 B 可见。

public class Singleton {

    // volatile 保证可见性和禁止指令重排序

    private static volatile Singleton singleton;



    public static Singleton getInstance() {

        // 第一次检查

        if (singleton == null) {

          // 同步代码块

          synchronized(this.getClass()) {

              // 第二次检查

              if (singleton == null) {

                    // 对象的实例化是一个非原子性操作

                    singleton = new Singleton();

                }

            }

        }

        return singleton;

    }

}

上面代码中， new Singleton() 是一个非原子性操作，对象实例化分为三步操作：（1）分配内存空间，（2）初始化实例，（3）返回内存地址给引用。所以，在使用构造器创建对象时，编译器可能会进行指令重排序。假设线程 A 在执行创建对象时，（2）和（3）进行了重排序，如果线程 B 在线程 A 执行（3）时拿到了引用地址，并在第一个检查中判断 singleton != null 了，但此时线程 B 拿到的不是一个完整的对象，在使用对象进行操作时就会出现问题。

所以，这里使用 volatile 修饰 singleton 变量，就是为了禁止在实例化对象时进行指令重排序。

总结

volatile 修饰符适用于以下场景：某个属性被多个线程共享，其中有一个线程修改了此属性，其他线程可以立即得到修改后的值；或者作为状态变量，如 flag = ture，实现轻量级同步。

volatile 属性的读写操作都是无锁的，它不能替代 synchronized，因为它没有提供原子性和互斥性。因为无锁，不需要花费时间在获取锁和释放锁上，所以说它是低成本的。

volatile 只能作用于属性，我们用 volatile 修饰属性，这样编译器就不会对这个属性做指令重排序。

volatile 提供了可见性，任何一个线程对其的修改将立马对其他线程可见。volatile 属性不会被线程缓存，始终从主存中读取。

volatile 提供了 happens-before 保证，对 volatile 变量 V 的写入 happens-before 所有其他线程后续对 V 的读操作。

volatile 可以使纯赋值操作是原子的，如 boolean flag = true; falg = false。y = x不是

volatile 可以在单例双重检查中实现可见性和禁止指令重排序，从而保证安全性。

volatile和synchronized