并发编程的三大特性:原子性,有序性,可见性。从这三个方面去看一下 volatile。
volatile 保证了可见性:
public class Demo1 {
private boolean flag = true;
public void test(){
while (flag){
}
System.out.println("test finish");
}
public void setFlag(boolean flag){
this.flag = flag;
}
public static void main(String[] args) {
Demo1 demo1 = new Demo1();
new Thread(()->{
demo1.test();
}).start();
new Thread(()->{
demo1.setFlag(false);
}).start();
}
}
事实上,控制台不会输出任何东西,程序能运行到电脑没电。改为下面这样则会正常运行。
private volatile boolean flag = true;
使用 volatile 保证了共享变量在线程之间的可见性。
volatile 不能保证原子性:
再看下面这段代码,10个线程对num执行++操作,直到num=100。volatile 并不能保证结果的正确性,结果有可能大于 100。
public class Demo2 {
private volatile int num = 0;
public void add() throws InterruptedException {
while (num < 100){
//Thread.sleep(10);
num++;
}
}
public static void main(String[] args) throws InterruptedException {
Demo2 demo2 = new Demo2();
for (int i=0; i<10; i++){
new Thread(()->{
demo2.add();//方便阅读,没捕获异常
}).start();
}
Thread.sleep(2000);
System.out.println(demo2.num);
}
}
假如 在num=99 时 thread1 进入 while 条件,由于 num++ 不是原子性操作,在执行 num++ 时 cpu 时间片用完而切换到 thread2,此时num 还是99,thread2 进行num++ 后,继续执行 thread1, num再 +1,结果错误。可以拿掉注释,放大这种情况。
public void add() throws InterruptedException {
while (num < 100){
Thread.sleep(10);
num++;
}
}
所以可以考虑把 num++ 变为原子操作 优化成以下方式:
//AtomicInteger 保证了原子性和可见性
private AtomicInteger num = new AtomicInteger(0);
public void add() throws InterruptedException {
while (num.get() < 100){
//1. Thread.sleep(10);
num.incrementAndGet();
}
}
插一句:AtomicInteger 涉及到 CAS,关于 CAS可以看我这篇文章(下一篇写)。
这样就正确了吗?其实并没有。因为进入 while 后且在执行 incrementAndGet() 之前,有可能时间片用完而切换到其他线程,也就是说,进入 while 之后的操作不是原子性的操作。可以拿掉1处的注释来放大这种现象。
其实这段代码很奇葩,基本上没人会这么写,但是可以通过代码学习到很多东西。让我们继续优化:
思路就是:怎么让程序进入 while之后的操作变为原子操作?第一个想到的就是 snychronizd,但是就这段代码来说,加上snychronizd,就会变成只会有一个线程执行,这并不是本意。当然可以手动释放 snychronizd 占有的锁,可以通过 抛异常、break、return,而且 snychronizd 会影响性能,这会显得很笨重。
那 snychronizd 就排除在外了,有了这个思路,方法就显而易见了,可以用显式锁来保证原子性:
private AtomicInteger num = new AtomicInteger(0);
private Lock lock = new ReentrantLock(false);
public void add() throws InterruptedException {
while (num.get() < 100){
lock.lock();
if (num.get() < 100){
num.incrementAndGet();
}
lock.unlock();
}
}
volatile 保证了有序性:
懒汉式单例问题:
public class SingletonDoubleCheck{
private SingletonDoubleCheck singleton;
private SingletonDoubleCheck(){}
public static SingletonDoubleCheck getInstance(){
if (singleton == null){
singleton = new SingletonDoubleCheck();
}
return singleton;
}
}
这样写会造成极大的安全隐患,高并发条件下,如果有两个线程同时运行,都满足 if 条件,然后对对象进行了两次初始化,不能保证单例的唯一性。
所以考虑进行同步优化:
public class SingletonDoubleCheck{
private static SingletonDoubleCheck singleton;
private SingletonDoubleCheck(){}
public static SingletonDoubleCheck getInstance(){
//只在没进行初始化之前进行,初始化过后,就不在进入,提高性能
if (singleton == null){
//同步,同步快内的程序可以看做原子操作
synchronized (SingletonDoubleCheck.class){
//再判断一次,防止多个线程同时进入后多次初始化
if (singleton == null){
singleton = new SingletonDoubleCheck();
}
}
}
return singleton;
}
}
这样看似已经很完美,其实在实际运行的过程中可能会抛出 NullPointerException。因为在实际运行过程中 Jvm 为了提高性能 会对指令进行重排序。
简单说一下重排序:假如在对象对象需要 A、B 两个单两个资源,构造函数中需要实例化 A、B 两个资源和自身的对象,有可能先对自身对象先进行实例化,而此时 A、B 并没有完成实例化。此时会造成 NullPointerException。
所以改为:
private volatile static SingletonDoubleCheck singleton;
volatile 会形成内存屏障,而禁用区域内的指令重排序:
关于内存屏障可以 戳这篇 and 这篇