Disruptor中有new对象，导致分代zgc跨代引用压力

[dpy1123]

Your question

在使用分代 ZGC 时，发现 jraft 在高 QPS 场景下产生了大量 GC 跨代引用，导致 GC 扫描和吞吐量明显下降。

Your scenes

我们在disruptor的对象复用中，又new了新的对象，导致老对象持有新对象。

具体而言：

1. FSMCallerImpl中enqueueTask

2.ReadOnlyServiceImpl中new Bytes(reqCtx)

3.NodeImpl中new LogEntry()

4.LogManagerImpl中appendEntries

Your advice

我们是否有可能把translator中new对象的行为去掉，也搞成复用对象。

Environment

• SOFAJRaft version:1.3.15
• JVM version :corretto-24.0.2

[killme2008]

Good catch! 可以的，欢迎来贡献。

[dpy1123]

目前看3和4应该是每次都会走到的。
我的想法是在disruptor的范围内复用，出了disruptor的范围后，再创建对象供后面使用。
以new LogEntry为例，我应该在NodeImpl#apply那边复用对象，在executeApplyingTasks的时候再new一份，应该就不会影响后续使用吧。

[killme2008]

目前看3和4应该是每次都会走到的。 我的想法是在disruptor的范围内复用，出了disruptor的范围后，再创建对象供后面使用。 以new LogEntry为例，我应该在NodeImpl#apply那边复用对象，在executeApplyingTasks的时候再new一份，应该就不会影响后续使用吧。

可以的，其实就是将 LogEntry 纳入复用范围。

[dpy1123]

NodeImpl.LogEntryAndClosure 属于短生命周期对象，其中的 LogEntry 持有实际日志数据 ByteBuffer（年轻代对象），done 为用户层回调（年轻代对象）；
LogManagerImpl.StableClosureEvent 为复用的长生命周期对象（老年代），其内部持有 StableClosure，而 StableClosure 又包含 List（年轻代对象）。
这导致形成跨代引用链。

实验方案

我们针对 JRaft 的日志提交路径，测试了以下三种优化策略：

方案编号	优化思路	说明
1️⃣	使用 MpscArrayQueue 替换 Disruptor	减少对象跨代持有，控制消费者生命周期，消除部分老年代常驻对象
2️⃣	减小 raftOptions.disruptorBufferSize，并将 NodeImpl 的 Apply 模式改为 Blocking	缩短事件滞留时间，降低批次对象在老年代的停留概率
3️⃣	提交到 Disruptor 时仅保存 sequence，ByteBuffer / List<LogEntry> 通过外部 Map 管理	避免复用对象长期持有短期数据引用，出环后立即清理

---

实验结果（ZGC 单代对照）

配置	QPS（约）
baseline（未优化）	13.5 万
方案 1（MPSC Queue）	14.5 万
方案 2 / 3（优化 Disruptor 引用）	14.2 万
单代 ZGC（理论上限）	15 万

为了避免跨代引用：

1. 是否可以考虑引入轻量级队列（如 MpscArrayQueue）或短期事件包装？
2. 官方是否有推荐的对象生命周期管理策略，用于降低 Raft 日志通道的 GC 压力？

[linking12]

@killme2008 有考虑过去除disruptor吗？ 感觉如果是JDK分代zgc上性能是下降的；

[killme2008]

@linking12 引入考虑双模式了，加入一个 EvenBus 抽象，这里本质上就是因为 disruptor 的复用模型引起的，在任务处理很快的情况下，批量复用的模式没有太大优势了，尤其 zgc 下。