内容:
1.实战演示Windows和Linux下的OOM
2.GC时候基于的内存结构
一、演示及分析
1.不同的平台JVM实现有所差别:
a)在Windows下栈的最小值为108k
b)在Linux下栈的最小值为228k
2.通过以下异常信息,可以推导jvm的内存结构。
[Full GC (Ergonomics) [PSYoungGen: 944K->890K(2048K)] [ParOldGen: 7129K->7129K(7168K)] 8074K->8019K(9216K), [Metaspace: 3357K->3357K(1056768K)], 0.1213761 secs] [Times: user=0.27 sys=0.00, real=0.12 secs]
[Full GC (Allocation Failure) Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
at java.util.Arrays.copyOf(Arrays.java:3210)
at java.util.Arrays.copyOf(Arrays.java:3181)
at java.util.ArrayList.grow(ArrayList.java:265)
at java.util.ArrayList.ensureExplicitCapacity(ArrayList.java:239)
at java.util.ArrayList.ensureCapacityInternal(ArrayList.java:231)
at java.util.ArrayList.add(ArrayList.java:462)
at JVM.HeapOutOfMemory.main(HeapOutOfMemory.java:20)
[PSYoungGen: 890K->890K(2048K)] [ParOldGen: 7129K->7129K(7168K)] 8019K->8019K(9216K), [Metaspace: 3357K->3357K(1056768K)], 0.0858551 secs] [Times: user=0.24 sys=0.00, real=0.09 secs]
Heap
PSYoungGen total 2048K, used 939K [0x00000000ffd00000, 0x0000000100000000, 0x0000000100000000)
eden space 1024K, 91% used [0x00000000ffd00000,0x00000000ffdeaeb0,0x00000000ffe00000)
from space 1024K, 0% used [0x00000000fff00000,0x00000000fff00000,0x0000000100000000)
to space 1024K, 0% used [0x00000000ffe00000,0x00000000ffe00000,0x00000000fff00000)
ParOldGen total 7168K, used 7129K [0x00000000ff600000, 0x00000000ffd00000, 0x00000000ffd00000)
object space 7168K, 99% used [0x00000000ff600000,0x00000000ffcf64c0,0x00000000ffd00000)
Metaspace used 3388K, capacity 4500K, committed 4864K, reserved 1056768K
class space used 352K, capacity 388K, committed 512K, reserved 1048576K
a)Young Generation:Object 产生和基本活跃区。
b)Eden :当new后,此时进入eden。如果对象特别大会直接进入old
c)from:
d)to: from 和to具有相同的大小。他们作为eden和old的缓冲地带,先放到to中,to满了以后放到from。目的是增加对象在young中的时间,因为在young中使用效率高,同时避免产生full GC。
e)old Genetion:经过内存的几次GC后依旧存在,此时会进入老年代。