java内存屏障与JVM并发详解.doc

深入Java底层：内存屏障与JVM并发详解(1)2010-04-27 09:17 Dennis Byrne infoQ我要评论(0)字号：T|T本文介绍了内存屏障对多线程程序的影响，同时将研究内存屏障与JVM并发机制的关系，如易变量（volatile）、同步（synchronized）和原子条件式（atomic conditional）。AD：内存屏障，又称内存栅栏，是一组处理器指令，用于实现对内存操作的顺序限制。本文假定读者已经充分掌握了相关概念和Java内存模型，不讨论并发互斥、并行机制和原子性。内存屏障用来实现并发编程中称为可见性（visibility）的同样重要的作用。关于JVM更多内容，请参阅：JVM详解 Java虚拟机原理与优化内存屏障为何重要？对主存的一次访问一般花费硬件的数百次时钟周期。处理器通过缓存（caching）能够从数量级上降低内存延迟的成本这些缓存为了性能重新排列待定内存操 作的顺序。也就是说，程序的读写操作不一定会按照它要求处理器的顺序执行。当数据是不可变的，同时/或者数据限制在线程范围内，这些优化是无害的。如果把这些优化与对称多处理（symmetric multi-processing）和共享可变状态（shared mutable state）结合，那么就是一场噩梦。当基于共享可变状态的内存操作被重新排序时，程序可能行为不定。一个线程写入的数据可能被其他线程可见，原因是数据 写入的顺序不一致。适当的放置内存屏障通过强制处理器顺序执行待定的内存操作来避免这个问题。内存屏障的协调作用内存屏障不直接由JVM暴露，相反它们被JVM插入到指令序列中以维持语言层并发原语的语义。我们研究几个简单Java程序的源代码和汇编指令。首先快速看一下Dekker算法中的内存屏障。该算法利用volatile变量协调两个线程之间的共享资源访问。请不要关注该算法的出色细节。哪些部分是相关的？每个线程通过发信号试图进入代码第一行的关键区域。如果线程在第三行意识到冲突（两个线程都要访问），通 过turn变量的操作来解决。在任何时刻只有一个线程可以访问关键区域。1. /coderunbyfirstthread/coderunbysecondthread 2. 3. 1intentFirst=true;intentSecond=true; 4. 2 5. 3while(intentSecond)while(intentFirst)/volatileread 6. 4if(turn!=0)if(turn!=1)/volatileread 7. 5intentFirst=false;intentSecond=false; 8. 6while(turn!=0)while(turn!=1) 9. 7intentFirst=true;intentSecond=true; 10. 8 11. 9 12. 10criticalSection();criticalSection(); 13. 11 14. 12turn=1;turn=0;/volatilewrite 15. 13intentFirst=false;intentSecond=false;/volatilewrite硬件优化可以在没有内存屏障的情况下打乱这段代码，即使编译器按照程序员的想法顺序列出所有的内存操作。考虑第三、四行的两次顺序volatile读操 作。每一个线程检查其他线程是否发信号想进入关键区域，然后检查轮到谁操作了。考虑第12、13行的两次顺序写操作。每一个线程把访问权释放给其他线程， 然后撤销自己访问关键区域的意图。读线程应该从不期望在其他线程撤销访问意愿后观察到其他线程对turn变量的写操作。这是个灾难。但是如果这些变量没有 volatile修饰符，这的确会发生！例如，没有volatile修饰符，第二个线程在第一个线程对turn执行写操作（倒数第二行）之前可能会观察到 第一个线程对intentFirst(倒数第一行)的写操作。关键词volatile避免了这种情况，因为它在对turn变量的写操作和对 intentFirst变量的写操作之间创建了一个先后关系。编译器无法重新排序这些写操作，如果必要，它会利用一个内存屏障禁止处理器重排序。让我们来 看看一些实现细节。PrintAssembly HotSpot选项是JVM的一个诊断标志，允许我们获取JIT编译器生成的汇编指令。这需要最新的OpenJDK版本或者新HotSpot update14或者更高版本。通过需要一个反编译插件。Kenai项目提供了用于Solaris、Linux和BSD的插件二进制文件。hsdis是另 一款可以在Windows通过源码构建的插件。两次顺序读操作的第一次（第三行）的汇编指令如下。指令流基于Itanium 2多处理硬件、JDK 1.6 update 17。本文的所有指令流都在左手边以行号标记。相关的读操作、写操作和内存屏障指令都以粗体标记。建议读者不要沉迷于每一行指令。1. 10x2000000001de819c:addsr37=597,r36;.84112554 2. 20x2000000001de81a0:ld1.acqr38=r37;.0b30014aa010 3. 30x2000000001de81a6:nop.m0x0;.0000000200c0 4. 40x2000000001de81ac:sxt1r38r38=r38;.00513004 5. 50x2000000001de81b0:cmp4.eqp0,p6=0,r38;.1100004c8639 6. 60x2000000001de81b6:nop.i0x0;.000000020003 7. 70x2000000001de81bc:br.cond.dpnt.many0x2000000001de8220;简短的指令流其实内容丰富。第一次volatile位于第二行。Java内存模型确保了JVM会在第二次读操作之前将第一次读操作交给处理器，也就是按照 “程序的顺序”但是这单单一行指令是不够的，因为处理器仍然可以自由乱序执行这些操作。为了支持Java内存模型的一致性，JVM在第一次读操作上添加了注解ld.acq，也就是“载入获取”（load acquire）。通过使用ld.acq，编译器确保第二行的读操作在接下来的读操作之前完成，问题就解决了。请注意这影响了读操作，而不是写。内存屏障强制读或写操作顺序限制不是单向的。强制读和写操作顺序限制的内存屏障是双向的，类似于双向开的栅栏。使用ld.acq就是单向内存屏障的例子。一致性具有两面性。如果一个读线程在两次读操作之间插入了内存屏障而另外一个线程没有在两次写操作之间添加内存屏障又有什么用呢？线程为了协调，必须同时 遵守这个协议，就像网络中的节点或者团队中的成员。如果某个线程破坏了这个约定，那么其他所有线程的努力都白费。Dekker算法的最后两行代码的汇编指令应该插入一个内存屏障，两次volatile写之间。1. $java-XX:+UnlockDiagnosticVMOptions-XX:PrintAssemblyOptions=hsdis-print-bytes 2. -XX:CompileCommand=print,WriterReader.writeWriterReader 3. 10x2000000001de81c0:addsr37=592,r36;.0b2841490421 4. 20x2000000001de81c6:st4.relr37=r39;.003895602380 5. 30x2000000001de81cc:addsr36=596,r36;.84112544 6. 40x2000000001de81d0:st1.relr36=r0;.09000048a011 7. 50x2000000001de81d6:mf;.000000440000 8. 60x2000000001de81dc:nop.i0x0;.00040000 9. 70x2000000001de81e0:movr12=r33;.006000420021 10. 80x2000000001de81e6:mov.retb0=r35,0x2000000001de81e0 11. 90x2000000001de81ec:mov.iar.pfs=r34;.00aa0220 12. 100x2000000001de81f0:movr6=r32;.093000400021这里我们可以看到在第四行第二次写操作被注解了一个显式内存屏障。通过使用st.rel，即“存储释放”（store release），编译器确保第一次写操作在第二次写操作之前完成。这就完成了两边的约定，因为第一次写操作在第二次写操作之前发生。st.rel屏障是单向的就像ld.acq一样。但是在第五行编译器设置了一个双向内存屏障。mf指令，或者称为“内存栅栏”，是Itanium 2指令集中的完整栅栏。笔者认为是多余的。深入Java底层：内存屏障与JVM并发详解(2)2010-04-27 09:17 Dennis Byrne infoQ我要评论(0)字号：T|T本文介绍了内存屏障对多线程程序的影响，同时将研究内存屏障与JVM并发机制的关系，如易变量（volatile）、同步（synchronized）和原子条件式（atomic conditional）。AD：内存屏障是特定于硬件的本文不想针对所有内存屏障做一综述。这将是一件不朽的功绩。但是，重要的是认识到这些指令在不同的硬件体系中迥异。下面的指令是连续写操作在多处理 Intel Xeon硬件上编译的结果。本文后面的所有汇编指令除非特殊声明否则都出自于Intel Xeon。1. 10x03f8340c:push%ebp;.55 2. 20x03f8340d:sub$0x8,%esp;.81ec08000000 3. 30x03f83413:mov$0x14c,%edi;.bf4c010000 4. 40x03f83418:movb$0x1,-0x505a72f0(%edi);.c687108da5af01 5. 50x03f8341f:mfence;.0faef0 6. 60x03f83422:mov$0x148,%ebp;.bd48010000 7. 70x03f83427:mov$0x14d,%edx;.ba4d010000 8. 80x03f8342c:movsbl-0x505a72f0(%edx),%ebx;.0fbe9a108da5af 9. 90x03f83433:test%ebx,%ebx;.85db 10. 100x03f83435:jne0x03f83460;.7529 11. 110x03f83437:movl$0x1,-0x505a72f0(%ebp);.c785108da5af01 12. 120x03f83441:movb$0x0,-0x505a72f0(%edi);.c687108da5af00 13. 130x03f83448:mfence;.0faef0 14. 140x03f8344b:add$0x8,%esp;.83c408 15. 150x03f8344e:pop%ebp;.5d我们可以看到x86 Xeon在第11、12行执行两次volatile写操作。第二次写操作后面紧跟着mfence操作显式的双向内存屏障，下面的连续写操作基于SPARC。1. 10xfb8ecc84:ldub%l1+0x155,%l3;.e60c6155 2. 20xfb8ecc88:cmp%l3,0;.80a4e000 3. 30xfb8ecc8c:bne,pn%icc,0xfb8eccb0;.12400009 4. 40xfb8ecc90:nop;.01000000 5. 50xfb8ecc94:st%l0,%l1+0x150;.e0246150 6. 60xfb8ecc98:clrb%l1+0x154;.c02c6154 7. 70xfb8ecc9c:membar#StoreLoad;.8143e002 8. 80xfb8ecca0:sethi%hi(0xff3fc000),%l0;.213fcff0 9. 90xfb8ecca4:ld%l0,%g0;.c0042000 10. 100xfb8ecca8:ret;.81c7e008 11. 110xfb8eccac:restore;.81e80000我们看到在第五、六行存在两次volatile写操作。第二次写操作后面是一个membar指令显式的双向内存屏障。x86和SPARC的指令流与Itanium的指令流存在一个重要区别。JVM在x86和SPARC上通过内存屏障跟踪连续写操作，但是在两次写操作之间没有放置内存屏障。另一方面，Itanium的指令流在两次写操作之间存在内存屏障。为何JVM在不同的硬件架构之间表现不一？因为硬件架构都有自己的内 存模型，每一个内存模型有一套一致性保障。某些内存模型，如x86和SPARC等，拥有强大的一致性保障。另一些内存模型，如Itanium、 PowerPC和Alpha，是一种弱保障。例如，x86和SPARC不会重新排序连续写操作也就没有必要放置内存屏障。Itanium、 PowerPC和Alpha将重新排序连续写操作因此JVM必须在两者之间放置内存屏障。JVM使用内存屏障减少Java内存模型和硬件内存模型之间的距离。隐式内存屏障显式屏障指令不是序列化内存操作的唯一方式。让我们再看一看Counter类这个例子。1. classCounter 2. 3. staticintcounter=0; 4. 5. publicstaticvoidmain(String_) 6. for(inti=0;i100000;i+) 7. inc(); 8. 9. 10. staticsynchronizedvoidinc()counter+=1; 11. 12. Counter类执行了一个典型的读-修改-写的操作。静态counter字段不是volatile的，因为所有三个操作必须要原子可见的。因此，inc 方法是synchronized修饰的。我们可以采用下面的命令编译Counter类并查看生成的汇编指令。Java内存模型确保了synchronized区域的退出和volatile内存操作都是相同的可见性，因此我们应该预料到会有另一个内存屏障。1. $java-XX:+UnlockDiagnosticVMOptions-XX:PrintAssemblyOptions=hsdis-print-bytes 2. -XX:-UseBiasedLocking-XX:CompileCommand=print,Counter.incCounter 3. 10x04d5eda7:push%ebp;.55 4. 20x04d5eda8:mov%esp,%ebp;.8bec 5. 30x04d5edaa:sub$0x28,%esp;.83ec28 6. 40x04d5edad:mov$0x95ba5408,%esi;.be0854ba95 7. 50x04d5edb2:lea0x10(%esp),%edi;.8d7c2410 8. 60x04d5edb6:mov%esi,0x4(%edi);.897704 9. 70x04d5edb9:mov(%esi),%eax;.8b06 10. 80x04d5edbb:or$0x1,%eax;.83c801 11. 90x04d5edbe:mov%eax,(%edi);.8907 12. 100x04d5edc0:lockcmpxchg%edi,(%esi);.f00fb13e 13. 110x04d5edc4:je0x04d5edda;.0f8410000000 14. 120x04d5edca:sub%esp,%eax;.2bc4 15. 130x04d5edcc:and$0xfffff003,%eax;.81e003f0ffff 16. 140x04d5edd2:mov%eax,(%edi);.8907 17. 150x04d5edd4:jne0x04d5ee11;.0f8537000000 18. 160x04d5edda:mov$0x95ba52b8,%eax;.b8b852ba95 19. 170x04d5eddf:mov0x148(%eax),%esi;.8bb048010000 20. 180x04d5ede5:inc%esi;.46 21. 190x04d5ede6:mov%esi,0x148(%eax);.89b048010000 22. 200x04d5edec:lea0x10(%esp),%eax;.8d442410 23. 210x04d5edf0:mov(%eax),%esi;.8b30 24. 220x04d5edf2:test%esi,%esi;.85f6 25. 230x04d5edf4:je0x04d5ee07;.0f840d000000 26. 240x04d5edfa:mov0x4(%eax),%edi;.8b7804 27. 250x04d5edfd:lockcmpxchg%esi,(%edi);.f00fb137 28. 260x04d5ee01:jne0x04d5ee1f;.0f8518000000 29. 270x04d5ee07:mov%ebp,%esp;.8be5 30. 280x04d5ee09:pop%ebp;.5d不出意外，synchronized生成的指令数量比volatile多。第18行做了一次增操作，但是JVM没有显式插入内存屏障。相反，JVM通过在 第10行和第25行cmpxchg的lock前缀一石二鸟。cmpxchg的语义超越了本文的范畴。lock cmpxchg不仅原子性执行写操作，也会刷新等待的读写操作。写操作现在将在所有后续内存操作之前完成。如果我们通过java.util.concurrent.atomic.AtomicInteger 重构和运行Counter，将看到同样的手段。1. importjava.util.concurrent.atomic.AtomicInteger; 2. 3. classCounter 4. 5. staticAtomicIntegercounter=newAtomicInteger(0); 6. 7. publicstaticvoidmain(Stringargs) 8. for(inti=0;i1000000;i+) 9. counter.incrementAndGet(); 10. 11. 12. 13. 14. $java-XX:+UnlockDiagnosticVMOptions-XX:PrintAssemblyOptions=hsdis-print-bytes 15. -XX:CompileCommand=print,*AtomicInteger.incrementAndGetCounter 16. 10x024451f7:push%ebp;.55 17. 20x024451f8:mov%esp,%ebp;.8bec 18. 30x024451fa:sub$0x38,%esp;.83ec38 19. 40x024451fd:jmp0x0244520a;.e908000000 20. 50x02445202:xchg%ax,%ax;.6690 21. 60x02445204:test%eax,0xb771e100;.850500e171b7 22. 70x0244520a:mov0x8(%ecx),%eax;.8b4108 23. 80x0244520d:mov%eax,%esi;.8bf0 24. 90x0244520f:inc%esi;.46 25. 100x02445210:mov$0x9a3f03d0,%edi;.bfd0033f9a 26. 110x02445215:mov0x160(%edi),%edi;.8bbf60010000 27. 120x0244521b:mov%ecx,%edi;.8bf9 28. 130x0244521d:add$0x8,%edi;.83c708 29. 140x02445220:lockcmpxchg%esi,(%edi);.f00fb137 30. 150x02445224:mov$0x1,%eax;.b801000000 31. 160x02445229:je0x02445234;.0f8405000000 32. 170x0244522f:mov$0x0,%eax;.b800000000 33. 180x02445234:cmp$0x0,%eax;.83f800 34. 190x02445237:je0x02445204;.74cb 35. 200x02445239:mov%esi,%eax;.8bc6 36. 210x0244523b:mov%ebp,%esp;.8be5 37. 220x0244523d:pop%ebp;.5d我们又一次在第14行看到了带有lock前缀的写操作。这确保了变量的新值（写操作）会在其他所有后续内存操作之前完成。深入Java底层：内存屏障与JVM并发详解(3)2010-04-27 09:17 Dennis Byrne infoQ我要评论(0)字号：T|T本文介绍了内存屏障对多线程程序的影响，同时将研究内存屏障与JVM并发机制的关系，如易变量（volatile）、同步（synchronized）和原子条件式（atomic conditional）。AD：内存屏障能够避免JVM非常擅于消除不必要的内存屏障。通常JVM很幸运，因为硬件内存模型的一致性保障强于或者等于Java内存模型。在这种情况下，JVM只是简单地插 入一个no op语句，而不是真实的内存屏障。例如，x86和SPARC内存模型的一致性保障足够强壮以消除读volatile变量时所需的内存屏障。还记得在 Itanium上两次读操作之间的显式单向内存屏障吗？x86上的Dekker算法中连续volatile读操作的汇编指令之间没有任何内存屏障。x86平台上共享内存的连续读操作。1. 10x03f83422:mov$0x148,%ebp;.bd48010000 2. 20x03f83427:mov$0x14d,%edx;.ba4d010000 3. 30x03f8342c:movsbl-0x505a72f0(%edx),%ebx;.0fbe9a108da5af 4. 40x03f83433:test%ebx,%ebx;.85db 5. 50x03f83435:jne0x03f83460;.7529 6. 60x03f83437:movl$0x1,-0x505a72f0(%ebp);.c785108da5af01 7. 70x03f83441:movb$0x0,-0x505a72f0(%edi);.c687108da5af00 8. 80x03f83448:mfence;.0faef0 9. 90x03f8344b:add$0x8,%esp;.83c408 10. 100x03f8344e:pop%ebp;.5d 11. 110x03f8344f:test%eax,0xb78ec000;.850500c08eb7 12. 120x03f83455:ret;.c3 13. 130x03f83456:nopw0x0(%eax,%eax,1);.66660f1f840000 14. 140x03f83460:mov-0x505a72f0(%ebp),%ebx;.8b9d108da5af 15. 150x03f83466:test%edi,0xb78ec000;.853d00c08eb7第三行和第十四行存在volatile读操作，而且都没有伴随内存屏障。也就是说，x86和SPARC上的volatile读操作的性能下降对于代码的优 化影响很小指令本身和常规读操作一样。单向内存屏障本质上比双向屏障性能要好一些。JVM在确保单向屏障即可的情况下会避免使用双向屏障。本文的第一个例子展示了这点。Itanium平台上的 连续两次读操作被插入单向内存屏障。如果读操作插入显式双向内存屏障，程序仍然正确，但是延迟比较长。动态编译静态编译器在构建阶段决定的一切事情，在动态编译器那里都可以在运行时决定，甚至更多。更多信息意味着存在更多机会可以优化。例如，让我们看看JVM在单 处理器运行时如何对待内存屏障。以下指令流来自于通过Dekker算法实现两次连续volatile写操作的运行时编译。程序运行于 x86硬件上的单处理器模式中的VMWare工作站镜像。1. 10x017b474c:push%ebp;.55 2. 20x017b474d:sub$0x8,%esp;.81ec08000000 3. 30x017b4753:mov$0x14c,%edi;.bf4c010000 4. 40x017b4758:movb$0x1,-0x507572f0(%edi);.c687108d8aaf01 5. 50x017b475f:mov$0x148,%ebp;.bd48010000 6. 60x017b4764:mov$0x14d,%edx;.ba4d010000 7. 70x017b4769:movsbl-0x507572f0(%edx),%ebx;.0fbe9a108d8aaf 8. 80x017b4770:test%ebx,%ebx;.85db 9. 90x017b4772:jne0x017b4790;.751c 10. 100x017b4774:movl$0x1,-0x507572f0(%ebp);.c785108d8aaf0111 11. 120x017b4785:add$0x8,%esp;.83c408 12. 130x017