ps: 老文章拆分出来的内容
并发三原则
只有保证了这三点才能在并发中获得想要的结果，我们想要进一步了解多线程，这3个原则必须要明白，并发都是围绕这2个原则展开的
简单来说是这样的
可见性 - 是指线程之间的可见性，一个线程修改的状态对另一个线程是可见的。也就是一个线程修改的结果，另一个线程马上就能看到。简单来说，线程的私有内存中对象副本和主内存对象的数据之间就是可见性问题，线程不把他私有内存中的对象副本协会到主内存中，那么对于其他想操作这个对象的线程来说就是"不可见的" ，最新数据不可见，所以此时其他线程可以获取该对象的旧数据
原子性 - 对基本类型变量的读取和赋值操作是原子性操作，即这些操作是不可中断的，要么执行完毕，要么就不执行。在多线程中，原子性是线程不安全的，其实和可见性有关联，线程在计算数据时会把在自己的工作区域 copy 一份数据的副本，然后计算的是这个数据的副本，最后再把数据学会内存中，这个过程里要是有别人线程同时操作同一个数据，那么我们的计算结果就是不正确了，就像打电话串线一样，结果肯定不对
x =3;
y =4;
z = x+y;
x++；
上面第三行就包括了多个操作，1是先读取x的值，2读取y的值，3将计算中的值，4把z的值写回内存。一般一个语句含有多个操作该语句就不是原子性的操作，只有最简单的读取和赋值才是原子性的操作
有序性 - 即程序执行的顺序按照代码的先后顺序执行，上面讲了因为原子性问题，绝部分操作都是可以再分的，分成多个操作，这其中有对数据的读，改，写等，这些操作速度不一，JVM 为了提高效率，在保证结果相同的前提下，有计划的多这么操作分组，在执行需要等待的操作中，穿插执行其他执行速度块的操作，这叫指令重排序
指令重排序指的是在 保证程序最终执行结果和代码顺序执行的结果一致的前提下，改变语句执行的顺序来优化输入代码，提高程序运行效率。
重排序在单线程中没啥问题，咱们等着执行结果呗，反正重排序保证结果正确。但是在多先撤我那个环境下是存在并发的，你这里对某一个对象的执行重排序了，但是不是瞬间完成的，这时另外的线程可以操作这个对象，那么你这个重排序后的执行可能造成此时对象数据的不正确，会对其他线程使用这个对象产生影响
以下面的举个例子：
int i = 0;
boolean flag = false;
i = 1; //语句1
flag = true; //语句2
定义了一个整形和Boolean型变量，并通过语句1和语句2对这两个变量赋值，但是JVM在执行这段代码的时候并不保证语句1在语句2之前执行，也就是说可能会发生 指令重排序。
再来个例子：
//线程1:
context = loadContext(); //语句1
inited = true; //语句2
//线程2:
while (!inited) {
sleep()
}
doSomethingWithConfig(context);
对于线程1来说，语句1和语句2没有依赖关系，因此有可能会发生指令重排序的情况。但是对于线程2来说，语句2在语句1之前执行，那么就会导致进入doSomethingWithConfig函数的时候context没有初始化
Java 提供了3个关键字 volatile、synchronized 和 final 来实现并发3原则
- final - 最好理解，一切都是不可变的，所以不在乎有多少个线程同时操作这个资源
- synchronized - 之前的文章介绍了，synchronized 保证了有序性，你想 synchronized 使用一把锁锁住了资源，那别人想用只能等着，即便你再怎么重排序，我也能保证执行效果
- volatile - 就比较复杂了，也是本文的重点
volatile
Volatile 是面试官最爱文的，即便你是做 android 开发的，你也逃不出去，所以大家好好钻研吧
volatile 的特性： 先是非同步的 -> 保证了可见性 -> 同时也保证有序性 -> 但是不保证原子性
-
非同步 - volatile 修饰的变量不是 synchronized 的，不是同步的，同一时间是能被多个线程操作的，所以 volatile 的使用范围比较窄，多用于修饰 static 静态变量
-
保证可见性 - 好多地方都说 volatile 修饰的变量，线程直接和内存交互，不会保存副本，而实际上线程还是会保存副本，只不过 CPU 每次都会从内存中拿到最新的值，并且改变数据之后立马写回内存并通知其他改数据的备份数据改变了，看上去就像线程直接和内存交互一样
-
不保证原子性 - volatile 语义并不能保证变量的原子性。对任意单个volatile变量的读/写具有原子性，但类似于i++、i–这种复合操作不具有原子性，因为自增运算包括读取i的值、i值增加1、重新赋值3步操作，并不具备原子性
-
保证有序性 - volatile 能够屏蔽指令重排序：
- 当程序执行到volatile变量的读操作或者写操作时，在其前面的操作的更改肯定全部已经进行，且结果已经对后面的操作可见；在其后面的操作肯定还没有进行；
- 在进行指令优化时，不能将在对volatile变量访问的语句放在其后面执行，也不能把volatile变量后面的语句放到其前面执行。
一个经典的例子：
public class VolatileDemo {
int x = 0 ;
//注意：这里的b没有被volatile修饰
boolean b = false;
/**
* 写操作
*/
private void write(){
x = 5;
b = true;
}
/**
* 读操作
*/
private void read(){
//如果b=false的话，就会无限循环，直到b=true才会执行结束，会打印出x的值
while(!b){
}
System.out.println("x="+x);
}
public static void main(String[] args) throws Exception {
final VolatileDemo volatileDemo = new VolatileDemo();
//线程1执行写操作
Thread thread1 = new Thread(new Runnable() {
@Override
public void run() {
volatileDemo.write();
}
});
//线程2执行读操作
Thread thread2 = new Thread(new Runnable() {
@Override
public void run() {
volatileDemo.read();
}
});
//我们让线程2的读操作先执行
thread2.start();
//睡1毫秒，为了保证线程2比线程1先执行
TimeUnit.MILLISECONDS.sleep(1);
//再让线程1的写操作执行
thread1.start();
thread1.join();
thread2.join();
//等待线程1和线程2全部结束后，打印执行结束
System.out.println("执行结束");
}
}
b 不是 volatile 的，所以我们先让 thread2 跑起来，再运行 thread1，因为 b 不是内存可见的，即便 thread1 修改了 b 的值，但是在 thread2 中 b 的值一直没有变化，这里就体现出了 volatile 的用处，若是不用 volatile 声明标记，那么 thread2 会一直跑这个循环出不来
volatile 适用场景：
- 禁止系统重排序的情况
- 只有一个线程写，多个线程读的情况
- 关键的标记行参数
- 静态单例
当然了 volatile 最经典的用处就是单例了
public class RxBus {
public static volatile RxBus instance;
public static RxBus getInstance() {
if (instance == null) {
synchronized (RxBus.class) {
if (instance == null) {
instance = new RxBus();
}
}
}
return instance;
}
}
我们对于静态单例使用了 volatile 就能保证整个方法的执行顺序是按照我们缩写的执行。
若是我们不加 volatile ，在多线程时指令重排序，一个线程发现 instance 是 null 的就会 new 一个对象出来，此时因为指令冲排序，很可能先在内存 new 一块空间然后赋值给 instance ，然后再去执行实例化对象的操作，对象实例化的操作是比较重的。这是领一额个线程进来，发现 instance 不是 null ，然后就去执行代码，但是此时 instance 实际只是有了一块内存地址，但是对象本身还没初始化，就会产生空指针的问题
volatile 的优势是同步性能开销比锁低很多，若是使用 synchronized + 锁，切换锁给不同的线程要好几毫秒，比 new 个线程对象都耗费时间多了
但是 volatile 也有很严重的问题，那就是 volatile 不能保证原子性，虽然 volatile 让内存可以同步到所有地方，但是并不能阻止多个线程同时操作同一个数据，是没法保证原子性的，所以是不能代替 synchronized + 锁，因此我们在使用 volatile 要及其小心，要思考会不会带来并发问题，一般我们见到的 volatile 应用都很少，也都很死，都是固定的几个场景使用
网友评论