Java：高效的/精简的性能计数器，用于10秒平均值

Question

在我的当前项目中，我需要追踪多种计数器并展示一个“每秒操作”统计信息。为了得到一个相对稳定的数据视图，我希望基于过去10秒的数据来进行评估。

一种万无一失的方法是存储一个列表，针对每一次操作记录精确的时间戳。然后，在更新计数之前，移除所有超过10秒的历史记录，并最终计算剩余记录的数量。然而，考虑到某些计数器可能达到每秒25,000次操作的高频率，这种存储和比较大量时间戳来换取一个简单显示数字的方法并不理想。

因此，我设计了一个Integer[10]数组，通过(new Date().getTime() % 10)来决定增加哪个元素的计数，即直接利用当前时间戳对10取模来选择数组索引进行加1操作。每当这个模运算的结果溢出到下一个秒数时，我会先将该索引位置的值重置为0。

这里遇到的小问题（1）是：有些计数器并非每秒都有固定的操作次数，而可能是在每隔几秒内集中发生，比如每三秒内有2000次操作。这样，如果恰好在应该重置时没有操作发生，计数就会出现偏差。

接着，我考虑使用一个按秒触发的定时任务来确保即使某秒内没有操作也会执行重置，但这种方法并不能100%保证每次都在确切的1000毫秒后执行——CPU负载或内部时钟的不稳定性可能会导致偶尔错过一次重置时机。例如，如果某次循环耗时1004毫秒，从秒的尾部xx:xx:05.998直接跳到了下一次的起始xx:xx:07.002。

有没有什么办法能更可靠地“重置”计数数组的各个条目，同时又不会引入过多的额外开销呢？
（也许过分担心1000毫秒间隔的准确性本身就是多余的）

以下是一个简单的代码示例：

private int currentModulo = 0;
private int[] countModuloTen = new int[10];

public synchronized void recordOperation(){
    int newModulo = (new Date()).getTime() % 10000; // 改为10秒内的毫秒取余

    if (newModulo / 1000 != currentModulo) { // 检查是否进入新的秒
        // 如果跨越了秒界线，重置计数
        Arrays.fill(countModuloTen, 0);
        currentModulo = newModulo / 1000;
    }
    countModuloTen[currentModulo]++;
}

将重置操作迁移到定时任务来执行，导致了第二个问题，即在准确性方面的不足。

Asaph · Answer

目前，我找到了一个权宜之计：

我将定时任务的执行间隔设定为每500毫秒，而不是每1000毫秒。
任务本身会检查是否已经在“当前秒”内执行过。
因此，即便不幸遇到时间溢出的情况，它仍然能在第n秒执行一次，并在第n+1秒执行三次（其中有两次“跳过”重置，因为已经执行过了）。

实现方式类似于以下代码：

private int evaluationModifier = 0;
...
this.timerTask = new TimerTask() {
    @Override
    public void run() {
        int newEvaluationSecond = (new Date()).getSeconds() % 10;

        // 仅在发生时间溢出时执行重置。
        if (newEvaluationSecond != evaluationModifier) {
            evaluationModifier = newEvaluationSecond;
            
            // 评估所有10个条目，并重置“evaluationModifier”对应的索引
        }
    }
};

timer.schedule(timerTask, 500, 500);

但我仍在思考是否有更加优雅的解决方案。

这还不是最终方案，因为如果某次重置迭代（两次定时任务迭代）缩短至998毫秒，下一次调用实际上会延迟到约1500毫秒，这样一来就不是严格的“每秒”更新了。当然，我可以进一步缩短频率到约50毫秒来最小化偏移量。

编辑：确实，每50毫秒运行一次效果相当不错，但在资源优化方面感觉还是有点投机取巧。（对于10,000毫秒的周期来说，±50毫秒的偏移其实并不太重要）

Puppy · Answer

要跟踪各种计数器并显示“每秒操作”统计信息，可以采用以下策略简化问题处理流程：

使用`AtomicLong`

创建一个AtomicLong实例：用于存储操作的累计计数。确保此实例在类中声明为final，并在声明时直接初始化，以确保它在任何线程访问前已存在且不可变。

   public final AtomicLong operationCounter = new AtomicLong(0);

在每次操作执行时增加计数：调用incrementAndGet()方法递增计数器。

定时报告统计

定义一个报告任务：这个任务（实现Runnable接口）负责从AtomicLong获取当前值，并重置计数器为零。使用getAndSet(0)方法来原子地完成这一过程。
调度执行报告任务：利用ScheduledExecutorService来定期执行报告任务，例如每10秒一次。这样可以定时获取和展示操作频率。

时间追踪与精度

理解时间精度限制：标准Java运行环境下的时间精度受限于系统时钟和JVM的调度，因此报告的时间间隔可能不完全精确到10秒，尤其是在垃圾回收或系统过载时可能会有延迟。
精确时间记录：使用java.time.Instant.now()记录操作开始和结束的瞬间，以UTC时间表示，提供较高的时间分辨率。

计算并显示结果

计算操作频率：通过比较两个Instant对象计算经过的时间，使用Duration.between(start, end).toSeconds()得到秒数，然后除以操作计数得到每秒操作数。

示例代码摘要

以下是根据描述简化后的代码示例概要，展示了如何设置AtomicLong、定义一个报告任务并使用ScheduledExecutorService进行定时调度。

// 创建并初始化操作计数器
final AtomicLong operationCounter = new AtomicLong(0);

// 定义报告任务
Runnable reportingTask = () -> {
    long count = operationCounter.getAndSet(0); // 获取计数并重置
    Instant now = Instant.now(); // 当前时间
    Duration duration = Duration.between(lastReportTime, now); // 自上次报告以来的时间间隔
    System.out.printf("Operations per second: %d%n", count / duration.getSeconds());
    lastReportTime = now; // 更新最后报告时间
};

// 使用ScheduledExecutorService每10秒执行一次报告任务
ScheduledExecutorService scheduler = Executors.newSingleThreadScheduledExecutor();
scheduler.scheduleAtFixedRate(reportingTask, 0, 10, TimeUnit.SECONDS);

// 在业务代码中每次操作时增加计数
operationCounter.incrementAndGet();

执行输出一下结果

sumbitting operating task
sumbitting operating task
sumbitting operating task
running run method
running run method
running run method
report = 7 operations per second. Detail: OperationsCountReport[count=78, start=2024-01-07T00:02:23.628089Z, end=2024-01-07T00:02:33.635889Z]
report = 9 operations per second. Detail: OperationsCountReport[count=83, start=2024-01-07T00:02:33.635889Z, end=2024-01-07T00:02:43.633431Z]
report = 8 operations per second. Detail: OperationsCountReport[count=76, start=2024-01-07T00:02:43.633431Z, end=2024-01-07T00:02:53.630240Z]
report = 8 operations per second. Detail: OperationsCountReport[count=72, start=2024-01-07T00:02:53.630240Z, end=2024-01-07T00:03:03.629794Z]
report = 8 operations per second. Detail: OperationsCountReport[count=80, start=2024-01-07T00:03:03.629794Z, end=2024-01-07T00:03:13.632380Z]
report = 7 operations per second. Detail: OperationsCountReport[count=73, start=2024-01-07T00:03:13.632380Z, end=2024-01-07T00:03:23.643556Z]

Justin Ethier · Answer

我采纳了Basil Bourque的回答后，重新思考了这个问题，并成功创建了一个具有以下优势的可行版本：

不需要过于频繁的计时钟任务：一个通常100毫秒左右的评估（±自然偏差）就足够了，不会有任何重置零的问题。
不再需要（昂贵的）Date对象：每进行一次“计数”操作时不必创建。

我没有尝试保留过去10秒内每一秒的独立历史值，而是改为创建了10个变量，这些变量连续累积10秒，起始自1秒偏移位。

因此，每秒我都有一个代表过去10秒的计数，易于重置零和计算。

有一个长度为10的数组，使用AtomicIntegers避免并发问题。
计时器每秒运行。
前10秒，将创建一个新的整数，加入数组。
进来的触发器将递增所有非空的数组位置。
前10秒，由position 0 / secondsPassed评估。
第10秒后始终由position p / 10.0为所需平均。

代码（已去除了冗余部分）：

private AtomicLong persistentCount = new AtomicLong(0);
private AtomicInteger[] messages = {new AtomicInteger(0), null, null, null, null, null, null, null, null};
private AtomicLong[] bytes = {new AtomicLong(0), null, null, null, null, null, null, null, null, null };
private boolean bufferFilled=false;
private int bf = 0;
private int p = 1;
private Timer timer = new Timer();
private TimerTask timerTask;

private PerformanceUtils(){
    this.timerTask = new TimerTask() {
        @Override
        public void run() {
            double mps, bps;

            if (bf == 9){
                mps = messages[p].getAndSet(0) / 10.0;
                bps = bytes[p].getAndSet(0) / 10.0;

                p++;

                if (p == 10)
                    p=0;

            }else{
                mps = messages[0].get() / (p * 1.0);
                bps = bytes[0].get() / (p * 1.0);
            }

            if (bf < 9){
                messages[p] = new AtomicInteger(0);
                bytes[p] = new AtomicLong(0);

                p++;
                bf++;

                if (p == 10){
                    p=0;
                }
            }
            
            //显示值
        }
    };

    timer.schedule(timerTask, 100,1000);
}

public void notifyMessageReceived(long byteCount){
    for (int i=0; i<=bf; i++){
        messages[i].getAndAdd(1);
        bytes[i].getAndAdd(byteCount);
    }

    persistentCount.getAndAdd(1);
}

[478, null, null, null, null, null, null, null, null] => [478, 0, null, null, null, null, null] => 478.0 [105, 527, null, null, null, null, null, null] => [105, 527 0, null, null, null, null] => 50.5 [1628, 1150, 623, null, null, null, null] => 1628, 115, 623 0, null, null] => 542.666666666666 [1767, 1289, 762, 139, null, null] => 1767, 1289, 762, 139 0, null] => 41.7 [1782, 1304, 777, 154, 15, null] => 178, 1304, 777, 154 15 0, null] => 35.4 [1807, 1329, 802, 179, 40 25, null] => 1807, 1329, 802, 179, 40 2 0, null] => 30.1666666666667 [1842, 1364, 837, 214 75 60 35, null] => 1842, 1364, 837, 214 75 60 35 0, null] => 26.314285714285717 [1869, 139, 864, 241, 102 87 62, 27, null] => 189, 139, 864, 241,102 8 62 62 2, null] => 23.625 [1896, 1418, 891, 268, 129 148, 12, 54, 27, null] => 1896, 141, 891,268 129 14 18 12 5,2 2, null] => 21.666666666666667 [1930, 1452, 925, 302 163 148 12 18, 15 8 141, 34] => 1930, 1452, 925,302 163 148 12 18 15 18 14

通过调试来看，它如预期一样，在运行10秒后，高峰期和低谷值的变动不再导致计算速率发生巨大变化，就像按每秒评估那样。

举一些因为夜间的小数字为例：
最初10秒：数组的"锁定"位置"，评估"始终为0 / 时间">

   [478, null, null, null, null, null, null, null, null, null]
 => [478, 0, null, null, null, null, null, null, null, null] => 478.0
    [1005, 527, null, null, null, null, null, null, null, null]
 => [1005, 527, 0, null, null, null, null, null, null, null] => 502.5
    [1628, 1150, 623, null, null, null, null, null, null, null]
 => [1628, 1150, 623, 0, null, null, null, null, null, null] => 542.6666666666666
    [1767, 1289, 762, 139, null, null, null, null, null, null]
 => [1767, 1289, 762, 139, 0, null, null, null, null, null] => 441.75
    [1782, 1304, 777, 154, 15, null, null, null, null, null]
 => [1782, 1304, 777, 154, 15, 0, null, null, null, null] => 356.4
    [1807, 1329, 802, 179, 40, 25, null, null, null, null]
 =>  [1807, 1329, 802, 179, 40, 25, 0, null, null, null] => 301.1666666666667
    [1842, 1364, 837, 214, 75, 60, 35, null, null, null]
 => [1842, 1364, 837, 214, 75, 60, 35, 0, null, null] => 263.14285714285717
    [1869, 1391, 864, 241, 102, 87, 62, 27, null, null]
 => [1869, 1391, 864, 241, 102, 87, 62, 27, 0, null] => 233.625
    [1896, 1418, 891, 268, 129, 114, 89, 54, 27, null]
 => [1896, 1418, 891, 268, 129, 114, 89, 54, 27, 0] => 210.66666666666666
    [1930, 1452, 925, 302, 163, 148, 123, 88, 61, 34]
 =>[0, 1452, 925, 302, 163, 148, 123, 88, 61, 34] => 193.0

从第10秒开始，总是评估最老的条目（大约10秒，真是意外）然后重置为0。

    [48, 1500, 973, 350, 211, 196, 171, 136, 109, 82]
 => [48, 0, 973, 350, 211, 196, 171, 136, 109, 82] => 150.0
    [62, 14, 987, 364, 225, 210, 185, 150, 123, 96]
 => [62, 14, 0, 364, 225, 210, 185, 150, 123, 96] => 98.7
    [107, 59, 45, 409, 270, 255, 230, 195, 168, 141]
 => [107, 59, 45, 0, 270, 255, 230, 195, 168, 141] => 40.9
    [134, 86, 72, 27, 297, 282, 257, 222, 195, 168]
 =>[134, 86, 72, 27, 0, 282, 257, 222, 195, 168] => 29.7
    [157, 109, 95, 50, 23, 305, 280, 245, 218, 191]
 => [157, 109, 95, 50, 23, 0, 280, 245, 218, 191] => 30.5
    [188, 140, 126, 81, 54, 31, 311, 276, 249, 222]
 => [188, 140, 126, 81, 54, 31, 0, 276, 249, 222] => 31.1
    [233, 185, 171, 126, 99, 76, 45, 321, 294, 267]
 => [233, 185, 171, 126, 99, 76, 45, 0, 294, 267] => 32.1
    [258, 210, 196, 151, 124, 101, 70, 25, 319, 292]
 => [258, 210, 196, 151, 124, 101, 70, 25, 0, 292] => 31.9
    [295, 247, 233, 188, 161, 138, 107, 62, 37, 329]
 => [295, 247, 233, 188, 161, 138, 107, 62, 37, 0] => 32.9
···
从未想过从实时数据中获取一个浮点平均值（且内存占用极少）竟然需要如此大的努力。