volatile关键字及其应用

1.并发编程中的三个概念

原子性

即一个操作或者多个操作要么全部执行并且执行的过程不会被任何因素打断，要么就都不执行。

可见性

是指当多个线程访问同一个变量时，一个线程修改了这个变量的值，其他线程能够立即看得到修改的值。

举个简单的例子，看下面这段代码：

//线程1执行的代码
int i = 0;
i = 10;
 
//线程2执行的代码
j = i;

j的取值0或10 ， 线程1对变量i修改了之后，线程2没有立即看到线程1修改的值。

有序性

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

举个简单的例子，看下面这段代码：

int i = 0;              
boolean flag = false;
i = 1;                //语句1  
flag = true;          //语句2

从代码顺序上看，语句1是在语句2前面的，那么JVM在真正执行这段代码的时候会保证语句1一定会在语句2前面执行吗？

再看下面一个例子：

int a = 10;    //语句1
int r = 2;    //语句2
a = a + 3;    //语句3
r = a*a;     //语句4

这段代码有4个语句，那么可能的一个执行顺序是：语句2 语句1 语句3 语句4

那么可不可能是这个执行顺序呢？： 语句2   语句1    语句4   语句3

再给一个多线程下的例子：

//线程1:
context = loadContext();   //语句1
inited = true;             //语句2
 
//线程2:
while(!inited ){
  sleep()
}
doSomethingwithconfig(context);

上面的代码会有什么问题吗？

 

要想并发程序正确地执行，必须要保证原子性、可见性以及有序性。只要有一个没有被保证，就有可能会导致程序运行不正确。

 

那么Java语言 本身对 原子性、可见性以及有序性提供了哪些保证呢？

原子性

在Java中，对基本数据类型的变量的读取和赋值操作是原子性操作，只有简单的读取、赋值（而且必须是将数字赋值给某个变量，变量之间的相互赋值不是原子操作）才是原子操作。

如果要实现更大范围操作的原子性，可以通过synchronized和Lock来实现。由于synchronized和Lock能够保证任一时刻只有一个线程执行该代码块，那么自然就不存在原子性问题了，从而保证了原子性。

可见性

Java提供了volatile关键字来保证可见性。

通过synchronized和Lock也能够保证可见性，synchronized和Lock能保证同一时刻只有一个线程获取锁然后执行同步代码，并且在释放锁之前会将对变量的修改刷新到主存当中。因此可以保证可见性。

有序性

在Java里面，可以通过volatile关键字来保证一定的“有序性”。另外可以通过synchronized和Lock来保证有序性，很显然，synchronized和Lock保证每个时刻是有一个线程执行同步代码，相当于是让线程顺序执行同步代码，自然就保证了有序性。

另外，Java内存模型具备一些先天的“有序性”，即不需要通过任何手段就能够得到保证的有序性，这个通常也称为 happens-before 原则。如果两个操作的执行次序无法从happens-before原则推导出来，那么它们就不能保证它们的有序性，虚拟机可以随意地对它们进行重排序。

 

2.场景引入，问题初现

如上图，这张图说的是java内存模型中，每个线程有自己的工作内存，同时还有一个共享的主内存。比如说有两个线程，他们的代码里都需要读取data这个变量的值，那么他们都会从主内存里加载data变量的值到自己的工作内存，然后才可以使用那个值。

 

为啥一定要让每个线程用一个工作内存来存放变量的副本以供读取呢？我直接让线程每次都从主内存加载变量的值不行吗？

因为线程运行的代码对应的是一些指令，是由CPU执行的！但是CPU每次执行指令运算的时候，也就是执行我们写的那一大坨代码的时候，要是每次需要一个变量的值，都从主内存加载，性能会比较差！所以说后来想了一个办法，就是线程有工作内存的概念，类似于一个高速的本地缓存。

 

这样会有什么问题？

线程1和线程2其实都是在操作一个变量data，但是线程1修改了data变量的值之后，线程2是看不到的，一直都是看到自己本地工作内存中的一个旧的副本的值！这就是所谓的java并发编程中的可见性问题。

 

3.volatile的作用及背后的原理

3.1 volatile保证可见性

第一，一旦data变量定义的时候前面加了volatile来修饰的话，那么线程1只要修改data变量的值，就会在修改完自己本地工作内存的data变量值之后，强制将这个data变量最新的值刷回主内存，必须让主内存里的data变量值立马变成最新的值！

第二，如果此时别的线程的工作内存中有这个data变量的本地缓存，也就是一个变量副本的话，那么会强制让其他线程的工作内存中的data变量缓存直接失效过期，不允许再次读取和使用了！

第三，如果线程2在代码运行过程中再次需要读取data变量的值，此时尝试从本地工作内存中读取，就会发现这个data = 0已经过期了！此时，他就必须重新从主内存中加载data变量最新的值！那么不就可以读取到data = 1这个最新的值了！

volatile完美解决了java并发中可见性的问题！

 

3.2 volatile保证有序性

volatile关键字禁止指令重排序有两层意思：

1）当程序执行到volatile变量的读操作或者写操作时，在其前面的操作的更改肯定全部已经进行，且结果已经对后面的操作可见；在其后面的操作肯定还没有进行；

2）在进行指令优化时，不能将在对volatile变量访问的语句放在其后面执行，也不能把volatile变量后面的语句放到其前面执行。

可能上面说的比较绕，举个简单的例子：

//x、y为非volatile变量
//flag为volatile变量
 
x = 2;        //语句1
y = 0;        //语句2
flag = true;  //语句3
x = 4;         //语句4
y = -1;       //语句5

由于flag变量为volatile变量，那么在进行指令重排序的过程的时候，不会将语句3放到语句1、语句2前面，也不会将语句3放到语句4、语句5后面。但是要注意语句1和语句2的顺序、语句4和语句5的顺序是不作任何保证的。

并且volatile关键字能保证，执行到语句3时，语句1和语句2必定是执行完毕了的，且语句1和语句2的执行结果对语句3、语句4、语句5是可见的。

 

3.3 volatile保证原子性吗？

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);
    }
}

运行结果会不一致，会出现一个小于10000的数字。

volatile关键字能保证可见性没有错，但是上面的程序错在没能保证原子性。可见性只能保证每次读取的是最新的值，但是volatile没办法保证对变量的操作的原子性。

在前面已经提到过，自增操作是不具备原子性的，它包括读取变量的原始值、进行加1操作、写入工作内存。那么就是说自增操作的三个子操作可能会分割开执行。

 

4 CopyOnWrite思想

读多写少场景下引发的问题

ArrayList默认情况下肯定是线程不安全的，我们应该怎么让这个ArrayList变成线程安全的呢？

有一个非常简单的办法，对这个ArrayList的访问都加上线程同步的控制。

比如说一定要在synchronized代码段来对这个ArrayList进行访问，这样的话，就能同一时间就让一个线程来操作它了，或者是用ReadWriteLock读写锁的方式来控制，都可以。

public Object read() {
    lock.readLock().lock();
    // 对ArrayList读取
    lock.readLock().unlock();
}

public void write() {
    lock.writeLock().lock();
    // 对ArrayList写
    lock.writeLock().unlock();
}

大家想想，类似上面的代码有什么问题呢？

最大的问题，其实就在于写锁和读锁的互斥。假设写操作频率很低，读操作频率很高，是写少读多的场景。

那么偶尔执行一个写操作的时候，是不是会加上写锁，此时大量的读操作过来是不是就会被阻塞住，无法执行？

这个就是读写锁可能遇到的最大的问题。

引入CopyOnWrite思想来解决问题

CopyOnWrite ： 写数据的时候利用拷贝的副本来执行

那那个写线程现在把副本数组给修改完了，现在怎么才能让读线程感知到这个变化呢？ 这里要配合上volatile关键字的使用。

下面是JDK里的 CopyOnWriteArrayList 的源码。

// 这个数组是核心的，因为用volatile修饰了
// 只要把最新的数组对他赋值，其他线程立马可以看到最新的数组
private transient volatile Object [] array;

public boolean add(E e) {
  final ReentrantLock lock = this.lock;
  lock.lock();    
	try
	 {        
			Object[] elements = getArray();
      int len = elements.length;
			// 对数组拷贝一个副本出来
      Object[] newElements = Arrays.copyOf(elements, len + 1);           
			// 对副本数组进行修改，比如在里面加入一个元素
      newElements[len] = e;           
			// 然后把副本数组赋值给volatile修饰的变量
      setArray(newElements); 
			return true;
		} finally {
      lock.unlock();
    }
}

万一要是多个线程都要同时更新呢？那搞出来多个副本会不会有问题？

当然不能多个线程同时更新了，这个时候就是看上面源码里，加入了lock锁的机制，也就是同一时间只有一个线程可以更新。

那么更新的时候，会对读操作有任何的影响吗？

绝对不会，因为读操作就是非常简单的对那个数组进行读而已，不涉及任何的锁。而且只要他更新完毕对volatile修饰的变量赋值，那么读线程立马可以看到最新修改后的数组，这是volatile保证的。

private E get(Object [] a, int index) {
  	// 最简单的对数组进行读取
    return (E) a[index];
}

这样就完美解决了我们之前说的读多写少的问题。如果用读写锁互斥的话，会导致写锁阻塞大量读操作，影响并发性能。

但是如果用了CopyOnWriteArrayList，就是用空间换时间，更新的时候基于副本更新，避免锁，然后最后用volatile变量来赋值保证可见性，更新的时候对读线程没有任何的影响！

CopyOnWrite思想在kafka中的应用

在Kafka的内核源码中，有这么一个场景，客户端在向Kafka写数据的时候，会把消息先写入客户端本地的内存缓冲，然后在内存缓冲里形成一个Batch之后再一次性发送到Kafka服务器上去，这样有助于提升吞吐量。

这个时候Kafka的内存缓冲用的是什么数据结构呢？大家看源码：

 private final ConcurrentMap<TopicPartition, Deque<RecordBatch>> batches;
 this.batches = new CopyOnWriteMap();

我们来看一下这个CopyOnWriteMap的源码实现：

		// 典型的volatile修饰普通Map
		private volatile Map<K, V> map;

    public synchronized V put(K k, V v) {   
				// 更新的时候先创建副本，更新副本，然后对volatile变量赋值写回去
        Map<K, V> copy = new HashMap(this.map);
        V prev = copy.put(k, v);
        this.map = Collections.unmodifiableMap(copy);
        return prev;
    }

	  public V get(Object k) {    
				// 读取的时候直接读volatile变量引用的map数据结构，无需锁
        return this.map.get(k);
    }

所以Kafka这个核心数据结构在这里之所以采用CopyOnWriteMap思想来实现，就是因为这个Map的key-value对，其实没那么频繁更新。也就是TopicPartition-Deque这个key-value对，更新频率很低。

但是他的get操作却是高频的读取请求，因为会高频的读取出来一个TopicPartition对应的Deque数据结构，来对这个队列进行入队出队等操作，所以对于这个map而言，高频的是其get操作。

这个时候，Kafka就采用了CopyOnWrite思想来实现这个Map，避免更新key-value的时候阻塞住高频的读操作，实现无锁的效果，优化线程并发的性能。

 

 

参考来源：

java并发编程---volatile

不了解这些“高级货”，活该你面试当炮灰。。。

大白话聊聊Java并发面试问题之volatile到底是什么？