彻底深入理解和分析Java中OutOfMemoryError内存溢出

朴灿烈づ我的快乐病毒、 2022-09-06 15:29 232阅读 0赞

java开发人员经常遇到OutOfMemoryError的问题。要解决这些问题，要有对java虚拟机的内存管理有一定的认识，甚至对linux系统也要有一定的熟悉。昨天隔壁项目的应用遇到了OutOfMemoryError：unable to create new native thread问题，再次把之前的草稿文章整理，顺便总结发出来。

如果对jvm虚拟机还不了解，请先看我之前的总结：

[《java(5)-深入理解虚拟机JVM》][java_5_-_JVM][和《][java_5_-_JVM][java(9)-深入浅出GC垃圾回收机制][java_9_-_GC][》][java_5_-_JVM]

# 第一种OutOfMemoryError： PermGen space #

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

**1）、程序中使用了大量的jar或class，使java虚拟机装载类的空间不够，与Permanent Generation space有关。这个主要是java8之前遇到的问题**，可以通过配置-XX:PermSize和-XX:MaxPermSize来设置。即PermGen space是有关非堆内存的内存溢出，

>       在JDK8之前的HotSpot JVM，存放这些”永久的”的区域叫做“永久代(permanent generation)”。永久代的垃圾收集是和老年代(old generation)捆绑在一起的，因此无论谁满了，都会触发永久代和老年代的垃圾收集。当JVM加载的类信息容量超过了参数-XX：MaxPermSize设定的值时，应用将会报OOM的错误：java.lang.OutOfMemoryError: PermGen
> 
>       JDK8的JVM不再有PermGen。但类的元数据信息（metadata）还在，只不过不再是存储在连续的非堆空间上，而是移动到叫做“Metaspace”的本地内存（Native memory）中。

**2)、在JDK6.0及之前版本，字符串常量池是放在Perm Gen区(也就是方法区)中；**可以运行如下代码，会报异常信息：java.lang.OutOfMemoryError:PermGen space

public class StringConstantPoolTest {
        public static void main(String[] args) {
            List<String> list = Lists.newArrayList();
            while (true) {
                list.add(String.valueOf(System.currentTimeMillis()).intern());
            }
        }
    }

**3）我们看看java8之前永久代Perm Gen非堆内存分配 -XX:PermSize例子：**

java8之前永久代是一片连续的堆空间。在JVM启动之前通过在命令行设置参数-XX:MaxPermSize来设定永久代最大可分配的内存空间：

-XX:PermSize：设置JVM非堆内存初始值，默认是物理内存的1/64；  
      -XX:MaxPermSize：设置最大非堆内存的大小，默认是物理内存的1/4。  
    （还有一说：MaxPermSize缺省值和-server -client选项相关，-server选项下默认MaxPermSize为64m，-client选项下默认MaxPermSize为32m）

永久代或者“Perm Gen”包含了JVM需要的应用元数据，这些元数据包括类的版本、字段、方法、接口等描述信息，还有运行时常量池，用于存放编译器生成的各种字面量和符号引用。注意，永久代不是Java堆内存的一部分。class文件中包括  
      永久代存放JVM运行时使用的类。永久代同样包含了Java SE库的类和方法。永久代的对象在full GC时进行垃圾收集。

在jdk7设置-XX:MaxPermSize过小会导致java.lang.OutOfMemoryError: PermGen space，原因如下：PermGen space用于存放Class和Meta的信息，GC不会对PermGen space进行处理，所以如果Load很多Class的话，就会出现上述Error。这种Error在web服务器对JSP进行pre compile的时候比较常见。

动态生成类的情况比较容易出现永久代的内存溢出。们现在通过动态生成类来模拟 “PermGen space”的内存溢出：

package com.demo.test;
    public class TestClass {
    }

**动态加载类com.demo.test.TestClass：**

package com.demo.test.web;
         
        /**
         * Created by huangguisu on 2019/7/10.
         */
         
        import java.io.File;
        import java.net.URL;
        import java.net.URLClassLoader;
        import java.util.ArrayList;
         import java.util.List;
         
        public class PermGenOom{
            public static void main(String[] args) {
                URL url = null;
                List<ClassLoader> classLoaderList = new ArrayList<ClassLoader>();
                try {
                    url = new File("/tmp").toURI().toURL();
                    URL[] urls = {url};
                    while (true){
                        ClassLoader loader = new URLClassLoader(urls);
                        classLoaderList.add(loader);
                        loader.loadClass("com.demo.test.TestClass");
                    }
                } catch (Exception e) {
                    e.printStackTrace();
                }
            }
        }

使用JDK1.7执行，指定的 PermGen 区-XX:MaxPermSize的大小为 8M：

![20210821160603236.png][]

# **第二种OutOfMemoryError：  Java heap space** #

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

1)、发生这种问题的原因是java虚拟机创建的对象太多，在进行垃圾回收之间，虚拟机分配的到堆内存空间已经用满。通过增加Java虚拟机中Xms（初始堆大小）和Xmx（最大堆大小）参数的大小。如 -Xms4G -Xmx4G 这个跟实际情况来设定。

2）在JDK7.0版本，字符串常量池被移到了堆中了。可以运行如下代码，会报异常信息：java.lang.OutOfMemoryError: Java heap space

3)、在JDK8.0版本，字符串常量池放到元空间，运行如下代码，也会报异常信息：java.lang.OutOfMemoryError: Java heap space ：

看看java.lang.OutOfMemoryError: Java heap space例子：

package com.demo.test.web;
    import java.util.ArrayList;
    import java.util.List;
    public class HeapOom {
        public static void main(String[] args) {
            List<byte[]> list = new ArrayList<byte[]>();
            int i = 0;
            boolean flag = true;
            while (flag){
                try {
                    i++;
                    list.add(new byte[1024 * 1024]);//每次增加一个1M大小的数组对象
                }catch (Throwable e){
                    e.printStackTrace();
                    flag = false;
                    System.out.println("count="+i);//记录运行的次数
                }
            }
        }
    }

我们设置堆内存的大小为16M，当运行到第15次，当无法申请空间时会抛出OutOfMemoryError：

![20200710160033361.png][]

![20200710155943553.png][]

# 第三种 java8 java.lang.OutOfMemoryError: Metadata space  #

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

java8的Metaspace 容量默认情况下，Metaspace类元数据只受可用的本地内存限制（容量取决于是32位或是64位操作系统的可用虚拟内存大小）。  
新参数（MaxMetaspaceSize）用于限制本地内存分配给类元数据的大小。如果没有指定这个参数，元空间会在运行时根据需要动态调整。  
如果设置-XX:MaxMetaspaceSize，当，Metaspace被耗尽；与JDK1.7运行时非常相似，报错：ERROR: java.lang.OutOfMemoryError: Metadata space。

这种情况一般不会遇到，很少人会手动设置java8的MaxMetaspaceSize参数。

# **第四种、StackOverflowError栈溢出** #

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

java方法被执行的时候都会同时创建栈帧（Stack Frame）.用于存储局部变量表、操作数栈、动态链接，方法出口等信息。方法被调用到执行完成对的过程，就是相应对于栈帧在JVM从入栈到出栈的过程。当线程请求的栈深度大于虚拟机所允许的深度是出现错误：StackOverflowError。

Java栈由栈帧组成，一个帧对应一个方法调用。虚拟机栈是一个LIFO的栈: 调用方法时压入栈帧，方法返回时弹出栈帧并抛弃。Java栈的主要任务是存储方法参数、局部变量、中间运算结果，并且提供部分其它模块工作需要的数据。  
    我们通过递归方法来测试栈的深度和栈溢出：

public class StackOverflowError {
        //使用计数器计算栈的深度
        private static int index = 1;
     
        //没有结束条件的递归导致死递归
        public void recursiveCall(){
            index++;
            recursiveCall();
        }
     
        public static void main(String[] args) {
            StackOverflowError stackOverflowError = new StackOverflowError();
            try {
                stackOverflowError.recursiveCall();
            }catch (Throwable e){
                System.out.println("Stack deep : "+index);
                e.printStackTrace();
            }
        }
     
    }

指定线程栈大小为-Xss128k，运行结果：

![20200710143944156.png][]

![20200710144051600.png][]

**  如果调整**线程栈大小-Xss256k， 深度也是不一样的：

![2020071015112051.png][]

# 第五种OutOfMemoryError：unable to create new native thread #

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

## 1、错误现象： ##

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2hndWlzdQ_size_16_color_FFFFFF_t_70][]

##  **2、错误原因** ##

在网上看到的文章大致总结的原因如下：

**1）服务器剩余内存不足（非JVM内存），不能创建新的线程。**

能创建的线程数的具体计算公式如下：

> Number of threads= (MaxProcessMemory - JVMMemory - ReservedOsMemory) / (ThreadStackSize)  
> MaxProcessMemory         指的是一个进程的最大内存  
> JVMMemory                JVM内存  
> ReservedOsMemory         保留的操作系统内存  
> ThreadStackSize          线程栈的大小

**2）超出系统用户最大进程限制:**  
通过以下命令可以查看最大进程限制配置max user processes.（注意，不同用户的最大进程限制配置max user processes可能不一样）详细解读在我之前的总结文章[《][Link 1][limit资源限制ulimit 详解][Link 1][》https://guisu.blog.csdn.net/article/details/46126249][Link 1]。

ulimit -a 查看资源：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2hndWlzdQ_size_16_color_FFFFFF_t_70 1][]

## **3、错误分析** ##

**1）首先通过ps -efL |grep pid |wc -l 查看当前应用的线程数。**

ps -efL |grep pid看具体的线程数：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2hndWlzdQ_size_16_color_FFFFFF_t_70 2][]

如果应用程序部署在实机而不是docker，可以直接查看，如果是docker，进入容器内部，命令ps -efL参数L不一定有，但是可以在宿主主机上查看具体java应用进程，然后再通过ps -efL |grep pid查看线程数。

** 2）检查系统的资源限制max user processes：**

这个需要先查看应用的具体是哪个用户，比如应用所在的用户是appuser：

![20210821163307873.png][]

然后切换到su appuser, 查看系统资源限制ulimit -a：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2hndWlzdQ_size_16_color_FFFFFF_t_70 3][]

3)、如果系统资源限制没有问题，就是查看系统的使用内存情况。

## **4、我们的实际情况** ##

由于我们应用使用k8s部署，进入容器后无法执行ps -efL |grep pid，而且又是线上问题，需要尽快解决。我们只好先重启服务。

然后把一些截图和错误日志保留下来：

**1)、系统分析**

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2hndWlzdQ_size_16_color_FFFFFF_t_70 4][]

从上面的截图事后分析，明显是系统资源不足，create gc thread，out of system resources（超过了系统资源）。

但是我们在容器内执行ulimit -a，看到的max user processes是32768. 程序的线程数不太可能到达3万多。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2hndWlzdQ_size_16_color_FFFFFF_t_70 5][]

** 2)代码分析**

我们分析代码，报错的地方确实有new thread。new thread创建大量线程后，如果线程处理某个业务很慢没有及时回收，那么肯定存在短时间内创建大量的线程。这个肯定是需要通过线程池来优化处理。

**3) 问题的本质：**

重启服务后，最后我们和运维人员一块分析检查，进入到宿主主机，查看当前应用总线程数才101，运维人员最后检查pod的各种参数，最后发现Kubelet 开启 PodPidsLimit 功能。

配置 Kubelet 的 **–pod-max-pids=**3000 选项，即容器内允许的最大进程数为 3000 个。

问题本质原因就是：我们应用开启了大量线程，超过容器限定PodPidsLimit数量3000个，而不是ulimit -u的资源限制。

# 总结 #

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

## **1、在问题中成长和深入学习。** ##

遇到问题时最好的学习机会，通过透过问题看本质则是由虚到实，往深层次地挖掘，最后能形成底层技术深度加固。要真正的精通一门技术，最终还要通过实践来深入。问题是最好的实践。就像游泳教练，必定游泳水平好，因为这些都是实践性很强的工作。书上学来终觉浅，绝知此事要躬行。

在实践中，遇到问题，不仅只解决问题，还要对问题刨根问底，深入挖掘问题发生的根本原因，这样可以系统性地修复问题，从而使其永久消失。从问题本身着手,沿着因果关系链条,顺藤摸瓜,穿越不同的抽象层面,直至找出原有问题的根本原因.

我们中国古代以来就有“打破沙锅问到底”的习惯;“打破沙锅问到底”是一句俗语,形象表达了锲而不舍、不断探索的精神,这是人们常挂在嘴边的一句口头禅。

我们遇到问题，从外到里，逐层分析：  
1、问题表象是什么  
2、直接原因是什么？  
3、中间原因是什么？  
4、根本原因是什么？

真正的解决问题必须找出问题的根本原因，如果只解决问题，而不深入问题背后的根本原因，这门技术也是不够深入。

比如：

问题：java应用出现超时抖动？

1）解决：Java应用出现FGC. (增大 -Xmx  -Xms 内存设置）

2）、直接原因：流量激增？  长时间运行？ 代码问题导致占用内存对象不释放？。。。

3）、中间原因：流量没有做预警？ 研发人员能力问题？

4）、根本原因：JVM虚拟机的基本原理？GC机制？ JVM性能监控？......

## **2、理解本质** ##

将世界万物理解为原子，将整个互联网理解成0和1，这倒的确是非常本质了，不过并不能解答任何问题。从问题看本质，实质上是一个从表层逐步深入的过程。遇到问题要打破砂锅问到底，了解最终引发问题的根本原因，最后形成高效解决问题的能力：解决问题和绕开问题。

## 3、善于总结、不断反思。 ##

每一次的总结和反思，只要足够深刻、足够深入骨髓，乃至触及灵魂和价值观，都可以是一次浴火重生。总结是深刻反思的过程，总结是自我检视、自我完善的过程，由“经事”而“长智”的过程，正是“吃一堑长一智”。

毛主席说：“我是靠总结经验吃饭的。”不断总结、善于总结才能不断进步、不断提高。

###  ###

[java_5_-_JVM]: https://guisu.blog.csdn.net/article/details/8230427
[java_9_-_GC]: https://guisu.blog.csdn.net/article/details/8549353
[20210821160603236.png]: /images/20220829/4f225c4dccf74509a0ff860b26ddd218.png
[20200710160033361.png]: /images/20220829/764a2b57dc9345e5bb392b92dfdf1426.png
[20200710155943553.png]: /images/20220829/0b2a3bfe70f94e5ea33c148c403c30c2.png
[20200710143944156.png]: /images/20220829/702a35c8724c4daea901f90f2e6ae131.png
[20200710144051600.png]: /images/20220829/4b2773b84fa04249a1543b0bc81ec804.png
[2020071015112051.png]: /images/20220829/f872a50c377a429a971956de2286814b.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2hndWlzdQ_size_16_color_FFFFFF_t_70]: /images/20220829/bb7bd530f31642b4988db5b3671b8e21.png
[Link 1]: https://guisu.blog.csdn.net/article/details/46126249
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2hndWlzdQ_size_16_color_FFFFFF_t_70 1]: /images/20220829/580511fc19ff4edb966bdd8fc515bdb5.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2hndWlzdQ_size_16_color_FFFFFF_t_70 2]: /images/20220829/307eea3cb93c4e88a1b3e8c3ca81eb33.png
[20210821163307873.png]: /images/20220829/36b4618ab99e49038906cc7538d70d73.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2hndWlzdQ_size_16_color_FFFFFF_t_70 3]: /images/20220829/4c9445216a39421baea28621c36efb4d.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2hndWlzdQ_size_16_color_FFFFFF_t_70 4]: /images/20220829/1d7627c735434b8a8001216f5f6e960d.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2hndWlzdQ_size_16_color_FFFFFF_t_70 5]: /images/20220829/eb7cd00acc4f436087c607cc18f0fe2c.png