在当前的 Java 内存模型下,线程可以缓存内存中的值,而不是直接在主存中进行读写。这就可能造成一个线程在主存中修改了一个变量的值,而本线程还继续使用它的缓存值,产生数据的不一致疑问
要解决这个问题,就需要把变量声明为volatile,这就指示 JVM,这个变量是不稳定的,每次使用它都到主存中进行读取
volatile 关键字的主要作用就是保证变量的可见性然后还有一个作用是防止指令重排序
volatile并不能保证多个线程共同修改running变量时所带来的不一致问题,也就是说volatile不能替代synchronized
错误使用:volatile不保证原子性,不能解决原子性需求
class T {
volatile int count = 0;
void m(){
for (int i = 0; i < 1000000; i++) {
count++;
}
}
public static void main(String[] args) {
T t=new T();
List<Thread> threads=new ArrayList<>();
for (int i = 0; i < 10; i++) {
threads.add(new Thread(t::m,"thread-"+i));
}
threads.forEach((o)->o.start());
threads.forEach((o)->{
try {
//主线程进入waiting状态
//在A线程中调用了B线程的join()方法时,表示只有当B线程执行完毕时,A线程才能继续执行
o.join();
} catch (InterruptedException e) {
e.printStackTrace();
}
});
System.out.println(t.count);
}
}
//执行结果为3419156,但1000000才是正确结果
内存屏障
内存屏障,洋文称Memory Barrier(Memory Fence)
Valatile基于内存屏障保证了共享变量的可见性与有序性
之前提到valatile可以避免指令重排导致的运行结果正确性问题,事实上,valatile并不是通过禁止指令重排那么简单,而是通过内存屏障,保证的有序性
-
可见性
-
写屏障(sfence)保证在该屏障之前的,对共享变量的改动,都同步到主存当中,在数据变更后插入写屏障
-
public void actor2(I_Result r) { num = 2; ready = true; // ready 是 volatile 赋值带写屏障 // 写屏障 }
-
读屏障(lfence)保证在该屏障之后,对共享变量的读取,加载的是主存中最新数据,在读数据前插入读屏障
-
public void actor1(I_Result r) { // 读屏障 // ready 是 volatile 读取值带读屏障 if(ready) { r.r1 = num + num; } else { r.r1 = 1; } }
-
-
有序性
-
写屏障会确保指令重排序时,不会将写屏障之前的代码排在写屏障之后
-
public void actor2(I_Result r) { num = 2; ready = true; // 写屏障 }
-
读屏障会确保指令重排序时,不会将读屏障之后的代码排在读屏障之前
-
public void actor1(I_Result r) { // 读屏障 // ready 是 volatile 读取值带读屏障 if(ready) { r.r1 = num + num; } else { r.r1 = 1; } }
-
缺陷
无法解决指令交错问题:
多个线程各自代码有序并不能保证多个线程总的代码有序
读写的屏障底层事实是通过JMM内存模型定义的lock指令来实现