程序计数器 :永不会OutOfMemoryError
栈溢出
-
《Java虚拟机规范》中描述了两种异常:StackOverflowError异常 和 OutOfMemoryError异常。
1.1. StackOverflowError:某个线程里方法嵌套调用太多,当栈帧大小总和 >-Xss
设置的值,从而产生StackOverflowError
。(读书笔记摘自 书名:深入理解Java虚拟机:JVM高级特性与最佳实践(第3版)作者:周志明)
1.2. OutOfMemory:java启动一个新线程时,没有足够空间为该线程分配java栈,从而产生OutOfMemoryError
。(参考:StackOverflow和OutOfMemory)
堆溢出
/**
* VM Args:-Xms20m -Xmx20m -XX:+HeapDumpOnOutOfMemoryError
* @author zzm
*/
public class HeapOOM {
static class OOMObject {
}
public static void main(String[] args) {
List<OOMObject> list = new ArrayList<OOMObject>();
while (true) {
list.add(new OOMObject());
}
}
}
运行结果:
java.lang.OutOfMemoryError: Java heap space
Dumping heap to java_pid3404.hprof ...
Heap dump file created [22045981 bytes in 0.663 secs]
java.lang.OutOfMemoryError: Java heap space
当JVM试图在堆中分配一个新的对象,但没有足够的连续空闲空间时,就会抛出这个错误。这个错误可能发生在堆的任何部分,包括新生代或老年代。
堆内存泄露分析
-
分析Dump文件,先确认是内存泄漏(Memory Leak) 还是 内存溢出(Memory Overflow)。
-
如果是内存泄漏,可进一步通过
工具
查看泄漏对象到GC Roots的引用链,找到泄漏对象是通过怎样的引用路径、与哪些GC Roots相关联,才导致垃圾收集器无法回收它们,根据泄漏对象的类型信息以及它到GC Roots引用链的信息,一般可以比较准确地定位到这些对象创建的位置,进而 找出产生内存泄漏的代码的具体位置。 -
如果不是内存泄漏,换句话说就是内存中的对象确实都是必须存活的,那就应当检查Java虚拟机的堆参数(
-Xmx
与-Xms
)设置,与机器的内存对比,看看是否还有向上调整的空间。再从代码上检查是否存在某些对象生命周期过长、持有状态时间过长、存储结构设计不合理等情况,尽量减少程序运行期的内存消耗。 -
常见使用不当场景
4.1. 循环上万次的字符串处理、
4.2. 创建上千万个对象、
4.3. 在一段代码内申请上百M甚至上G的内存。
运行时常量池
在 JDK6或更早 的HotSpot虚拟机中,字符串常量池都是分配在永久代中。
java.lang.OutOfMemoryError:PermGenspace
在 JDK 6 中 运行时常量池导致的内存溢出异常
/**
* VM Args:-XX:PermSize=6M -XX:MaxPermSize=6M
* @author zzm
*/
public class RuntimeConstantPoolOOM {
public static void main(String[] args) {
// 使用Set保持着常量池引用,避免Full GC回收常量池行为
Set<String> set = new HashSet<String>();
// 在short范围内足以让6MB的PermSize产生OOM了
short i = 0;
while (true) {
set.add(String.valueOf(i++).intern());
}
}
}
运行结果:
Exception in thread "main" java.lang.OutOfMemoryError: PermGen space (说明运行时常量池存储在永久代)
at java.lang.String.intern(Native Method)
at org.fenixsoft.oom.RuntimeConstantPoolOOM.main(RuntimeConstantPoolOOM.java: 18)
java.lang.OutOfMemoryError: Java heap space
JDK7 及以上版本,把原本存放在永久代
的字符串常量池被移至Java堆
之中。
/**
* VM Args:-Xmx=6M
* @author zzm
*/
public class RuntimeConstantPoolOOM {
public static void main(String[] args) {
// 使用Set保持着常量池引用,避免Full GC回收常量池行为
Set<String> set = new HashSet<String>();
// 在short范围内足以让6MB的PermSize产生OOM了
short i = 0;
while (true) {
set.add(String.valueOf(i++).intern());
}
}
}
// OOM异常一:
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space (说明运行时常量池存储在堆里)
at java.base/java.lang.Integer.toString(Integer.java:440)
at java.base/java.lang.String.valueOf(String.java:3058)
at RuntimeConstantPoolOOM.main(RuntimeConstantPoolOOM.java:12)
// OOM异常二:
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
at java.base/java.util.HashMap.resize(HashMap.java:699)
at java.base/java.util.HashMap.putVal(HashMap.java:658)
at java.base/java.util.HashMap.put(HashMap.java:607)
at java.base/java.util.HashSet.add(HashSet.java:220)
at RuntimeConstantPoolOOM.main(RuntimeConstantPoolOOM.java from InputFile-Object:14)
方法区
java.lang.OutOfMemoryError: PermGen space
在 JDK 7 中的运行,借助CGLib使得方法区出现内存溢出异常
/**
* VM Args:-XX:PermSize=10M -XX:MaxPermSize=10M
* @author zzm
*/
public class JavaMethodAreaOOM {
public static void main(String[] args) {
while (true) {
Enhancer enhancer = new Enhancer();
enhancer.setSuperclass(OOMObject.class);
enhancer.setUseCache(false);
enhancer.setCallback(new MethodInterceptor() {
public Object intercept(Object obj, Method method, Object[] args, MethodProxy proxy) throws Throwable {
return proxy.invokeSuper(obj, args);
}
});
enhancer.create();
}
}
static class OOMObject {
}
}
在JDK 7中的运行结果:
Caused by: java.lang.OutOfMemoryError: PermGen space (还在永久代)
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClassCond(ClassLoader.java:632)
at java.lang.ClassLoader.defineClass(ClassLoader.java:616)
... 8 m
在 JDK8 以后,永久代便完全退出了历史舞台,元空间作为其替代者登场。
java.lang.OutOfMemoryError: MetaSpace
在默认设置下,前面列举的那些正常的动态创建新类型
的测试用例已经很难再迫使虚拟机产生方法区的溢出异常了。不过为了让使用者有预防实际应用里出现类似于代码清单2-9那样的破坏性的操作,HotSpot还是提供了一些参数作为元空间的防御措施,
读书笔记摘自 书名:深入理解Java虚拟机:JVM高级特性与最佳实践(第3版)作者:周志明