结果发现 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 东西虽好，也不能乱用哦！