JUC(8)

小卡斯蒂
64 阅读2分钟

开启掘金成长之旅！这是我参与「掘金日新计划 · 12 月更文挑战」的第8天，点击查看活动详情

volatile变量用来解决

  • 可见性

    • 写屏障（sfence）保证在该屏障之前的 t1 对共享变量的改动，都同步到主存当中
    • 而读屏障（lfence）保证在该屏障之后 t2 对共享变量的读取，加载的是主存中最新数据

  • 有序性

    • 写屏障会确保指令重排序时，不会将写屏障之前的代码排在写屏障之后
    • 读屏障会确保指令重排序时，不会将读屏障之后的代码排在读屏障之前

  • 更底层是读写变量时使用 lock 指令来多核 CPU 之间的可见性与有序性

上面的问题用我的话来说就是INSTANCE = new Singleton();这个语句,JVM中可能会先给INSTANCE赋值而不是调用构造方法,因此第二个线程会错误的认为此时的INSTANCE不为null,那么就会返回这个空对象

上面的问题出现的原因是JVM错误的进行了指令重排序,导致24先与21执行,如果加上了volatile,就可以保证有序性,也就是24加上了写屏障,那么在24及24之前就无法进行指令重排序

synchronized也可以保证有序性和可见性,只不过需要变量的使用全部都在synchronized代码块中,像上述代码就不适用于这条规则

5.9 happens-before

happens-before 规定了对共享变量的写操作对其它线程的读操作可见，它是可见性与有序性的一套规则总结，抛 开以下 happens-before 规则，JMM 并不能保证一个线程对共享变量的写，对于其它线程对该共享变量的读可见

  • 线程解锁 m 之前对变量的写，对于接下来对 m 加锁的其它线程对该变量的读可见
  • 线程对 volatile 变量的写，对接下来其它线程对该变量的读可见
  • 线程 start 前对变量的写，对该线程开始后对该变量的读可见
  • 线程结束前对变量的写，对其它线程得知它结束后的读可见（比如其它线程调用 t1.isAlive() 或 t1.join()等待 它结束）
  • 线程 t1 打断 t2（interrupt）前对变量的写，对于其他线程得知 t2 被打断后对变量的读可见（通过 t2.interrupted 或 t2.isInterrupted）
  • 对变量默认值（0，false，null）的写，对其它线程对该变量的读可见
  • 具有传递性，如果 x hb-> y 并且 y hb-> z 那么有 x hb-> z ，配合 volatile 的防指令重排，有下面的例子
avatar
文章
阅读
粉丝