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

落日映苍穹つ 2022-05-08 16:28 193阅读 0赞

在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的运行参数。  
![在这里插入图片描述][70]  
其运行结果如图所示：  
![在这里插入图片描述][70 1]  
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][https_www.cnblogs.com_rrttp_p_7616085.html]

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

下图是MemoryAnalyzer打开hprof文件的界面：![在这里插入图片描述][70 2]

## 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());
    		}
    	}
    }

其结果如下图所示：  
![在这里插入图片描述][70 3]

关于常量池的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来运行得出以下结果。  
![在这里插入图片描述][70 4]

而使用jdk1.7会得到以下结果：  
![在这里插入图片描述][70 5]  
原因就是：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所需要的包可以点击这里:[下载][Link 1]）

这里我们仍然采用了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{ 
    		
    	}
    }

结果如下：  
![在这里插入图片描述][70 6]  
在经常动态生成大量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来测试直接内存的溢出。  
![在这里插入图片描述][70 7]

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);
    		}
    	}
    }

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

[70]: /images/20220506/4286027b5feb458f86a2a3e4eba43679.png
[70 1]: /images/20220506/8e8cf347f6724f5a9fc5cfe533b23af6.png
[https_www.cnblogs.com_rrttp_p_7616085.html]: https://www.cnblogs.com/rrttp/p/7616085.html
[http_essen.iteye.com_blog_1825314]: http://essen.iteye.com/blog/1825314
[70 2]: /images/20220506/90f661fe77d0429bb048e0cb8a1f4664.png
[70 3]: /images/20220506/57123f2b012c43ef8de81f163d017fb7.png
[70 4]: /images/20220506/84dc75f5fcd34ec8aeb8bc7e35b2c3f6.png
[70 5]: /images/20220506/3e445d16a7ac433b97a7cd3caaa67b1e.png
[Link 1]: https://download.csdn.net/download/jdfk423/10701703
[70 6]: /images/20220506/f9478df4773d416bbda1eed4b3312b7d.png
[70 7]: /images/20220506/bc63f5185523414087afdfd849942247.png
[70 8]: /images/20220506/042091186e3a4b1d81aa4f6089185ffa.png