A Big Boy Blog - Tech Articls & Notes

Background

如果CPU访问的内存数据不在Cache中（一级、二级、三级），这就产生了Cache Line miss问题，此时CPU不得不发出新的加载指令，从内存中获取数据。

Cache主要分为L1、L2 和 L3，如果出现Cache Line Missing，CPU就要从内存中访问数据，这就会产生一个较大的时延，程序性能显著降低。为此我们不得不提高Cache命中率，也就是充分发挥局部性原理。

时间局部性：对于同一数据可能被多次使用，自第一次加载到Cache Line后，后面的访问就可以多次从Cache Line中命中，从而提高读取速度（而不是从下层缓存读取）。
空间局部性：一个Cache Line有64字节块，我们可以充分利用一次加载64字节的空间，把程序后续会访问的数据，一次性全部加载进来，从而提高Cache Line命中率（而不是重新去寻址读取）。

举例，长度为16的row和column数组，在Cache Line 64字节数据块上内存地址是连续的，能被一次加载到Cache Line中，所以在访问数组时，Cache Line命中率高，性能发挥到极致。

public int run(int[] row, int[] column) {
    int sum = 0;
    for(int i = 0; i < 16; i++ ) {
        sum += row[i] * column[i];
    }
    return sum;
}

变量i则体现了时间局部性，i作为计数器被频繁操作，一直存放在寄存器中，每次从寄存器访问，而不是从主存甚至磁盘访问。虽然连续紧凑的内存分配带来高性能，但并不代表它一直都能带来高性能。

https://blog.csdn.net/qq_27680317/article/details/78486220

Introduction

volatile这个关键字，不仅仅在Java语言中有，在很多语言中都有的，而且其用法和语义也都是不尽相同的。尤其在C语言、C++以及Java中，都有volatile关键字。都可以用来声明变量或者对象。

volatile通常被比喻成”轻量级的synchronized“，也是Java并发编程中比较重要的一个关键字。和synchronized不同，volatile是一个变量修饰符，只能用来修饰变量。无法修饰方法及代码块等。

volatile的用法比较简单，只需要在声明一个可能被多线程同时访问的变量时，使用volatile修饰就可以了。

一个比较典型的使用双重锁校验的形式实现单例的，其中使用volatile关键字修饰可能被多个线程同时访问到的singleton。

public class Singleton {  
    private volatile static Singleton singleton;  
    private Singleton (){} 
    public static Singleton getSingleton() {
        if (singleton == null) {  
            synchronized (Singleton.class) {  
                if (singleton == null) {  
                    singleton = new Singleton();  
                }
            }
        }  
        return singleton;  
    }
}

为了提高处理器的执行速度，在处理器和内存之间增加了多级缓存来提升。但是由于引入了多级缓存，就存在缓存数据不一致问题。而volatile就可以解决读写数据不一致的问题。

对于volatile变量，当对volatile变量进行写操作的时候，JVM会向处理器发送一条lock前缀的指令，将这个缓存中的变量回写到系统主存中。但是就算写回到内存，如果其他处理器缓存的值还是旧的，再执行计算操作就会有问题，所以在多处理器下，为了保证各个处理器的缓存是一致的，就会实现缓存一致性协议。

如果一个变量被volatile所修饰的话，在每次数据变化之后，其值都会被强制刷入主存。而其他处理器的缓存由于遵守了缓存一致性协议，也会把这个变量的值从主存加载到自己的缓存中。这就保证了一个volatile在并发编程中，其值在多个缓存中是可见的。

缓存一致性协议：每个处理器通过嗅探在总线上传播的数据来检查自己缓存的值是不是过期了，当处理器发现自己缓存行对应的内存地址被修改，就会将当前处理器的缓存行设置成无效状态，当处理器要对这个数据进行修改操作的时候，会强制重新从系统内存里把数据读到处理器缓存里。

被volatile修饰的共享变量，就具有了以下两点特性：

保证了不同线程对该变量操作的内存可见性；
禁止指令重排序；

可见性

Java虚拟机规范试图定义一种Java内存模型(JMM)，来屏蔽掉各种硬件和操作系统的内存访问差异，让Java程序在各种平台上都能达到一致的内存访问效果。简单来说，由于CPU执行指令的速度是很快的，但是内存访问的速度就慢了很多，相差的不是一个数量级，所以搞处理器的那群大佬们又在CPU里加了好几层高速缓存。

Java内存模型规定了所有的变量都存储在主内存中，每条线程还有自己的工作内存，线程的工作内存中保存了该线程中是用到的变量的主内存副本拷贝，线程对变量的所有操作都必须在工作内存中进行，而不能直接读写主内存。不同的线程之间也无法直接访问对方工作内存中的变量，线程间变量的传递均需要自己的工作内存和主存之间进行数据同步进行。所以就可能出现线程1改了某个变量的值，但是线程2不可见的情况。

可见性是指当多个线程访问同一个变量时，一个线程修改了这个变量的值，其他线程能够立即看得到修改的值。即，被其修饰的变量在被修改后可以立即同步到主内存，被其修饰的变量在每次在用之前都从主内存刷新。

因此，可以使用volatile来保证多线程操作时变量的可见性。volatile对于可见性的实现，内存屏障也起着至关重要的作用。

因为内存屏障相当于一个数据同步点，他要保证在这个同步点之后的读写操作必须在这个点之前的读写操作都执行完之后才可以执行。并且在遇到内存屏障的时候，缓存数据会和主存进行同步，或者把缓存数据写入主存、或者从主存把数据读取到缓存。

问题来了：已经有了缓存一致性协议，为什么还需要volatile？

并不是所有的硬件架构都提供了相同的一致性保证，Java作为一门跨平台语言，JVM需要提供一个统一的语义。
操作系统中的缓存和JVM中线程的本地内存并不是一回事，通常我们可以认为：MESI（Cache一致性协议）可以解决缓存层面的可见性问题。使用volatile关键字，可以解决JVM层面的可见性问题。
缓存可见性问题的延伸：由于传统的MESI协议的执行成本比较大。所以CPU通过Store Buffer和Invalidate Queue组件来解决，但是由于这两个组件的引入，也导致缓存和主存之间的通信并不是实时的。也就是说，缓存一致性模型只能保证缓存变更可以保证其他缓存也跟着改变，但是不能保证立刻、马上执行。

在计算机内存模型中，也是使用内存屏障来解决缓存的可见性问题的（再次强调：缓存可见性和并发编程中的可见性可以互相类比，但是他们并不是一回事儿）。

写内存屏障（Store Memory Barrier）可以促使处理器将当前store buffer（存储缓存）的值写回主存。读内存屏障（Load Memory Barrier）可以促使处理器处理invalidate queue（失效队列）。进而避免由于Store Buffer和Invalidate Queue的非实时性带来的问题。

所以，内存屏障也是保证可见性的重要手段，操作系统通过内存屏障保证缓存间的可见性，JVM通过给volatile变量加入内存屏障保证线程之间的可见性。

内存屏障：用于控制特定条件下的重排序和内存可见性问题。Java编译器也会根据内存屏障的规则禁止重排序。

Example 1

1	i = i + 1;

假设i初值为0，当只有一个线程执行它时，结果肯定得到1，当两个线程执行时，会得到结果2吗？这倒不一定了。

可能存在下面这种情况：

线程1： load i from 主存    // i = 0
        i + 1   // i = 1
线程2： load i from主存 // 因为线程1还没将i的值写回主存，所以i还是0
        i +  1  //i = 1
线程1:  save i to 主存
线程2： save i to 主存

如果两个线程按照上面的执行流程，那么i最后的值居然是1了。如果最后的写回生效的慢，你再读取i的值，都可能是0，这就是缓存不一致问题。

原子性

线程是CPU调度的基本单位。CPU有时间片的概念，会根据不同的调度算法进行线程调度。当一个线程获得时间片之后开始执行，在时间片耗尽之后，就会失去CPU使用权。所以在多线程场景下，由于时间片在线程间轮换，就会发生原子性问题。

原子性是指一个操作是不可中断的，要全部执行完成，要不就都不执行。

volatile是不能保证原子性的。

volatile应用场景：

运算结果并不依赖变量的当前值，或者能够确保只有单一的线程会修改变量的值。
变量不需要与其他状态变量共同参与不变约束。

除以上场景外，都需要使用其他方式来保证原子性，如synchronized或者concurrent包。

举例说明

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()>1)  //保证前面的线程都执行完
            Thread.yield();

        System.out.println(test.inc);
    }
}

以上代码比较简单，就是创建10个线程，然后分别执行1000次i++操作。正常情况下，程序的输出结果应该是10000，但是，多次执行的结果都小于10000。这其实就是volatile无法满足原子性的原因。

为什么会出现这种情况呢，那就是因为虽然volatile可以保证inc在多个线程之间的可见性。但是无法inc++的原子性。

为什么volatile不能保证原子性呢？因为他不是锁，他没做任何可以保证原子性的处理。当然就不能保证原子性了。

synchronized 为了保证原子性，需要通过字节码指令monitorenter和monitorexit，但是volatile和这两个指令之间是没有任何关系的。volatile是不能保证原子性的。

可见性

有序性

由于处理器优化和指令重排等，CPU还可能对输入代码进行乱序执行，比如load->add->save 有可能被优化成load->save->add 。这就是可能存在有序性问题。

有序性即程序执行的顺序按照代码的先后顺序执行。

关键功能：禁止指令重排优化等。

普通的变量仅仅会保证在该方法的执行过程中所依赖的赋值结果的地方都能获得正确的结果，而不能保证变量的赋值操作的顺序与程序代码中的执行顺序一致。

volatile禁止指令重排，保证了代码的程序会严格按照代码的先后顺序执行。这就保证了有序性。被volatile修饰的变量的操作，会严格按照代码顺序执行，load->add->save 的执行顺序就是：load、add、save。

volatile是通过内存屏障来来禁止指令重排的。

内存屏障（Memory Barrier）是一类同步屏障指令，是CPU或编译器在对内存随机访问的操作中的一个同步点，使得此点之前的所有读写操作都执行后才可以开始执行此点之后的操作。

具体实现方式是在编译期生成字节码时，会在指令序列中增加内存屏障来保证，下面是基于保守策略的JMM内存屏障插入策略：

在每个volatile写操作的前面插入一个StoreStore屏障
- 对于这样的语句Store1; StoreStore; Store2，在Store2及后续写入操作执行前，保证Store1的写入操作对其它处理器可见。
在每个volatile写操作的后面插入一个StoreLoad屏障
- 对于这样的语句Store1; StoreLoad; Load2，在Load2及后续所有读取操作执行前，保证Store1的写入对所有处理器可见。
在每个volatile读操作的后面插入一个LoadLoad屏障
- 对于这样的语句Load1; LoadLoad; Load2，在Load2及后续读取操作要读取的数据被访问前，保证Load1要读取的数据被读取完毕。
在每个volatile读操作的后面插入一个LoadStore屏障
- 对于这样的语句Load1; LoadStore; Store2，在Store2及后续写入操作被刷出前，保证Load1要读取的数据被读取完毕。

所以，volatile通过在volatile变量的操作前后插入内存屏障的方式，来禁止指令重排，进而保证多线程情况下对共享变量的有序性。

总结

synchronized可以保证原子性、有序性和可见性。而volatile却只能保证有序性和可见性。

Reference

http://www.hollischuang.com/archives/2648
[如何正确写单例模式] http://wuchong.me/blog/2014/08/28/how-to-correctly-write-singleton-pattern/
[Cache一致性协议之MESI] https://blog.csdn.net/muxiqingyang/article/details/6615199
[面试官最爱的volatile关键字] https://juejin.im/post/5a2b53b7f265da432a7b821c

Error

command not found

背景

AtomicReference

原理

AtomicStampedReference

原理

用法

CAS操作

Compare And Swap(CAS)

sysctl

CPU

Network

ulimit

Background

Lib

Network

CAS

Framework

Object Pools

Operation System

CPU Cache Performance

CPU Cache Line

False Sharing

Coding

Reference vs Primitives

Caculations

java.util vs fastutil

Introduction

可见性

原子性

可见性

有序性

总结

Reference

Admin

Nginx

X-Pack

Index Pattern