同步与Java内存模型(一)序言
先来看如下这个简单的Java类，该类中并没有使用任何的同步。
final class SetCheck {
private int a = 0;
private long b = 0;
void set() {
a = 1;
b = -1;
}
boolean check() {
return ((b == 0) ||
(b == -1 && a == 1));
}
}如果是在一个串行执行的语言中，执行SetCheck类中的check方法永远不会返回false，即使编译器，运行时和计算机硬件并没有按照你所期望的逻辑来处理这段程序，该方法依然不会返回false。在程序执行过程中，下面这些你所不能预料的行为都是可能发生的：
- 编译器可能会进行指令重排序，所以b变量的赋值操作可能先于a变量。如果是一个内联方法，编译器可能更甚一步将该方法的指令与其他语句进行重排序。
- 处理器可能会对语句所对应的机器指令进行重排序之后再执行，甚至并发地去执行。
- 内存系统（由高速缓存控制单元组成）可能会对变量所对应的内存单元的写操作指令进行重排序。重排之后的写操作可能会对其他的计算/内存操作造成覆盖。
- 编译器，处理器以及内存系统可能会让两条语句的机器指令交错。比如在32位机器上，b变量的高位字节先被写入，然后是a变量，紧接着才会是b变量的低位字节。
- 编译器，处理器以及内存系统可能会导致代表两个变量的内存单元在（如果有的话）连续的check调用（如果有的话）之后的某个时刻才更新，而以这种方式保存相应的值（如在CPU寄存器中）仍会得到预期的结果（check永远不会返回false）。
在串行执行的语言中，只要程序执行遵循类似串行的语义，如上几种行为就不会有任何的影响。在一段简单的代码块中，串行执行程序不会依赖于代码的内部执行细节，因此如上的几种行为可以随意控制代码。这样就为编译器和计算机硬件提供了基本的灵活性。基于此，在过去的数十年内很多技术（CPU的流水线操作，多级缓存，读写平衡，寄存器分配等等）应运而生，为计算机处理速度的大幅提升奠定了基础。这些操作的类似串行执行的特性可以让开发人员无须知道其内部发生了什么。对于开发人员来说，如果不创建自己的线程，那么这些行为也不会对其产生任何的影响。
然而这些情况在并发编程中就完全不一样了，上面的代码在并发过程中，当一个线程调用check方法的时候完全有可能另一个线程正在执行set方法，这种情况下check方法就会将上面提到的优化操作过程暴露出来。如果上述任意一个操作发生，那么check方法就有可能返回false。例如，check方法读取long类型的变量b的时候可能得到的既不是0也不是-1.而是一个被写入一半的值。另一种情况，set方法中的语句的乱序执行有可能导致check方法读取变量b的值的时候是-1，然而读取变量a时却依然是0。
换句话说，不仅是并发执行会导致问题，而且在一些优化操作（比如指令重排序）进行之后也会导致代码执行结果和源代码中的逻辑有所出入。由于编译器和运行时技术的日趋成熟以及多处理器的逐渐普及，这种现象就变得越来越普遍。对于那些一直从事串行编程背景的开发人员（其实，基本上所有的程序员）来说，这可能会导致令人诧异的结果，而这些结果可能从没在串行编程中出现过。这可能就是那些微妙难解的并发编程错误的根本源头吧。
在绝大部分的情况下，有一个很简单易行的方法来避免那些在复杂的并发程序中因代码执行优化导致的问题：使用同步。例如，如果SetCheck类中所有的方法都被声明为synchronized,那么你就可以确保那么内部处理细节都不会影响代码预期的结果了。
但是在有些情况下你却不能或者不想去使用同步，抑或着你需要推断别人未使用同步的代码。在这些情况下你只能依赖Java内存模型所阐述的结果语义所提供的最小保证。Java内存模型允许上面提到的所有操作，但是限制了它们在执行语义上潜在的结果，此外还提出了一些技术让程序员可以用来控制这些语义的某些方面。
Java内存模型是Java语言规范的一部分，主要在JLS的第17章节介绍。这里，我们只是讨论一些基本的动机，属性以及模型的程序一致性。这里对JLS第一版中所缺少的部分进行了澄清。
我们假设Java内存模型可以被看作在1.2.4中描述的那种标准的SMP机器的理想化模型。
在这个模型中，每一个线程都可以被看作为运行在不同的CPU上，然而即使是在多处理器上，这种情况也是很罕见的。但是实际上，通过模型所具备的某些特性，这种CPU和线程单一映射能够通过一些合理的方法去实现。例如，因为CPU的寄存器不能被另一个CPU直接访问，这种模型必须考虑到某个线程无法得知被另一个线程操作变量的值的情况。这种情况不仅仅存在于多处理器环境上，在单核CPU环境里，因为编译器和处理器的不可预测的行为也可能导致同样的情况。
Java内存模型没有具体讲述前面讨论的执行策略是由编译器，CPU，缓存控制器还是其它机制促成的。甚至没有用开发人员所熟悉的类，对象及方法来讨论。取而代之，Java内存模型中仅仅定义了线程和内存之间那种抽象的关系。众所周知，每个线程都拥有自己的工作存储单元（缓存和寄存器的抽象）来存储线程当前使用的变量的值。Java内存模型仅仅保证了代码指令与变量操作的有序性，大多数规则都只是指出什么时候变量值应该在内存和线程工作内存之间传输。这些规则主要是为了解决如下三个相互牵连的问题：
原子性：哪些指令必须是不可分割的。在Java内存模型中，这些规则需声明仅适用于-—实例变量和静态变量，也包括数组元素，但不包括方法中的局部变量-—的内存单元的简单读写操作。
可见性：在哪些情况下，一个线程执行的结果对另一个线程是可见的。这里需要关心的结果有，写入的字段以及读取这个字段所看到的值。
- 有序性：在什么情况下，某个线程的操作结果对其它线程来看是无序的。最主要的乱序执行问题主要表现在读写操作和赋值语句的相互执行顺序上。
当正确的使用了同步，上面属性都会具有一个简单的特性：一个同步方法或者代码块中所做的修改对于使用了同一个锁的同步方法或代码块都具有原子性和可见性。同步方法或代码块之间的执行过程都会和代码指定的执行顺序保持一致。即使代码块内部指令也许是乱序执行的，也不会对使用了同步的其它线程造成任何影响。
当没有使用同步或者使用的不一致的时候，情况就会变得复杂。Java内存模型所提供的保障要比大多数开发人员所期望的弱，也远不及目前业界所实现的任意一款Java虚拟机。这样，开发人员就必须负起额外的义务去保证对象的一致性关系：对象间若有能被多个线程看到的某种恒定关系，所有依赖这种关系的线程就必须一直维持这种关系，而不仅仅由执行状态修改的线程来维持。
同步和Java内存模型 (二)原子性
除了long型字段和double型字段外，java内存模型确保访问任意类型字段所对应的内存单元都是原子的。这包括引用其它对象的引用类型的字段。此外，volatile long 和volatile double也具有原子性 。（虽然java内存模型不保证non-volatile long 和 non-volatile double的原子性，当然它们在某些场合也具有原子性。）（译注：non-volatile long在64位JVM，OS，CPU下具有原子性）
当在一个表达式中使用一个non-long或者non-double型字段时，原子性可以确保你将获得这个字段的初始值或者某个线程对这个字段写入之后的值；但不会是两个或更多线程在同一时间对这个字段写入之后产生混乱的结果值（即原子性可以确保，获取到的结果值所对应的所有bit位，全部都是由单个线程写入的）。但是，如下面（译注：指可见性章节）将要看到的，原子性不能确保你获得的是任意线程写入之后的最新值。 因此，原子性保证通常对并发程序设计的影响很小。
同步和Java内存模型 (三)可见性
只有在下列情况时，一个线程对字段的修改才能确保对另一个线程可见：
一个写线程释放一个锁之后，另一个读线程随后获取了同一个锁。本质上，线程释放锁时会将强制刷新工作内存中的脏数据到主内存中，获取一个锁将强制线程装载（或重新装载）字段的值。锁提供对一个同步方法或块的互斥性执行，线程执行获取锁和释放锁时，所有对字段的访问的内存效果都是已定义的。
注意同步的双重含义：锁提供高级同步协议，同时在线程执行同步方法或块时，内存系统（有时通过内存屏障指令）保证值的一致性。这说明，与顺序程序设计相比较，并发程序设计与分布式程序设计更加类似。同步的第二个特性可以视为一种机制：一个线程在运行已同步方法时，它将发送和/或接收其他线程在同步方法中对变量所做的修改。从这一点来说，使用锁和发送消息仅仅是语法不同而已。
如果把一个字段声明为volatile型，线程对这个字段写入后，在执行后续的内存访问之前，线程必须刷新这个字段且让这个字段对其他线程可见（即该字段立即刷新）。每次对volatile字段的读访问，都要重新装载字段的值。
一个线程首次访问一个对象的字段，它将读到这个字段的初始值或被某个线程写入后的值。
此外，把还未构造完成的对象的引用暴露给某个线程，这是一个错误的做法 (see ?.1.2)。在构造函数内部开始一个新线程也是危险的，特别是这个类可能被子类化时。Thread.start有如下的内存效果：调用start方法的线程释放了锁，随后开始执行的新线程获取了这个锁。如果在子类构造函数执行之前，可运行的超类调用了new Thread(this).start()，当run方法执行时，对象很可能还没有完全初始化。同样，如果你创建且开始一个新线程T，这个线程使用了在执行start之后才创建的一个对象X。你不能确信X的字段值将能对线程T可见。除非你把所有用到X的引用的方法都同步。如果可行的话，你可以在开始T线程之前创建X。
线程终止时，所有写过的变量值都要刷新到主内存中。比如，一个线程使用Thread.join来终止另一个线程，那么第一个线程肯定能看到第二个线程对变量值得修改。
注意，在同一个线程的不同方法之间传递对象的引用，永远也不会出现内存可见性问题。
内存模型确保上述操作最终会发生，一个线程对一个特定字段的特定更新，最终将会对其他线程可见，但这个“最终”可能是很长一段时间。线程之间没有同步时，很难保证对字段的值能在多线程之间保持一致（指写线程对字段的写入立即能对读线程可见）。特别是，如果字段不是volatile或没有通过同步来访问这个字段，在一个循环中等待其他线程对这个字段的写入，这种情况总是错误的(see ?.2.6)。
在缺乏同步的情况下，模型还允许不一致的可见性。比如，得到一个对象的一个字段的最新值，同时得到这个对象的其他字段的过期的值。同样，可能读到一个引用变量的最新值，但读取到这个引用变量引用的对象的字段的过期值。
不管怎样，线程之间的可见性并不总是失效（指线程即使没有使用同步，仍然有可能读取到字段的最新值），内存模型仅仅是允许这种失效发生而已。因此，即使多个线程之间没有使用同步，也不保证一定会发生内存可见性问题（指线程读取到过期的值），java内存模型仅仅是允许内存可见性问题发生而已。在很多当前的JVM实现和java执行平台中，甚至是在那些使用多处理器的JVM和平台中，也很少出现内存可见性问题。共享同一个CPU的多个线程使用公共的缓存，缺少强大的编译器优化，以及存在强缓存一致性的硬件，这些都会使线程更新后的值能够立即在多线程之间传递。这使得测试基于内存可见性的错误是不切实际的，因为这样的错误极难发生。或者这种错误仅仅在某个你没有使用过的平台上发生，或仅在未来的某个平台上发生。这些类似的解释对于多线程之间的内存可见性问题来说非常普遍。没有同步的并发程序会出现很多问题，包括内存一致性问题。
同步和Java内存模型(四)有序性
有序性
有序性规则表现在以下两种场景: 线程内和线程间
- 从某个线程的角度看方法的执行，指令会按照一种叫“串行”（as-if-serial）的方式执行，此种方式已经应用于顺序编程语言。
- 这个线程“观察”到其他线程并发地执行非同步的代码时，任何代码都有可能交叉执行。唯一起作用的约束是：对于同步方法，同步块以及volatile字段的操作仍维持相对有序。
再次提醒，这些仅是最小特性的规则。具体到任何一个程序或平台上，可能存在更严格的有序性规则。所以你不能依赖它们，因为即使你的代码遵循了这些更严格的规则，仍可能在不同特性的JVM上运行失败，而且测试非常困难。
需要注意的是，线程内部的观察视角被JLS [1] 中其他的语义的讨论所采用。例如，算术表达式的计算在线程内看来是从左到右地执行操作（JLS 15.6章节），而这种执行效果是没有必要被其他线程观察到的。
仅当某一时刻只有一个线程操作变量时，线程内的执行表现为串行。出现上述情景，可能是因为使用了同步，互斥体[2] 或者纯属巧合。当多线程同时运行在非同步的代码里进行公用字段的读写时，会形成一种执行模式。在这种模式下，代码会任意交叉执行，原子性和可见性会失效，以及产生竞态条件。这时线程执行不再表现为串行。
尽管JLS列出了一些特定的合法和非法的重排序，如果碰到所列范围之外的问题，会降低以下这条实践保证 ：运行结果反映了几乎所有的重排序产生的代码交叉执行的情况。所以，没必要去探究这些代码的有序性。
同步和Java内存模型（五）Volatile
Volatile
从原子性，可见性和有序性的角度分析，声明为volatile字段的作用相当于一个类通过get/set同步方法保护普通字段，如下：
final class VFloat {
private float value;
final synchronized void set(float f) { value = f; }
final synchronized float get() { return value; }
}与使用synchronized相比，声明一个volatile字段的区别在于没有涉及到锁操作。但特别的是对volatile字段进行“++”这样的读写操作不会被当做原子操作执行。
另外，有序性和可见性仅对volatile字段进行一次读取或更新操作起作用。声明一个引用变量为volatile，不能保证通过该引用变量访问到的非volatile变量的可见性。同理，声明一个数组变量为volatile不能确保数组内元素的可见性。volatile的特性不能在数组内传递，因为数组里的元素不能被声明为volatile。
由于没有涉及到锁操作，声明volatile字段很可能比使用同步的开销更低，至少不会更高。但如果在方法内频繁访问volatile字段，很可能导致更低的性能，这时还不如锁住整个方法。
如果你不需要锁，把字段声明为volatile是不错的选择，但仍需要确保多线程对该字段的正确访问。可以使用volatile的情况包括：
- 该字段不遵循其他字段的不变式。
- 对字段的写操作不依赖于当前值。
- 没有线程违反预期的语义写入非法值。
- 读取操作不依赖于其它非volatile字段的值。
当只有一个线程可以修改字段的值，其它线程可以随时读取，那么把字段声明为volatile是合理的。例如，一个名叫Thermometer(中文：体温计)的类，可以声明temperature字段为volatile。正如在3.4.2节所讨论，一个volatile字段很适合作为完成某些工作的标志。另一个例子在4.4节有描述，通过使用轻量级的执行框架使某些同步工作自动化，但是仍需把结果字段声明为volatile，使其对各个任务都是可见的。
