摘要：结合的日志发现就算是发生了老年代也已经回收不了，内存已经到顶。定位由于生产上的内存文件非常大，达到了几十。也是由于我们的内存设置太大有关。同时后台也开始打印内存溢出了，这样便复现出问题。结果发现类型的对象占用了将近的内存。
前言
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.ucloud.cn/yun/76891.html
摘要：发现这是的一个堆栈，前段时间正好解决过一个由于队列引起的一次强如也发生内存溢出没想到又来一出。因此初步判断为大量线程执行函数之后互相竞争导致使用率增高，而通过对堆栈发现是和使用有关。 showImg(https://segmentfault.com/img/remote/1460000017395756?w=1816&h=1080); 前言 到了年底果然都不太平，最近又收到了运维报警：...
摘要：结合之前的线程快照，我发现这个消费线程也是处于状态，和后面的业务线程池一模一样。本地模拟本地也是创建了一个单线程的线程池，分别执行了两个任务。发现当任务中抛出一个没有捕获的异常时，线程池中的线程就会处于状态，同时所有的堆栈都和生产相符。 showImg(https://segmentfault.com/img/remote/1460000018482477); 背景 事情（事故）是这样...
摘要：我们知道是一个队列，生产者往队列里发布一项事件或称之为消息也可以时，消费者能获得通知如果没有事件时，消费者被堵塞，直到生产者发布了新的事件。实战本文先不具体去阐述的工作具体原理，只是简单地将与其整合。 什么是Disruptor 从功能上来看，Disruptor 是实现了队列的功能，而且是一个有界队列。那么它的应用场景自然就是生产者-消费者模型的应用场合了。可以拿 JDK 的 Block...
摘要：纯分享直接上干货操作系统并发支持进程管理内存管理文件系统系统进程间通信网络通信阻塞队列数组有界队列链表无界队列优先级有限无界队列延时无界队列同步队列队列内存模型线程通信机制内存共享消息传递内存模型顺序一致性指令重排序原则内存语义线程 纯分享 , 直接上干货! 操作系统并发支持 进程管理内存管...
阅读 1711·2021-11-22 12:09
阅读 1451·2019-08-30 13:22
阅读 2082·2019-08-29 17:00
阅读 2634·2019-08-29 16:28
阅读 2945·2019-08-26 13:51
阅读 1174·2019-08-26 13:25
阅读 3236·2019-08-26 12:14
阅读 3006·2019-08-26 12:14
