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

已于 2023-03-03 22:39:19 修改
阅读量1k 收藏 2
点赞数
分类专栏： JVM 文章标签： jvm 学习 面试
于 2023-02-25 23:24:19 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/qq_40036754/article/details/128698559
版权
文章探讨了JVM中的内存溢出问题，包括堆内存、方法区、直接内存和栈内存溢出的各种案例。提到了JDK不同版本的垃圾回收器变化，如PS、G1、ZGC等，并通过实验展示了如何使用JMeter进行并发测试引发Tomcat的HTTP头部大小问题。此外，文章还讨论了lambda表达式如何可能导致方法区溢出，以及重写finalize方法对GC的影响。最后，强调了线程管理和线程池配置不当可能导致的OOM问题。
摘要由CSDN通过智能技术生成

文章目录

前言

  • 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冯坚持
关注
专栏目录
JVM内存模型和性能调优：JVM内存分配与回收：长期存活的对象将进入老年代- 第24篇
悟纤学院
04-24 2万+
一、长期存活的对象将进入老年代 既然虚拟机采用了分代收集的思想来管理内存，那么内存回收时就必须能识别哪些对象应放在新生代，哪些对象应放在老年代中。为了做到这一点，虚拟机给每个对象一个对象年龄（Age）计数器。 如果对象在 Eden 出生并经过第一次 Minor GC 后仍然能够存活，并且能被 Survivor 容纳的话，将被移动到 Survivor 空间中，并将对象年龄设为1。对...
JVM调优面试题——基础知识
二蛋的博客
03-03 5053
1、JDK，JRE以及JVM的关系2、编译器到底干了什么事3、类加载机制是什么3.1、装载3.2、链接3.3、初始化4、类加载器有哪些5、什么是双亲委派机制6、介绍一下JVM内存划分（运行时数据区）6.1、方法区6.2、堆6.3、虚拟机栈7、堆为什么进行分代设计8、老年代的担保机制9、为什么Eden：S0：S1是8：1：110、对象的创建以及分配过程11、方法区、元数据区、持久代是什么关系？12、对象在内存中的布局
JVM状态监控与OOM案例分析
11-30
JVM状态监控与OOM案例分析…… 简单认识，了解
JVM性能调优(九)：OOM案例
mingyuli的博客
11-14 1108
`
OOM - 实例一
u011385186的专栏
11-03 389
线上脚本任务出现了OOM，dump文件有27G左右，首先还是从线程去分析 jstack -l pid 查看线程，发现有同一个任务触发存在多个，排查下来定位是sleep时间过长，导致吞吐量不够，每天的任务会出现24h内都无法处理完成的情况。   经验 代码实现要合理，尽量减少全局变量hold住大对象 脚本类型的任务吞吐量，触发时间，触发方式等都需要提前预估好 排查jstack文件时，p...
oom java_[JVM]OOM实例分析
weixin_42510317的博客
02-21 159
本文内容总结自《深入理解Java虚拟机：JVM高级特性与最佳实践(第2版)》中的第2章。通过设置虚拟机的启动参数来模拟内存区域溢出的情况通过异常信息判断出是哪个内存溢出了，知道什么样的代码可能会导致内存溢出Java内存区域设置虚拟机的启动参数在使用代码进行验证之前，我们需要先了解如何设置虚拟机的启动参数，设置方法有两种。使用命令行执行程序时使用命令行运行程序时，直接在java后面跟上参数和程序名称...
JVM调优实战（二）- 生产OOM案例
最新发布
weixin_39682329的博客
02-29 567
在一个高并发的在线支付系统中，由于每个支付请求都需要创建一个新的处理线程，系统在高峰时段会同时处理数千个支付请求，从而创建了大量的线程。由于短时间内产生大量垃圾对象，垃圾回收器频繁触发，占用了大量的计算资源，导致实际垃圾回收时间超过了98%的执行时间，最终抛出。每个请求都会创建一个新的线程。: 是指系统在同一时刻实际处理的请求或事务的数量，反映了系统可以同时承载的正常使用系统功能的用户的数量。：复杂的业务接口查询可能涉及多表联查、大量数据计算和聚合等操作，这些操作都可能消耗大量的系统资源，从而影响性能。
面试官：如何进行 JVM 调优（附真实案例）
热门推荐
程序员囧辉
03-28 4万+
看完起飞
JVM状态监控与OOM案例分析.pptx
10-12
JVM状态监控与OOM案例分析.pptx
不想 CRUD 干到老，就来看看这篇 OOM 排查的实战案例！
程序猿DD
09-16 400
点击上方蓝色“程序猿DD”，选择“设为星标”回复“资源”获取独家整理的学习资料！作者：三国梦回来源：cnblogs.com/grey-wolf/p/9179113.html一、经历概要程...
OOM实战
一人一屋淋雨声
03-24 282
public class Outmemory { /** * -Xms1m -Xmx1m       -XX:SurvivorRatio=8 //新生代中eden区域与Survivor区域的容量比例，默认值8，代表 Eden：survivor =8：1       -XX:+HeapDumpOnOutOfMemoryError * @param args */ public static v...
第27章：OOM常见各种场景及解决方案
赞的心路历程
11-25 2111
1、OOM案例1：堆溢出 1.1、报错信息 java.lang.OutOfMemoryError: Java heap space 1.2、案例模拟 127.0.0.1:8080/add /** * 案例1：模拟线上环境OOM */ @RequestMapping("/add") public void addObject(){ System.err.println("add"+peopleSevice); ArrayList<People> peop
Java中OOM异常的情况案例
梦中注定的博客
07-12 302
Java中OOM异常的情况总结 在《Java虚拟机规范》中规定，除了程序计数器外，虚拟机内存的其他几个运行时区域都有发生OutOfMemoryError异常的可能。即会出现如下OOM异常： Java堆溢出 Java堆用于存储对象实例，只要是不断地创建对象，并且保证GC Roots到对象之间有可达路径来避免垃圾回收机制来清除这些对象，那么随着对象的增加，总容量触及最大堆的容量限制后就会产生内存溢出异常。 虚拟机栈和本地方法栈溢出 1）如果线程请求的栈深度大于虚拟机所允许的最大深度，将抛出StackOv
【JVM技术专题】让你完全攻克内存溢出（OOM）这一难题「案例篇」
世界上并没有完美的程序，但是我们并不因此而沮丧，因为写程序就是一个不断追求完美的过程。
10-28 856
代码中可能存在大对象分配，可能存在内存泄露，导致在多次GC之后，还是无法找到一块足够大的内存容纳当前对象。业务场景会剧增对象数据，应该提升内存空间。
案例：隐秘而低调的内存泄露（OOM）
测试帮日记
05-29 218
本文选自《大话软件测试》一书 内存泄露测试的整个过程如下： l 在手机里启动被测APP并打开DDMS。 l 在DDMS中选中【com.example.android.hcgallery】之后单击按钮【show heap updates】，然后切换到标签页【VM Heap】，再单击按钮【Cause GC】。 l 不断操作APP，并观察Heap。经过一段时间的操作我们发现不论是%Used还是d...
JVM虚拟机实战案例 -- OOM
dujunjiehaha的博客
01-22 388
一、通过运行时验证Java虚拟机规范中描述的各个运行时区域存储的内容 二、在工作中遇到OOM，根据异常信息快速判断是哪个区域的内存溢出，知道什么样的代码可能导致OOM，以及解决方案 Java堆溢出 VM参数： Xms20M -Xmx20M -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=D:\Java\dump2.hprof 代码 Ma...
OOM问题小例子及思考
一直在奋起，一直在路上
04-03 697
前段时间朋友新进入一个公司，遇到线上系统cpu飙高，内存占满情况；和他交流过后有了本篇总结，该博文会以一个简单的小例子来演示oom，以及通过输出dump文件，最后用可视化工具进行分析定位具体oom的代码。
面试官：哪些场景会产生OOM？怎么解决？
艾小仙的专栏
09-17 2074
这个面试题是一个朋友在面试的时候碰到的，什么时候会抛出OutOfMemery异常呢？初看好像挺简单的，其实深究起来考察的是对整个JVM的了解，而且这个问题从网上可以翻到一些乱七八糟的答案，其实在总结下来基本上4个场景可以概括下来。 堆内存溢出 堆内存溢出太常见，大部分人都应该能想得到这一点，堆内存用来存储对象实例，我们只要不停的创建对象，并且保证GC Roots和对象之间有可达路径避免垃圾回收，那么在对象数量超过最大堆的大小限制后很快就能出现这个异常。 写一段代码测试一下，设置堆内存大小2M。 publi
评论 1
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

java冯坚持

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值