内存间交互操作

Java 内存模型中定义了以下 8 种操作来完成主内存与工作内存之间交互的实现细节:

  • luck(锁定):作用于主内存的变量,它把一个变量标示为一条线程独占的状态。
  • unlock(解锁):作用于主内存的变量,它把一个处于锁定状态的变量释放出来,释放后的变量才可以被其
    他线程锁定。
  • read(读取):作用于主内存的变量,它把一个变量的值从主内存传输到工作内存中,以便随后的 load 动
    作使用。
  • load(载入):作用于工作内存的变量,它把 read 操作从主内存中得到的变量值放入工作内存的变量副本
    中。
  • use(使用):作用于工作内存的变量,它把工作内存中的一个变量的值传递给执行引擎,每当虚拟机遇到
    一个需要使用到变量的值得字节码指令时将会执行这个操作。
  • assign(赋值):作用于工作内存的变量,它把一个从执行引擎接收到的值赋给工作内存的变量,每当虚拟
    机遇到一个给变量赋值的字节码指令时执行这个操作。
  • store(存储):作用于工作内存的变量,它把工作内存中的一个变量的值传递到主内存中,以便随后的 write 操作使用。
  • write(写入):作用于主内存的变量,它把 store 操作从工作内存中得到的变量值放入主内存的变量中。
  • Java 内存模型还规定了执行上述 8 种基本操作时必须满足如下规则:

  • 不允许 read 和 load、store 和 write 操作之一单独出现,以上两个操作必须按顺序执行,但没有保证必须
    连续执行,也就是说,read 与 load 之间、store 与 write 之间是可插入其他指令的。
  • 不允许一个线程丢弃它的最近的 assign 操作,即变量在工作内存中改变了之后必须把该变化同步回主内
    存。
  • 不允许一个线程无原因地(没有发生过任何 assign 操作)把数据从线程的工作内存同步回主内存中。
  • 一个新的变量只能从主内存中“诞生”,不允许在工作内存中直接使用一个未被初始化(load 或 assig
    n)的变量,换句话说就是对一个变量实施 use 和 store 操作之前,必须先执行过了 assign 和 load 操作。
  • 一个变量在同一个时刻只允许一条线程对其执行 lock 操作,但 lock 操作可以被同一个条线程重复执行多
    次,多次执行 lock 后,只有执行相同次数的 unlock 操作,变量才会被解锁。
  • 如果对一个变量执行 lock 操作,将会清空工作内存中此变量的值,在执行引擎使用这个变量前,需要重新执
    行 load 或 assign 操作初始化变量的值。
  • 如果一个变量实现没有被 lock 操作锁定,则不允许对它执行 unlock 操作,也不允许去 unlock 一个被其他
    线程锁定的变量。
  • 对一个变量执行 unlock 操作之前,必须先把此变量同步回主内存(执行 store 和 write 操作)。

volatile 型变量的特殊规则

* Java 内存模型对 volatile 专门定义了一些特殊的访问规则,当一个变量被定义成 volatile 之后,他将具备两种特性:
  • 保证此变量对所有线程的可见性。这里不具体解释了。需要注意,volatile 变量的写操作除了对它本身的读操
    作可见外,volatile 写操作之前的所有共享变量均对 volatile 读操作之后的操作可见,另外注意其适用场景。
  • 禁止指令重排序优化。普通的变量仅仅会保证在该方法的执行过程中所有依赖赋值结果的地方都能获得正确
    的结果,而不能保证变量赋值操作的顺序与程序中的执行顺序一致,在单线程中,我们是无法感知这一点
    的。
  • 补充:Java 语言规范规定了 JVM 线程内部维持顺序化语义,也就是说只要程序的最终结果等同于它在严格
    的顺序化环境下的结果,那么指令的执行顺序就可能与代码的顺序不一致,这个过程通过叫做指令的重排
    序。指令重排序存在的意义在于:JVM 能够根据处理器的特性(CPU 的多级缓存系统、多核处理器等)适
    当的重新排序机器指令,使机器指令更符合 CPU 的执行特点,最大限度的发挥机器的性能。在没有同步的
    情况下,编译器、处理器以及运行时等都可能对操作的执行顺序进行一些意想不到的调整。

final 域

final 类型的域是不能修改的,除了这一点外,在 Java 内存模型中,final 域还有着特殊的语义,final 域能确保初
始化过程的安全性,从而可以不受限制地访问不可变对象,并在共享这些对象时无须同步。具体而言,就是被 final 修饰的字段在构造器中一旦被初始化完成,并且构造器没有把“this”的引用传递出去(this 引用逃逸是一件
很危险的事情,其他线程有可能通过这个引用访问到“初始化了一半”的对象),那么在其他线程中就能看到 final 字段的值,而且其外、外部可见状态永远也不会改变。它所带来的安全性是最简单最纯粹的。

long 和 double 型变量的特殊规则

Java 内存模型要求 lock、unlock、read、load、assign、use、store 和 write 这 8 个操作都具有原子性,但
是对于 64 位的数据类型 long 和 double,在模型中特别定义了一条宽松的规定:允许虚拟机将没有被 volatile
修饰的 64 位数据的读写操作划分为两次 32 位的操作来进行。这样,如果有多个线程共享一个未被声明为 volatil
e 的 long 或 double 类型的变量,并且同时对它们进行读取和修改操作,那么某些线程可能会读到一个既非原
值,也非其他线程修改值得代表了“半个变量”的数值。不过这种读取到“半个变量”的情况非常罕见,因为 Ja
va 内存模型虽然允许虚拟机不把 long 和 double 变量的读写实现成原子操作,但允许迅疾选择把这些操作实现
为具有原子性的操作,而且还“强烈建议”虚拟机这样实现。目前各种平台下的商用虚拟机几乎都选择把 64 位
数据的读写操作作为原子操作来对待,因此在编码时,不需要将 long 和 double 变量专门声明为 volatile。