java内存屏障与JVM并发详解

深入Java底层：内存屏障与JVM并发详解(1)

本文介绍了内存屏障对多线程程序的影响，同时将研究内存屏障与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. // 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 r

ead

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 w

rite

硬件优化可以在没有内存屏障的情况下打乱这段代码，即使编译器按照程序员的想法顺序列出所有的内存操作。考虑第三、四行的两次顺序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指令集中的完整栅栏。笔者认为是多余的。

深入Java底层：内存屏障与JVM并发详解(2)

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

AD：内存屏障是特定于硬件的

本文不想针对所有内存屏障做一综述。这将是一件不朽的功绩。但是，重要的是认识到这些指令在不同的硬件体系中迥异。下面的指令是连续写操作在多处理 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.

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.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前缀的写操作。这确保了变量的新值（写操作）会在其他所有后续内存操作之前完成。

深入Java底层：内存屏障与JVM并发详解(3)

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

AD：内存屏障能够避免

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开发人员了解一些代码在底层如何运行的知识。

java技术面试必问：JVM 内存模型讲解

java技术面试必问：JVM 内存模型讲解 今天我们就来聊一聊Java内存模型，面试中面试官会通过考察你对jvm的理解更深入得了解你的水平。在了解jvm内存模型前我们先回顾下，java程序的执行过程： java文件在通过java编译器生产.class 字节码文件，然后由jvm中的类加载器加载各个类中的字节码文件，加载完成后由jvm执行引擎执行，在整个加载过程中，jvm用一段空间来存储程序执行期间需要的数据和相关信息，这个空间就叫做jvm内存。 一、JVM 的重要性 首先你应该知道，运行一个 Java 应用程序，我们必须要先安装 JDK 或者 JRE 。这是因为 Java 应用在编译后会变成字节码，然后通过字节码运行在 JVM 中，而 JVM 是JRE 的核心组成部分。 二、优点 JVM 不仅承担了 Java 字节码的分析（JIT compiler）和执行（Runtime），同时也内置了自动内存分配管理机制。这个机制可以大大降低手动分配回收机制可能带来的内存泄露和内存溢出风险，使 Java 开发人员不需要关注每个对象的内存分配以及回收，从而更专注于业务本身。 三、缺点 这个机制在提升 Java 开发效率的同时，也容易使 Java 开发人员过度依赖于自动化，弱化对内存的管理能力，这样系统就很容易发生 JVM 的堆内存异常、垃圾回收（GC）的不合适以及 GC 次数过于频繁等问题，这些都将直接影响到应用服务的性能。 四、内存模型 JVM 内存模型共分为5个区：堆（Heap）、方法区（Method Area）、程序计数器（Program Counter Register）、虚拟机栈（VM Stack）、本地方法栈（Native Method Stack）。 其中，堆（Heap）、方法区（Method Area）为线程共享，程序计数器（Program Counter Register）、虚拟机栈（VM Stack）、本地方法栈（Native Method Stack）为线程隔离。 五、堆（Heap） 堆是 JVM 内存中最大的一块内存空间，该内存被所有线程共享，几乎所有对象和数组都被分配到了堆内存中。 堆被划分为新生代和老年代，新生代又被进一步划分为 Eden 区和 Survivor 区，最后 Survivor 由 From Survivor 和 To Survivor 组成。

Java虚拟机(JVM)参数配置说明

Java虚拟机（JVM）参数配置说明 在Java、J2EE大型应用中，JVM非标准参数的配置直接关系到整个系统的性能。 JVM非标准参数指的是JVM底层的一些配置参数，这些参数在一般开发中默认即可，不需要任何配置。但是在生产环境中，为了提高性能，往往需要调整这些参数，以求系统达到最佳新能。另外这些参数的配置也是影响系统稳定性的一个重要因素，相信大多数Java开发人员都见过“O utOfMem ory”类型的错误。呵呵，这其中很可能就是JVM参数配置不当或者就没有配置没意识到配置引起的。 为了说明这些参数，还需要说说JDK中的命令行工具一些知识做铺垫。 首先看如何获取这些命令配置信息说明： 假设你是windows平台，你安装了J2SDK，那么现在你从cmd控制台窗口进入J2SDK安装目录下的bin目录，然后运行java命令，出现如下结果，这些就是包括java.exe工具的和J VM的所有命令都在里面。 ----------------------------------------------------------------------- D:\j2sdk15\bin>java Usage: java [-options] class [args...] (to execute a class) or java [-options] -jar jarfile [args...] (to execute a jar file) where options include: -client to select the "client" VM -server to select the "server" VM -hotspot is a synonym for the "client" VM [deprecated] The default VM is client.

JAVA内存分析指引201007_V0.2

JA V A内存分析指引 2010-07 1 环境说明 根据一般项目部署情况，生产环境以WebSphere5和WebSphere6为主，本文中所涉及环境变量也主要采用WebSphere的相关环境变量。 WebSphere5安装目录（默认）： Windows：C:\Program Files\WebSphere\AppServer AIX：/usr/WebSphere/ AppServer WebSphere5日志路径 Windows:C:\Program Files\WebSphere\AppServer\logs\server1 AIX: /usr/WebSphere/ AppServer/logs/server1 WebSphere6安装目录(默认)： Windows：C:\Program Files\IBM\WebSphere\AppServer AIX：/usr/IBM/WebSphere/AppServer WebSphere6日志路径： Windows:C:\Program Files\IBM\WebSphere\AppServer\profiles\AppSrv01\logs\server1 AIX: /usr/IBM/WebSphere/AppServer/profiles/AppSrv01/logs/server1 2 内存溢出原理 内存溢出是指应用系统中存在无法回收的内存或使用的内存过多，最终使得程序运行要用到的内存大于虚拟机能提供的最大内存。 为了解决Java中内存溢出问题，我们首先必须了解Java是如何管理内存的。Java的内存管理就是对象的分配和释放问题。在Java中，内存的分配是由程序完成的，而内存的释放是由垃圾收集器(Garbage Collection，GC)完成的。 Java的内存垃圾回收机制是从程序的主要运行对象开始检查引用链，当遍历一遍后发现没有被引用的孤立对象就作为垃圾回收。GC为了能够正确释放对象，必须监控每一个对象的运行状态，包括对象的申请、引用、被引用、赋值等，GC都需要进行监控。监视对象状态是为了更加准确地、及时地释放对象，而释放对象的根本原则就是该对象不再被引用。

weblogic内存溢出解决方法

彻底解决Weblogic报出https://www.sodocs.net/doc/0415015689.html,ng.OutOfMemoryError: PermGen space问题： 打开域下面的bin目录（D:\Oracle\Middleware\user_projects\domains\base_domain\bin）。 编辑setDomainEnv.cmd文件，将以下蓝色的地方设置内存大小改成自己需要的。 set WLS_HOME=%WL_HOME%\server if "%JA V A_VENDOR%"=="Sun" ( set WLS_MEM_ARGS_64BIT=-Xms256m -Xmx512m set WLS_MEM_ARGS_32BIT=-Xms256m -Xmx512m ) else ( set WLS_MEM_ARGS_64BIT=-Xms512m -Xmx512m set WLS_MEM_ARGS_32BIT=-Xms512m -Xmx512m ) set MEM_ARGS_64BIT=%WLS_MEM_ARGS_64BIT% set MEM_ARGS_32BIT=%WLS_MEM_ARGS_32BIT% if "%JA V A_USE_64BIT%"=="true" ( set MEM_ARGS=%MEM_ARGS_64BIT% ) else ( set MEM_ARGS=%MEM_ARGS_32BIT% ) set MEM_PERM_SIZE_64BIT=-XX:PermSize=128m set MEM_PERM_SIZE_32BIT=-XX:PermSize=48m if "%JA V A_USE_64BIT%"=="true" ( set MEM_PERM_SIZE=%MEM_PERM_SIZE_64BIT% ) else ( set MEM_PERM_SIZE=%MEM_PERM_SIZE_32BIT% ) set MEM_MAX_PERM_SIZE_64BIT=-XX:MaxPermSize=256m set MEM_MAX_PERM_SIZE_32BIT=-XX:MaxPermSize=128m

java内存泄露定位与分析

使用IBM 性能分析工具解决生产环境中的性能问题（javacore） 上一篇 / 下一篇 2012-06-01 14:14:01 / 个人分类：javacore 查看( 655 ) / 评论( 0 ) / 评分( 0 / 0 ) https://www.sodocs.net/doc/0415015689.html,/developerworks/cn/java/j-lo-javacore/index.html 序言 企业级应用系统软件通常有着对并发数和响应时间的要求，这就要求大量的用户能在高响应时间内完成业务操作。这两个性能指标往往 决定着一个应用系统软件能否成功上线，而这也决定了一个项目最终能否验收成功，能否得到客户认同，能否继续在一个行业发展壮大 下去。由此可见性能对于一个应用系统的重要性，当然这似乎也成了软件行业的不可言说的痛——绝大多数的应用系统在上线之前， 项目组成员都要经历一个脱胎换骨的过程。 生产环境的建立包含众多方面，如存储规划、操作系统参数调整、数据库调优、应用系统调优等等。这几方面互相影响，只有经过不断 的调整优化，才能达到资源的最大利用率，满足客户对系统吞吐量和响应时间的要求。在无数次的实践经验中，很多软件专家能够达成 一致的是：应用系统本身的优化是至关重要的，否则即使有再大的内存，也会被消耗殆尽，尤其是产生OOM（Out Of Memory）的错 误的时候，它会贪婪地吃掉你的内存空间，直到系统宕机。 内存泄露—难啃的骨头 产生OOM 的原因有很多种，大体上可以简单地分为两种情况，一种就是物理内存确实有限，发生这种情况时，我们很容易找到原因，但是它一般不会发生在实际的生产环境中。因为生产环境往往有足以满足应用系统要求的配置，这在项目最初就是根据系统要求进行购 置的。 另外一种引起OOM 的原因就是应用系统本身对资源的的不恰当使用、配置，引起内存使用持续增加，最终导致JVM Heap Memory 被耗尽，如没有正确释放JDBC 的Connection Pool 中的对象，使用Cache 时没有限制Cache 的大小等等。本文并不针对各种情 况做讨论，而是以一个项目案例为背景，探索解决这类问题的方式方法，并总结一些最佳实践，供广大开发工程师借鉴参考。 项目背景介绍 项目背景： 1. 内网用户500 人，需要同时在线进行业务操作（中午休息一小时，晚6 点下班）。 2. 生产环境采用传统的主从式，未做Cluster ，提供HA 高可用性。 3. 服务器为AIX P570，8U，16G，但是只有一半的资源，即4U，8G 供新系统使用。 项目三月初上线，此前笔者与架构师曾去客户现场简单部署过一两次，主要是软件的安装，应用的部署，测一下应用是不是能够跑起来，算作是上线前的准备工作。应用上线（试运行）当天，项目组全体入住客户现场，看着用户登录数不断攀升，大家心里都没有底，高峰 时候到了440，系统开始有点反应变慢，不过还是扛下来了，最后归结为目前的资源有限，等把另一半资源划过来，就肯定没问题了。（须知增加资源，调优的工作大部分都要重新做一遍，系统级、数据库级等等，这也是后面为什么建议如果资源可用，最好一步到位的

登入用友T3软件提示错误;“内存溢出”

登入用友T3软件提示错误；“内存溢出” 登入用友T3软件提示错误；“内存溢出” 系统缺少ufrtprn.ocx组件造成的。首先把c:\windows\system32\ufcomsql\ufrtprn.ocx 这个文件复制到其他地方，再用正常的文件（下面的附件）替换一下，然后重新注册，注册如下：如果操作系统是XP或2003，则：开始–运行 –regsvr32c:\windows\system32\ufcomsql\ufrtprn.ocx；如果操作系统是WINDOWS2000，则：开始–运行–regsvr32c:\winnt\system32\ufcomsql\ufrtprn.ocx。如果还是不行，那么就建议重新安装软件了。 服务异常了，可能是多种原因造成的，你可以在C:\Windows\System32\UF2000.log，打开UF2000.log查看错误详情再处理，如果你不太熟悉软件或者数据库的话，建议把用友安装目录下的ADMIN全部拷贝出来，然后重新安装软件，然后进行数据库附加即可 试一下： 1：执行系统管理，做初始化操作 2：若方法1未执行初始化，可能是这前做过初始化，开始-运行-regedit确定、找到注册表项：[HKEY_LOCAL_MACHINE\SOFTWARE\UFSoft\UF2000\2.0\Setup]，右击删除Setup、再登录系统管理做初始化操作 方法3：若初始化操作建立系统数据库操作失败，可手工建立此系统数据库，还原用友通安装目录\Admin\ Ufsystem.bak文件，还原时数据库名称定义为UFSystem 重启”F8”,回车,进入安全模式，“高级启动选项”，找到“最后一次正确配置”

JVM内存分配(栈堆)与JVM回收机制

Java 中的堆和栈 简单的说： Java把内存划分成两种：一种是栈内存，一种是堆内存。 在函数中定义的一些基本类型的变量和对象的引用变量都在函数的栈内存中分配。 当在一段代码块定义一个变量时，Java就在栈中为这个变量分配内存空间，当超过变量的作用域后，Java会自动释放掉为该变量所分配的内存空间，该内存空间可以立即被另作他用。 堆内存用来存放由new创建的对象和数组。 在堆中分配的内存，由Java虚拟机的自动垃圾回收器来管理。 在堆中产生了一个数组或对象后，还可以在栈中定义一个特殊的变量，让栈中这个变量的取值等于数组或对象在堆内存中的首地址，栈中的这个变量就成了数组或对象的引用变量。 引用变量就相当于是为数组或对象起的一个名称，以后就可以在程序中使用栈中的引用变量来访问堆中的数组或对象。 具体的说： 栈与堆都是Java用来在Ram中存放数据的地方。与C++不同，Java自动管理栈和堆，程序员不能直接地设置栈或堆。 Java的堆是一个运行时数据区,类的(对象从中分配空间。这些对象通过new、newarray、anewarray和multianewarray等指令建立，它们不需要程序代码来显式的释放。堆是由垃圾回收来负责的，堆的优势是可以动态地分配内存大小，生存期也不必事先告诉编译器，因为它是在运行时动态分配内存的，Java的垃圾收集器会自动收走这些不再使用的数据。但缺点是，由于要在运行时动态分配内存，存取速度较慢。 栈的优势是，存取速度比堆要快，仅次于寄存器，栈数据可以共享。但缺点是，存在栈中的数据大小与生存期必须是确定的，缺乏灵活性。栈中主要存放一些基本类型的变量（,int, short, long, byte, float, double, boolean, char）和对象句柄。 栈有一个很重要的特殊性，就是存在栈中的数据可以共享。假设我们同时定义： int a = 3; int b = 3； 编译器先处理int a = 3；首先它会在栈中创建一个变量为a的引用，然后查找栈中是否有3这个值，如果没找到，就将3存放进来，然后将a指向3。接着处理int b = 3；在创建完b的引用变量后，因为在栈中已经有3这个值，便将b直接指向3。这样，就出现了a与b同时均指向3的情况。这时，如果再令a=4；那么编译器会重新搜索栈中是否有4值，如果没有，则将4存放进来，并令a指向4；如果已经有了，则直接将a指向这个地址。因此a值的改变不会影响到b 的值。要注意这种数据的共享与两个对象的引用同时指向一个对象的这种共享是不同的，因为这种情况a的修改并不会影响到b, 它是由编译器完成的，它有利于节省空间。而一个对象引用变量修改了这个对象的内部状态，会影响到另一个对象引用变量。 String是一个特殊的包装类数据。可以用： String str = new String("abc"); String str = "abc"; 两种的形式来创建，第一种是用new()来新建对象的，它会在存放于堆中。每调用一次就会创建一个新的对象。 而第二种是先在栈中创建一个对String类的对象引用变量str，然后查找栈中有没有存放"abc"，如果没有，则将"abc"存放进栈，并令str指向”abc”，如果已经有”abc”则直接令 str指向“abc”。 比较类里面的数值是否相等时，用equals()方法；当测试两个包装类的引用是否指向同一个对象时，用==，下面用例子说明上面的理论。 String str1 = "abc"; String str2 = "abc"; System.out.println(str1==str2); //true

java内存空间详解

硬盘 heap stack Data code 内存 程序 操作系统代码 程序代码 New ，在堆里面为属性分配空间，初始化（String 默认值为null ） 声明的时候非配空间，初始值为null （局部变量，方法参数） 全局变量 存放程序所需要的代码 类变量，全局字符串，常量存放在数据段

Java内存分配与管理是Java的核心技术之一，之前我们曾介绍过Java的内存管理与内存泄露以及Java垃圾回收方面的知识，今天我们再次深入Java核心，详细介绍一下Java 在内存分配方面的知识。一般Java在内存分配时会涉及到以下区域： ◆寄存器：我们在程序中无法控制 ◆栈：存放基本类型的数据和对象的引用，但对象本身不存放在栈中，而是存放在堆中 ◆堆：存放用new产生的数据 ◆静态域：存放在对象中用static定义的静态成员 ◆常量池：存放常量

◆非RAM存储：硬盘等永久存储空间 Java内存分配中的栈 在函数中定义的一些基本类型的变量数据和对象的引用变量都在函数的栈内存中分配。 当在一段代码块定义一个变量时，Java就在栈中为这个变量分配内存空间，当该变量退出该作用域后，Java会自动释放掉为该变量所分配的内存空间，该内存空间可以立即被另作他用。 Java内存分配中的堆 堆内存用来存放由new创建的对象和数组。在堆中分配的内存，由Java虚拟机的自动垃圾回收器来管理。 在堆中产生了一个数组或对象后，还可以在栈中定义一个特殊的变量，让栈中这个变量的取值等于数组或对象在堆内存中的首地址，栈中的这个变量就成了数组或对象的引用变量。引用变量就相当于是为数组或对象起的一个名称，以后就可以在程序中使用栈中的引用变量来访问堆中的数组或对象。引用变量就相当于是为数组或者对象起的一个名称。 引用变量是普通的变量，定义时在栈中分配，引用变量在程序运行到其作用域之外后被释放。而数组和对象本身在堆中分配，即使程序运行到使用new 产生数组或者对象的语句所在的代码块之外，数组和对象本身占据的内存不会被释放，数组和对象在没有引用变量指向它的时候，才变为垃圾，不能在被使用，但仍然占据内存空间不放，在随后的一个不确定的时间被垃圾回收器收走（释放掉）。这也是Java 比较占内存的原因。 实际上，栈中的变量指向堆内存中的变量，这就是Java中的指针！ 常量池(constant pool) 常量池指的是在编译期被确定，并被保存在已编译的.class文件中的一些数据。除了包含代码中所定义的各种基本类型（如int、long等等）和对象型（如String及数组）的常量值(final)还包含一些以文本形式出现的符号引用，比如： ◆类和接口的全限定名； ◆字段的名称和描述符； ◆方法和名称和描述符。 虚拟机必须为每个被装载的类型维护一个常量池。常量池就是该类型所用到常量的一个有序集和，包括直接常量（string,integer和floating point常量）和对其他类型，字段和

Eclipse中JVM内存设置

Eclipse中JVM内存设置 eclipse.ini内存设置 -vmargs -Xms128M -Xmx512M -XX:PermSize=64M -XX:MaxPermSize=128M 这里有几个问题： 1. 各个参数的含义什么？ 2. 为什么有的机器我将-Xmx和-XX:MaxPermSize都设置为512M之后Eclipse可以启动，而有些机器无法启动？ 3. 为何将上面的参数写入到eclipse.ini文件Eclipse没有执行对应的设置？ 下面我们一一进行回答 1. 各个参数的含义什么？ 参数中-vmargs的意思是设置JVM参数，所以后面的其实都是JVM的参数了，我们首先了解一下JVM内存管理的机制，然后再解释每个参数代表的含义。 堆(Heap)和非堆(Non-heap)内存 按照官方的说法：“Java 虚拟机具有一个堆，堆是运行时数据区域，所有类实例和数组的内存均从此处分配。堆是在Java 虚拟机启动时创建的。”“在JVM中堆之外的内存称为非堆内存(Non-heap memo ry)”。可以看出JVM主要管理两种类型的内存：堆和非堆。简单来说堆就是Java代码可及的内存，是留给开发人员使用的；非堆就是JVM留给自己用的，所以方法区、JVM内部处理或优化所需的内存(如JIT编译后的代码缓存)、每个类结构(如运行时常数池、字段和方法数据)以及方法和构造方法的代码都在非堆内存中。 堆内存分配

JVM初始分配的内存由-Xms指定，默认是物理内存的1/64；JVM最大分配的内存由-Xmx指定，默认是物理内存的1/4。默认空余堆内存小于40%时，JVM就会增大堆直到-X mx的最大限制；空余堆内存大于70%时，JVM会减少堆直到-Xms的最小限制。因此服务器一般设置-Xms、-Xmx相等以避免在每次GC 后调整堆的大小。 非堆内存分配 JVM使用-XX:PermSize设置非堆内存初始值，默认是物理内存的1/64；由XX:MaxP ermSize设置最大非堆内存的大小，默认是物理内存的1/4。 JVM内存限制(最大值) 首先JVM内存限制于实际的最大物理内存(废话！呵呵)，假设物理内存无限大的话，J VM内存的最大值跟操作系统有很大的关系。简单的说就32位处理器虽然可控内存空间有4GB,但是具体的操作系统会给一个限制，这个限制一般是2GB-3GB（一般来说Windows 系统下为1.5G-2G，Linux系统下为2G-3G），而64bit以上的处理器就不会有限制了。 2. 为什么有的机器我将-Xmx和-XX:MaxPermSize都设置为512M之后Eclipse可以启动，而有些机器无法启动？ 通过上面对JVM内存管理的介绍我们已经了解到JVM内存包含两种：堆内存和非堆内存，另外JVM最大内存首先取决于实际的物理内存和操作系统。所以说设置VM参数导致程序无法启动主要有以下几种原因： 1) 参数中-Xms的值大于-Xmx，或者-XX:PermSize的值大于-XX:MaxPermSize； 2) -Xmx的值和-XX:MaxPermSize的总和超过了JVM内存的最大限制，比如当前操作系统最大内存限制，或者实际的物理内存等等。说到实际物理内存这里需要说明一点的是，如果你的内存是1024MB，但实际系统中用到的并不可能是1024MB，因为有一部分被硬件占用了。 3. 为何将上面的参数写入到eclipse.ini文件Eclipse没有执行对应的设置？

JAVA内存溢出解决方案

JAVA内存溢出 解决方案 1. 内存溢出类型 1.1. https://www.sodocs.net/doc/0415015689.html,ng.OutOfMemoryError: PermGen space JVM管理两种类型的内存，堆和非堆。堆是给开发人员用的上面说的就是，是在JVM启动时创建；非堆是留给JVM自己用的，用来存放类的信息的。它和堆不同，运行期内GC不会释放空间。如果web app用了大量的第三方jar或者应用有太多的class文件而恰好MaxPermSize设置较小，超出了也会导致这块内存的占用过多造成溢出，或者tomcat热部署时侯不会清理前面加载的环境，只会将context更改为新部署的，非堆存的内容就会越来越多。 PermGen space的全称是Permanent Generation space,是指内存的永久保存区域，这块内存主要是被JVM存放Class和Meta信息的,Class在被Loader时就会被放到PermGen space中，它和存放类实例(Instance)的Heap区域不同,GC(Garbage Collection)不会在主程序运行期对PermGen space进行清理，所以如果你的应用中有很CLASS的话,就很可能出现PermGen space错误，这种错误常见在web服务器对JSP进行pre compile的时候。如果你的WEB APP下都用了大量的第三方jar, 其大小超过了jvm默认的大小(4M)那么就会产生此错误信息了。 一个最佳的配置例子：(经过本人验证，自从用此配置之后，再未出现过tomcat死掉的情况) set JAVA_OPTS=-Xms800m -Xmx800m -XX:PermSize=128M -XX:MaxNewSize=256m -XX:MaxPermSize=256m 1.2. https://www.sodocs.net/doc/0415015689.html,ng.OutOfMemoryError: Java heap space 第一种情况是个补充，主要存在问题就是出现在这个情况中。其默认空间(即-Xms)是物理内存的1/64，最大空间(-Xmx)是物理内存的1/4。如果内存剩余不到40％，JVM就会增大堆到Xmx设置的值，内存剩余超过70％，JVM就会减小堆到Xms设置的值。所以服务器的Xmx和Xms设置一般应该设置相同避免每次GC后都要调整虚拟机堆的大小。假设物理内存无限大，那么JVM内存的最大值跟操作系统有关，一般32位机是1.5g到3g之间，而64位的就不会有限制了。

JVM内存大小配置方式

JVM内存大小配置方式 By:sheagle@https://www.sodocs.net/doc/0415015689.html, 1.最简单的方式，tomcat当中进行配置 用记事本打开tomcat安装路径下bin文件夹中的Catalina.bat，在文件当中添加set JAV A_OPTS=-Xms256m-Xmx512m 该方式只适合于使用Catalina Start指令及其类似方式通过执行Startup.bat中的指令方式启动tomcat 2.在Eclipse当中配置tomcat的内存启动大小 Eclipse->Window->Preferences->Server->Runtime Environments->选中Apache Tomcat v5.0->点击Edit按钮->在弹出对话框里点击JRE后面的Installed JREs按钮->在弹出对话框中选中tomcat使用的那个JRE->点击Edit按钮->在弹出对话框中，找到Default VM Arguments，并在输入框中输入：-Xms256M-Xmx512M 该修改方式只适合于使用Eclipse启动tomcat 3.在注册表中修改tomcat大小 如果你的电脑上边安装了tomcat服务，那么你也可以通过以下设置来修改通过

服务启动时的tomcat内存。 打开tomcat安装路径下bin文件夹中的tomcat6w.exe。选中Java,修改Inital memory pool和Maximum memory pool 该修改方式只适合于使用“服务”方式启动tomcat 总结： 关于tomcat启动时JVM虚拟机内存大小的配置，针对每种情况会有多种不同的配置方式，基本上都是修改配 置文件中参数的大小，无论使用哪种配置方式进行配置，只要能达到效果即可

apache服务器出现内存溢出的解决方法

apache服务器出现内存溢出的解决方法 2011-10-08 14:26 Tomcat内存溢出的原因 在生产环境中tomcat内存设置不好很容易出现内存溢出。造成内存溢出是不一样的，当然处理方式也不一样。 这里根据平时遇到的情况和相关资料进行一个总结。常见的一般会有下面三种情况： 1.OutOfMemoryError： Java heap space 2.OutOfMemoryError： PermGen space 3.OutOfMemoryError： unable to create new native thread. Tomcat内存溢出解决方案 对于前两种情况，在应用本身没有内存泄露的情况下可以用设置tomcat jvm参数来解决。（-Xms -Xmx -XX：PermSize -XX：MaxPermSize） 最后一种可能需要调整操作系统和tomcat jvm参数同时调整才能达到目的。 第一种：是堆溢出。 原因分析： JVM堆的设置是指java程序运行过程中JVM可以调配使用的内存空间的设置.JVM在启动的时候会自动设置Heap size的值，其初始空间(即-Xms)是物理内存的1/64，最大空间(-Xmx)是物理内存的1/4。可以利用JVM提供的-Xmn -Xms -Xmx等选项可进行设置。Heap size 的大小是Young Generation 和Tenured Generaion 之和。 在JVM中如果98％的时间是用于GC且可用的Heap size 不足2％的时候将抛出此异常信息。 Heap Size 最大不要超过可用物理内存的80％，一般的要将-Xms和-Xmx选项设置为相同，而-Xmn为1/4的-Xmx值。 没有内存泄露的情况下，调整-Xms -Xmx参数可以解决。 -Xms：初始堆大小 -Xmx：最大堆大小 但堆的大小受下面三方面影响：

Java JVM参数设置及日志查看

基础知识-Java JVM参数设置及日志查看 JVM内存参数 -Xms：初始堆大小；默认值为物理内存的1/64(<1GB)，默认(MinHeapFreeRatio 参数可以调整)空余堆内存小于40%时，JVM就会增大堆直到-Xmx的最大限制。-Xmx：最大堆大小；默认值为物理内存的1/4(<1GB) 默认(MaxHeapFreeRatio参数可以调整)空余堆内存大于70%时，JVM会减少堆直到-Xms的最小限制 -Xmn：年轻代大小(1.4or lator)；注意：此处的大小是（eden+ 2 survivor space).与jmap -heap中显示的New gen是不同的。整个堆大小=年轻代大小+ 年老代大小+ 持久代大小。增大年轻代后,将会减小年老代大小.此值对系统性能影响较大,Sun官方推荐配置为整个堆的3/8 -XX:NewSize：设置年轻代大小(for 1.3/1.4) -XX:MaxNewSize：年轻代最大值(for 1.3/1.4) -XX:PermSize：设置持久代(perm gen)初始值物理内存的1/64 -XX:MaxPermSize：设置持久代最大值；默认值为物理内存的1/4。注意IBM的JDK设置此参数无效。 -Xss：每个线程的堆栈大小；JDK5.0以后每个线程堆栈大小为1M,以前每个线程堆栈大小为256K.更具应用的线程所需内存大小进行调整.在相同物理内存下,减小这个值能生成更多的线程.但是操作系统对一个进程内的线程数还是有限制的,不能无限生成,经验值在3000~5000左右。一般小的应用，如果栈不是很深，应该是128k够用的大的应用建议使用256k。这个选项对性能影响比较大，需要严格的选择。 -XX:ThreadStackSize：Thread Stack Size；(0 means use default stack size) [Sparc: 512; Solaris x86: 320 (was 256 prior in 5.0 and earlier); Sparc 64 bit: 1024; Linux amd64: 1024 (was 0 in 5.0 and earlier); all others 0.]，此值设置和-Xss设置相似，目前较多使用-Xss。 -XX:NewRatio：年轻代(包括Eden和两个Survivor区)与年老代的比值(除去持久代)-XX:NewRatio=4表示年轻代与年老代所占比值为1:4,年轻代占整个堆栈的1/5 当Xms=Xmx并且设置了Xmn的情况下，该参数不需要进行设置。 -XX:SurvivorRatio：Eden区与Survivor区的大小比值；设置为8,则两个Survivor 区与一个Eden区的比值为2:8,一个Survivor区占整个年轻代的1/10 -XX:LargePageSizeInBytes：内存页的大小不可设置过大，会影响Perm的大小，默认为128m -XX:+UseFastAccessorMethods：原始类型的快速优化 -XX:+DisableExplicitGC：关闭System.gc()；这个参数谨慎使用。 -XX:MaxTenuringThreshold：垃圾最大年龄；如果设置为0的话,则年轻代对象不经过Survivor区,直接进入年老代. 对于年老代比较多的应用,可以提高效率.如果将此值设置为一个较大值,则年轻代对象会在Survivor区进行多次复制,这样可以增加对象再年轻代的存活时间,增加在年轻代即被回收的概率，该参数只有在串行GC时才有效。 -XX:+AggressiveOpts：加快编译 -XX:+UseBiasedLocking：锁机制的性能改善

JAVA内存泄露专题

内存泄露与内存溢出 1定义 1、内存泄漏：一般可以理解为系统资源（各方面的资源，堆、栈、线程等）在错误使用的情况下，导致使用完毕的资源无法回收（或没有回收）,从而造成那部分内存不可用的情况。 2、内存溢出：指内存不够使用而抛出异常，内存泄露是其形成的原因之一。 2危害 会导致新的资源分配请求无法完成，引起系统错误，最后导致系统崩溃。 3内存泄漏分类 4 内存泄露/溢出发生的区域

5内存溢出异常 6内存溢出常见原因 7发生内存泄露的情形Java内存泄露根本原因是什么呢？

答：长生命周期的对象持有短生命周期对象的引用就很可能发生内存泄露，尽管短生命周期对象已经不再需要，但是因为长生命周期对象持有它的引用而导致不能被回收，这就是java中内存泄露的发生场景。 具体主要有如下几大类： 7.1 静态集合类引起内存泄露 像HashMap、Vector等的使用最容易出现内存泄露，这些静态变量的生命周期和应用程序一致，他们所引用的所有的对象Object也不能被释放，因为他们也将一直被Vector等引用着。 例: 解析： 在这个例子中，循环申请Object 对象，并将所申请的对象放入一个Vector 中，如果仅仅释放引用本身（o=null），那么Vector 仍然引用该对象，所以这个对象对GC 来说是不可回收的。因此，如果对象加入到Vector 后，还必须从Vector 中删除，最简单的方法就是将Vector对象设置为null。 7.2创建过大对象

以上代码运行时瞬间报错。 7.3监听器 在java 编程中，我们都需要和监听器打交道，通常一个应用当中会用到很多监听器，我们会调用一个控件的诸如addXXXListener()等方法来增加监听器，但往往在释放对象的时候却没有记住去删除这些监听器，从而增加了内存泄漏的机会。 7.4 各种连接 比如数据库连接（dataSourse.getConnection()），网络连接(socket)和io连接，除非其显式的调用了其close（）方法将其连接关闭，否则是不会自动被GC 回收的。对于Resultset 和Statement 对象可以不进行显式回收，但Connection 一定要显式回收，因为Connection 在任何时候都无法自动回收，而Connection一旦回收，Resultset 和Statement 对象就会立即为NULL。但是如果使用连接池，情况就不一样了，除了要显式地关闭连接，还必须显式地关闭Resultset Statement 对象（关闭其中一个，另外一个也会关闭），否则就会造成大量的Statement 对象无法释放，从而引起内存泄漏。这种情况下一般都会在try里面去的连接，在finally里面释放连接。 7.5 内部类和外部模块等的引用 内部类的引用是比较容易遗忘的一种，而且一旦没释放可能导致一系列的后继类对象没有释放。此外程序员还要小心外部模块不经意的引用，例如程序员A 负责A 模块，调用了B 模块的一个方法如： public void registerMsg(Object b); 这种调用就要非常小心了，传入了一个对象，很可能模块B就保持了对该对象的引用，这时候就需要注意模块B 是否提供相应的操作去除引用。 7.6 单例模式 不正确使用单例模式是引起内存泄露的一个常见问题，单例对象在被初始化后将在JVM的整个生命周期中存在（以静态变量的方式），如果单例对象持有外部对象的引用，那么这个外部对象将不能被jvm正常回收，导致内存泄露

系统应用服务器内存溢出解决报告

XXX系统应用服务器内存溢出解决报告 xxxx股份有限公司 2010.9

目录 第一章问题现象与分析 (2) 1.1、问题现象 (2) 1.2、通常导致这种现象的原因 (2) 1.3、xxx社保宕机现象对比分析 (3) 第二章解决方法路线图 (4) 2.1 jvm的调整 (4) 2.2 减少jvm内存使用 (5) 2.2.1 加快db访问速度，减少中间件并发业务量 (5) 2.2.2 限制sql返回结果集 (6) 2.2.3 减少业务会话中存放的对象 (6) 2.3 补救措施 (6) 第三章、解决结果与进一步建议 (6) 3.1 解决结果 (6) 3.2 进一步建议 (7) 第一章问题现象与分析 1.1、问题现象 XXX应用服务器经常有内存溢出、系统没有响应的现象，尤其在每月的月末最为明显。 目前的应用服务器有三种类型，其中ibm和linux应用服务器报告频繁出现内存溢出或没有响应的现象，hp unix应用服务器相稳定。在出现问题期间Weblogic无法响应任何客户端请求，大量请求加载到了这台没有响应的Server上，最后只有杀掉并重启这台应用服务器。 1.2、通常导致这种现象的原因 WLS Server 没响应可能的几种原因：

1、繁重的I/O，呼叫DB时间过长导致中间件内存耗尽，server没有响应。 2、程序死循环，loop－backs，这种情况cpu很忙，系统没有响应。 3、连接到外部server，没响应，由于网络等原因 4、2个以上的执行者同步死锁 5、业务量过大，全部线程都被占用，出现队列等待现象 6、读写本地I/O，发生阻塞 WLS Server 宕机的原因： OutOfMemory JNI程序 jvm的bug os的bug 1.3、xxx社保宕机现象对比分析 ?应用服务器没有响应分析 通过初步判断，对于xxx应用服务器没有响应的情况可以做如下排出法解决： ――程序死循环 这种情况会导致cpu非常繁忙，而通过目前观察，每次系统没响应的时候，cpu没有一直100%忙，另外，对出现问题时的java core分析没有发现这类线程，因此可以基本排除这种可能，。 ――连接到外部server，没响应，由于网络等原因 目前我们的业务基本都是直接通过中间件访问数据，没有通过应用服务器间调用或多数据库调用的，基本排除这种可能。 ――2个以上的执行者同步死锁 这种情况有可能，但比较难找，一般都是业务高峰的时候才有可能出现，跟应用人员了解后得知我们很少使用同步方式实现对资源的共享。另外通过对javacore进行分析，并未发现同步造成的死锁现象。 ――业务量过大，全部线程都被占用，出现队列等待现象 通过观察我们的业务量在高峰时确实很大，但由于我们配置的线程数都很高，尽管出现宕机时也没有达到配置的上线，所以这个方面可以被排除。 ――繁重的I/O，呼叫DB时间过长导致中间件内存耗尽 由于我们经常有新业务变更，尤其近期还有居民医保业务上线，因此I/O问题导致

JVM内存最大能调多大分析

JVM内存最大能调多大分析【经典】 2010-11-10 13:21 转载自 最终编辑 上次用weblogic 把 -XmxXXXX 设成2G，就启动不起来，设小点就起来了，当时很气，怎么2G都起不了，今天在看到了一篇解释，转过来了 这次一位老友提出了这个问题，记得当年一个java高手在blogjava提出后，被骂得半死。大家使用java -XmxXXXX -version版本得出了不同的结论。后来老友说大概是1800M左右，我当时反驳，“我设置过服务器8G内存，我使用两个tomcat，每个2G”。为此，我翻开所有的JVM的内存管理的c代码，没有任何结论。我不是linux内核程序员，但是我看过linux的源码，知道32位体系结构的计算机寻址空间是2^32=4G，intel Pentium Pro处理器寻址空间是36位，CPU内部增加了PAE寄存器。用于处理多出来的4根地址 线的使用，所以PAE的技术实现最大2^36=64G寻址。通过linux的内核源码，标准Linux内核对于物理内存的管理采用1:3的分配比例，即物理内存的1/4为内核空间（kernel space），剩下的3/4为用户进程空间（user space），因此，在一台4G内存的服务器上，用户进程可使用的内存最大也就是3G。当进程被内核调入CPU运行时，不同的地址空间数据会被调入4G以内的用户进程空间，其实就能用3G。 IA32架构上，单一进程是不能使用超过4G的内存空间的。但是我记得我给mysql server分配内存大约是左右,不是2的32次方-1，我分配java 2G内存的计算机是IBM的RS6000. 经过不同平台的测试,我得出了大概的数值,win2k下左右,nt下,原因是这样的,Classic VM and HotSpot VM 存放用户区的连续地址中,NT把 kernel DLLs 放在 0x7c 开头的地址空间,所以nt下只有<2G的空间,所以JVM heap 使用极限是2G.用户的dll开始于0x,用户的应用程序开始于0x00400000.我现在唯一确定的是sun可能为了防止和某些 JVM插件的冲突,把dll的地址给rebase一下,这样使用的空间就很少了一部分.为什末rebase,原因是这样的,因为在windows下编译 dll 的默认地址都是, 一般在release之前的时候要rebase一下,rebase 的-b 这个参数是指定一个起始地址,MSDN建议地址是0x，这个工具随visual studio和platform SDK发放。 例如 -b 0x6D000000 \jdk\jre\bin\*.dll \jdk\jre\bin\hotspot\这样你的JVM用的内存多一些,目前关于这个我只能得到BEA的 JRockit最大也只能使用内存,看来各家编译JDK时都作了些手脚. 目前只能得到bea的的-Xmx最小值是16 MB,sun的资料很不全,还好java开源了,可以不依靠sun了. sun提供的资料 Maximum Address Space Per Process Operating System Maximum Address Space Per Process