深入Java底层:内存屏障与JVM并发详解

开发 后端
本文介绍了内存屏障对多线程程序的影响,同时将研究内存屏障与JVM并发机制的关系,如易变量(volatile)、同步(synchronized)和原子条件式(atomic conditional)。

内存屏障,又称内存栅栏,是一组处理器指令,用于实现对内存操作的顺序限制。本文假定读者已经充分掌握了相关概念和Java内存模型,不讨论并发互斥、并行机制和原子性。内存屏障用来实现并发编程中称为可见性(visibility)的同样重要的作用。

关于JVM更多内容,请参阅:JVM详解 Java虚拟机原理与优化

内存屏障为何重要?

对主存的一次访问一般花费硬件的数百次时钟周期。处理器通过缓存(caching)能够从数量级上降低内存延迟的成本这些缓存为了性能重新排列待定内存操 作的顺序。也就是说,程序的读写操作不一定会按照它要求处理器的顺序执行。当数据是不可变的,同时/或者数据限制在线程范围内,这些优化是无害的。

如果把这些优化与对称多处理(symmetric multi-processing)和共享可变状态(shared mutable state)结合,那么就是一场噩梦。当基于共享可变状态的内存操作被重新排序时,程序可能行为不定。一个线程写入的数据可能被其他线程可见,原因是数据 写入的顺序不一致。适当的放置内存屏障通过强制处理器顺序执行待定的内存操作来避免这个问题。

内存屏障的协调作用

内存屏障不直接由JVM暴露,相反它们被JVM插入到指令序列中以维持语言层并发原语的语义。我们研究几个简单Java程序的源代码和汇编指令。首先快速看一下Dekker算法中的内存屏障。该算法利用volatile变量协调两个线程之间的共享资源访问。

请不要关注该算法的出色细节。哪些部分是相关的?每个线程通过发信号试图进入代码第一行的关键区域。如果线程在第三行意识到冲突(两个线程都要访问),通 过turn变量的操作来解决。在任何时刻只有一个线程可以访问关键区域。

  1.  // code run by first thread     // code run by second thread  
  2.  
  3.  1    intentFirst = true;          intentSecond = true;  
  4.  2  
  5.  3    while (intentSecond)   while (intentFirst)       // volatile read  
  6.  4     if (turn != 0) {      if (turn != 1) {       // volatile read  
  7.  5       intentFirst = false;        intentSecond = false;  
  8.  6       while (turn != 0) {}        while (turn != 1) {}  
  9.  7       intentFirst = true;        intentSecond = true;  
  10.  8     }               }  
  11.  9  
  12. 10    criticalSection();   criticalSection();  
  13. 11  
  14. 12    turn = 1;     turn = 0;                 // volatile write  
  15. 13    intentFirst = false;   intentSecond = false;     // volatile write 

硬件优化可以在没有内存屏障的情况下打乱这段代码,即使编译器按照程序员的想法顺序列出所有的内存操作。考虑第三、四行的两次顺序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. 1  0x2000000001de819c:      adds r37=597,r36;;  ;...84112554  
  2. 2  0x2000000001de81a0:      ld1.acq r38=[r37];;  ;...0b30014a a010  
  3. 3  0x2000000001de81a6:      nop.m 0x0     ;...00000002 00c0  
  4. 4  0x2000000001de81ac:      sxt1 r38r38=r38;;  ;...00513004  
  5. 5  0x2000000001de81b0:      cmp4.eq p0,p6=0,r38  ;...1100004c 8639  
  6. 6  0x2000000001de81b6:      nop.i 0x0     ;...00000002 0003  
  7. 7  0x2000000001de81bc:      br.cond.dpnt.many 0x2000000001de8220; 

简短的指令流其实内容丰富。第一次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.write WriterReader   
  3.  1  0x2000000001de81c0:      adds r37=592,r36;;  ;...0b284149 0421  
  4.  2  0x2000000001de81c6:      st4.rel [r37]=r39  ;...00389560 2380  
  5.  3  0x2000000001de81cc:      adds r36=596,r36;;  ;...84112544  
  6.  4  0x2000000001de81d0:      st1.rel [r36]=r0  ;...09000048 a011  
  7.  5  0x2000000001de81d6:      mf            ;...00000044 0000  
  8.  6  0x2000000001de81dc:      nop.i 0x0;;   ;...00040000  
  9.  7  0x2000000001de81e0:      mov r12=r33   ;...00600042 0021  
  10.  8  0x2000000001de81e6:      mov.ret b0=r35,0x2000000001de81e0  
  11.  9  0x2000000001de81ec:      mov.i ar.pfs=r34  ;...00aa0220  
  12. 10  0x2000000001de81f0:      mov r6=r32    ;...09300040 0021 

这里我们可以看到在第四行第二次写操作被注解了一个显式内存屏障。通过使用st.rel,即“存储释放”(store release),编译器确保第一次写操作在第二次写操作之前完成。这就完成了两边的约定,因为第一次写操作在第二次写操作之前发生。

st.rel屏障是单向的——就像ld.acq一样。但是在第五行编译器设置了一个双向内存屏障。mf指令,或者称为“内存栅栏”,是Itanium 2指令集中的完整栅栏。笔者认为是多余的。#p#

内存屏障是特定于硬件的

本文不想针对所有内存屏障做一综述。这将是一件不朽的功绩。但是,重要的是认识到这些指令在不同的硬件体系中迥异。下面的指令是连续写操作在多处理 Intel Xeon硬件上编译的结果。本文后面的所有汇编指令除非特殊声明否则都出自于Intel Xeon。

  1. 1  0x03f8340c: push   %ebp               ;...55  
  2.  2  0x03f8340d: sub    $0x8,%esp          ;...81ec0800 0000  
  3.  3  0x03f83413: mov    $0x14c,%edi        ;...bf4c0100 00  
  4.  4  0x03f83418: movb   $0x1,-0x505a72f0(%edi)  ;...c687108d a5af01  
  5.  5  0x03f8341f: mfence                    ;...0faef0  
  6.  6  0x03f83422: mov    $0x148,%ebp        ;...bd480100 00  
  7.  7  0x03f83427: mov    $0x14d,%edx        ;...ba4d0100 00  
  8.  8  0x03f8342c: movsbl -0x505a72f0(%edx),%ebx  ;...0fbe9a10 8da5af  
  9.  9  0x03f83433: test   %ebx,%ebx          ;...85db  
  10. 10  0x03f83435: jne    0x03f83460         ;...7529  
  11. 11  0x03f83437: movl   $0x1,-0x505a72f0(%ebp)  ;...c785108d a5af01  
  12. 12  0x03f83441: movb   $0x0,-0x505a72f0(%edi)  ;...c687108d a5af00  
  13. 13  0x03f83448: mfence                    ;...0faef0  
  14. 14  0x03f8344b: add    $0x8,%esp          ;...83c408  
  15. 15  0x03f8344e: pop    %ebp               ;...5d 

我们可以看到x86 Xeon在第11、12行执行两次volatile写操作。第二次写操作后面紧跟着mfence操作——显式的双向内存屏障,下面的连续写操作基于SPARC。

  1.  1 0xfb8ecc84: ldub  [ %l1 + 0x155 ], %l3  ;...e60c6155  
  2.  2 0xfb8ecc88: cmp  %l3, 0               ;...80a4e000  
  3.  3 0xfb8ecc8c: bne,pn   %icc, 0xfb8eccb0  ;...12400009  
  4.  4 0xfb8ecc90: nop                       ;...01000000  
  5.  5 0xfb8ecc94: st  %l0, [ %l1 + 0x150 ]  ;...e0246150  
  6.  6 0xfb8ecc98: clrb  [ %l1 + 0x154 ]     ;...c02c6154  
  7.  7 0xfb8ecc9c: membar  #StoreLoad        ;...8143e002  
  8.  8 0xfb8ecca0: sethi  %hi(0xff3fc000), %l0  ;...213fcff0  
  9.  9 0xfb8ecca4: ld  [ %l0 ], %g0          ;...c0042000  
  10. 10 0xfb8ecca8: ret                       ;...81c7e008  
  11. 11 0xfb8eccac: 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. class Counter{  
  2.  
  3.     static int counter = 0;  
  4.  
  5.     public static void main(String[] _){  
  6.         for(int i = 0; i < 100000; i++)  
  7.             inc();  
  8.     }  
  9.  
  10.     static synchronized void inc(){ counter += 1; }  
  11.  

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.inc Counter   
  3.  1  0x04d5eda7: push   %ebp               ;...55  
  4.  2  0x04d5eda8: mov    %esp,%ebp          ;...8bec  
  5.  3  0x04d5edaa: sub    $0x28,%esp         ;...83ec28  
  6.  4  0x04d5edad: mov    $0x95ba5408,%esi   ;...be0854ba 95  
  7.  5  0x04d5edb2: lea    0x10(%esp),%edi    ;...8d7c2410  
  8.  6  0x04d5edb6: mov    %esi,0x4(%edi)     ;...897704  
  9.  7  0x04d5edb9: mov    (%esi),%eax        ;...8b06  
  10.  8  0x04d5edbb: or     $0x1,%eax          ;...83c801  
  11.  9  0x04d5edbe: mov    %eax,(%edi)        ;...8907  
  12. 10  0x04d5edc0: lock cmpxchg %edi,(%esi)  ;...f00fb13e  
  13. 11  0x04d5edc4: je     0x04d5edda         ;...0f841000 0000  
  14. 12  0x04d5edca: sub    %esp,%eax          ;...2bc4  
  15. 13  0x04d5edcc: and    $0xfffff003,%eax   ;...81e003f0 ffff  
  16. 14  0x04d5edd2: mov    %eax,(%edi)        ;...8907  
  17. 15  0x04d5edd4: jne    0x04d5ee11         ;...0f853700 0000  
  18. 16  0x04d5edda: mov    $0x95ba52b8,%eax   ;...b8b852ba 95  
  19. 17  0x04d5eddf: mov    0x148(%eax),%esi   ;...8bb04801 0000  
  20. 18  0x04d5ede5: inc    %esi               ;...46  
  21. 19  0x04d5ede6: mov    %esi,0x148(%eax)   ;...89b04801 0000  
  22. 20  0x04d5edec: lea    0x10(%esp),%eax    ;...8d442410  
  23. 21  0x04d5edf0: mov    (%eax),%esi        ;...8b30  
  24. 22  0x04d5edf2: test   %esi,%esi          ;...85f6  
  25. 23  0x04d5edf4: je     0x04d5ee07         ;...0f840d00 0000  
  26. 24  0x04d5edfa: mov    0x4(%eax),%edi     ;...8b7804  
  27. 25  0x04d5edfd: lock cmpxchg %esi,(%edi)  ;...f00fb137  
  28. 26  0x04d5ee01: jne    0x04d5ee1f         ;...0f851800 0000  
  29. 27  0x04d5ee07: mov    %ebp,%esp          ;...8be5  
  30. 28  0x04d5ee09: pop    %ebp               ;...5d 

不出意外,synchronized生成的指令数量比volatile多。第18行做了一次增操作,但是JVM没有显式插入内存屏障。相反,JVM通过在 第10行和第25行cmpxchg的lock前缀一石二鸟。cmpxchg的语义超越了本文的范畴。

lock cmpxchg不仅原子性执行写操作,也会刷新等待的读写操作。写操作现在将在所有后续内存操作之前完成。如果我们通过java.util.concurrent.atomic.AtomicInteger 重构和运行Counter,将看到同样的手段。

  1.  import java.util.concurrent.atomic.AtomicInteger;  
  2.  
  3.     class Counter{  
  4.  
  5.         static AtomicInteger counter = new AtomicInteger(0);  
  6.  
  7.         public static void main(String[] args){  
  8.             for(int i = 0; i < 1000000; i++)  
  9.                 counter.incrementAndGet();  
  10.         }  
  11.  
  12.     }  
  13.  
  14. $ java -XX:+UnlockDiagnosticVMOptions -XX:PrintAssemblyOptions=hsdis-print-bytes   
  15. -XX:CompileCommand=print,*AtomicInteger.incrementAndGet Counter   
  16.  1  0x024451f7: push   %ebp               ;...55  
  17.  2  0x024451f8: mov    %esp,%ebp          ;...8bec  
  18.  3  0x024451fa: sub    $0x38,%esp         ;...83ec38  
  19.  4  0x024451fd: jmp    0x0244520a         ;...e9080000 00  
  20.  5  0x02445202: xchg   %ax,%ax            ;...6690  
  21.  6  0x02445204: test   %eax,0xb771e100    ;...850500e1 71b7  
  22.  7  0x0244520a: mov    0x8(%ecx),%eax     ;...8b4108  
  23.  8  0x0244520d: mov    %eax,%esi          ;...8bf0  
  24.  9  0x0244520f: inc    %esi               ;...46  
  25. 10  0x02445210: mov    $0x9a3f03d0,%edi   ;...bfd0033f 9a  
  26. 11  0x02445215: mov    0x160(%edi),%edi   ;...8bbf6001 0000  
  27. 12  0x0244521b: mov    %ecx,%edi          ;...8bf9  
  28. 13  0x0244521d: add    $0x8,%edi          ;...83c708  
  29. 14  0x02445220: lock cmpxchg %esi,(%edi)  ;...f00fb137  
  30. 15  0x02445224: mov    $0x1,%eax          ;...b8010000 00  
  31. 16  0x02445229: je     0x02445234         ;...0f840500 0000  
  32. 17  0x0244522f: mov    $0x0,%eax          ;...b8000000 00  
  33. 18  0x02445234: cmp    $0x0,%eax          ;...83f800  
  34. 19  0x02445237: je     0x02445204         ;...74cb  
  35. 20  0x02445239: mov    %esi,%eax          ;...8bc6  
  36. 21  0x0244523b: mov    %ebp,%esp          ;...8be5  
  37. 22  0x0244523d: pop    %ebp               ;...5d 

我们又一次在第14行看到了带有lock前缀的写操作。这确保了变量的新值(写操作)会在其他所有后续内存操作之前完成。#p#

内存屏障能够避免

JVM非常擅于消除不必要的内存屏障。通常JVM很幸运,因为硬件内存模型的一致性保障强于或者等于Java内存模型。在这种情况下,JVM只是简单地插 入一个no op语句,而不是真实的内存屏障。

例如,x86和SPARC内存模型的一致性保障足够强壮以消除读volatile变量时所需的内存屏障。还记得在 Itanium上两次读操作之间的显式单向内存屏障吗?x86上的Dekker算法中连续volatile读操作的汇编指令之间没有任何内存屏障。x86平台上共享内存的连续读操作。

  1. 1  0x03f83422: mov    $0x148,%ebp        ;...bd480100 00  
  2.  2  0x03f83427: mov    $0x14d,%edx        ;...ba4d0100 00  
  3.  3  0x03f8342c: movsbl -0x505a72f0(%edx),%ebx  ;...0fbe9a10 8da5af  
  4.  4  0x03f83433: test   %ebx,%ebx          ;...85db  
  5.  5  0x03f83435: jne    0x03f83460         ;...7529  
  6.  6  0x03f83437: movl   $0x1,-0x505a72f0(%ebp)  ;...c785108d a5af01  
  7.  7  0x03f83441: movb   $0x0,-0x505a72f0(%edi)  ;...c687108d a5af00  
  8.  8  0x03f83448: mfence                    ;...0faef0  
  9.  9  0x03f8344b: add    $0x8,%esp          ;...83c408  
  10. 10  0x03f8344e: pop    %ebp               ;...5d  
  11. 11  0x03f8344f: test   %eax,0xb78ec000    ;...850500c0 8eb7  
  12. 12  0x03f83455: ret                       ;...c3  
  13. 13  0x03f83456: nopw   0x0(%eax,%eax,1)   ;...66660f1f 840000  
  14. 14  0x03f83460: mov    -0x505a72f0(%ebp),%ebx  ;...8b9d108d a5af  
  15. 15  0x03f83466: test   %edi,0xb78ec000    ;...853d00c0 8eb7 

第三行和第十四行存在volatile读操作,而且都没有伴随内存屏障。也就是说,x86和SPARC上的volatile读操作的性能下降对于代码的优 化影响很小——指令本身和常规读操作一样。

单向内存屏障本质上比双向屏障性能要好一些。JVM在确保单向屏障即可的情况下会避免使用双向屏障。本文的第一个例子展示了这点。Itanium平台上的 连续两次读操作被插入单向内存屏障。如果读操作插入显式双向内存屏障,程序仍然正确,但是延迟比较长。

动态编译

静态编译器在构建阶段决定的一切事情,在动态编译器那里都可以在运行时决定,甚至更多。更多信息意味着存在更多机会可以优化。例如,让我们看看JVM在单 处理器运行时如何对待内存屏障。以下指令流来自于通过Dekker算法实现两次连续volatile写操作的运行时编译。程序运行于 x86硬件上的单处理器模式中的VMWare工作站镜像。

  1. 1  0x017b474c: push   %ebp               ;...55  
  2.  2  0x017b474d: sub    $0x8,%esp          ;...81ec0800 0000  
  3.  3  0x017b4753: mov    $0x14c,%edi        ;...bf4c0100 00  
  4.  4  0x017b4758: movb   $0x1,-0x507572f0(%edi)  ;...c687108d 8aaf01  
  5.  5  0x017b475f: mov    $0x148,%ebp        ;...bd480100 00  
  6.  6  0x017b4764: mov    $0x14d,%edx        ;...ba4d0100 00  
  7.  7  0x017b4769: movsbl -0x507572f0(%edx),%ebx  ;...0fbe9a10 8d8aaf  
  8.  8  0x017b4770: test   %ebx,%ebx          ;...85db  
  9.  9  0x017b4772: jne    0x017b4790         ;...751c  
  10. 10  0x017b4774: movl   $0x1,-0x507572f0(%ebp)  ;...c785108d 8aaf0111   
  11. 12  0x017b4785: add    $0x8,%esp          ;...83c408  
  12. 13  0x017b4788: pop    %ebp               ;...5d 

在单处理器系统上,JVM为所有内存屏障插入了一个no op指令,因为内存操作已经序列化了。每一个写操作(第10、11行)后面都跟着一个屏障。JVM针对原子条件式做了类似的优化。下面的指令流来自于同一 个VMWare镜像的AtomicInteger.incrementAndGet动态编译结果。

  1. 1  0x036880f7: push   %ebp               ;...55  
  2.  2  0x036880f8: mov    %esp,%ebp          ;...8bec  
  3.  3  0x036880fa: sub    $0x38,%esp         ;...83ec38  
  4.  4  0x036880fd: jmp    0x0368810a         ;...e9080000 00  
  5.  5  0x03688102: xchg   %ax,%ax            ;...6690  
  6.  6  0x03688104: test   %eax,0xb78b8100    ;...85050081 8bb7  
  7.  7  0x0368810a: mov    0x8(%ecx),%eax     ;...8b4108  
  8.  8  0x0368810d: mov    %eax,%esi          ;...8bf0  
  9.  9  0x0368810f: inc    %esi               ;...46  
  10. 10  0x03688110: mov    $0x9a3f03d0,%edi   ;...bfd0033f 9a  
  11. 11  0x03688115: mov    0x160(%edi),%edi   ;...8bbf6001 0000  
  12. 12  0x0368811b: mov    %ecx,%edi          ;...8bf9  
  13. 13  0x0368811d: add    $0x8,%edi          ;...83c708  
  14. 14  0x03688120: cmpxchg %esi,(%edi)       ;...0fb137  
  15. 15  0x03688123: mov    $0x1,%eax          ;...b8010000 00  
  16. 16  0x03688128: je     0x03688133         ;...0f840500 0000  
  17. 17  0x0368812e: mov    $0x0,%eax          ;...b8000000 00  
  18. 18  0x03688133: cmp    $0x0,%eax          ;...83f800  
  19. 19  0x03688136: je     0x03688104         ;...74cc  
  20. 20  0x03688138: mov    %esi,%eax          ;...8bc6  
  21. 21  0x0368813a: mov    %ebp,%esp          ;...8be5  
  22. 22  0x0368813c: pop    %ebp               ;...5d 

注意第14行的cmpxchg指令。之前我们看到编译器通过lock前缀把该指令提供给处理器。由于缺少SMP,JVM决定避免这种成本——与静态编译有些不同。

结束语

内存屏障是多线程编程的必要装备。它们形式多样,某些是显式的,某些是隐式的。某些是双向的,某些是单向的。JVM利用这些形式在所有平台中有效地支持Java内存模型。我们希望本文能够帮助经验丰富的JVM开发人员了解一些代码在底层如何运行的知识。

【编辑推荐】

  1. 深入Java虚拟机:JVM中的Stack和Heap
  2. JVM内存模型及垃圾收集策略解析
  3. Java的未来:百家争鸣的JVM 

 

责任编辑:王晓东 来源: infoQ
相关推荐

2020-04-21 22:18:20

MESI内存CPU

2018-11-01 10:34:37

JVM内存配置

2019-12-10 14:51:00

CPU缓存内存

2023-10-27 07:47:58

Java语言顺序性

2015-12-28 11:41:57

JVM内存区域内存溢出

2019-05-06 08:37:14

JVMLinux内存

2011-12-20 10:43:21

Java

2010-09-25 12:54:24

JVM内存

2010-09-27 09:31:42

JVM内存结构

2023-11-05 12:05:35

JVM内存

2021-08-16 10:35:52

JVM标记法屏障

2020-05-27 21:13:27

JavaJVM内存

2010-09-25 12:38:40

JVM内存模型

2010-09-27 13:48:41

JVM内存结构

2019-11-12 14:40:43

CPU缓存内存

2009-04-28 13:48:09

2011-08-24 09:30:29

JavaJVM

2010-09-27 08:38:49

JVM堆JVM栈

2010-09-26 13:23:13

JVM内存管理机制

2019-02-26 14:33:22

JVM内存虚拟机
点赞
收藏

51CTO技术栈公众号