idea 做网站登录,开网站做商城怎么样,怎样建立网站的快捷方式,门户网站模板免费下载并发编程的模型 并发编程需要解决的两个问题#xff1a;线程之间如何同步#xff0c;线程之间如何通信。 线程之间通信#xff1a;共享内存#xff0c;消息传递。 共享内存通过线程之间读-写程序的公共状态进行通信。消息传递要通过线程之间主动传递消息进行通信。 线程之间…并发编程的模型 并发编程需要解决的两个问题线程之间如何同步线程之间如何通信。 线程之间通信共享内存消息传递。 共享内存通过线程之间读-写程序的公共状态进行通信。消息传递要通过线程之间主动传递消息进行通信。 线程之间同步控制不同线程之间操作发生的相对顺序。 共享内存并发模型中的同步是显式进行的。需要手动指明代码在线程之间如何互斥地执行。在消息传递的并发模型里由于消息的发送必须在消息的接收之前因此同步是隐式进行的。 Java的并发采用了共享内存模型。线程之间的通信是隐式进行的需要手动进行控制。 Java内存模型 在Java中实例域静态域和数组对象存储在堆内存中堆内存在内存之间共享。局部变量方法定义参数和异常处理参数不会在内存中共享不存在可见性问题不受内存模型的影响。Java线程之间的通信由JMM控制JMM决定了一个线程对共享变量的写入何时对另一个线程可见。抽象来看就是线程之间的共享变量存储在主内存中每个线程有一个私有的本地内存本地内存中存储了该线程以读/写共享变量的副本。 线程A与B通信需要经过两个步骤 首先线程A把本地内存A中更新过的共享变量刷新到主内存中去。然后线程B到主内存中去读取线程A之前已更新过的共享变量。JMM通过控制主内存与每个线程的本地内存之间的交互来为程序提供内存可见性的保证。 重排序 为了提高程序执行时的效率编译器和处理器通常会对指令做重排序。 编译器优化的重排序。编译器在不改变单线程程序语义的前提下可以重新安排语句的执行顺序。指令级并行的重排序。现代处理器采用了指令级并行技术Instruction-Level Parallelism ILP来将多条指令重叠执行。如果不存在数据依赖性处理器可以改变语句对应机器指令的执行顺序。内存系统的重排序。由于处理器使用缓存和读/写缓冲区这使得加载和存储操作看上去可能是在乱序执行。 这些重排序都可能会导致多线程程序出现内存可见性问题。对于编译器JMM的编译器重排序规则会禁止特定类型的编译器重排序不是所有的编译器重排序都要禁止。对于处理器重排序JMM的处理器重排序规则会要求java编译器在生成指令序列时插入特定类型的内存屏障memory barriersintel称之为memory fence指令通过内存屏障指令来禁止特定类型的处理器重排序不是所有的处理器重排序都要禁止。 JMM通过禁止特定类型的编译器重排序和处理器重排序为程序提供了内存可见性的保障。 处理器重排序和内存屏障指令 现代的处理器使用写缓冲区来临时保存向内存写入的数据。每个处理器上的写缓冲区仅仅对它所在的处理器可见。这个特性会对内存操作的执行顺序产生重要的影响处理器对内存的读/写操作的执行顺序不一定与内存实际发生的读/写操作顺序一致如图 假设处理器A和处理器B按程序的顺序并行执行内存访问最终却可能得到x y 0的结果。具体的原因如下图所示 里处理器A和处理器B可以同时把共享变量写入自己的写缓冲区A1B1然后从内存中读取另一个共享变量A2B2最后才把自己写缓存区中保存的脏数据刷新到内存中A3B3。当以这种时序执行时程序就可以得到x y 0的结果。 从内存操作实际发生的顺序来看直到处理器A执行A3来刷新自己的写缓存区写操作A1才算真正执行了。虽然处理器A执行内存操作的顺序为A1-A2但内存操作实际发生的顺序却是A2-A1。此时处理器A的内存操作顺序被重排序了。 为了保证内存可见性java编译器在生成指令序列的适当位置会插入内存屏障指令来禁止特定类型的处理器重排序。JMM把内存屏障指令分为下列四类 StoreLoad Barriers是一个“全能型”的屏障它同时具有其他三个屏障的效果。执行该屏障开销会很昂贵因为当前处理器通常要把写缓冲区中的数据全部刷新到内存中buffer fully flush。 happens-before happens-before概念用来描述操作之间的内存可见性。在JMM中如果一个操作执行的结果需要对另一个操作可见那么这两个操作之间必须要存在happens-before关系。这里提到的两个操作既可以是在一个线程之内也可以是在不同线程之间。 与程序员密切相关的happens-before规则如下 程序顺序规则一个线程中的每个操作happens- before 于该线程中的任意后续操作。监视器锁规则对一个监视器锁的解锁happens- before 于随后对这个监视器锁的加锁。volatile变量规则对一个volatile域的写happens- before 于任意后续对这个volatile域的读。传递性如果A happens- before B且B happens- before C那么A happens- before C。注意两个操作之间具有happens-before关系并不意味着前一个操作必须要在后一个操作之前执行happens-before仅仅要求前一个操作执行的结果对后一个操作可见且前一个操作按顺序排在第二个操作之前the first is visible to and ordered before the second。 数据依赖性 如果两个操作访问同一个变量且这两个操作中有一个为写操作此时这两个操作之间就存在数据依赖性。数据依赖分下列三种类型 上面三种情况只要重排序两个操作的执行顺序程序的执行结果将会被改变。 前面提到过编译器和处理器可能会对操作做重排序。编译器和处理器在重排序时会遵守数据依赖性编译器和处理器不会改变存在数据依赖关系的两个操作的执行顺序。 注意这里所说的数据依赖性仅针对单个处理器中执行的指令序列和单个线程中执行的操作不同处理器之间和不同线程之间的数据依赖性不被编译器和处理器考虑。 as-if-serial语义 as-if-serial语义的意思指不管怎么重排序编译器和处理器为了提高并行度单线程程序的执行结果不能被改变。编译器runtime 和处理器都必须遵守as-if-serial语义。 为了遵守as-if-serial语义编译器和处理器不会对存在数据依赖关系的操作做重排序因为这种重排序会改变执行结果。但是如果操作之间不存在数据依赖关系这些操作可能被编译器和处理器重排序。为了具体说明请看下面计算圆面积的代码示例 double pi 3.14; //A double r 1.0; //B double area pi * r * r; //C 复制代码上面三个操作的数据依赖关系如下图所示 如上图所示A和C之间存在数据依赖关系同时B和C之间也存在数据依赖关系。因此在最终执行的指令序列中C不能被重排序到A和B的前面C排到A和B的前面程序的结果将会被改变。但A和B之间没有数据依赖关系编译器和处理器可以重排序A和B之间的执行顺序。下图是该程序的两种执行顺序 as-if-serial语义把单线程程序保护了起来遵守as-if-serial语义的编译器runtime 和处理器共同为编写单线程程序的程序员创建了一个幻觉单线程程序是按程序的顺序来执行的。as-if-serial语义使单线程程序员无需担心重排序会干扰他们也无需担心内存可见性问题。 程序顺序规则 根据happens- before的程序顺序规则上面计算圆的面积的示例代码存在三个happens- before关系 A happens- before BB happens- before CA happens- before C这里的第3个happens- before关系是根据happens- before的传递性推导出来的。 这里A happens- before B但实际执行时B却可以排在A之前执行看上面的重排序后的执行顺序。在第一章提到过如果A happens- before BJMM并不要求A一定要在B之前执行。JMM仅仅要求前一个操作执行的结果对后一个操作可见且前一个操作按顺序排在第二个操作之前。这里操作A的执行结果不需要对操作B可见而且重排序操作A和操作B后的执行结果与操作A和操作B按happens- before顺序执行的结果一致。在这种情况下JMM会认为这种重排序并不非法not illegalJMM允许这种重排序。 在计算机中软件技术和硬件技术有一个共同的目标在不改变程序执行结果的前提下尽可能的开发并行度。编译器和处理器遵从这一目标从happens- before的定义我们可以看出JMM同样遵从这一目标。 重排序对多线程的影响 现在让我们来看看重排序是否会改变多线程程序的执行结果。请看下面的示例代码 class ReorderExample { int a 0; boolean flag false;public void writer() {a 1; //1flag true; //2 }Public void reader() {if (flag) { //3int i a * a; //4……} } } 复制代码flag变量是个标记用来标识变量a是否已被写入。这里假设有两个线程A和BA首先执行writer()方法随后B线程接着执行reader()方法。线程B在执行操作4时能否看到线程A在操作1对共享变量a的写入 答案是不一定能看到。 由于操作1和操作2没有数据依赖关系编译器和处理器可以对这两个操作重排序同样操作3和操作4没有数据依赖关系编译器和处理器也可以对这两个操作重排序。让我们先来看看当操作1和操作2重排序时可能会产生什么效果请看下面的程序执行时序图 如上图所示操作1和操作2做了重排序。程序执行时线程A首先写标记变量flag随后线程B读这个变量。由于条件判断为真线程B将读取变量a。此时变量a还根本没有被线程A写入在这里多线程程序的语义被重排序破坏了 下面再让我们看看当操作3和操作4重排序时会产生什么效果借助这个重排序可以顺便说明控制依赖性。下面是操作3和操作4重排序后程序的执行时序图 在程序中操作3和操作4存在控制依赖关系。当代码中存在控制依赖性时会影响指令序列执行的并行度。为此编译器和处理器会采用猜测Speculation执行来克服控制相关性对并行度的影响。以处理器的猜测执行为例执行线程B的处理器可以提前读取并计算a*a然后把计算结果临时保存到一个名为重排序缓冲reorder buffer ROB的硬件缓存中。当接下来操作3的条件判断为真时就把该计算结果写入变量i中。 从图中我们可以看出猜测执行实质上对操作3和4做了重排序。重排序在这里破坏了多线程程序的语义 在单线程程序中对存在控制依赖的操作重排序不会改变执行结果这也是as-if-serial语义允许对存在控制依赖的操作做重排序的原因但在多线程程序中对存在控制依赖的操作重排序可能会改变程序的执行结果。 数据竞争与顺序一致性保证 当程序未正确同步时就会存在数据竞争。java内存模型规范对数据竞争的定义如下 在一个线程中写一个变量在另一个线程读同一个变量而且写和读没有通过同步来排序。当代码中包含数据竞争时程序的执行往往产生违反直觉的结果前一章的示例正是如此。如果一个多线程程序能正确同步这个程序将是一个没有数据竞争的程序。 JMM对正确同步的多线程程序的内存一致性做了如下保证 如果程序是正确同步的程序的执行将具有顺序一致性sequentially consistent– 即程序的执行结果与该程序在顺序一致性内存模型中的执行结果相同马上我们将会看到这对于程序员来说是一个极强的保证。这里的同步是指广义上的同步包括对常用同步原语lockvolatile和final的正确使用。 顺序一致性内存模型 顺序一致性内存模型是一个被计算机科学家理想化了的理论参考模型它为程序员提供了极强的内存可见性保证。顺序一致性内存模型有两大特性 一个线程中的所有操作必须按照程序的顺序来执行。不管程序是否同步所有线程都只能看到一个单一的操作执行顺序。在顺序一致性内存模型中每个操作都必须原子执行且立刻对所有线程可见。顺序一致性内存模型为程序员提供的视图如下 在概念上顺序一致性模型有一个单一的全局内存这个内存通过一个左右摆动的开关可以连接到任意一个线程。同时每一个线程必须按程序的顺序来执行内存读/写操作。从上图我们可以看出在任意时间点最多只能有一个线程可以连接到内存。当多个线程并发执行时图中的开关装置能把所有线程的所有内存读/写操作串行化。 假设有两个线程A和B并发执行。其中A线程有三个操作它们在程序中的顺序是A1-A2-A3。B线程也有三个操作它们在程序中的顺序是B1-B2-B3。 假设这两个线程使用监视器来正确同步A线程的三个操作执行后释放监视器随后B线程获取同一个监视器。那么程序在顺序一致性模型中的执行效果将如下图所示 现在我们再假设这两个线程没有做同步下面是这个未同步程序在顺序一致性模型中的执行示意图 未同步程序在顺序一致性模型中虽然整体执行顺序是无序的但所有线程都只能看到一个一致的整体执行顺序。以上图为例线程A和B看到的执行顺序都是B1-A1-A2-B2-A3-B3。之所以能得到这个保证是因为顺序一致性内存模型中的每个操作必须立即对任意线程可见。 但是在JMM中就没有这个保证。未同步程序在JMM中不但整体的执行顺序是无序的而且所有线程看到的操作执行顺序也可能不一致。比如在当前线程把写过的数据缓存在本地内存中且还没有刷新到主内存之前这个写操作仅对当前线程可见从其他线程的角度来观察会认为这个写操作根本还没有被当前线程执行。只有当前线程把本地内存中写过的数据刷新到主内存之后这个写操作才能对其他线程可见。在这种情况下当前线程和其它线程看到的操作执行顺序将不一致。 同步程序的顺序一致性效果 下面我们对前面的示例程序ReorderExample用监视器来同步看看正确同步的程序如何具有顺序一致性。 请看下面的示例代码 class SynchronizedExample { int a 0; boolean flag false;public synchronized void writer() {a 1;flag true; }public synchronized void reader() {if (flag) {int i a;……} } } 复制代码上面示例代码中假设A线程执行writer()方法后B线程执行reader()方法。这是一个正确同步的多线程程序。根据JMM规范该程序的执行结果将与该程序在顺序一致性模型中的执行结果相同。下面是该程序在两个内存模型中的执行时序对比图 在顺序一致性模型中所有操作完全按程序的顺序串行执行。而在JMM中临界区内的代码可以重排序但JMM不允许临界区内的代码“逸出”到临界区之外那样会破坏监视器的语义。JMM会在退出监视器和进入监视器这两个关键时间点做一些特别处理使得线程在这两个时间点具有与顺序一致性模型相同的内存视图具体细节后文会说明。虽然线程A在临界区内做了重排序但由于监视器的互斥执行的特性这里的线程B根本无法“观察”到线程A在临界区内的重排序。这种重排序既提高了执行效率又没有改变程序的执行结果。 从这里我们可以看到JMM在具体实现上的基本方针在不改变正确同步的程序执行结果的前提下尽可能的为编译器和处理器的优化打开方便之门。 未同步程序的执行特性 对于未同步或未正确同步的多线程程序JMM只提供最小安全性线程执行时读取到的值要么是之前某个线程写入的值要么是默认值0nullfalseJMM保证线程读操作读取到的值不会无中生有out of thin air的冒出来。为了实现最小安全性JVM在堆上分配对象时首先会清零内存空间然后才会在上面分配对象JVM内部会同步这两个操作。因此在以清零的内存空间pre-zeroed memory分配对象时域的默认初始化已经完成了。 JMM不保证未同步程序的执行结果与该程序在顺序一致性模型中的执行结果一致。因为未同步程序在顺序一致性模型中执行时整体上是无序的其执行结果无法预知。保证未同步程序在两个模型中的执行结果一致毫无意义。 和顺序一致性模型一样未同步程序在JMM中的执行时整体上也是无序的其执行结果也无法预知。同时未同步程序在这两个模型中的执行特性有下面几个差异 顺序一致性模型保证单线程内的操作会按程序的顺序执行而JMM不保证单线程内的操作会按程序的顺序执行比如上面正确同步的多线程程序在临界区内的重排序。这一点前面已经讲过了这里就不再赘述。顺序一致性模型保证所有线程只能看到一致的操作执行顺序而JMM不保证所有线程能看到一致的操作执行顺序。这一点前面也已经讲过这里就不再赘述。JMM不保证对64位的long型和double型变量的读/写操作具有原子性而顺序一致性模型保证对所有的内存读/写操作都具有原子性。第3个差异与处理器总线的工作机制密切相关。在计算机中数据通过总线在处理器和内存之间传递。每次处理器和内存之间的数据传递都是通过一系列步骤来完成的这一系列步骤称之为总线事务bus transaction。总线事务包括读事务read transaction和写事务write transaction。读事务从内存传送数据到处理器写事务从处理器传送数据到内存每个事务会读/写内存中一个或多个物理上连续的字。这里的关键是总线会同步试图并发使用总线的事务。在一个处理器执行总线事务期间总线会禁止其它所有的处理器和I/O设备执行内存的读/写。下面让我们通过一个示意图来说明总线的工作机制 如上图所示假设处理器AB和C同时向总线发起总线事务这时总线仲裁bus arbitration会对竞争作出裁决这里我们假设总线在仲裁后判定处理器A在竞争中获胜总线仲裁会确保所有处理器都能公平的访问内存。此时处理器A继续它的总线事务而其它两个处理器则要等待处理器A的总线事务完成后才能开始再次执行内存访问。假设在处理器A执行总线事务期间不管这个总线事务是读事务还是写事务处理器D向总线发起了总线事务此时处理器D的这个请求会被总线禁止。 总线的这些工作机制可以把所有处理器对内存的访问以串行化的方式来执行在任意时间点最多只能有一个处理器能访问内存。这个特性确保了单个总线事务之中的内存读/写操作具有原子性。 在一些32位的处理器上如果要求对64位数据的读/写操作具有原子性会有比较大的开销。为了照顾这种处理器java语言规范鼓励但不强求JVM对64位的long型变量和double型变量的读/写具有原子性。当JVM在这种处理器上运行时会把一个64位long/ double型变量的读/写操作拆分为两个32位的读/写操作来执行。这两个32位的读/写操作可能会被分配到不同的总线事务中执行此时对这个64位变量的读/写将不具有原子性。 当单个内存操作不具有原子性将可能会产生意想不到后果。请看下面示意图 如上图所示假设处理器A写一个long型变量同时处理器B要读这个long型变量。处理器A中64位的写操作被拆分为两个32位的写操作且这两个32位的写操作被分配到不同的写事务中执行。同时处理器B中64位的读操作被拆分为两个32位的读操作且这两个32位的读操作被分配到同一个的读事务中执行。当处理器A和B按上图的时序来执行时处理器B将看到仅仅被处理器A“写了一半“的无效值。 volatile的特性 当我们声明共享变量为volatile后对这个变量的读/写将会很特别。理解volatile特性的一个好方法是把对volatile变量的单个读/写看成是使用同一个锁对这些单个读/写操作做了同步。下面我们通过具体的示例来说明请看下面的示例代码 class VolatileFeaturesExample {//使用volatile声明64位的long型变量volatile long vl 0L;public void set(long l) {vl l; //单个volatile变量的写}public void getAndIncrement () {vl; //复合多个volatile变量的读/写}public long get() {return vl; //单个volatile变量的读} } 复制代码假设有多个线程分别调用上面程序的三个方法这个程序在语义上和下面程序等价 class VolatileFeaturesExample {long vl 0L; // 64位的long型普通变量//对单个的普通 变量的写用同一个锁同步public synchronized void set(long l) { vl l;}public void getAndIncrement () { //普通方法调用long temp get(); //调用已同步的读方法temp 1L; //普通写操作set(temp); //调用已同步的写方法}public synchronized long get() { //对单个的普通变量的读用同一个锁同步return vl;} } 复制代码如上面示例程序所示对一个volatile变量的单个读/写操作与对一个普通变量的读/写操作使用同一个锁来同步它们之间的执行效果相同。 锁的happens-before规则保证释放锁和获取锁的两个线程之间的内存可见性这意味着对一个volatile变量的读总是能看到任意线程对这个volatile变量最后的写入。 锁的语义决定了临界区代码的执行具有原子性。这意味着即使是64位的long型和double型变量只要它是volatile变量对该变量的读写就将具有原子性。如果是多个volatile操作或类似于volatile这种复合操作这些操作整体上不具有原子性。 简而言之volatile变量自身具有下列特性 可见性。对一个volatile变量的读总是能看到任意线程对这个volatile变量最后的写入。原子性对任意单个volatile变量的读/写具有原子性但类似于volatile这种复合操作不具有原子性。volatile的写-读建立的happens before关系 上面讲的是volatile变量自身的特性对程序员来说volatile对线程的内存可见性的影响比volatile自身的特性更为重要也更需要我们去关注。 从JSR-133开始volatile变量的写-读可以实现线程之间的通信。 从内存语义的角度来说volatile与锁有相同的效果volatile写和锁的释放有相同的内存语义volatile读与锁的获取有相同的内存语义。 请看下面使用volatile变量的示例代码 class VolatileExample {int a 0;volatile boolean flag false;public void writer() {a 1; //1flag true; //2}public void reader() {if (flag) { //3int i a; //4……}} } 复制代码假设线程A执行writer()方法之后线程B执行reader()方法。根据happens before规则这个过程建立的happens before 关系可以分为两类 根据程序次序规则1 happens before 2; 3 happens before 4。根据volatile规则2 happens before 3。根据happens before 的传递性规则1 happens before 4。上述 happens before 关系的图形化表现形式如下 在上图中每一个箭头链接的两个节点代表了一个 happens before 关系。黑色箭头表示程序顺序规则橙色箭头表示 volatile 规则蓝色箭头表示组合这些规则后提供的 happens before 保证。 这里A线程写一个volatile变量后B线程读同一个volatile变量。A线程在写volatile变量之前所有可见的共享变量在B线程读同一个volatile变量后将立即变得对B线程可见。 volatile写-读的内存语义 volatile 写的内存语义如下 当写一个 volatile 变量时JMM 会把该线程对应的本地内存中的共享变量刷新到主内存。 以上面示例程序 VolatileExample 为例假设线程 A 首先执行 writer() 方法随后线程 B 执行 reader() 方法初始时两个线程的本地内存中的 flag 和 a 都是初始状态。下图是线程 A 执行 volatile 写后共享变量的状态示意图 如上图所示线程A在写flag变量后本地内存A中被线程A更新过的两个共享变量的值被刷新到主内存中。此时本地内存A和主内存中的共享变量的值是一致的。 volatile读的内存语义如下 当读一个 volatile 变量时JMM 会把该线程对应的本地内存置为无效。线程接下来将从主内存中读取共享变量。 下面是线程B读同一个 volatile 变量后共享变量的状态示意图 如上图所示在读 flag 变量后本地内存 B 已经被置为无效。此时线程 B 必须从主内存中读取共享变量。线程 B 的读取操作将导致本地内存B与主内存中的共享变量的值也变成一致的了。 如果我们把 volatile 写和 volatile 读这两个步骤综合起来看的话在读线程 B 读一个volatile 变量后写线程 A 在写这个 volatile 变量之前所有可见的共享变量的值都将立即变得对读线程 B 可见。 下面对 volatile 写和 volatile 读的内存语义做个总结 线程 A 写一个 volatile 变量实质上是线程 A 向接下来将要读这个 volatile 变量的某个线程发出了其对共享变量所在修改的消息。线程 B 读一个 volatile 变量实质上是线程 B 接收了之前某个线程发出的在写这个volatile 变量之前对共享变量所做修改的消息。线程A写一个 volatile 变量随后线程 B 读这个 volatile 变量这个过程实质上是线程A 通过主内存向线程 B 发送消息。volatile 内存语义的实现 JMM 如何实现 volatile 写/读的内存语义。 前文我们提到过重排序分为编译器重排序和处理器重排序。为了实现 volatile 内存语义JMM 会分别限制这两种类型的重排序类型。下面是 JMM 针对编译器制定的 volatile 重排序规则表 举例来说第三行最后一个单元格的意思是在程序顺序中当第一个操作为普通变量的读或写时如果第二个操作为 volatile 写则编译器不能重排序这两个操作。 从上表我们可以看出 当第二个操作是 volatile 写时不管第一个操作是什么都不能重排序。这个规则确保volatile 写之前的操作不会被编译器重排序到 volatile 写之后。当第一个操作是 volatile 读时不管第二个操作是什么都不能重排序。这个规则确保volatile 读之后的操作不会被编译器重排序到 volatile 读之前。当第一个操作是 volatile 写第二个操作是 volatile 读时不能重排序。为了实现 volatile 的内存语义编译器在生成字节码时会在指令序列中插入内存屏障来禁止特定类型的处理器重排序。对于编译器来说发现一个最优布置来最小化插入屏障的总数几乎不可能为此JMM 采取保守策略。下面是基于保守策略的 JMM 内存屏障插入策略 在每个 volatile 写操作的前面插入一个 StoreStore 屏障。在每个 volatile 写操作的后面插入一个 StoreLoad 屏障。在每个 volatile 读操作的后面插入一个 LoadLoad 屏障。在每个 volatile 读操作的后面插入一个 LoadStore 屏障。上述内存屏障插入策略非常保守但它可以保证在任意处理器平台任意的程序中都能得到正确的volatile 内存语义。 下面是保守策略下volatile 写 插入内存屏障后生成的指令序列示意图 上图中的 StoreStore 屏障可以保证在 volatile 写之前其前面的所有普通写操作已经对任意处理器可见了。这是因为 StoreStore 屏障将保障上面所有的普通写在 volatile 写之前刷新到主内存。 这里比较有意思的是 volatile 写后面的 StoreLoad 屏障。这个屏障的作用是避免 volatile写与后面可能有的 volatile 读/写操作重排序。因为编译器常常无法准确判断在一个 volatile写的后面是否需要插入一个 StoreLoad 屏障比如一个 volatile 写之后方法立即return。为了保证能正确实现 volatile 的内存语义JMM 在这里采取了保守策略在每个volatile 写的后面或在每个 volatile 读的前面插入一个 StoreLoad 屏障。从整体执行效率的角度考虑JMM 选择了在每个 volatile 写的后面插入一个 StoreLoad 屏障。因为volatile 写-读内存语义的常见使用模式是一个写线程写 volatile 变量多个读线程读同一个 volatile 变量。当读线程的数量大大超过写线程时选择在 volatile 写之后插入StoreLoad 屏障将带来可观的执行效率的提升。从这里我们可以看到 JMM 在实现上的一个特点首先确保正确性然后再去追求执行效率。 下面是在保守策略下volatile 读插入内存屏障后生成的指令序列示意图 上图中的 LoadLoad 屏障用来禁止处理器把上面的 volatile 读与下面的普通读重排序。LoadStore 屏障用来禁止处理器把上面的 volatile 读与下面的普通写重排序。 上述 volatile 写和 volatile 读的内存屏障插入策略非常保守。在实际执行时只要不改变volatile 写-读的内存语义编译器可以根据具体情况省略不必要的屏障。下面我们通过具体的示例代码来说明 class VolatileBarrierExample {int a;volatile int v1 1;volatile int v2 2;void readAndWrite() {int i v1; //第一个volatile读int j v2; // 第二个volatile读a i j; //普通写v1 i 1; // 第一个volatile写v2 j * 2; //第二个 volatile写}… //其他方法 } 复制代码针对 readAndWrite() 方法编译器在生成字节码时可以做如下的优化 注意最后的 StoreLoad 屏障不能省略。因为第二个 volatile 写之后方法立即 return。此时编译器可能无法准确断定后面是否会有 volatile 读或写为了安全起见编译器常常会在这里插入一个 StoreLoad 屏障。 上面的优化是针对任意处理器平台由于不同的处理器有不同“松紧度”的处理器内存模型内存屏障的插入还可以根据具体的处理器内存模型继续优化。以 x86 处理器为例上图中除最后的StoreLoad 屏障外其它的屏障都会被省略。 前面保守策略下的 volatile 读和写在 x86 处理器平台可以优化成 前文提到过x86 处理器仅会对写-读操作做重排序。X86 不会对读-读读-写和写-写操作做重排序因此在 x86 处理器中会省略掉这三种操作类型对应的内存屏障。在 x86 中JMM 仅需在volatile 写后面插入一个 StoreLoad 屏障即可正确实现 volatile 写-读的内存语义。这意味着在 x86 处理器中volatile 写的开销比 volatile 读的开销会大很多因为执行StoreLoad 屏障开销会比较大。 JSR-133 为什么要增强 volatile 的内存语义 在 JSR-133 之前的旧 Java 内存模型中虽然不允许 volatile 变量之间重排序但旧的Java 内存模型允许 volatile 变量与普通变量之间重排序。在旧的内存模型中VolatileExample 示例程序可能被重排序成下列时序来执行 在旧的内存模型中当1和2之间没有数据依赖关系时1和2之间就可能被重排序3和4类似。其结果就是读线程B执行4时不一定能看到写线程 A 在执行1时对共享变量的修改。 因此在旧的内存模型中 volatile 的写-读没有锁的释放-获所具有的内存语义。为了提供一种比锁更轻量级的线程之间通信的机制JSR-133 专家组决定增强 volatile 的内存语义严格限制编译器和处理器对 volatile 变量与普通变量的重排序确保 volatile 的写-读和锁的释放-获取一样具有相同的内存语义。从编译器重排序规则和处理器内存屏障插入策略来看只要volatile 变量与普通变量之间的重排序可能会破坏 volatile 的内存语意这种重排序就会被编译器重排序规则和处理器内存屏障插入策略禁止。 由于 volatile 仅仅保证对单个 volatile 变量的读/写具有原子性而锁的互斥执行的特性可以确保对整个临界区代码的执行具有原子性。在功能上锁比 volatile 更强大在可伸缩性和执行性能上volatile 更有优势。 锁的释放-获取建立的happens before 关系 锁是java并发编程中最重要的同步机制。锁除了让临界区互斥执行外还可以让释放锁的线程向获取同一个锁的线程发送消息。下面是锁释放-获取的示例代码 class MonitorExample {int a 0;public synchronized void writer() { //1a; //2} //3public synchronized void reader() { //4int i a; //5……} //6 } 复制代码假设线程A执行writer()方法随后线程B执行reader()方法。根据happens before规则这个过程包含的happens before 关系可以分为两类 根据程序次序规则1 happens before 2, 2 happens before 3; 4 happens before 5, 5 happens before 6。根据监视器锁规则3 happens before 4。根据happens before 的传递性2 happens before 5。上述happens before 关系的图形化表现形式如下 在上图中每一个箭头链接的两个节点代表了一个 happens before 关系。黑色箭头表示程序顺序规则橙色箭头表示监视器锁规则蓝色箭头表示组合这些规则后提供的 happens before保证。 上图表示在线程A释放了锁之后随后线程B获取同一个锁。在上图中2 happens before 5。因此线程A在释放锁之前所有可见的共享变量在线程B获取同一个锁之后将立刻变得对B线程可见。 锁释放和获取的内存语义 当线程释放锁时JMM 会把该线程对应的本地内存中的共享变量刷新到主内存中。以上面的MonitorExample 程序为例A线程释放锁后共享数据的状态示意图如下 当线程获取锁时JMM 会把该线程对应的本地内存置为无效。从而使得被监视器保护的临界区代码必须要从主内存中去读取共享变量。下面是锁获取的状态示意图 对比锁释放-获取的内存语义与 volatile 写-读的内存语义可以看出锁释放与 volatile 写有相同的内存语义锁获取与 volatile 读有相同的内存语义。 下面对锁释放和锁获取的内存语义做个总结 线程 A 释放一个锁实质上是线程 A 向接下来将要获取这个锁的某个线程发出了线程 A 对共享变量所做修改的消息。线程 B 获取一个锁实质上是线程 B 接收了之前某个线程发出的在释放这个锁之前对共享变量所做修改的消息。线程 A 释放锁随后线程 B 获取这个锁这个过程实质上是线程 A 通过主内存向线程 B 发送消息。锁内存语义的实现 class ReentrantLockExample { int a 0; ReentrantLock lock new ReentrantLock();public void writer() {lock.lock(); //获取锁try {a;} finally {lock.unlock(); //释放锁} }public void reader () {lock.lock(); //获取锁try {int i a;……} finally {lock.unlock(); //释放锁} } } 复制代码ReentrantLock 的实现依赖于 java 同步器框架 AbstractQueuedSynchronizer本文简称之为AQS。AQS 使用一个整型的 volatile 变量命名为 state来维护同步状态马上我们会看到这个 volatile 变量是 ReentrantLock 内存语义实现的关键。 下面是ReentrantLock 的类图仅画出与本文相关的部分 ReentrantLock 分为公平锁和非公平锁。 使用公平锁时加锁方法 lock() 的方法调用轨迹如下 ReentrantLock : lock()FairSync : lock()AbstractQueuedSynchronizer : acquire(int arg)ReentrantLock : tryAcquire(int acquires)在第4步真正开始加锁下面是该方法的源代码 protected final boolean tryAcquire(int acquires) {final Thread current Thread.currentThread();int c getState(); //获取锁的开始首先读volatile变量stateif (c 0) {if (isFirst(current) compareAndSetState(0, acquires)) {setExclusiveOwnerThread(current);return true;}}else if (current getExclusiveOwnerThread()) {int nextc c acquires;if (nextc 0) throw new Error(Maximum lock count exceeded);setState(nextc);return true;}return false; } 复制代码从上面源代码中我们可以看出加锁方法首先读 volatile 变量 state。 在使用公平锁时解锁方法 unlock() 的方法调用轨迹如下 ReentrantLock : unlock()AbstractQueuedSynchronizer : release(int arg)Sync : tryRelease(int releases)在第3步真正开始释放锁下面是该方法的源代码 protected final boolean tryRelease(int releases) {int c getState() - releases;if (Thread.currentThread() ! getExclusiveOwnerThread())throw new IllegalMonitorStateException();boolean free false;if (c 0) {free true;setExclusiveOwnerThread(null);}setState(c); //释放锁的最后写volatile变量statereturn free; } 复制代码从上面的源代码我们可以看出在释放锁的最后写 volatile 变量 state。 公平锁在释放锁的最后写 volatile 变量 state在获取锁时首先读这个 volatile 变量。根据 volatile 的 happens-before 规则释放锁的线程在写 volatile 变量之前可见的共享变量在获取锁的线程读取同一个 volatile 变量后将立即变的对获取锁的线程可见。 使用非公平锁时加锁方法 lock() 的方法调用轨迹如下 ReentrantLock : lock()NonfairSync : lock()AbstractQueuedSynchronizer : compareAndSetState(int expect, int update)在第3步真正开始加锁下面是该方法的源代码 protected final boolean compareAndSetState(int expect, int update) {return unsafe.compareAndSwapInt(this, stateOffset, expect, update); } 复制代码该方法以原子操作的方式更新 state 变量本文把 java 的 compareAndSet() 方法调用简称为 CAS。JDK 文档对该方法的说明如下如果当前状态值等于预期值则以原子方式将同步状态设置为给定的更新值。此操作具有 volatile 读和写的内存语义。 这里我们分别从编译器和处理器的角度来分析,CAS 如何同时具有 volatile 读和 volatile 写的内存语义。 前文我们提到过编译器不会对 volatile 读与 volatile 读后面的任意内存操作重排序编译器不会对 volatile 写与 volatile 写前面的任意内存操作重排序。组合这两个条件意味着为了同时实现 volatile 读和 volatile 写的内存语义编译器不能对 CAS 与 CAS 前面和后面的任意内存操作重排序。 下面我们来分析在常见的 intel x86 处理器中CAS 是如何同时具有 volatile 读和 volatile 写的内存语义的。 下面是 sun.misc.Unsafe 类的 compareAndSwapInt() 方法的源代码 public final native boolean compareAndSwapInt(Object o, long offset,int expected,int x); 复制代码可以看到这是个本地方法调用。这个本地方法在 openjdk 中依次调用的 C 代码为unsafe.cppatomic.cpp 和 atomicwindowsx86.inline.hpp。这个本地方法的最终实现在 openjdk 的如下位置openjdk-7-fcs-src-b147-27jun2011\openjdk\hotspot\src\oscpu\windowsx86\vm\ atomicwindowsx86.inline.hpp对应于 windows 操作系统X86 处理器。下面是对应于 intel x86 处理器的源代码的片段 // Adding a lock prefix to an instruction on MP machine // VC doesnt like the lock prefix to be on a single line // so we cant insert a label after the lock prefix. // By emitting a lock prefix, we can define a label after it. #define LOCK_IF_MP(mp) __asm cmp mp, 0 \__asm je L0 \__asm _emit 0xF0 \__asm L0:inline jint Atomic::cmpxchg (jint exchange_value, volatile jint* dest, jint compare_value) {// alternative for InterlockedCompareExchangeint mp os::is_MP();__asm {mov edx, destmov ecx, exchange_valuemov eax, compare_valueLOCK_IF_MP(mp)cmpxchg dword ptr [edx], ecx} } 复制代码如上面源代码所示程序会根据当前处理器的类型来决定是否为 cmpxchg 指令添加 lock 前缀。如果程序是在多处理器上运行就为 cmpxchg 指令加上 lock 前缀lock cmpxchg。反之如果程序是在单处理器上运行就省略 lock 前缀单处理器自身会维护单处理器内的顺序一致性不需要 lock 前缀提供的内存屏障效果。 intel 的手册对 lock 前缀的说明如下 确保对内存的读-改-写操作原子执行。在 Pentium 及 Pentium 之前的处理器中带有lock 前缀的指令在执行期间会锁住总线使得其他处理器暂时无法通过总线访问内存。很显然这会带来昂贵的开销。从 Pentium 4Intel Xeon 及 P6 处理器开始intel 在原有总线锁的基础上做了一个很有意义的优化如果要访问的内存区域area of memory在 lock 前缀指令执行期间已经在处理器内部的缓存中被锁定即包含该内存区域的缓存行当前处于独占或以修改状态并且该内存区域被完全包含在单个缓存行cache line中那么处理器将直接执行该指令。由于在指令执行期间该缓存行会一直被锁定其它处理器无法读/写该指令要访问的内存区域因此能保证指令执行的原子性。这个操作过程叫做缓存锁定cache locking缓存锁定将大大降低 lock 前缀指令的执行开销但是当多处理器之间的竞争程度很高或者指令访问的内存地址未对齐时仍然会锁住总线。禁止该指令与之前和之后的读和写指令重排序。把写缓冲区中的所有数据刷新到内存中。上面的第2点和第3点所具有的内存屏障效果足以同时实现 volatile 读和 volatile 写的内存语义。 经过上面的这些分析现在我们终于能明白为什么 JDK 文档说 CAS 同时具有 volatile 读和volatile 写的内存语义了。 现在对公平锁和非公平锁的内存语义做个总结 公平锁和非公平锁释放时最后都要写一个 volatile 变量 state。公平锁获取时首先会去读这个 volatile 变量。非公平锁获取时首先会用 CAS 更新这个 volatile 变量,这个操作同时具有 volatile 读和 volatile 写的内存语义。从本文对 ReentrantLock 的分析可以看出锁释放-获取的内存语义的实现至少有下面两种方式 利用 volatile 变量的写-读所具有的内存语义。利用 CAS 所附带的 volatile 读和 volatile 写的内存语义。concurrent 包的实现 由于 java 的 CAS 同时具有 volatile 读和 volatile 写的内存语义因此 Java 线程之间的通信现在有了下面四种方式 A 线程写 volatile 变量随后 B 线程读这个 volatile 变量。A 线程写 volatile 变量随后 B 线程用 CAS 更新这个 volatile 变量。A 线程用 CAS 更新一个volatile变量随后 B 线程用 CAS 更新这个 volatile 变量。A 线程用 CAS 更新一个 volatile 变量随后 B 线程读这个 volatile 变量。Java 的 CAS 会使用现代处理器上提供的高效机器级别原子指令这些原子指令以原子方式对内存执行读-改-写操作这是在多处理器中实现同步的关键从本质上来说能够支持原子性读-改-写指令的计算机器是顺序计算图灵机的异步等价机器因此任何现代的多处理器都会去支持某种能对内存执行原子性读-改-写操作的原子指令。同时volatile 变量的读/写和 CAS 可以实现线程之间的通信。把这些特性整合在一起就形成了整个 concurrent 包得以实现的基石。如果我们仔细分析 concurrent 包的源代码实现会发现一个通用化的实现模式 首先声明共享变量为 volatile然后使用 CAS 的原子条件更新来实现线程之间的同步同时配合以 volatile 的读/写和 CAS 所具有的 volatile 读和写的内存语义来实现线程之间的通信。AQS非阻塞数据结构和原子变量类java.util.concurrent.atomic 包中的类这些 concurrent 包中的基础类都是使用这种模式来实现的而 concurrent 包中的高层类又是依赖于这些基础类来实现的。从整体来看concurrent 包的实现示意图如下 final 对于final 域编译器和处理器要遵守两个重排序规则 在构造函数内对一个 final 域的写入与随后把这个被构造对象的引用赋值给一个引用变量这两个操作之间不能重排序。初次读一个包含 final 域的对象的引用与随后初次读这个 final 域这两个操作之间不能重排序。下面我们通过一些示例性的代码来分别说明这两个规则 public class FinalExample {int i; //普通变量final int j; //final变量static FinalExample obj;public void FinalExample () { //构造函数i 1; //写普通域j 2; //写final域}public static void writer () { //写线程A执行obj new FinalExample ();}public static void reader () { //读线程B执行FinalExample object obj; //读对象引用int a object.i; //读普通域int b object.j; //读final域} } 复制代码这里假设一个线程 A 执行 writer() 方法随后另一个线程 B 执行 reader() 方法。 写 final 域的重排序规则 写 final 域的重排序规则禁止把 final 域的写重排序到构造函数之外。这个规则的实现包含下面2个方面 JMM 禁止编译器把 final 域的写重排序到构造函数之外。编译器会在 final 域的写之后构造函数 return 之前插入一个 StoreStore 屏障。这个屏障禁止处理器把 final 域的写重排序到构造函数之外。现在让我们分析 writer() 方法。writer() 方法只包含一行代码finalExample new FinalExample()。这行代码包含两个步骤 构造一个 FinalExample 类型的对象 把这个对象的引用赋值给引用变量 obj。 假设线程 B 读对象引用与读对象的成员域之间没有重排序马上会说明为什么需要这个假设下图是一种可能的执行时序 在上图中写普通域的操作被编译器重排序到了构造函数之外读线程B错误的读取了普通变量i初始化之前的值。而写 final 域的操作被写 final 域的重排序规则“限定”在了构造函数之内读线程 B 正确的读取了 final 变量初始化之后的值。 写 final 域的重排序规则可以确保在对象引用为任意线程可见之前对象的 final 域已经被正确初始化过了而普通域不具有这个保障。以上图为例在读线程 B “看到”对象引用 obj 时很可能 obj 对象还没有构造完成对普通域i的写操作被重排序到构造函数外此时初始值2还没有写入普通域i。 读 final 域的重排序规则 读 final 域的重排序规则如下 在一个线程中初次读对象引用与初次读该对象包含的 final 域JMM 禁止处理器重排序这两个操作注意这个规则仅仅针对处理器。编译器会在读 final 域操作的前面插入一个 LoadLoad 屏障。初次读对象引用与初次读该对象包含的 final 域这两个操作之间存在间接依赖关系。由于编译器遵守间接依赖关系因此编译器不会重排序这两个操作。大多数处理器也会遵守间接依赖大多数处理器也不会重排序这两个操作。但有少数处理器允许对存在间接依赖关系的操作做重排序比如 alpha 处理器这个规则就是专门用来针对这种处理器。 reader() 方法包含三个操作 初次读引用变量 obj;初次读引用变量 obj 指向对象的普通域 j。初次读引用变量 obj 指向对象的 final 域 i。现在我们假设写线程 A 没有发生任何重排序同时程序在不遵守间接依赖的处理器上执行下面是一种可能的执行时序 在上图中读对象的普通域的操作被处理器重排序到读对象引用之前。读普通域时该域还没有被写线程A写入这是一个错误的读取操作。而读 final 域的重排序规则会把读对象 final 域的操作“限定”在读对象引用之后此时该 final 域已经被 A 线程初始化过了这是一个正确的读取操作。 读 final 域的重排序规则可以确保在读一个对象的 final 域之前一定会先读包含这个 final 域的对象的引用。在这个示例程序中如果该引用不为 null那么引用对象的 final 域一定已经被 A 线程初始化过了。 如果 final 域是引用类型 public class FinalReferenceExample { final int[] intArray; //final是引用类型 static FinalReferenceExample obj;public FinalReferenceExample () { //构造函数intArray new int[1]; //1intArray[0] 1; //2 }public static void writerOne () { //写线程A执行obj new FinalReferenceExample (); //3 }public static void writerTwo () { //写线程B执行obj.intArray[0] 2; //4 }public static void reader () { //读线程C执行if (obj ! null) { //5int temp1 obj.intArray[0]; //6} } } 复制代码这里 final 域为一个引用类型它引用一个 int 型的数组对象。对于引用类型写 final 域的重排序规则对编译器和处理器增加了如下约束 在构造函数内对一个 final 引用的对象的成员域的写入与随后在构造函数外把这个被构造对象的引用赋值给一个引用变量这两个操作之间不能重排序。对上面的示例程序我们假设首先线程 A 执行 writerOne() 方法执行完后线程 B 执行 writerTwo() 方法执行完后线程 C 执行 reader() 方法。下面是一种可能的线程执行时序 在上图中1 是对 final 域的写入2 是对这个 final 域引用的对象的成员域的写入3是把被构造的对象的引用赋值给某个引用变量。这里除了前面提到的1不能和3重排序外2和3也不能重排序。 JMM 可以确保读线程 C 至少能看到写线程 A 在构造函数中对 final 引用对象的成员域的写入。即 C 至少能看到数组下标 0 的值为 1。而写线程 B 对数组元素的写入读线程 C 可能看的到也可能看不到。JMM 不保证线程 B 的写入对读线程 C 可见因为写线程 B 和读线程 C 之间存在数据竞争此时的执行结果不可预知。 如果想要确保读线程 C 看到写线程 B 对数组元素的写入写线程 B 和读线程 C 之间需要使用同步原语lock 或 volatile来确保内存可见性。 为什么 final 引用不能从构造函数内“逸出” 前面我们提到过写 final 域的重排序规则可以确保在引用变量为任意线程可见之前该引用变量指向的对象的 final 域已经在构造函数中被正确初始化过了。其实要得到这个效果还需要一个保证在构造函数内部不能让这个被构造对象的引用为其他线程可见也就是对象引用不能在构造函数中“逸出”。为了说明问题让我们来看下面示例代码 public class FinalReferenceEscapeExample { final int i; static FinalReferenceEscapeExample obj;public FinalReferenceEscapeExample () {i 1; //1写final域obj this; //2 this引用在此“逸出” }public static void writer() {new FinalReferenceEscapeExample (); }public static void reader {if (obj ! null) { //3int temp obj.i; //4} } } 复制代码假设一个线程 A 执行 writer() 方法另一个线程 B 执行 reader() 方法。这里的操作2使得对象还未完成构造前就为线程 B 可见。即使这里的操作 2 是构造函数的最后一步且即使在程序中操作 2 排在操作 1 后面执行 read() 方法的线程仍然可能无法看到 final 域被初始化后的值因为这里的操作 1 和操作 2 之间可能被重排序。实际的执行时序可能如下图所示 从上图我们可以看出在构造函数返回前被构造对象的引用不能为其他线程可见因为此时的 final 域可能还没有被初始化。在构造函数返回后任意线程都将保证能看到 final 域正确初始化之后的值。 final 语义在处理器中的实现 现在我们以 x86 处理器为例说明 final 语义在处理器中的具体实现。 上面我们提到写 final 域的重排序规则会要求译编器在 final 域的写之后构造函数return 之前插入一个 StoreStore 障屏。读 final 域的重排序规则要求编译器在读 final 域的操作前面插入一个 LoadLoad 屏障。 由于 x86 处理器不会对写-写操作做重排序所以在 x86 处理器中写 final 域需要的 StoreStore 障屏会被省略掉。同样由于 x86 处理器不会对存在间接依赖关系的操作做重排序所以在 x86 处理器中读 final 域需要的 LoadLoad 屏障也会被省略掉。也就是说在 x86 处理器中final 域的读/写不会插入任何内存屏障