浅析Java OutOfMemoryError

淩亂°似流年 2022-05-31 09:00 181阅读 0赞

在日常中我们经常遇到这样的错误:java.lang.OutOfMemoryError: Java heap space。  
但是除了heap space 的OutOfMemoryError，还有其它几种OutOfMemoryError情况。今天我们就来了解一下：

--------------------

### 1、java.lang.OutOfMemoryError: Java heap space。 ###

这是因为虚拟机堆的空间所剩不多。当准备创建的对象需要的内存已经超过虚拟机堆所剩的空间。虚拟机会尝试通过full GC来回收内存，如果不行的话，就会抛出OutOfMemoryError。  
导致OutOfMemoryError异常的常见原因有以下几种：  
内存中加载的数据量过于庞大，如一次性从DB取出过多数据；  
集合类中有对象的引用，使用完后未清空，使得JVM不能回收；  
代码中存在死循环或循环产生过多重复的对象实体；  
启动参数内存值设定的过小。

举一个常见的OutOfMemoryError场景：先从DB读取数据存放到内存中，然后遍历处理。

public class HeapSpaceOutOfMemory {
    
      private static List<byte[]> getDataFromDb() {
        List<byte[]> list = new ArrayList<>();
        for (int i = 0; i < 500; i++) {
            byte[] data = new byte[1024 * 1024];// 1M的对象
            list.add(data);
        }
        return list;
      }
    
      public static void main(String[] args) {
        // 1、从db取数据，大小为500M
        List<byte[]> list = getDataFromDb();
        // 2、遍历处理list
        for (byte[] data : list) {
            //do something
        }
        System.out.println("success");
      }
    }

JVM参数： -Xms64M -Xmx128M -XX:+PrintGCDetails -Xloggc:/apps/logs/heap\_demo.log  
![image.png][]  
运行结果：  
![image.png][image.png 1]  
查看GC Log，可以看到有Full GC 的痕迹，但是Full GC的收效果不明显，年轻代和年老代都没有足够的空间为即将创建的对象分配空间。  
![image.png][image.png 2]  
解决OOM最快的方法就是调整-Xmx参数，增加堆的大小。  
调整JVM参数： -Xms64M -Xmx1024M -XX:+PrintGCDetails -Xloggc:/apps/logs/heap\_demo.log  
![image.png][image.png 3]  
![image.png][image.png 4]  
虽然通过调整-Xmx参数解决了上面OutOfMemoryError的问题，但是如果DB的数据突然暴涨到5G、50G、500G的时候，还是会出现OutOfMemoryError。此时通过调整-Xmx参数就不合适了，先不说机器有没有这么大的内存分配，就算机器的内存够分配，Full GC导致程序停顿的时间也会很长。因此我们要从代码下手，分批次处理数据，“小步快跑”，将5G的数据拆分成10个批次，50G的数据拆分成100个批次，500G的数据拆分成1000个批次，每个批次处理500M的数据，一个批次处理完后内存回收。这样的话就不用再担心突然暴涨的数据量导致程序OutOfMemoryError。

### 2、java.lang.OutOfMemoryError: Metaspace ###

JDK1.7中，存储在永久代的部分数据就已经转移到了Java Heap或者是 Native Heap，譬如符号引用(Symbols)转移到了native heap；字面量(interned strings)转移到了java heap；类的静态变量(class statics)转移到了java heap。但永久代仍存在于JDK1.7中，并没完全移除。  
JDK 8.HotSpot JVM使用本地化的内存存放类的元数据，这个空间叫做元空间（Metaspace）。官方定义：”In JDK 8, classes metadata is now stored in the native heap and this space is called Metaspace”。元空间的本质和永久代类似，都是对JVM规范中方法区的实现。不过元空间与永久代之间最大的区别在于：元空间并不在虚拟机中，而是使用本地内存。因此，默认情况下，元空间的大小仅受本地内存限制，但可以通过以下参数来指定元空间的大小：-XX:MetaspaceSize、-XX:MaxMetaspaceSize。  
测试代码：

public class MetaspaceOutOfMemory {
    
      public static void main(String[] args) throws Exception {
        ClassPool cp = ClassPool.getDefault();
        for (int i = 0;; i++) {
            cp.makeClass("com.demo.MetaspaceClass" + i).toClass();
            Thread.sleep(1);
        }
      }
    }

JVM参数：-XX:MetaspaceSize=32m -XX:MaxMetaspaceSize=64m -Xloggc:/apps/logs/heap\_demo.log  
打开VisualVm工具，可以发现Metaspace使用的空间大小随类装入的数量增加而增加，这也说明了Metaspace是用来存放类的元数据的。  
![image.png][image.png 5]

![image.png][image.png 6]  
![image.png][image.png 7]

### 3、java.lang.OutOfMemoryError: PermGen space ###

修改JVM参数为：-XX:PermSize=32M -XX:MaxPermSize=64M -Xloggc:/apps/logs/heap\_demo.log，切换到JDK7下运行MetaspaceOutOfMemory。打开VisualVm工具，此时出现了PermGen标签页。随着类装载的数量增加，最终出现了java.lang.OutOfMemoryError: PermGen space，进程退出。  
![image.png][image.png 8]  
![image.png][image.png 9]  
![image.png][image.png 10]

### 4、java.lang.OutOfMemoryError: GC overhead limit exceeded ###

GC overhead limt exceed检查是Hotspot VM 1.6定义的一个策略，通过统计GC时间来预测是否要OOM了，提前抛出异常。官方定义是：“并行/并发回收器在GC回收时间过长时会抛出OutOfMemroyError。过长的定义是，超过98%的时间用来做GC并且回收了不到2%的堆内存”。JVM默认启动的时候-XX:+UseGCOverheadLimit，即启用了该特性。  
测试程序：

public class GCOverheadLimit {
      public static void main(String[] args) {
        List list = new ArrayList();
        String str = "1";
        for (int i = 0; i < 1000000; i++) {
            for (int j = 0; j < 100; j++) {
                str += "$" + i;
            }
            list.add(str);
        }
      }
    }

JVM参数：-Xms64M -Xmx128M -XX:+UseGCOverheadLimit  
运行结果：  
![image.png][image.png 11]  
最近项目有一个程序，因为频繁Full GC导致程序僵死现象，一致耗着，如果加上-XX:+UseGCOverheadLimit参数就可以让程序提前退出，避免僵死程序长期占用资源。

### 5、java.lang.OutOfMemoryError: unable to create new native thread ###

如果JVM正在请求操作系统创建一个本地线程，而操作系统无法创建的时候，就会出现这个报错信息。JVM中可以生成的最大线程数量由JVM的堆内存大小、Thread的Stack内存大小、系统最大可创建的线程数量（Java线程的实现是基于底层系统的线程机制来实现的，Windows下\_beginthreadex，Linux下pthread\_create）三个方面影响。

### 6、java.lang.OutOfMemoryError: Requested array size exceeds VM limit ###

当你正准备创建一个超过虚拟机允许的大小的数组时，这条错误就会出现在你眼前。64位的操作系统上，JDK7，如果数组的长度是Integer.MAX\_VALUE-1,就会出现。

byte a[] = new byte[Integer.MAX_VALUE-1];

### 7、java.lang.OutOfMemoryError: request bytes for . Out of swap space？ ###

这个错误是当虚拟机向本地操作系统申请内存失败时抛出的。这和你用完了堆或者持久化中的内存的情况有些不同。这个错误通常是在你的程序已经逼近平台限制的时候产生的。这个信息告诉你的是你可能已经用光了物理内存以及虚拟内存了。由于虚拟内存通常是用磁盘作为交换分区，因此你最先想到的解决方法可能是先增加交换分区的大小。不过我从没见过一个程序在频繁进行内存交换还能正常运行的，所以这个方法可能不会起到什么作用。

[image.png]: /images/20220531/1f76783f999045da9486af45876b0c01.png
[image.png 1]: /images/20220531/7d01ee8f3bb240b4b251e6ecac906b07.png
[image.png 2]: /images/20220531/4e956cc4a0354f1997c8d5001b48c33a.png
[image.png 3]: /images/20220531/33d7737cc7f44a1babf6e154a43592f5.png
[image.png 4]: /images/20220531/d258d7af669e4ee9a1a8909b5e60a11f.png
[image.png 5]: /images/20220531/07d1fe0f26b14a709009290821e5ef7b.png
[image.png 6]: /images/20220531/0b1388b213a245c7bd984f69f13c20b2.png
[image.png 7]: /images/20220531/9031a253102140d284a48cd8178ebfaa.png
[image.png 8]: /images/20220531/acb7c5a0720c44f7bbdc32143b8f5a5e.png
[image.png 9]: /images/20220531/9a853a325609401bab5ca436c630e4df.png
[image.png 10]: /images/20220531/4fc4f31c1ce543deb58f8bb128bf35ce.png
[image.png 11]: /images/20220531/e19cb18a3f2f461f9507b026906e4311.png