深入理解JVM（三）：内存溢出

在Java虚拟机规范的描述中，除了程序计数器之外。虚拟机内存的其他几个运行区域都有发生OutOfMemoryError（OOM）异常的可能。

1.Java堆溢出

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

来看一下代码：

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

我们将JVM运行的参数设置为：
-Xms20m -Xmx20m -XX:+HeapDumpOnOutOfMemoryError

-Xms:将堆的最小值设置为20m,-Xmx:将堆的最大值也设置为20m，意为堆的内存是不可扩展的。-XX:+HeapDumpOnOutOfMemoryError：可以让虚拟机在出现内存溢出异常时Dump出当前的内存堆转储快照以便事后进行分析。

下图是使用MyEclipse设置JVM的运行参数。

其运行结果如图所示：

Java堆内存的OOM异常是实际应用中常见的内存溢出异常情况。当出现Java堆内存溢出时，异常堆栈信息：java.Lang.OutOfMemoryError会跟着进一步提示“Java heap space”。

解决思路：
1.先使用内存映像分析工具（如Eclipse Memory Analyzer）对Dump出来的堆转储快照进行分析，重点是确认内存中的对象是否是有必要的。分清是内存泄露还是内存溢出。

2.如果是内存泄露，可以进一步通过工具查看泄露对象到GC Roots的引用链。于是就能找到泄露对象是通过怎样的路径与GC Roots相关联并导致垃圾收集器器无法回收它们的。
如果不存在泄露，就是内存中的对象确实还必须活着，那就应该检查虚拟机的堆参数（-Xmx和-Xms），与机器物理内存对比看是否还可以调大，从代码上看是否存在某些对象生命周期过长、持有状态时间过长的情况，尝试减少程序运行期的内存消耗。

关于MyEclipse安装Memory Analyzer（作用是对Dump出来的hprof文件进行分析的）的部分可以参看这篇博客：https://www.cnblogs.com/rrttp/p/7616085.html

关于MemoryAnalyzer具体的一些使用和分析可以参看下面这篇博客：
http://essen.iteye.com/blog/1825314

下图是MemoryAnalyzer打开hprof文件的界面：

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

由于HotSpot虚拟机中并不区分虚拟机栈和本地方法栈，因此，对于HotSpot来说，虽然有-Xoss(设置本地方法栈大小)参数的存在，但实际上是无效的。栈的容量只由-Xss参数设定。关于虚拟机栈和本地方法栈，在Java虚拟机规范中描述了两种异常：

1.如果线程请求的栈深度大于虚拟机所允许的最大深度，将抛出StackOverflowError异常。

2.如果虚拟机在扩展栈时无法申请到足够的内存空间，则抛出OutOfMemoryError异常。

如果是单线程的话，无论是减少栈内存的容量还是增大栈帧中本地变量表的长度，结果都是抛出StackOverflowError异常。无法产生OutOfMemoryError异常。

如果测试不限于单线程，通过不断的建立线程的方法倒是可以产生内存溢出异常，如果下面的代码所示：

public class RuntimeConstantPoolOOM {
	public static void main(String[] args) {
		String str1 = new StringBuilder("计算机").append("软件").toString();
		System.out.println(str1.intern()==str1);	
		String str2 = new StringBuffer("ja").append("va").toString();
		System.out.println(str2.intern()==str2);
	}
}

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

由于运行时常量池是方法区的一部分，因此这两个区域的溢出就放在一起了。

HotSpot虚拟机使用永久代来实现方法区而已，这样HotSpot的垃圾收集器可以像管理Java堆一样管理这部分内存，能够省去专门为方法区编写的内存管理代码的工作。在JDK1.6之前的版本中，由于常量池分配在永久代内，我们可以通过-XX：PermSize和-XX：MaxPermSize限制方法区大小，从而间接限制其中常量池的容量。在JDK1.7中的HotSpot已经把原本放在永久代的字符串常量池移出。JDK1.8中已经移除了永久代，新加了一个叫做元数据区的native内存区。

常量区的溢出：

关于常量池溢出的代码，我们可以使用jdk1.6的环境来实现。下面的代码jdk1.7并不会很快溢出，只会直接循环下去。

虚拟机运行的参数：-XX:PermSize=10M -XX:MaxPermSize=10M

public class RuntimeConstantPoolOOM {
	public static void main(String[] args) {
		List<String> list = new ArrayList<String>();
		int i = 0;
		while(true){
			list.add(String.valueOf(i++).intern());
		}
	}
}

其结果如下图所示：

关于常量池的jdk1.6和jdk1.7的实现部分，可以查看一下代码：

public class RuntimeConstantPoolOOM {
	public static void main(String[] args) {	
		String str1 = new StringBuilder("计算机").append("软件").toString();
		System.out.println(str1.intern()==str1);
		
		String str2 = new StringBuffer("ja").append("va").toString();
		System.out.println(str2.intern()==str2);
	}
}

我们先使用了jdk1.6来运行得出以下结果。

而使用jdk1.7会得到以下结果：

原因就是：jdk1.6中的intern()方法会把首次遇到的字符串实例复制到永久代中，返回的就是永久代中的这个字符串的实例引用，而由StringBuilder创建的字符串实例在Java堆上，所以必然不是同一引用，将返回false。而JDK1.7的intern()实现不会再复制实例，只是在常量池中记录首次出现实例引用，因此intern()返回的引用和由StringBuilder创建的那个字符创实例是同一个。

其实jvm从启动，到执行main里面的第一条代码，要经历很多的，比如加载rt.jar里面所有的Class，加载一个class肯定要执行static{}中内容，况且rt.jar中的jdk的类里面有很多xxx.startWith(“java”)或者其他用到"java"的代码，jvm启动的时候直接按照常量加载进来了丢到internmap里面了， 所以在我们自己定义java字符之前，就被放入了常量池中。而中文字符却没有。

方法区的溢出：

方法区用于存放Class的相关信息，测试的基本思路就是使用大量的Class类填满这一部分。本次使用的CGLIB直接操作字节码运行时直接生成大量的动态类。（CGLIB所需要的包可以点击这里:下载）

这里我们仍然采用了jdk1.6的环境。只是因为jdk1.6采用的是永久代，方便更改大小。更容易得到溢出信息。

代码如下：

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() {
				
				@Override
				public Object intercept(Object obj, Method method, Object[] args, MethodProxy proxy) throws Throwable {
					return proxy.invokeSuper(obj, args);
				}
			});
			enhancer.create();
		}
	}
	
	static class OOMObject{
		
	}
}

结果如下：

在经常动态生成大量Class的应用中，需要特别注意类回收的状况。这类场景除了上面提到的程序使用了CGLib字节码增强和动态语言之外，常见的还有：大量JSP或者动态产生JSP文件的应用（JSP第一次运行时需要编译为Java类）、基于OSGi的应用。

4.本机直接内存溢出

DirecMemory容量可通过-XX：MaxDirectMemorySize指定，如果不指定则，默认与Java堆最大值（-Xmx指定）一样。DirectMemory是java nio引入的，直接以native的方式分配内存，不受jvm管理。

下面的代码越过了DirectByteBuffer类，直接通过反射获取Unsafe实例进行内存分配（Unsafe类的getUnsafe()方法限制了只有引导类加载器才会返回实例，也就是设计者希望只有rt.jar中的类才能使用Unsafe的功能）。因为，虽然使用DirectByteBuffer分配内存也会抛出内存溢出异常，但它抛出异常时并没有真正向操作系统中申请分配内存，而是通过计算得知内存无法分配，于是手动抛出内存，真正申请分配内存的方法是unsafe.allocatMemory()。

unsafe的allocateMemory方法就是native方法。我们可以使用unsafe来测试直接内存的溢出。

public class DirectMemoryOOM {
	private static final int _1MB = 1024*1024;
	public static void main(String[] args) throws IllegalArgumentException, IllegalAccessException {
		Field unsafeField = Unsafe.class.getDeclaredFields()[0];
		unsafeField.setAccessible(true);
		//通过字段获取对象，但是必须是静态对象才能传入null
		Unsafe unsafe = (Unsafe) unsafeField.get(null);
		while(true){
			unsafe.allocateMemory(_1MB);
		}
	}
}

下面是结果：

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