【Java虚拟机】4、OutOfMemoryError异常，

来源： javaer 分享于 2022-05-15 点击 2946 次点评：1

【Java虚拟机】4、OutOfMemoryError异常，

--------------------------------【Java虚拟机】系列--------------------------------
1、Java技术体系
2、Java内存区域
3、虚拟机对象
4、OutOfMemoryError异常
--------------------------------【Java虚拟机】系列--------------------------------

Part II: 自动内存管理机制

第2章 Java内存区域与内存溢出异常

实战：OutOfMemoryError异常

通过下图回顾Java运行时的内存发布图*（引自文章参考1）*：

java.lang.OutOfMemoryError这个错误大部分开发人员都有遇到过，产生该错误的原因大都出于以下原因：JVM内存过小、程序不严密，产生了过多的垃圾。

导致OutOfMemoryError异常的常见原因有以下几种：

内存中加载的数据量过于庞大，如一次从数据库取出过多数据；
集合类中有对对象的引用，使用完后未清空，使得JVM不能回收；
代码中存在死循环或循环产生过多重复的对象实体；
使用的第三方软件中的BUG；
启动参数内存值设定的过小；

此错误常见的错误提示：

tomcat:java.lang.OutOfMemoryError: PermGen space
tomcat:java.lang.OutOfMemoryError: Java heap space
weblogic:Root cause of ServletException java.lang.OutOfMemoryError
resin:java.lang.OutOfMemoryError
java:java.lang.OutOfMemoryError

解决java.lang.OutOfMemoryError的方法有如下几种：
一、增加jvm的内存大小。方法有：

1、Java堆溢出

Java堆用于存储对象实例，只要不断的创建对象，并且保证GC Roots到对象之间有可达路径来避免垃圾回收机制清除这些对象，那么在对象数量到达最大堆的容量限制后就会产生内存溢出异常。

/**
 * @Description: java 堆溢出 
 * VM Args：-Xms20m -Xmx20m -XX:+HeapDumpOnOutOfMemoryError
 * 
 * -Xms参数初始分配的堆内存
 * -Xmx参数最大允许分配的堆内存
 * 若-Xms=-Xmx,则可避免堆自动扩展
 * XX:+HeapDumpOnOutOfMemoryError可以让虚拟机在出现内存溢出是dump出当前的内存堆转储快照
 * 
 */
public class HeapOOM {

	static class OOMObject {
	}

	public static void main(String[] args) {
		List<OOMObject> list = new ArrayList<>();
		while (true) {
			list.add(new OOMObject());
		}
	}
}

运行结果：

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:261)
	at java.util.ArrayList.ensureExplicitCapacity(ArrayList.java:235)
	at java.util.ArrayList.ensureCapacityInternal(ArrayList.java:227)
	at java.util.ArrayList.add(ArrayList.java:458)
	at com.tyron.outofmemory.HeapOOM.main(HeapOOM.java:22)

解决方案：
要解决这个区域的异常，一般的手段是先通过内存映像分析工具（如Eclipse Memory Analyzer）对Dump出来的堆转储快照进行分析，重点是确认内存中的对象是否是必要的，也就是要先分清楚到底是出现了内存泄漏（Memory Leak）还是内存溢出（Memory Overflow）。
如果是内存泄漏，进一步查看泄漏对象到GC Roots的引用链，从而确认为什么无法回收；如果是内存溢出，则应当检查虚拟机堆参数（-Xmx与-Xmx）或检查是否存在对象生命周期过长、持有状态时间过长的情况；

2、虚拟机栈和本地方法栈溢出

HotSpot 虚拟机中并不区分虚拟机栈和本地方法栈。栈容量只由-Xss参数设定。
关于虚拟机栈和本地方法栈，在Java虚拟机规范中描述了两种异常：

如果线程请求的栈深度大于虚拟机所允许的最大深度，将抛出 StackOverflowError 异常；
如果虚拟机栈可以动态扩展（当前大部分的 Java 虚拟机都可动态扩展，只不过 Java 虚拟机规范中也允许固定长度的虚拟机栈），当扩展时无法申请到足够的内存时会抛出 OutOfMemoryError 异常；

/**
 * @Description: 栈溢出
 * 
 * -Xss参数设置栈容量
 * VM Args:-Xss128k
 */
public class JavaVMStackSOF {

	private int stackLength = 1;

	public void stackLeak() {
		stackLength++;
		stackLeak();
	}

	public static void main(String[] args) throws Throwable {
		JavaVMStackSOF oom = new JavaVMStackSOF();
		try {
			oom.stackLeak();
		} catch (Throwable e) {
			System.out.println("stack length:" + oom.stackLength);
			throw e;
		}
	}
}

stack length:18935
Exception in thread "main" java.lang.StackOverflowError
	at com.tyron.outofmemory.JavaVMStackSOF.stackLeak(JavaVMStackSOF.java:16)
	at com.tyron.outofmemory.JavaVMStackSOF.stackLeak(JavaVMStackSOF.java:16)
	at com.tyron.outofmemory.JavaVMStackSOF.stackLeak(JavaVMStackSOF.java:16)
	at com.tyron.outofmemory.JavaVMStackSOF.stackLeak(JavaVMStackSOF.java:16)
	at com.tyron.outofmemory.JavaVMStackSOF.stackLeak(JavaVMStackSOF.java:16)
	at com.tyron.outofmemory.JavaVMStackSOF.stackLeak(JavaVMStackSOF.java:16)

结果表明：在单个线程下，无论是由于栈帧太大，还是虚拟机栈容量太小，当内存无法分配的时候，虚拟机抛出的都是 StackOverflowError 异常，而不是OutOfMemoryError。

如果测试时不限于单线程，通过不断地建立线程的方式倒是可以产生内存溢出异常。自己可以创建多个线程，进行测试，在这种情况下，给每个线程的栈分配的内存越大，反而越容易产生内存溢出异常。但是：由于在Windows 平台的虚拟机中， Java 的线程是映射到操作系统的内核线程上的，所以多线程代码执行时有较大的风险，可能会导致操作系统假死。

原理解析：
操作系统分配给每个进程的内存是有限制的，譬如 32 位的 Windows 限制为 2GB。虚拟机提供了参数来控制 Java 堆和方法区的这两部分内存的最大值。剩余的内存为 2GB（操作系统限制）减去 Xmx（最大堆容量），再减去 MaxPermSize（最大方法区容量），程序计数器消耗内存很小，可以忽略掉。如果虚拟机进程本身耗费的内存不计算在内，剩下的内存就由虚拟机栈和本地方法栈“瓜分”了。每个线程分配到的栈容量越大，可以建立的线程数量自然就越少，建立线程时就越容易把剩下的内存耗尽。
如何解决：
如果是建立过多线程导致的内存溢出，在不能减少线程数或者更换 64 位虚拟机的情况下，就只能通过减少最大堆和减少栈容量来换取更多的线程。如果没有这方面的经验，这种通过“减少内存”的手段来解决内存溢出的方式会比较难以想到。

3、方法区和运行时常量池溢出

3.1运行时常量池导致的内存溢出异常

如果要向运行时常量池中添加内容，最简单的做法就是使用 String.intern()这个 Native 方法。该方法的作用是：如果字符串常量池中已经包含一个等于此 String 对象的字符串，则返回代表池中这个字符串的String 对象；否则，将此 String 对象包含的字符串添加到常量池中，并且返回此 String 对象的引用。在JDK1.6及之前的版本中，由于常量池分配在永久代内，我们可以通过-XX:PermSize 和-XX:MaxPermSize 限制方法区的大小，从而间接限制其中常量池的容量代码运行时常量池导致的内存溢出异常。而使用JDK1.7运行这段程序就不会得到相同的结果，while循环将一直进行下去，JDK1.8也是。

/**
 * @Description: 运行时常量池溢出 
 * VM args -XX:PermSize=10M -XX:MaxPermSize=10M -XX:MaxMetaspaceSize=10m
 */
public class RuntimeConstantPoolOOM {

	public static void main(String[] args) {
		// 使用List保持着常量池引用，避免Full GC回收常量池行为
		List<String> list = new ArrayList<String>();
		// 10MB的PermSize在integer范围内足够产生OOM了
		int i = 111;
		while (true) {
			list.add(String.valueOf(i++).intern());
			System.out.println(list.size());
		}
	}
}

JDK1.6运行结果：

JDK1.7运行结果：

JDK1.8运行结果和JDK1.7一样。

运行结果的不同，是由于不同的JDK版本在字符串常量池的实现方式不同：

// String.intern()返回引用的测试
public class RuntimeConstantPoolOOM {
	public static void main(String[] args) {
		String str1 = new StringBuilder("计算机").append("软件").toString();
		System.out.println(str1.intern() == str1);
		String str2 = new StringBuilder("ja").append("va").toString();
		System.out.println(str2.intern() == str2);
	}
}
// 运行结果（JDK1.6及以前版本）
false
false
// 运行结果（JDK1.7及以前版本）
true
false

产生差异的原因是：在JDK 1.6中，intern()方法会把首次遇到的字符串实例复制到永久代中，返回的也是永久代中这个字符串实例的引用，而由StringBuilder创建的字符串实例在Java堆上，所以必然不是同一个引用，将返回false。而JDK 1.7（以及部分其他虚拟机，例如JRockit）的intern()实现不会再复制实例，只是在常量池中记录首次出现的实例引用，因此intern()返回的引用和由StringBuilder创建的那个字符串实例是同一个。对str2比较返回false是因为“java”这个字符串在执行StringBuilder.toString()之前已经出现过，字符串常量池中已经有它的引用了，不符合“首次出现”的原则，而“计算机软件”这个字符串则是首次出现的，因此返回true。
关于JDK1.7下第二个运行结果的更详细解释，可以参看链接6。

3.2 方法区的内存溢出异常

方法区用于存放Class的相关信息，如类名、访问修饰符、常量池、字段描述、方法描述等。对于这些区域的测试，基本的思路是运行时产生大量的类去填满方法区，直到溢出。虽然直接使用Java SE API也可以动态产生类（如反射时的GeneratedConstructorAccessor和动态代理等），但在本次实验中操作起来比较麻烦。故借助CGLib直接操作字节码运行时生成了大量的动态类。

import java.lang.reflect.Method;
import net.sf.cglib.proxy.Enhancer;
import net.sf.cglib.proxy.MethodInterceptor;
import net.sf.cglib.proxy.MethodProxy;

/**
 * @Description: 借助CGLib使方法区出现内存溢出异常
 *               VM Args： -XX:PermSize=10M -XX:MaxPermSize=10M
 * 
 */
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 {
	}

}

执行该代码需要导入两个jar包：代码清单2-8jar包
运行结果：

方法区溢出也是一种常见的内存溢出异常，一个类要被垃圾收集器回收掉，判定条件是比较苛刻的。在经常动态生成大量Class的应用中，需要特别注意类的回收状况。这类场景除了上面提到的程序使用了CGLib字节码增强和动态语言之外，常见的还有：大量JSP或动态产生JSP文件的应用（JSP第一次运行时需要编译为Java类）、基于OSGi的应用（即使是同一个类文件，被不同的加载器加载也会视为不同的类）等。

4、本地直接内存溢出

DirectMemory容量可通过-XX：MaxDirectMemorySize指定，如果不指定，则默认与Java堆最大值（-Xmx指定）一样，下面代码中越过了DirectByteBuffer类，直接通过反射获取Unsafe实例进行内存分配（Unsafe类的getUnsafe()方法限制了只有引导类加载器才会返回实例，也就是设计者希望只有rt.jar中的类才能使用Unsafe的功能）。因为，虽然使用DirectByteBuffer分配内存也会抛出内存溢出异常，但它抛出异常时并没有真正向操作系统申请分配内存，而是通过计算得知内存无法分配，于是手动抛出异常，真正申请分配内存的方法是unsafe.allocateMemory()。

// 使用unsafe分配本机内存
import java.lang.reflect.Field;
import sun.misc.Unsafe;

/**
 * VM Args：-Xmx20M -XX:MaxDirectMemorySize=10M
 */
public class DirectMemoryOOM {
	private static final int _1MB = 1024 * 1024;

	public static void main(String[] args) throws Exception {
		Field unsafeField = Unsafe.class.getDeclaredFields()[0];
		unsafeField.setAccessible(true);
		Unsafe unsafe = (Unsafe) unsafeField.get(null);
		while (true)
			unsafe.allocateMemory(_1MB);
	}
}

Exception in thread "main" java.lang.OutOfMemoryError
	at sun.misc.Unsafe.allocateMemory(Native Method)
	at com.tyron.outofmemory.DirectMemoryOOM.main(DirectMemoryOOM.java:24)

由DirectMemory导致的内存溢出，一个明显的特征是在Heap Dump文件中不会看见明显的异常，如果读者发现OOM之后Dump文件很小，而程序中又直接或间接使用了NIO，那就可以考虑检查一下是不是这方面的原因。

Java代码导致OutOfMemoryError错误的解决：
需要重点排查以下几点：

检查代码中是否有死循环或递归调用。
检查是否有大循环重复产生新对象实体。
检查对数据库查询中，是否有一次获得全部数据的查询。一般来说，如果一次取十万条记录到内存，就可能引起内存溢出。这个问题比较隐蔽，在上线前，数据库中数据较少，不容易出问题，上线后，数据库中数据多了，一次查询就有可能引起内存溢出。因此对于数据库查询尽量采用分页的方式查询。
检查List、MAP等集合对象是否有使用完后，未清除的问题。List、MAP等集合对象会始终存有对对象的引用，使得这些对象不能被GC回收。

文章参考：

【Java虚拟机】4、OutOfMemoryError异常，