AI 助理
备案控制台
开发者社区 开发与运维 文章 正文

JVM知识体系学习八：OOM的案例（承接上篇博文，可以作为面试中的案例）

2024-10-19 11
版权
版权声明：
本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《 阿里云开发者社区用户服务协议》和 《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写 侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。
简介： 这篇文章通过多个案例深入探讨了Java虚拟机（JVM）中的内存溢出问题，涵盖了堆内存、方法区、直接内存和栈内存溢出的原因、诊断方法和解决方案，并讨论了不同JDK版本垃圾回收器的变化。

前言

  • JDK中的 垃圾回收器
    1. JDK8：PS+PO
    2. JDK9：G1。逻辑分代，物理不分代。从这里之前都是逻辑、物理都分代。
    3. JDK11：CMS就淘汰了，完成历史使命了。使用ZGC（Z Garbage Collector）垃圾回收器；逻辑、物理都不分代。
    4. JDK13：ZGC
    5. 说明，GC的调优越来越简单了；在有GC调优阶段，这是优势。
  • 学完这篇博客，可以在简历上写 有过JVM调优的经验 ，但是不能写精通哦了。

一、概述

OOM产生的原因多种多样，有些程序未必产生OOM，不断FGC(CPU飙高，但内存回收特别少) （上个博文的最后的案例：七.1）

  1. 硬件升级系统反而卡顿的问题（见上个博文的案例六.2）
  2. 线程池不当运用产生OOM问题（见上个博文的案例七.1）
    不断的往List里加对象（实在太LOW了）
  3. jira系统（提交测试报告用的应用系统）问题，jira跑在Tomcat中：通过设置-Xms1024m -Xmx9216m发现 系统在不停的GC，大约1秒一次。但是没有定位出来；想把堆文件dump出来，但是文件大约有10个G，dump文件可能会导致服务宕机，所以生产环境中一般不太好这样搞。然后添加 参数-XX:+HeapDumpOnOutOfMemoryError ，等什么时候溢出再看dump出的文件。但是项目有个习惯：就是宕机后立马重启。一秒一次GC，还不报错，项目很慢，但是可以响应。后来dump一次文件，大约10个G。但是没有查出来问题。
    实际系统不断重启
    解决问题：加内存 + 更换垃圾回收器 G1（JDK9才有）

二、案例二

tomcat 中 http-header-size过大问题

1、搭建实验环境

a、代码

@RestController
@RequestMapping("/test")
public class TestController {

    @RequestMapping("/oom")
    public String testName(){
        return "Hello world";
    }
}

b、发请求

http://localhost:9898/test/oom
在这里插入图片描述

c、Jmeter启动

2、设置参数

  1. server.port：设置项目默认端口
  2. server.max-http-header-size：设置 HTTP 消息头的最大大小。
    在这里插入图片描述
    在这里插入图片描述

3、使用jmeter模拟并发测试(模拟并发100)

  • 使用jmeter模拟并发测试(模拟并发100)，jmeter 是压力测试用的
  • 这里模拟默认了100个线程去申请http的请求，这http请求会调用程序，这个程序，由于Tomcat 设置了 10000000大小 ，http每申请一个内存就增加了这么大的空间使用。很快就容易OOM，内存溢出。
    在这里插入图片描述

4、tomcat源码：

Http11Processor类，处理请求。
在这里插入图片描述
Http11InputBuffer类为请求创建buffer
在这里插入图片描述
发现每个请求都创建headerBufferSize+8192K
MAT截图：
在这里插入图片描述
结论：
当请求过多，设置堆内存太小，会导致oom问题。
发现同事无意设置过大。

三、案例：方法区内存溢出

  • lambda表达式导致方法区溢出问题(MethodArea / Perm Metaspace)
  • 不是那么真实，面试时尽量不要说这个， 只是想表达方法区也会内存溢出（OutOfMemoryError）
  • lambda表达式导致方法区溢出问题(MethodArea / Perm Metaspace)

1、代码:LambdaGC.java

启动参数：-XX:MaxMetaspaceSize=9M -XX:+PrintGCDetails

package com.mashibing.jvm.c5_gc;

public class LambdaGC {
    public static void main(String[] args) {
        for(;;) {
            I i = C::n;
        }
    }
    public static interface I {
        void m();
    }

    public static class C {
        static void n() {
            System.out.println("hello");
        }
    }
}

2、元空间内存溢出日志

"C:\Program Files\Java\jdk1.8.0_181\bin\java.exe" -XX:MaxMetaspaceSize=9M -XX:+PrintGCDetails "-javaagent:C:\Program Files\JetBrains\IntelliJ IDEA Community Edition 2019.1\lib\idea_rt.jar=49316:C:\Program Files\JetBrains\IntelliJ IDEA Community Edition 2019.1\bin" -Dfile.encoding=UTF-8 -classpath "C:\Program Files\Java\jdk1.8.0_181\jre\lib\charsets.jar;C:\Program Files\Java\jdk1.8.0_181\jre\lib\deploy.jar;C:\Program Files\Java\jdk1.8.0_181\jre\lib\ext\access-bridge-64.jar;C:\Program Files\Java\jdk1.8.0_181\jre\lib\ext\cldrdata.jar;C:\Program Files\Java\jdk1.8.0_181\jre\lib\ext\dnsns.jar;C:\Program Files\Java\jdk1.8.0_181\jre\lib\ext\jaccess.jar;C:\Program Files\Java\jdk1.8.0_181\jre\lib\ext\jfxrt.jar;C:\Program Files\Java\jdk1.8.0_181\jre\lib\ext\localedata.jar;C:\Program Files\Java\jdk1.8.0_181\jre\lib\ext\nashorn.jar;C:\Program Files\Java\jdk1.8.0_181\jre\lib\ext\sunec.jar;C:\Program Files\Java\jdk1.8.0_181\jre\lib\ext\sunjce_provider.jar;C:\Program Files\Java\jdk1.8.0_181\jre\lib\ext\sunmscapi.jar;C:\Program Files\Java\jdk1.8.0_181\jre\lib\ext\sunpkcs11.jar;C:\Program Files\Java\jdk1.8.0_181\jre\lib\ext\zipfs.jar;C:\Program Files\Java\jdk1.8.0_181\jre\lib\javaws.jar;C:\Program Files\Java\jdk1.8.0_181\jre\lib\jce.jar;C:\Program Files\Java\jdk1.8.0_181\jre\lib\jfr.jar;C:\Program Files\Java\jdk1.8.0_181\jre\lib\jfxswt.jar;C:\Program Files\Java\jdk1.8.0_181\jre\lib\jsse.jar;C:\Program Files\Java\jdk1.8.0_181\jre\lib\management-agent.jar;C:\Program Files\Java\jdk1.8.0_181\jre\lib\plugin.jar;C:\Program Files\Java\jdk1.8.0_181\jre\lib\resources.jar;C:\Program Files\Java\jdk1.8.0_181\jre\lib\rt.jar;C:\work\ijprojects\JVM\out\production\JVM;C:\work\ijprojects\ObjectSize\out\artifacts\ObjectSize_jar\ObjectSize.jar" com.mashibing.jvm.gc.LambdaGC
[GC (Metadata GC Threshold) [PSYoungGen: 11341K->1880K(38400K)] 11341K->1888K(125952K), 0.0022190 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
[Full GC (Metadata GC Threshold) [PSYoungGen: 1880K->0K(38400K)] [ParOldGen: 8K->1777K(35328K)] 1888K->1777K(73728K), [Metaspace: 8164K->8164K(1056768K)], 0.0100681 secs] [Times: user=0.02 sys=0.00, real=0.01 secs] 
[GC (Last ditch collection) [PSYoungGen: 0K->0K(38400K)] 1777K->1777K(73728K), 0.0005698 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
[Full GC (Last ditch collection) [PSYoungGen: 0K->0K(38400K)] [ParOldGen: 1777K->1629K(67584K)] 1777K->1629K(105984K), [Metaspace: 8164K->8156K(1056768K)], 0.0124299 secs] [Times: user=0.06 sys=0.00, real=0.01 secs] 
java.lang.reflect.InvocationTargetException
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:498)
    at sun.instrument.InstrumentationImpl.loadClassAndStartAgent(InstrumentationImpl.java:388)
    at sun.instrument.InstrumentationImpl.loadClassAndCallAgentmain(InstrumentationImpl.java:411)
Caused by: java.lang.OutOfMemoryError: Compressed class space
    at sun.misc.Unsafe.defineClass(Native Method)
    at sun.reflect.ClassDefiner.defineClass(ClassDefiner.java:63)
    at sun.reflect.MethodAccessorGenerator$1.run(MethodAccessorGenerator.java:399)
    at sun.reflect.MethodAccessorGenerator$1.run(MethodAccessorGenerator.java:394)
    at java.security.AccessController.doPrivileged(Native Method)
    at sun.reflect.MethodAccessorGenerator.generate(MethodAccessorGenerator.java:393)
    at sun.reflect.MethodAccessorGenerator.generateSerializationConstructor(MethodAccessorGenerator.java:112)
    at sun.reflect.ReflectionFactory.generateConstructor(ReflectionFactory.java:398)
    at sun.reflect.ReflectionFactory.newConstructorForSerialization(ReflectionFactory.java:360)
    at java.io.ObjectStreamClass.getSerializableConstructor(ObjectStreamClass.java:1574)
    at java.io.ObjectStreamClass.access$1500(ObjectStreamClass.java:79)
    at java.io.ObjectStreamClass$3.run(ObjectStreamClass.java:519)
    at java.io.ObjectStreamClass$3.run(ObjectStreamClass.java:494)
    at java.security.AccessController.doPrivileged(Native Method)
    at java.io.ObjectStreamClass.<init>(ObjectStreamClass.java:494)
    at java.io.ObjectStreamClass.lookup(ObjectStreamClass.java:391)
    at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1134)
    at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1548)
    at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1509)
    at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1432)
    at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178)
    at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:348)
    at javax.management.remote.rmi.RMIConnectorServer.encodeJRMPStub(RMIConnectorServer.java:727)
    at javax.management.remote.rmi.RMIConnectorServer.encodeStub(RMIConnectorServer.java:719)
    at javax.management.remote.rmi.RMIConnectorServer.encodeStubInAddress(RMIConnectorServer.java:690)
    at javax.management.remote.rmi.RMIConnectorServer.start(RMIConnectorServer.java:439)
    at sun.management.jmxremote.ConnectorBootstrap.startLocalConnectorServer(ConnectorBootstrap.java:550)
    at sun.management.Agent.startLocalManagementAgent(Agent.java:137)

3、分析

  • Compressed class space： Compressed class 是对象头的压缩指针；在方法区中，有一块内存专门是给压缩后的class用的，一旦占满之后，就会内存溢出。这里通过space 可以看出 是方法区的内存溢出。
  • 通过案例可以知道 元空间也是可以产生内存溢出的

4、疑问

  • 为什么lambda表达式导致方法区溢出问题，大多数不应该在堆中吗？而且这里为什么不会在栈中的局部变量中呢？而会在方法区呢？

四、案例：直接内存溢出问题（少见）（尽量不说）

  • 《深入理解Java虚拟机》P59，除非使用Unsafe分配直接内存，或者使用NIO的问题会导致直接内存（Direct Memory）溢出问题

  • 很少见的，一般不会搞出这个情况。

五、案例：栈内存溢出问题

1、栈溢出原因

2、案例（递归）

a、代码

package com.mashibing.jvm;

public class StackOverFlow {
    public static void main(String[] args) {
        m();
    }

    static void m() {
        m();
    }
}

b、结果

在这里插入图片描述

c、原因

栈中是每个的栈针，这里有方法的递归，所以栈的深度越来越大，导致栈的内存溢出。

d、解决方法

  • 设置栈的大小：-Xss

代码分析

1、代码

  • 代码1
Object o = null;
for(int i=0; i<100; i++) {
    o = new Object();
    //业务处理
}
  • 代码2
for(int i=0; i<100; i++) {
    Object o = new Object();
}

2、分析

  • 肯定是第一个代码会好一些。
  • 原因：
    • 第一个代码栈上只创建一个变量，通过循环会创建一个个的实例对象，然后变量指向实例对象。当变量指向第二个实例对象时，上一个实例对象就没有引用了，就会被垃圾回收掉。
    • 第二个代码每次都会产生一个对象，且有很大可能很多对象不会被回收掉。方法执行完，会被释放掉。
  • 综上所述：第一个代码好一些。

七、重写finalize引发频繁GC

1、概述

  • 小米云，HBase同步系统，系统通过nginx访问超时报警，最后排查，C++程序员重写finalize引发频繁GC问题
  • 排除情况：
    1. nginx访问超时报警
    2. 发现CPU飙高
    3. 发现频繁GC
    4. 再发现对象过多
    5. 最后发现：C++程序员重写finalize引发频繁GC问题

2、问题

  • 问题1：为什么C++程序员会重写finalize？
  • 问题2：为什么重写finalize会导致频繁GC。

3、答案

  • 因为C++程序员是手动回收内存的，先new 再delete。

    • C++的构造函数和java 一样，也需要 new，但是C++需要手动回收内存，但是手动回收内存是析构函数来解析完成的， C++ 调用delete语句的时候会默认调用 析构函数，调用new 语句的时候默认会调用构造函数。所以 delete语句在C++里是 手动回收内存要使用的语句。C++程序员会理所当然的认为java里面是不是也有一个类似于析构函数这样的东西，结果发现有个finalize，结果重写了。

  • 为什么造成频繁GC呢？

    • 是因为重新的finalize，耗时比较长。有可能会达到200ms（不确定）。这里有一些耗时长的操作，如果好多对象同时产生了，但是收到时会调用finalize，每个都要调用，所以回收不过来了，就会频繁GC。

4、案例

  • 如果有一个系统，内存一直消耗不超过10%，但是观察GC日志，发现FGC总是频繁产生，会是什么引起的？

  • 有人手动调用了 System.gc() (这个比较Low)。

  • -XX:+DisableExplictGC，弃用System.gc()不管用 ，FGC

八、new 大量线程导致OOM（太LOW）

  • new 大量线程，会产生 native thread OOM.
  • 解决方案：
    • ==（太low）应该用线程池。 ==
    • 太LOW了，减少堆空间（太TMlow了）,预留更多内存产生native thread
  • 经验扩展：JVM内存占物理内存 比例 50% - 80%
文章标签：
Java
C++
应用服务中间件
程序员
nginx
关键词：
JVM案例
案例面试
学习面试
JVM知识体系
JVM知识体系学习
java冯坚持
目录
相关文章
java冯坚持
|
1天前
|
缓存 算法 Java
JVM知识体系学习六：JVM垃圾是什么、GC常用垃圾清除算法、堆内存逻辑分区、栈上分配、对象何时进入老年代、有关老年代新生代的两个问题、常见的垃圾回收器、CMS
这篇文章详细介绍了Java虚拟机（JVM）中的垃圾回收机制，包括垃圾的定义、垃圾回收算法、堆内存的逻辑分区、对象的内存分配和回收过程，以及不同垃圾回收器的工作原理和参数设置。
java冯坚持
12 4
JVM知识体系学习六：JVM垃圾是什么、GC常用垃圾清除算法、堆内存逻辑分区、栈上分配、对象何时进入老年代、有关老年代新生代的两个问题、常见的垃圾回收器、CMS
java冯坚持
|
1天前
|
存储 SQL 小程序
JVM知识体系学习五：Java Runtime Data Area and JVM Instruction （java运行时数据区域和java指令（大约200多条，这里就将一些简单的指令和学习））
这篇文章详细介绍了Java虚拟机（JVM）的运行时数据区域和JVM指令集，包括程序计数器、虚拟机栈、本地方法栈、直接内存、方法区和堆，以及栈帧的组成部分和执行流程。
java冯坚持
5 2
JVM知识体系学习五：Java Runtime Data Area and JVM Instruction （java运行时数据区域和java指令（大约200多条，这里就将一些简单的指令和学习））
java冯坚持
|
1天前
|
Arthas 监控 Java
JVM知识体系学习七：了解JVM常用命令行参数、GC日志详解、调优三大方面（JVM规划和预调优、优化JVM环境、JVM运行出现的各种问题）、Arthas
这篇文章全面介绍了JVM的命令行参数、GC日志分析以及性能调优的各个方面，包括监控工具使用和实际案例分析。
java冯坚持
13 3
java冯坚持
|
1天前
|
存储 Java
JVM知识体系学习四：排序规范（happens-before原则）、对象创建过程、对象的内存中存储布局、对象的大小、对象头内容、对象如何定位、对象如何分配
这篇文章详细地介绍了Java对象的创建过程、内存布局、对象头的MarkWord、对象的定位方式以及对象的分配策略，并深入探讨了happens-before原则以确保多线程环境下的正确同步。
java冯坚持
6 0
JVM知识体系学习四：排序规范（happens-before原则）、对象创建过程、对象的内存中存储布局、对象的大小、对象头内容、对象如何定位、对象如何分配
热爱技术的小郑
|
2月前
|
Java Docker 索引
记录一次索引未建立、继而引发一系列的问题、包含索引创建失败、虚拟机中JVM虚拟机内存满的情况
这篇文章记录了作者在分布式微服务项目中遇到的一系列问题，起因是商品服务检索接口测试失败，原因是Elasticsearch索引未找到。文章详细描述了解决过程中遇到的几个关键问题：分词器的安装、Elasticsearch内存溢出的处理，以及最终成功创建`gulimall_product`索引的步骤。作者还分享了使用Postman测试接口的经历，并强调了问题解决过程中遇到的挑战和所花费的时间。
热爱技术的小郑
73 2
程序员飞鱼
|
4天前
|
存储 缓存 算法
JVM核心知识点整理（内存模型），收藏再看！
JVM核心知识点整理（内存模型），收藏再看！
程序员飞鱼
12 1
JVM核心知识点整理（内存模型），收藏再看！
潇洒洒
|
1天前
|
存储 安全 Java
jvm 锁的 膨胀过程？锁内存怎么变化的
【10月更文挑战第3天】在Java虚拟机（JVM）中，`synchronized`关键字用于实现同步，确保多个线程在访问共享资源时的一致性和线程安全。JVM对`synchronized`进行了优化，以适应不同的竞争场景，这种优化主要体现在锁的膨胀过程，即从偏向锁到轻量级锁，再到重量级锁的转变。下面我们将详细介绍这一过程以及锁在内存中的变化。
潇洒洒
10 4
拉丁解牛说技术
|
4天前
|
Java API 对象存储
JVM进阶调优系列(2)字节面试:JVM内存区域怎么划分，分别有什么用?
本文详细解析了JVM类加载过程的关键步骤，包括加载验证、准备、解析和初始化等阶段，并介绍了元数据区、程序计数器、虚拟机栈、堆内存及本地方法栈的作用。通过本文，读者可以深入了解JVM的工作原理，理解类加载器的类型及其机制，并掌握类加载过程中各阶段的具体操作。
拉丁解牛说技术
20 3
椰椰椰耶
|
9天前
|
存储 Java Linux
【JVM】JVM执行流程和内存区域划分
【JVM】JVM执行流程和内存区域划分
椰椰椰耶
30 1
最好zzz
|
10天前
|
存储 安全 Java
JVM锁的膨胀过程与锁内存变化解析
在Java虚拟机（JVM）中，锁机制是确保多线程环境下数据一致性和线程安全的重要手段。随着线程对共享资源的竞争程度不同，JVM中的锁会经历从低级到高级的膨胀过程，以适应不同的并发场景。本文将深入探讨JVM锁的膨胀过程，以及锁在内存中的变化。
最好zzz
16 1