DD

@RobWin If we give up the pre-calculation approach, we can also implement it like this. https://github.com/dropwizard/metrics/blob/release/4.2.x/metrics-core/src/main/java/com/codahale/metrics/SlidingTimeWindowReservoir.java

> What do you mean by pre-calcation? @RobWin I mean TotalAggregation is updated everytime and SnapshotImpl just takes the current value. I call this a 'pre-calculation' approach. If we pass...

BTW, I found some code from dropwizard, and I’m wondering if we can draw inspiration from it to implement a lock-free Metrics. https://github.com/dropwizard/metrics/blob/release/4.2.x/metrics-core/src/main/java/com/codahale/metrics/LockFreeExponentiallyDecayingReservoir.java

changes since last review: 1. triggering liquidation via order: • liquidation is triggered by creating a reverse IOC order. • Introduce a new API endpoint: ApiLiquidationOrder. 2. decouple liquidation check...

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

NodeImpl.LogEntryAndClosure 属于短生命周期对象，其中的 LogEntry 持有实际日志数据 ByteBuffer（年轻代对象），done 为用户层回调（年轻代对象）； LogManagerImpl.StableClosureEvent 为复用的长生命周期对象（老年代），其内部持有 StableClosure，而 StableClosure 又包含 List（年轻代对象）。 这导致形成跨代引用链。 ### 实验方案 我们针对 JRaft 的日志提交路径，测试了以下三种优化策略： | **方案编号** | **优化思路** | **说明** | |:-------------:|:-------------|:----------| | **1️⃣** | 使用...