强如 Disruptor 也发生内存溢出?

前言

OutOfMemoryError 问题相信很多朋友都遇到过,相对于常见的业务异常(数组越界、空指针等)来说这类问题是很难定位和解决的。

本文以最近碰到的一次线上内存溢出的定位、解决问题的方式展开;希望能对碰到类似问题的同学带来思路和帮助。

主要从表现-->排查-->定位-->解决 四个步骤来分析和解决问题。

表象

最近我们生产上的一个应用不断的爆出内存溢出,并且随着业务量的增长出现的频次越来越高。

该程序的业务逻辑非常简单,就是从 Kafka 中将数据消费下来然后批量的做持久化操作。

而现象则是随着 Kafka 的消息越多,出现的异常的频次就越快。由于当时还有其他工作所以只能让运维做重启,并且监控好堆内存以及 GC 情况。

重启大法虽好,可是依然不能根本解决问题。

排查

于是我们想根据运维之前收集到的内存数据、GC 日志尝试判断哪里出现问题。

结果发现老年代的内存使用就算是发生 GC 也一直居高不下,而且随着时间推移也越来越高。

结合 jstat 的日志发现就算是发生了 FGC 老年代也已经回收不了,内存已经到顶。

甚至有几台应用 FGC 达到了上百次,时间也高的可怕。

这说明应用的内存使用肯定是有问题的,有许多赖皮对象始终回收不掉。

定位

由于生产上的内存 dump 文件非常大,达到了几十G。也是由于我们的内存设置太大有关。

所以导致想使用 MAT 分析需要花费大量时间。

因此我们便想是否可以在本地复现,这样就要好定位的多。

为了尽快的复现问题,我将本地应用最大堆内存设置为 150M。

然后在消费 Kafka 那里 Mock 为一个 while 循环一直不断的生成数据。

同时当应用启动之后利用 VisualVM 连上应用实时监控内存、GC 的使用情况。

结果跑了 10 几分钟内存使用并没有什么问题。根据图中可以看出,每产生一次 GC 内存都能有效的回收,所以这样并没有复现问题。

没法复现问题就很难定位了。于是我们 review 代码,发现生产的逻辑和我们用 while 循环 Mock 数据还不太一样。

查看生产的日志发现每次从 Kafka 中取出的都是几百条数据,而我们 Mock 时每次只能产生一条

为了尽可能的模拟生产情况便在服务器上跑着一个生产者程序,一直源源不断的向 Kafka 中发送数据。

果然不出意外只跑了一分多钟内存就顶不住了,观察左图发现 GC 的频次非常高,但是内存的回收却是相形见拙。

同时后台也开始打印内存溢出了,这样便复现出问题。

解决

从目前的表现来看就是内存中有许多对象一直存在强引用关系导致得不到回收。

于是便想看看到底是什么对象占用了这么多的内存,利用 VisualVM 的 HeapDump 功能可以立即 dump 出当前应用的内存情况。

结果发现 com.lmax.disruptor.RingBuffer 类型的对象占用了将近 50% 的内存。

看到这个包自然就想到了 Disruptor 环形队列。

再次 review 代码发现:从 Kafka 里取出的 700 条数据是直接往 Disruptor 里丢的。

这里也就能说明为什么第一次模拟数据没复现问题了。

模拟的时候是一个对象放进队列里,而生产的情况是 700 条数据放进队列里。这个数据量是 700 倍的差距。

而 Disruptor 作为一个环形队列,再对象没有被覆盖之前是一直存在的。

我也做了一个实验,证明确实如此。

我设置队列大小为 8 ,从 0~9 往里面写 10 条数据,当写到 8 的时候就会把之前 0 的位置覆盖掉,后面的以此类推(类似于 HashMap 的取模定位)。

所以在生产上假设我们的队列大小是 1024,那么随着系统的运行最终肯定会导致 1024 个位置上装满了对象,而且每个位置是 700 个!

于是查看了生产上 Disruptor 的 RingBuffer 配置,结果是:1024*1024

这个数量级就非常吓人了。

为了验证是否是这个问题,我在本地将该值换为 2 ,一个最小值试试。

同样的 128M 内存,也是通过 Kafka 一直源源不断的取出数据。通过监控如下:

跑了 20 几分钟系统一切正常,每当一次 GC 都能回收大部分内存,最终呈现锯齿状。

这样问题就找到了,不过生产上这个值具体设置多少还得根据业务情况测试才能知道,但原有的 1024*1024 是绝对不能再使用了。

总结

虽然到了最后也就改了一行代码(还没改,直接修改配置),但这排查过程我觉得是有意义的。

也会让大部分觉得 JVM 这样的黑盒难以下手的同学有一个直观的感受。

同时也得感叹 Disruptor 东西虽好,也不能乱用哦!

相关演示代码查看:

https://github.com/crossoverJie/JCSprout/tree/master/src/main/java/com/crossoverjie/disruptor

你的点赞与转发是最大的支持。

原文地址:https://www.cnblogs.com/crossoverJie/p/9552119.html

时间: 2024-10-11 09:36:49

强如 Disruptor 也发生内存溢出?的相关文章

小编带你进入强如 Disruptor 也发生内存溢出?

前言OutOfMemoryError 问题相信很多朋友都遇到过,相对于常见的业务异常(数组越界.空指针等)来说这类问题是很难定位和解决的. 本文以最近碰到的一次线上内存溢出的定位.解决问题的方式展开:希望能对碰到类似问题的同学带来思路和帮助. 主要从表现-->排查-->定位-->解决 四个步骤来分析和解决问题. 表象最近我们生产上的一个应用不断的爆出内存溢出,并且随着业务量的增长出现的频次越来越高. 该程序的业务逻辑非常简单,就是从 Kafka 中将数据消费下来然后批量的做持久化操作.

如何写出让java虚拟机发生内存溢出异常OutOfMemoryError的代码

程序小白在写代码的过程中,经常会不经意间写出发生内存溢出异常的代码.很多时候这类异常如何产生的都傻傻弄不清楚,如果能故意写出让jvm发生内存溢出的代码,有时候看来也并非一件容易的事.最近通过学习<深入理解java虚拟机-JVM高级特性与最佳实践>这本书,终于初步了解了一下java虚拟机的内存模型.本文通过写出使jvm发生内存溢出异常的代码来对自己的学习结果进行总结,同时也提醒自己以后写代码时候不要再跳进这个坑啦. java的内存管理是由java虚拟机自动进行管理的,并不需要程序员过多的手动干预

JVM 发生内存溢出的 8 种原因、及解决办法

阅读本文大概需要 2.3 分钟. 出处:割肉机 cnblogs.com/williamjie/p/11164572.html Java 堆空间 GC 开销超过限制 请求的数组大小超过虚拟机限制 Perm gen 空间 Metaspace 无法新建本机线程 杀死进程或子进程 发生 stack_trace_with_native_method 1. Java 堆空间 发生频率:5颗星 造成原因 无法在 Java 堆中分配对象 吞吐量增加 应用程序无意中保存了对象引用,对象无法被 GC 回收 应用程序

性能分析 | JVM发生内存溢出的8种原因及解决办法

推荐阅读:史上最详细JVM与性能优化知识点综合整理 1.Java 堆空间 2.GC 开销超过限制 3.请求的数组大小超过虚拟机限制 4.Perm gen 空间 5.Metaspace 6.无法新建本机线程 7.杀死进程或子进程 8.发生 stack_trace_with_native_method 1. Java 堆空间 发生频率:5颗星 造成原因 无法在 Java 堆中分配对象 吞吐量增加 应用程序无意中保存了对象引用,对象无法被 GC 回收 应用程序过度使用 finalizer.finali

viewPager--viewpager时,发生内存溢出OOM问题

两个问题:1.如果图片达到500kb每张,你这个划屏会有顿卡:2.快速滑动有出现0.几秒的白屏.图片越大,顿卡越明显. 回复parcool:500kb的背景算大的了,如果是想做图片墙,viewpager不适合,可以使用开源的图片墙工具,内存+硬盘缓存 还有哦,你这个图片根本没有手动回收,依然会OOM! 今天在制作应用某个功能的引导页时,使用了ViewPager进行页面切换,每个页面就放了一个ImageView,使用背景图来进行展示,由于多图(11张)的原因,导致了OOM问题,这里总结一下. 代码

使用ViewPager时,发生内存溢出OOM问题

今天在制作应用某个功能的引导页时,使用了ViewPager进行页面切换,每个页面就放了一个ImageView,使用背景图来进行展示,由于多图(11张)的原因,导致了OOM问题,这里总结一下. 代码如下: public class GuideActivity extends Activity implements OnPageChangeListener{ private ViewPager viewPager; private GuideAdapter adapter; private Line

【转载】Android 内存溢出如何发生的。

且谈Android内存溢出 前言 关于android的内存溢出在创新文档库中也有不少,网络上也有很多这方面的资料.所以这遍文章不算是正真意义上的创新,仅仅只是对xxx源码中出现的一些android开发中容易犯错的代码习惯一次总结. 1.  Android的内存溢出是如何发生的 Android的虚拟机是基于寄存器的Dalvik,它的最大堆大小一般是16M,有的机器为24M.因此我们所能利用的内存空间是有限的.如果我们的内存占用超过了一定的水平就会出现OutOfMemory的错误. 原因主要有两个:

内存溢出和内存泄漏的区别,产生原因以及解决方案

1.1内存溢出:(Out Of Memory---OOM) 系统已经不能再分配出你所需要的空间,比如你需要100M的空间,系统只剩90M了,这就叫内存溢出 例子:一个盘子用尽各种方法只能装4个果子,你装了5个,结果掉倒地上不能吃了.这就是溢出.比方说栈,栈满时再做进栈必定产生空间溢出,叫上溢,栈空时再做退栈也产生空间溢出,称为下溢.就是分配的内存不足以放下数据项序列,称为内存溢出.说白了就是我承受不了那么多,那我就报错, 1.2内存泄漏:  (Memory Leak)---->强引用所指向的对象

JVM学习与问题总结——java内存区域与内存溢出异常

java虚拟机将内存分为哪些区域? 根据Java SE7版本的Java虚拟机规范,虚拟机管理的内存包括5个运行时数据区域: 程序计数器 虚拟机栈 本地方法栈 方法区 堆 运行时数据区各部分的作用? 程序计数器 一个线程所执行的字节码的行号指示器. 字节码解释器会通过改变计数器的值来选取下一条将要执行的指令,那么分支.循环.跳转.异常处理.线程恢复都需要依赖计数器来完成.而Java虚拟机当中的多线程是通过争取CPU时间片来切换线程执行任务,当一个线程重新获取CPU时间片的时候就需要恢复上一次任务执