记一次生产jvm oom问题

本文介绍了如何在JavaJVM中配置参数处理OOM(内存溢出),使用MAT工具分析内存dump文件,发现ScheaTest$ZxcUser类的byte[]数组导致问题。通过调整延时队列策略,限制任务队列大小,避免内存异常。最后提到对于重要数据,应考虑使用MQ的延时队列进行处理以确保数据完整性。

前言

        jvm添加以下参数,发生OOM时自动导出内存溢出文件

-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/opt

  内存分析工具: MAT, 下载地址:Eclipse Memory Analyzer Open Source Project | The Eclipse Foundation, 注意工具地址要跟你的jdk匹配,至少你的jdk要比MAT的需要的高

参考使用地址:JVM 内存分析工具 MAT 的深度讲解与实践——入门篇 - 掘金

生产业务简单描述

        小程序注册用户推送,需要发布一个注册事件进行上报处理,逻辑需要设备的数据,而这部分数据发生在用户注册以后才会生成,可能隔个几秒才会出来,所以才需要借助延时队列进行处理。10s后再进行发布

        之所以会有这种并发问题是因为这个小程序在有广告投放的时候会瞬间很多流量打进来,从而引起这种问题。

分析dump文件

主界面如下

Histogram方式

然后选择如下信息

可以看到byte[]的第一个引用是com.zxc.movie.main.bo.movie.ScheaTest$ZxcUser,到此就能找到源头了,可以全局搜索该类的引用情况

dominator_tree方式

也可以很容易定位到com.zxc.movie.main.bo.movie.ScheaTest$ZxcUser引用的问题

模拟代码如下

package com.zxc.movie.main.bo.movie;

import java.util.concurrent.ScheduledThreadPoolExecutor;
import java.util.concurrent.TimeUnit;

public class ScheaTest {

    public static void main(String[] args) throws Exception{

        ScheduledThreadPoolExecutor executor = new ScheduledThreadPoolExecutor(1);

//        TimeUnit.SECONDS.sleep(20);
        System.out.println("come");
        while (true) {
            Thread.sleep(100);
            executor.schedule(new ZxcRunner(), 1000, TimeUnit.SECONDS);
        }

    }
    public static class ZxcRunner implements Runnable {

        private ZxcUser zxcUser = new ZxcUser();

        public ZxcUser getZxcUser() {
            return zxcUser;
        }

        @Override
        public void run() {
            System.out.println(zxcUser);
        }
    }

    public static class ZxcUser {
        private byte[] bytes = new byte[1024 * 1024];
    }
}

确实是com.zxc.movie.main.bo.movie.ScheaTest$ZxcUser出现了问题

总结

        这里是我模拟的一个情况,可能比较好定位,真实的业务情况可能稍微复杂点,但是业务就是这么个事,延时任务里面对象一瞬间过多导致内存溢出了

解决方案

            真实的业务情况不会推迟1000s才执行任务,大概在10s内就可以发出去了,这里只是为了更好的看到这个问题,也就是说生产上在10s内进入了很多事件,导致发生了OOM的问题,改进如下

package com.zxc.movie.main.bo.movie;

import java.util.concurrent.ScheduledThreadPoolExecutor;
import java.util.concurrent.TimeUnit;

public class ScheaTest {

    public static void main(String[] args) throws Exception{

        ScheduledThreadPoolExecutor executor = new ScheduledThreadPoolExecutor(1);

//        TimeUnit.SECONDS.sleep(20);
        while (true) {
            Thread.sleep(100);
            if(executor.getQueue().size() < 5) {
                executor.schedule(new ZxcRunner(), 1000, TimeUnit.SECONDS);
            } else {
                System.out.println("队列满了,待释放");
            }
        }

    }
    public static class ZxcRunner implements Runnable {

        private ZxcUser zxcUser = new ZxcUser();

        public ZxcUser getZxcUser() {
            return zxcUser;
        }

        @Override
        public void run() {
            System.out.println(zxcUser);
        }
    }

    public static class ZxcUser {
        private byte[] bytes = new byte[1024 * 1024];
    }
}

改为了判断队列的大小超过指定值就不放进去了,这样生产10s出现很多内容也不会有问题了,解决完效果如下

当队列小于指定的大小便可以正常加入,超出的时候就把任务丢了,防止内存异常,这里把任务丢了是因为业务允许,如果业务不允许那么就需要把这部分任务给存储起来后续再进行操作

备注

        之所以这样做是因为生产这方面的数据是允许丢失的,如果你的数据比较重要的话那可以先临时存到其他地方,然后再拿出来去处理,或者数据不要用这种内存的方式来异步了,可以借助MQ的延时队列去处理

<think>嗯,用户想通过JVMOOM堆栈信息找到引发内存溢出的具体类。那我得先理清楚步骤,确保回答结构清晰,还要引用提供的参考资料。首先,OOM有不同的类型,比如堆溢出、栈溢出,所以需要先确认是哪种OOM类型。根据引用3,堆溢出是Java heap space,而栈溢出是StackOverflowError。用户的问题是关于OOM,所以可能主要关注堆溢出。 接下来,用户需要知道如何从堆栈信息中找到具体的类。这时候需要分析dump文件。引用1提到了使用VisualVM工具,可以加载dump文件来查看对象实例和类的信息。另外,引用3提到堆内存溢出时,JVM会生成dump文件,需要配置参数-XX:+HeapDumpOnOutOfMemoryError。这部分应该作为关键步骤之一。 然后,可能需要使用MAT(Memory Analyzer Tool)或者VisualVM来分析dump文件中的对象数量和占用内存情况。比如,查找占据内存最大的对象,或者存在大量重复的类实例。例如,如果发现大量的String对象,可能是字符串处理不当导致的泄漏。 另外,用户可能不知道如何生成dump文件,所以需要给出具体的JVM参数设置,比如-XX:+HeapDumpOnOutOfMemoryError和-XX:HeapDumpPath。这部分在引用3里也有提到,堆内存不足时total增加到max就会OOM,并生成dump。 还要注意区分不同的内存区域,比如方法区、栈等,但用户的问题是关于OOM,所以重点在堆内存。但也要提醒用户确认错误类型,比如是Java heap space还是其他类型,这会影响排查方向。 可能还需要提到检查代码中的常见内存泄漏点,比如静态集合、未关闭的资源、大量缓存等。引用2中提到了线程分配不足导致的OOM,但用户的问题可能更偏向堆内存,所以主要关注对象实例。 总结步骤应该是:确认OOM类型→获取dump文件→分析工具定位类→结合代码检查。这样用户能一步步排查。同时,相关的问题可以包括如何生成dump文件、常用分析工具推荐、内存泄漏常见原因等。</think>### 排查JVM OOM问题定位类的步骤 1. **确认OOM类型** - 根据报错信息区分内存溢出类型: - `OutOfMemoryError: Java heap space`:堆内存溢出,需检查对象实例分配[^3] - `OutOfMemoryError: Metaspace`:元空间溢出(类信息过多) - `OutOfMemoryError: unable to create new native thread`:线程数超限[^2] 2. **获取Heap Dump文件** - 启动JVM时添加参数自动生成Dump文件: ```bash -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/path/to/dump.hprof ``` - 通过工具手动生成(如`jmap -dump:format=b,file=dump.hprof <pid>`) 3. **分析Heap Dump** - **工具选择**: - **Eclipse MAT**:定位支配树(Dominator Tree),显示占用内存最大的对象 - **VisualVM**:查看堆内存中类的实例数量及占用空间[^1] - **关键操作**: - 查找`Retained Heap`(对象连带其引用的对象总内存)最高的类 - 检查`Shallow Heap`(对象自身内存)异常的类 - 关注重复创建的类实例(如大量相同类型对象未被回收) 4. **结合代码定位问题** - 若发现某个类实例数异常增长,检查代码中以下场景: - 静态集合未清理(如全局`Map`缓存) - 资源未关闭(如数据库连接、流对象) - 循环引用导致GC无法回收 --- ### 示例分析流程 假设Dump文件显示`com.example.User`类实例占用了80%堆内存: 1. 在MAT中通过`Dominator Tree`定位到`User`类的实例 2. 查看引用链(Path to GC Roots),发现被全局静态`List<User>`缓存持有 3. 检查代码中对该集合的写入逻辑,确认未正确清理过期数据 ---
评论 3
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值