OutOfMemoryError异常——方法区和运行时常量池溢出。

╰+攻爆jí腚メ 2024-02-18 19:13 19阅读 0赞

由于运行时常量池是方法区的一部分，因此这两个区域的溢出测试就放在一起进行。前面提到JDK1.7开始逐步“去永久代”的事情，在此就以测试代码观察一下这件事对程序的实际影响。

String.intern()是一个Native方法，他的作用是：如果字符串常量池中已经包含一个等于此String对象的字符串，则返回代表池中这个字符串的String对象；否则，将此String对象包含的字符串添加到常量池中，并且返回此String对象的引用。在JDK 1.6及之前的版本中，由于常量池分配在永久代内，我们可以通过-XX : PermSIze和-XX : MaxPermSize限制方法区大小，从而间接限制其中常量池的容量，如下面代码所示。

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

运行结果：

> ![20180328161425057][]

从运行结果中可以看到，运行时常量池溢出，在OutOfMemoryError后面跟随的提示信息是“PermGen space”，说明运行时常量池属于方法区（HotSpot虚拟机中的永久代）的一部分。

而使用JDK 1.7运行这段程序就不会得到相同的结果，while循环将一直进行下去。关于这个字符串常量池的实现问题，还可以引申出一个更有意思的影响，如下代码所示。

> public class RuntimeConstantPoolOOM \{  
>   
> public static void main(String\[\] args) \{  
> 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，而在JDK1.7中运行，会得到一个true和一个false。产生差异的原因是：在JDK1.6中，intern()方法会把首次遇到的字符串实例复制到永久代中，返回的也是永久代中这个字符串实例的引用，而由StringBuilder创建的字符串实例在Java堆上，所以必然不是同一个引用，将返回false。而JDK 1.7（以及部分其他虚拟机，例如JRockit）的intern()实现不会再复制实例，只是在常量池中记录首次出现的实例引用，因此intern()返回的引用和由StringBuilder创建的那个字符串实例是同一个。对str2比较返回false是因为“java”这个字符串在执行StringBuilder.toString()之前已经出现过，字符串常量池中已经有他的引用了，不符合“首次出现”的原则，而“计算机软件”这个字符串则是首次出现的，因此返回true。

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

值得特别注意的是，我们在这个例子中模拟的场景并非纯粹是一个试验，这样的应用经常会出现在实际应用中：当前的很多主流框架，如Spring、Hibernate，在对类进行增强时，都会使用到CGLib这类字节码技术，增强的类越多，就需要越大的方法区来保证动态生态的Class可以加载入内存。另外，JVM的动态语言（例如Groovy等）通常都会持续创建类来实现语言的动态性，随着这类语言的流行，也越来越容易遇到与下面代码相似的溢出场景。

> 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 \{  
>   
> \}  
> \}

运行结果：

> ![20180328162952263][]

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

[20180328161425057]: https://image.dandelioncloud.cn/pgy_files/images/2024/01/29/23989753cae141ff8f60373b505376f6.png
[20180328162952263]: https://image.dandelioncloud.cn/pgy_files/images/2024/01/29/4619c7ef70e54040819e7bf08b05f105.png