baseline    102.0 ns/op
candidate    98.5 ns/op

这两行最多说明“某两次测量得到两个数字”，还不能证明 candidate 真快了 3.5 ns。我们至少还需要知道：

• 测量的是冷启动、稳定态，还是某个随机的 JVM 生命周期位置？
• 样本来自多个独立 JVM，还是同一个 JVM 中高度相关的 Iteration？
• 差异来自代码，还是 JIT、GC、进程布局、机器漂移与测试顺序？
• 3.5 ns 即使真实存在，对实际系统是否有意义？

到了分布式流处理系统，问题又多一层：如果事件已经在系统外排队 30 秒，而指标只从 Source 接收到事件后开始计时，那么“P99 延迟 20 ms”可能完全正确，也完全没有用户价值。

本文只做三件事：

1. 精读三篇论文，讲清它们分别解决了什么问题、怎样解决、用什么证据论证，以及结论的边界；
2. 从源码层解释 JMH 怎样运行，再用四个具体场景讲清它的正确用法；
3. 总结我对“可信性能证据”的理解。

三篇论文不是三份互不相关的摘要，而是依次补上性能测试中的三个缺口：

贯穿全文的核心思想只有一句话：

可信 Benchmark 不是“多跑几次”，而是先定义测量对象，再找到独立实验单位，最后用与问题匹配的统计方法表达不确定性。

一、三篇论文精读：从“测得准”到“测得对”

1.1 2007：Java 性能不是一个常数

论文：Statistically Rigorous Java Performance Evaluation，Andy Georges、Dries Buytaert、Lieven Eeckhout，OOPSLA 2007。

它要解决什么问题

Java 程序的执行时间会被很多运行时因素影响：

• JIT 的采样与编译时机；
• 线程调度；
• GC 发生的时间与堆布局；
• 操作系统中断、缓存与其他机器状态。

因此，即使代码、参数和机器都不变，多次运行也会得到不同结果。论文真正质疑的不是“有噪声”这件事，而是当时大量研究处理噪声的方式没有统计含义。

作者调查了 50 篇 Java 性能论文：

• 16 篇没有说明实验方法；
• 10 篇报告最好值，8 篇报告平均值；
• 中位数与第二好值各有 4 篇，最差值有 3 篇；
• 只有 4 篇报告置信区间。

best of N 看似在排除机器噪声，实际回答的是“这 N 次中最幸运的一次有多快”。N 越大，遇到极端好运样本的机会越大，所以 best of 3 与 best of 30 甚至不是同一个估计目标。

假设两个实现的测量结果如下：

取最好值会宣布 B 获胜；但如果明天随机运行一次，A 更可能更快。最好值偏爱“容易偶尔走运”的实现，而不是典型情况下更快的实现。

它怎样解决

论文先把两个经常混在一起的问题拆开。

启动性能关注 JVM 启动、类加载、初始化、JIT 与任务执行的总成本。实验方法是：

1. 启动多个独立 JVM；
2. 每个 JVM 只执行一次任务；
3. 将每次 JVM invocation 视为一个观测；
4. 在这些观测上计算均值与置信区间。

稳定态性能关注长时间运行程序在初始化之后的执行能力。论文的方法是：

1. 启动多个独立 JVM；
2. 每个 JVM 执行多个 Iteration；
3. 在每个 JVM 内找到作者认为已经稳定的窗口，并计算该 JVM 的平均值；
4. 最后在多个 JVM 平均值之间计算总体均值与置信区间。

这里最关键的不是“预热多少次”，而是实验单位：

Fork 1: Iteration 1 ... Iteration k  ->  Fork 1 的稳定态均值 m1
Fork 2: Iteration 1 ... Iteration k  ->  Fork 2 的稳定态均值 m2
...
Fork n: Iteration 1 ... Iteration k  ->  Fork n 的稳定态均值 mn

最终在 m1, m2, ..., mn 上估计均值与不确定性

同一个 JVM 内的 Iteration 共享 JIT Profile、已编译代码、堆与 GC 历史，因此不能简单地把 5 个 Fork × 10 个 Iteration 宣称为 50 次彼此独立的 JVM 实验。

论文使用置信区间表达随机误差。一个常见的小样本均值区间可以简写为：

CI = x̄ ± t(0.975, n - 1) × s / √n

每个符号的含义是：

• CI：这里是 95% 置信区间；
• x̄：n 个独立实验单位的样本均值；
• s：这 n 个样本的样本标准差；
• n：独立实验单位的数量，在这里通常应理解为独立 JVM invocation 的数量，而不是方法调用次数；
• √n：样本数量 n 的平方根；
• t(0.975, n - 1)：自由度为 n - 1 的 t 分布 97.5% 分位点，用来形成双侧 95% 区间。

95% 置信区间的严格含义不是“真实均值有 95% 概率位于这个已经算出的区间内”，而是：如果按照同一规则反复做实验并构造区间，长期来看约 95% 的区间会覆盖真实均值。

它怎样论证

作者没有只做一个玩具算例，而是构造了较大的实验矩阵：

• 5 种 Jikes RVM 垃圾收集策略；
• 14 个 Benchmark，其中 7 个来自 SPECjvm98，7 个来自 DaCapo；
• 每个 Benchmark 从最小可运行堆开始，到 6 倍最小堆结束，以 0.25 倍为步长，共 21 个堆大小；
• 3 台不同硬件平台。

论文使用 30 个 JVM invocation 分析启动性能；稳定态实验则使用多个 JVM，并在每个 JVM 内执行多个 Iteration。作者把常见的 best、second best、mean、median、worst 方法与更严格的置信区间比较结论进行对照。

在这套特定实验中：

• 启动性能的常见简化方法，误导性结论最高达到约 16%；
• 某些方法给出相反优劣方向的错误结论超过 3%；
• 稳定态比较在最小关注差异为 1% 时，误导性结论超过 20%；
• 即使使用 Replay Compilation 控制一部分 JIT 随机性，误导也没有完全消失。

这些百分比不能脱离论文的 GC、堆、硬件与阈值设置外推；它们真正证明的是：错误的汇总方法并非只在理论上有风险，而是足以改变工程结论。

论文还发现，达到同一精度所需的样本数会随 Benchmark、GC 与堆大小显著变化。有的组合不到 10 次就得到很窄的区间，有的组合做满 30 次后区间仍然较宽。因此，“统一跑 5 次”或“达到 30 次就可靠”都没有理论依据。

这篇论文的核心结论

我认为它最重要的贡献不是某个统计公式，而是确立了四个基本原则：

1. 启动性能与稳定态性能是两个不同的问题；
2. JVM invocation 是 Java 性能评估中不可忽略的独立层级；
3. 最好值、最差值不能代表典型性能；
4. 性能结果必须同时报告估计值与不确定性。

它没有解决什么

论文用“最近一段 Iteration 的变异系数 CoV 低于阈值”寻找稳定窗口。CoV 是标准差除以均值，它只能说明最近的点挤得是否紧，不能证明：

• 序列没有缓慢上升或下降；
• 相邻 Iteration 彼此独立；
• 不存在奇偶交替或周期；
• 后面不会发生 Deoptimization 或状态切换。

换句话说，低波动不等于稳态。这正是第二篇论文要修正的地方。

1.2 2013：严谨不等于把每一层都机械地跑很多次

论文：Rigorous Benchmarking in Reasonable Time，Tomas Kalibera、Richard Jones，ISMM 2013（可访问全文）。

它要解决什么问题

2007 年论文告诉我们要运行多个 JVM、多个 Iteration，并报告区间。但新的现实问题是：如果 Build、JVM Execution、Iteration 都重复很多次，实验成本会迅速爆炸。

作者调查了 2011 年 PLDI、ASPLOS、ISMM、TOPLAS 与 TACO 的 122 篇论文：

• 90 篇测量了执行时间；
• 其中 71 篇没有报告任何变异信息；
• 65 篇报告了执行时间比值；
• 只有 3 篇尝试为比值给出置信区间。

论文认为，研究者不是不知道应该严谨，而是不知道：

• 哪一层必须重复；
• 每层重复多少次；
• 多花一分钟应该增加 Build、Execution，还是 Iteration；
• 怎样直接表达“新版本究竟快了多少”。

它怎样解决

第一步是区分三类变量：

统计方法可以描述随机误差，却无法自动修复系统偏差。如果 baseline 总在机器冷的时候跑、candidate 总在机器热的时候跑，再漂亮的置信区间也只是在精确描述一个有偏实验。

第二步是把实验看成嵌套层级：

Build 1
  ├─ JVM Execution 1
  │    ├─ Iteration 1
  │    └─ Iteration 2
  └─ JVM Execution 2
       ├─ Iteration 1
       └─ Iteration 2

Build 2
  └─ ...

如果只考虑 Fork 与 Iteration 两层，总体均值方差可以用下面的简化模型理解：

Var(x̄) ≈ σ²fork / F + σ²iter / (F × I)

符号含义如下：

• Var(x̄)：最终均值估计的不确定性；
• σ²fork：不同 Fork 之间的方差分量；
• σ²iter：同一 Fork 内不同 Iteration 的方差分量；
• F：Fork 数量；
• I：每个 Fork 中参与测量的 Iteration 数量。

这个式子揭示了一个非常实际的结论：

增加 Iteration 只能缩小第二项，无法消除 Fork 之间的差异。

如果主要噪声来自不同 JVM 进程，那么把每个 Fork 的 Iteration 从 5 增加到 50，收益可能很小；增加独立 Fork 才真正压缩主要不确定性。如果重新 Build 也会改变代码布局与性能，那么还需要在更高层加入 Build 方差，并重复 Build。

论文因此提出“定标实验”：

1. 第一次为某个 Benchmark、VM 与平台组合做较充分的嵌套重复；
2. 估计每一层贡献的方差；
3. 测量每一层重复的时间成本，例如启动 JVM、完成预热、重新构建；
4. 在给定总时间预算下，把重复分配到“方差贡献大且单位成本合理”的层级；
5. 只有当 Benchmark、VM 或平台明显变化时，才重新定标。

第三步是修正“低 CoV 等于稳态”。作者区分：

• Initialized state：明显的初始化阶段已经结束；
• Independent state：后续 Iteration 不仅看似平稳，而且没有明显自相关。

他们结合 Run-sequence Plot、Lag Plot 与自相关函数 ACF 检查序列，而不是只看最近窗口的波动大小。

它怎样论证

作者对 DaCapo 的多种 Benchmark、JVM 与平台组合执行最多 300 个 Iteration，并比较手工诊断、DaCapo Harness 启发式和 2007 年 CoV 方法。

下面是论文 Table 3 中 Platform P1 的三个典型例子：

三行数据分别说明：

• avrora9 中，CoV 方法在初始化完成之前就宣布稳定；
• lusearch9 第 5 轮已经达到论文判定的独立态，CoV 方法却预热到第 247 轮；
• xalan6 第 2 轮已经独立，CoV 方法反而无法收敛。

因此，固定 Warmup(iterations = 5) 只是配置，不是“已经进入稳定态”的证据；同样，无限增加 Warmup 也未必能得到独立样本。

论文还给出一个很重要、但经常被忽略的退路：如果 Benchmark 在合理时间内无法达到独立态，就不要让在线启发式在每次运行中随意挑不同窗口，而应在所有运行中选择同一个、已经完成初始化的生命周期位置。它测量的可能不是理想“峰值稳态”，但至少比较对象一致。

第四步是直接报告效应量区间。只说 p < 0.05 只能说明数据不太支持“完全无差异”，不能回答差异是否重要。对于执行时间，更有用的表达是：

candidate / baseline = 0.94，95% CI [0.92, 0.97]

这是一个教学示例，不是论文的实测数据。它表达的是：candidate 的执行时间估计为 baseline 的 94%，区间为 92% 到 97%；也就是性能改善大约在 3% 到 8% 之间。差异的方向、幅度和不确定性一次说清楚了。

这篇论文的核心结论

第二篇论文把“多跑几次”推进成了“在哪一层多跑几次”：

1. 先控制或随机化系统偏差；
2. 找到真正引入随机性的最高层；
3. 用定标实验估计各层方差与成本；
4. 把重复预算花在主要不确定性上；
5. 报告性能变化的幅度与区间，而不只报告显著性。

它没有解决什么

这套方法不是一组可以从论文直接复制的固定次数。作者明确强调：重复次数依赖 Benchmark、VM 与平台，论文表格中的数字不能原样套用到另一台机器。

它还需要几个前提：

• 分层结构和方差模型与实际实验大致匹配；
• 定标之后，各层成本与方差没有发生根本变化；
• 实验者愿意查看时间序列并判断初始化与独立性；
• 测量指标本身已经定义正确。

最后一个前提非常关键。统计方法能告诉我们一个指标估计得有多准，却不能告诉我们这个指标是否代表用户真正关心的问题。第三篇论文就从这里开始。

1.3 2018：流系统的“最大输入速度”不等于可持续吞吐

论文：Benchmarking Distributed Stream Data Processing Systems，Jeyhun Karimov 等，ICDE 2018。

它要解决什么问题

当时不少流处理 Benchmark 存在三类测量边界错误。

第一，Kafka、Redis 等外部组件可能先成为瓶颈，最后测到的是整套部署中最慢的外部组件，而不是流处理引擎。

第二，Driver 与 SUT（System Under Test）混在一起。不同系统使用自己的内部指标，延迟起点、吞吐口径和结果数量都不一致，横向比较失去共同尺度。

第三，只测 Processing-time Latency。事件在 Source 之前的等待时间被排除后，背压越严重，SUT 反而可能摄入得越慢、内部处理延迟越稳定；外部队列却在持续增长。

这就是 Coordinated Omission：测量节奏跟着被测系统变慢，恰好漏掉系统无法及时服务的那部分等待。

它怎样解决

论文把 Driver 与 SUT 完全分离：

具体做法包括：

• Driver 在独立机器上按固定速率生成数据，不等待上一条处理完成；
• 每条事件在生成时记录 Event Time；
• Driver 与 SUT Source 之间放置内存队列，吸收瞬时摄入波动并暴露 backlog；
• 吞吐从 Driver/队列侧测量，延迟在输出侧根据原始时间戳计算；
• Driver 不与 SUT 共用机器，避免生成负载抢占被测系统资源。

这里需要区分两个延迟：

Event-time latency      = 输出时间 - 事件生成时间
Processing-time latency = 输出时间 - SUT 摄入时间

前者包含 SUT 外部排队，更接近事件从产生到获得结果的等待；后者只描述事件进入 SUT 之后的处理时间。两者都有诊断价值，但不能互相替代。

窗口算子的输出由多条输入共同产生，不能随便选择一条输入的时间戳。论文定义：

窗口输出的 event time = 所有贡献输入中最大的 event time
窗口输出延迟 = 输出时间 - 窗口输出的 event time

其中：

• “贡献输入”是实际参与该聚合或 Join 输出的输入事件；
• “最大的 event time”代表最后一个必要输入到达的逻辑时间；
• “输出时间”是 SUT 产生结果的时刻。

例如一个聚合结果由 event time 为 580、590、600 的三条输入构成，并在 610 输出，那么论文口径下的窗口输出延迟是 610 - 600 = 10。这样不会把窗口本身等待数据凑齐的完整跨度全部算成引擎处理延迟。

这个定义也有明确语义边界：它衡量“最后一个必要事件之后多久产出窗口结果”，不是每一条早到事件的等待时间。如果业务关心第一条事件进入窗口后等待了多久，还需要另加指标。

论文进一步定义 Sustainable Throughput：

系统能够长期处理、且不会出现持续背压或 Event-time Latency 持续增长的最高输入速率。

寻找方法不是让 Source 无限制拉取并记录瞬时峰值，而是：

1. 先给出明显高于系统能力的固定生成速率；
2. 观察队列长度和 Event-time Latency 是否持续增长；
3. 逐步降低生成速率；
4. 找到系统可以长期维持、backlog 不再单调增长的最高速率。

它怎样论证

作者使用游戏业务启发的窗口聚合和窗口 Join，评估当时版本的 Storm 1.0.2、Spark 2.0.1 与 Flink 1.1.3，并改变：

• 集群节点数；
• 窗口大小与滑动步长；
• 数据倾斜；
• 输入速率波动；
• 聚合与 Join 工作负载。

最有说服力的证据不是三个系统的历史排行榜，而是过载实验中的指标分裂：

• SUT 启动背压后，摄入速率下降；
• Processing-time Latency 可以保持相对稳定；
• 但事件继续堆积在外部队列中，Event-time Latency 持续上升。

如果只看 SUT 内部处理时间，会误判系统仍然健康；外部时间戳和 backlog 才揭示真实的容量不足。论文也展示了不同系统在数据倾斜、突发流量、窗口聚合和窗口 Join 下呈现不同瓶颈，说明单一的“每秒多少条”无法概括流系统性能。

这篇论文的核心结论

第三篇论文把问题从“数字是否稳定”推进到“数字是否测对了东西”：

1. Driver 必须独立于 SUT，且不能随 SUT 变慢而同步降速；
2. 延迟起点应尽可能接近事件产生，而不是方便测量的 Source 内部；
3. 吞吐必须与 backlog、Event-time Latency 一起解释；
4. 最大瞬时摄入速率不等于可长期维持的处理能力；
5. 窗口、Join、倾斜与突发流量必须作为独立工作负载。

它没有解决什么

首先，论文为了隔离引擎能力，主动移除了 Kafka、Redis 等外部系统。因此它回答的是“引擎在特定 Driver 下的能力”，不是完整生产链路的端到端容量。若性能声明包含消息队列和 Sink，它们就必须重新进入 SUT 边界。

其次，论文作者把以下问题留作后续工作：

• Exactly-once 的性能代价；
• Out-of-order 与 Late Event；
• 故障、恢复与状态一致性；
• 更丰富的并发查询组合。

最后，这是 2018 年特定版本与特定硬件上的结果，不能用来给今天的产品排名。我的进一步判断是：它对跨独立集群运行的不确定性讨论也弱于前两篇论文。因此，现代流系统 Benchmark 应把 2007/2013 年的独立重复、分层方差和效应量区间重新加到 2018 年的正确测量边界之上。

1.4 三篇论文真正连起来的主线

三篇论文分别强调统计、实验预算和系统语义，但最终可以收敛成四个连续问题：

第一篇论文解决了第 2、4 个问题的基础；第二篇把第 2、3、4 个问题做成有限预算下的方法；第三篇则提醒我们，第 1 个问题一旦错了，后面的严谨统计没有意义。

二、JMH 怎样实现，以及四个典型使用场景

JMH 是 OpenJDK 提供的 JVM Benchmark Harness。它最擅长测量单 JVM 内的 nano、micro、milli 级代码路径，也可以承载较大的方法级测试。

它能帮助解决：

• 方法调用循环与计时；
• JVM Fork、Warmup、Measurement；
• 多线程协同与 State 生命周期；
• 死代码消除、返回值消费；
• 参数组合与结果输出。

它不能自动解决：

• 被测代码是否代表真实业务；
• Warmup 是否真的达到稳定且独立的状态；
• 多个 Iteration 是否可以当作独立实验；
• baseline 与 candidate 是否受到机器漂移和执行顺序影响；
• 微基准改善能否转化成端到端吞吐或延迟改善。

因此，JMH 是严谨实验的执行工具，不是结论生成器。

2.1 JMH 不是用反射调用一次方法，而是生成专用 Harness

JMH 的关键实现位于官方仓库的几个部分：

• jmh-generator-annprocess 中的 BenchmarkProcessor 是注解处理器；
• BenchmarkGenerator 根据 @Benchmark、@State、@Setup 等生成测试代码；
• Runner 解析配置并启动 Fork；
• ForkedMain 是被 Fork JVM 的入口；
• ThroughputResult、AverageTimeResult 等将操作数和时间转换成 Score。

整体流程如下：

生成代码的核心逻辑可以简化为：

while (control.warmupShouldWait) {
    benchmark(state);
}

long start = System.nanoTime();
long operations = 0;
do {
    blackhole.consume(benchmark(state));
    operations++;
} while (!control.isDone);
long elapsed = System.nanoTime() - start;

真实生成代码还会处理：

• 多线程开始与结束屏障；
• @Setup、@TearDown 的 Trial、Iteration、Invocation 生命周期；
• @OperationsPerInvocation 与 Batch Size；
• 异常传播；
• AuxCounters；
• 不同 Benchmark Mode 的专用循环。

这种编译期生成有两个价值。

第一，测试方法位于紧凑循环内，不需要每次通过反射调用。第二，JMH 可以根据声明提前生成 State 获取、返回值消费和生命周期代码，并在编译期发现一部分非法组合。

如果 @Benchmark 返回非 void 值，生成代码会把返回值交给 Blackhole.consume(...)。所以最简单的防止死代码消除方式通常不是在业务代码里手写 Blackhole，而是直接返回计算结果。

2.2 Fork、Warmup、Measurement 分别代表什么

一次典型 JMH 运行可以这样理解：

一个 Benchmark 参数组合
  ├─ Fork 1：全新的 JVM
  │    ├─ Warmup Iteration 1..W
  │    └─ Measurement Iteration 1..M
  ├─ Fork 2：全新的 JVM
  │    ├─ Warmup Iteration 1..W
  │    └─ Measurement Iteration 1..M
  └─ Fork F：...

• Fork：新的 JVM 进程，拥有新的 JIT Profile、堆、地址空间和运行时历史；
• Warmup Iteration：执行负载但不进入最终 Score，用于把 JVM 推到目标生命周期位置；
• Measurement Iteration：在固定时间窗口内反复调用 Benchmark 方法并形成一个 Iteration Score；
• Invocation：Benchmark 方法的一次调用，通常数量极大，但不是独立 JVM 实验。

JMH 的四种常用 Mode 回答不同问题：

Throughput 与 AverageTime 的核心换算非常简单：

Throughput  = N / T
AverageTime = T / N

其中：

• N 是 Measurement 时间内完成的操作数；
• T 是 Measurement 的有效计时时间；
• 多线程 Throughput 会先聚合线程结果；
• @OperationsPerInvocation 会改变一次 Benchmark invocation 代表的逻辑操作数。

不要只因为 ns/op 看起来直观，就默认选择 AverageTime；Mode 必须服从问题。如果想知道 8 个线程争用一个计数器时每秒能完成多少次更新，Throughput 更自然。如果想测一次冷初始化，应该考虑 SingleShotTime、关闭 Warmup，并增加独立 Fork。

2.3 建立项目、运行与读懂输出

JMH 官方推荐使用独立 Maven Benchmark 模块，而不是像 JUnit 一样只添加一个依赖后直接从 IDE 运行。下面使用当前稳定版 1.37 创建项目：

mvn archetype:generate \
  -DinteractiveMode=false \
  -DarchetypeGroupId=org.openjdk.jmh \
  -DarchetypeArtifactId=jmh-java-benchmark-archetype \
  -DarchetypeVersion=1.37 \
  -DgroupId=org.example \
  -DartifactId=benchmark \
  -Dversion=1.0

cd benchmark
mvn clean verify
java -jar target/benchmarks.jar -l

一个适合首次定标的命令是：

java -jar target/benchmarks.jar '.*HashBenchmark.*' \
  -f 5 \
  -wi 5 -w 1s \
  -i 10 -r 1s \
  -rf json \
  -rff target/jmh-result.json

参数含义如下：

这些数字只是第一次观察时间序列和方差的起点，不是三篇论文推导出的通用最优值。正式比较前，应根据 Benchmark、JDK、机器与目标精度调整。

典型输出类似：

Benchmark          Mode  Cnt   Score   Error  Units
HashBenchmark.mix  avgt   50  37.210 ± 0.880  ns/op

这是一行教学输出，不是本文实测结论：

• Mode=avgt 表示 AverageTime；
• Cnt=50 通常来自 5 Fork × 10 Measurement Iteration，不是只调用了 50 次；
• Score=37.210 ns/op 是聚合后的平均操作时间；
• Error=0.880 是 JMH 展示的 99.9% 均值误差范围；
• JMH 的扩展输出会明确写出该区间假设正态分布。

这里必须保持克制：JMH 展示的 Score ± Error 不是 baseline 与 candidate 的效应量区间，也不会证明 50 个 Iteration 全部独立。做版本回归判断时，应保存 JSON 原始结果，查看每个 Fork 的分布，并计算 candidate/baseline 的变化幅度与区间。

2.4 场景一：纯计算——防止死代码消除与常量折叠

下面测量一个整数混合函数：

package org.example;

import java.util.concurrent.TimeUnit;
import org.openjdk.jmh.annotations.Benchmark;
import org.openjdk.jmh.annotations.BenchmarkMode;
import org.openjdk.jmh.annotations.Mode;
import org.openjdk.jmh.annotations.OutputTimeUnit;
import org.openjdk.jmh.annotations.Param;
import org.openjdk.jmh.annotations.Scope;
import org.openjdk.jmh.annotations.State;

@State(Scope.Thread)
@BenchmarkMode(Mode.AverageTime)
@OutputTimeUnit(TimeUnit.NANOSECONDS)
public class HashBenchmark {

    @Param({"7", "42"})
    public int seed;

    @Param({"64", "1024"})
    public int rounds;

    @Benchmark
    public int mix() {
        int value = seed;
        for (int i = 0; i < rounds; i++) {
            value = Integer.rotateLeft(value * 31 + i, 5);
        }
        return value;
    }
}

这里有三个关键点：

1. seed 和 rounds 来自非 final 的 State 字段，避免把整个输入写成编译期常量；
2. 方法返回结果，JMH 生成代码会消费它，降低整个计算被当作无用代码删除的风险；
3. Scope.Thread 让每个线程拥有自己的 State，避免无意中测到共享字段争用。

下面这种写法是危险的：

@Benchmark
public void wrong() {
    mixConstant(42, 1024);
}

输入固定、结果又没有被使用，JIT 可能进行常量折叠或死代码消除。最后测到的可能只是空 Harness 的成本。

这个场景适合纯算法、编码、哈希、序列化内部函数等 CPU 热路径。但如果生产输入有不同长度、字符集或分支分布，就必须用 @Param 或预生成数据覆盖这些形态，不能只测最容易优化的一种输入。

2.5 场景二：数据结构——用 State 与生命周期隔离准备成本

下面比较有序数组上的线性查找与二分查找：

package org.example;

import java.util.Arrays;
import java.util.concurrent.TimeUnit;
import org.openjdk.jmh.annotations.Benchmark;
import org.openjdk.jmh.annotations.BenchmarkMode;
import org.openjdk.jmh.annotations.Level;
import org.openjdk.jmh.annotations.Mode;
import org.openjdk.jmh.annotations.OutputTimeUnit;
import org.openjdk.jmh.annotations.Param;
import org.openjdk.jmh.annotations.Scope;
import org.openjdk.jmh.annotations.Setup;
import org.openjdk.jmh.annotations.State;

@State(Scope.Thread)
@BenchmarkMode(Mode.AverageTime)
@OutputTimeUnit(TimeUnit.NANOSECONDS)
public class LookupBenchmark {

    @Param({"16", "1024", "65536"})
    public int size;

    private int[] values;
    private int key;

    @Setup(Level.Trial)
    public void prepareDataset() {
        values = new int[size];
        for (int i = 0; i < size; i++) {
            values[i] = i * 2;
        }
        key = values[size - 1];
    }

    @Benchmark
    public int linearSearch() {
        for (int i = 0; i < values.length; i++) {
            if (values[i] == key) {
                return i;
            }
        }
        return -1;
    }

    @Benchmark
    public int binarySearch() {
        return Arrays.binarySearch(values, key);
    }
}

@Setup(Level.Trial) 在一个 Benchmark Trial 开始时准备一次数组，数组构造不进入查询的计时结果。这样测到的是“已有数据结构上的查找成本”。

如果真正的问题是“构造并查询一次需要多久”，那就应该另写一个 Benchmark，把构造放进 @Benchmark。不要为了得到更小的数字，把生产路径必需的工作偷偷移到 Setup。

三个常见生命周期分别是：

Level.Invocation 的 Setup 时间可以从有效计时中扣除，但它仍会改变缓存、分支预测和对象状态，而且每次调用都有 Harness 成本。除非被测语义确实要求逐次重置，否则优先批量准备输入或使用多个预生成样本。

2.6 场景三：并发争用——Scope 选错，测量问题就变了

下面比较共享 AtomicLong 与 LongAdder 的更新吞吐：

package org.example;

import java.util.concurrent.TimeUnit;
import java.util.concurrent.atomic.AtomicLong;
import java.util.concurrent.atomic.LongAdder;
import org.openjdk.jmh.annotations.Benchmark;
import org.openjdk.jmh.annotations.BenchmarkMode;
import org.openjdk.jmh.annotations.Mode;
import org.openjdk.jmh.annotations.OutputTimeUnit;
import org.openjdk.jmh.annotations.Scope;
import org.openjdk.jmh.annotations.State;

@State(Scope.Benchmark)
@BenchmarkMode(Mode.Throughput)
@OutputTimeUnit(TimeUnit.SECONDS)
public class ContendedCounterBenchmark {

    private final AtomicLong atomic = new AtomicLong();
    private final LongAdder adder = new LongAdder();

    @Benchmark
    public void atomicIncrement() {
        atomic.incrementAndGet();
    }

    @Benchmark
    public void adderIncrement() {
        adder.increment();
    }
}

分别运行单线程与多线程：

java -jar target/benchmarks.jar ContendedCounterBenchmark -t 1 -f 5
java -jar target/benchmarks.jar ContendedCounterBenchmark -t 8 -f 5

Scope.Benchmark 使同一个 Trial 中的所有工作线程共享一个 State，因此多线程运行确实会争用同一计数器。如果改成 Scope.Thread，8 个线程会更新 8 份独立 State，测到的是并行独享吞吐，而不是共享争用。

这个例子还有一个比性能更重要的语义提醒：

• AtomicLong.incrementAndGet() 可以为每次更新提供一个线性化后的返回值；
• LongAdder 通过分散竞争提高高并发更新能力，但读取总和不是同一种强一致语义。

因此，不能根据 LongAdder 的 ops/s 更高就宣布它“全面替代” AtomicLong。Benchmark 只有在候选实现满足同一业务契约时，才有比较意义。

2.7 场景四：快慢路径——用 AuxCounters 解释主 Score

平均吞吐可能掩盖输入分布变化。下面让 0%、1% 或 10% 的输入触发异常解析路径，并用 AuxCounters 同时报告成功与失败速率：

package org.example;

import java.util.concurrent.TimeUnit;
import org.openjdk.jmh.annotations.AuxCounters;
import org.openjdk.jmh.annotations.Benchmark;
import org.openjdk.jmh.annotations.BenchmarkMode;
import org.openjdk.jmh.annotations.Level;
import org.openjdk.jmh.annotations.Mode;
import org.openjdk.jmh.annotations.OutputTimeUnit;
import org.openjdk.jmh.annotations.Param;
import org.openjdk.jmh.annotations.Scope;
import org.openjdk.jmh.annotations.Setup;
import org.openjdk.jmh.annotations.State;

@BenchmarkMode(Mode.Throughput)
@OutputTimeUnit(TimeUnit.SECONDS)
public class ParserBenchmark {

    @State(Scope.Thread)
    public static class Inputs {

        @Param({"0", "1", "10"})
        public int invalidPercent;

        private String[] values;
        private int cursor;

        @Setup(Level.Trial)
        public void prepare() {
            values = new String[1024];
            for (int i = 0; i < values.length; i++) {
                values[i] = i % 100 < invalidPercent
                        ? "invalid"
                        : Integer.toString(i);
            }
        }

        public String next() {
            return values[cursor++ & (values.length - 1)];
        }
    }

    @State(Scope.Thread)
    @AuxCounters(AuxCounters.Type.OPERATIONS)
    public static class Outcomes {
        public long valid;
        public long invalid;
    }

    @Benchmark
    public int parse(Inputs inputs, Outcomes outcomes) {
        try {
            int value = Integer.parseInt(inputs.next());
            outcomes.valid++;
            return value;
        } catch (NumberFormatException e) {
            outcomes.invalid++;
            return -1;
        }
    }
}

运行后，除了主 Benchmark 的总吞吐，还会看到 valid 与 invalid 两个 Secondary Result。这样可以回答：

• 总吞吐下降是不是因为失败比例提高；
• 慢路径究竟占多少操作；
• 两个版本是否处理了相同输入分布。

@AuxCounters 的边界必须讲清楚：

• 它只能标注 Scope.Thread 的 State；
• 只有 public 数值字段或返回数值的 public 方法会成为指标；
• public 字段会在每个 Iteration 开始前重置，并在结束时读取；
• Type.OPERATIONS 会按时间归一化，适合成功/失败吞吐；
• Type.EVENTS 报告未按时间归一化的事件总数；
• 它是实验性 API，适合解释分支构成，不应代替主性能指标与正确性断言。

2.8 怎样从 JMH 输出得到版本结论

假设 AverageTime 模式下定义：

R = candidate time / baseline time

其中：

• R < 1 表示 candidate 更快；
• R > 1 表示 candidate 更慢；
• R = 1 表示两者平均时间相同。

正式比较至少应做到：

1. 使用相同硬件、JDK、JVM 参数和 Benchmark 参数；
2. 运行多个 Fork，保留每个 Fork/Iteration 的 JSON 结果；
3. 交替或随机化 baseline 与 candidate 的执行顺序，避免时间漂移总偏向一方；
4. 报告 R 的区间，而不是只比较两行 Score；
5. 预先定义工程阈值，例如小于 1% 的变化不做优化结论；
6. 同时检查正确性、分配率、GC 与其他可能被转移的成本。

以“1% 是最小关注变化”为例：

如果使用 Throughput，方向要反过来定义，或者改为 baseline throughput / candidate throughput，让“小于 1 表示改善”的语义保持一致。无论怎样定义，都必须在报告中写清分子、分母和“越大越好还是越小越好”。

JMH 的 profiler 可以帮助解释结果：

java -jar target/benchmarks.jar LookupBenchmark -prof gc

例如一个实现 ns/op 下降，却显著增加 gc.alloc.rate.norm，它可能只是把 CPU 成本换成了分配和 GC 成本。Profiler 是归因线索，不是自动因果证明；发现异常后仍需要结合代码、汇编、硬件计数器或更高层测试验证。

三、总结与感悟

读完三篇论文再回看 JMH，我最大的感受是：性能测试的难点从来不是让程序多执行几遍，而是知道每一个数字究竟代表什么。

第一篇论文最重要的提醒是，不要把偶然的最好值当作能力，也不要把同一 JVM 中的大量调用当作大量独立证据。Java 的动态运行时决定了 Fork 层级不可忽略。

第二篇论文进一步说明，严谨并不等于无限增加运行时间。真正有效的方法是先找出方差来自 Build、Fork 还是 Iteration，再把重复预算花到正确层级。跑得更多不一定知道得更多；在错误层级重复，只会更精确地低估不确定性。

第三篇论文把视线从统计拉回系统语义。一个指标可以测得非常稳定，却从错误的时间点开始计时。流处理系统尤其如此：如果没有固定到达率、外部时间戳、backlog 与 Event-time Latency，背压完全可能把容量不足伪装成低延迟。

JMH 的价值，是把 JVM 内部微基准中最容易犯的一批 Harness 错误标准化处理：生成专用循环、启动 Fork、组织 Warmup 与 Measurement、管理 State、消费返回值、输出机器可读结果。但它无法替我们决定测量边界，也不会自动证明 Warmup 已经稳定，更不会把一个 5 ns 的方法级改善自动转换成系统吞吐提升。

因此，我现在更愿意用下面这句话定义一份好的 Benchmark：

它不是给出一个漂亮数字，而是让别人能够明确知道这个数字在什么条件下成立、误差有多大、什么证据可以推翻它。

真正开始写 Benchmark 之前，可以先写出性能声明：

在固定的硬件、JDK、参数和输入分布下，
candidate 相对 baseline 改善哪一个指标，
改善幅度至少是多少，
并且没有破坏哪一种正确性与资源约束。

如果这句话写不清楚，代码暂时也不用急着写。因为 Benchmark 的顺序应该是：

先定义问题 → 再设计实验 → 然后运行工具 → 最后解释证据

而不是先得到一个数字，再回头为它寻找故事。

参考资料

1. Andy Georges, Dries Buytaert, Lieven Eeckhout, Statistically Rigorous Java Performance Evaluation, OOPSLA 2007.
2. Tomas Kalibera, Richard Jones, Rigorous Benchmarking in Reasonable Time, ISMM 2013；可访问全文.
3. Jeyhun Karimov et al., Benchmarking Distributed Stream Data Processing Systems, ICDE 2018.
4. OpenJDK, Java Microbenchmark Harness.
5. OpenJDK JMH, 官方示例目录.
6. OpenJDK JMH 源码：BenchmarkProcessor、BenchmarkGenerator、Runner、Result.

本文精读 2017 年论文 State Management in Apache Flink: Consistent Stateful Distributed Stream Processing。它不是逐句翻译，也不罗列配置项。全文用同一个例子贯穿：两个 Kafka 分区输入一个有状态聚合算子，结果写入事务 Sink。我们会逐条记录检查 Barrier 到达时状态怎样变化，失败后哪些记录重放，以及一个外部事务究竟应该提交还是回滚。

阅读时需要分清三类内容：

• 论文事实：来自论文 §3.2、Algorithm 1、状态后端与生产实验；
• 现代 Flink：以 Apache Flink 2.3 文档为版本基线；
• 工程推论：从上述机制推导到 Connector 和 SeaTunnel/Zeta 设计，不代表论文原文结论。

先给出全文结论：

Checkpoint 不是“保存一批对象”，而是为一次确定的输入前缀建立可重新进入的执行世界。Source 位置、算子状态、必要的通道状态和 Sink 提交必须对这个输入前缀给出相容答案。

一、一致性问题：恢复点必须解释同一段历史

1.1 单独正确的状态，组合起来可能错误

假设账户 alice 在 Checkpoint 41 中的余额状态是 900，Kafka 下一条待读 Offset 是 121。随后 Offset 121 到来一笔 +50：

Checkpoint 41:
  nextOffset = 121
  balance(alice) = 900

处理 P0@121(+50) 后:
  nextOffset = 122
  balance(alice) = 950

一个合法恢复点只能选择前后两个组合之一：

因此，问题不是 Offset 和状态有没有分别保存成功，而是它们是否属于同一个输入前缀。对于完整数据流，这个恢复合同至少涉及四部分：

• Source 位置决定恢复后从哪里重放；
• Operator State必须恰好包含该位置之前记录的状态影响；
• Channel State解释已经离开上游但尚未进入下游状态的记录；
• Sink 事务解释哪些输出已经进入最终外部可见状态。

这里的“一致时刻”不是要求所有机器在同一毫秒暂停，而是要求因果关系闭合：快照里不能只有结果没有原因，也不能把同一原因既放进状态、又放进待重放输入。

1.2 为什么外部数据库不能自动解决问题

把算子状态放进外部数据库，可以解决状态字节的可靠存储，却不能自动回答“这个数据库版本对应哪个 Kafka Offset、哪个下游事务”。如果每条记录都同时更新状态表、提交 Offset、写目标系统，系统仍需要一个跨越这些参与者的提交协议；否则失败窗口只是从内存搬到了多个外部系统之间。

数据库可以是 State Backend 或 Sink，但 Epoch 的归属关系仍由流处理运行时协调。这正是论文把 Managed State、Snapshot Protocol 与外部提交放进同一架构讨论的原因。

二、Managed State：运行时究竟管理什么

2.1 Keyed State、Operator State 与隐藏状态

Managed State 的价值不在于 API 名字，而在于运行时知道状态的逻辑所有权、序列化方式以及恢复时如何重分配。

ValueState、ListState、MapState 等只是 Keyed State 的访问接口。关键在于同一个 key 的状态不绑定当前线程或机器，而是先属于一个稳定逻辑分片，再由当前并行实例承载。

相反，普通成员字段、静态 Map、Connector 后台线程里的 Buffer，如果没有进入 Managed State 或另一个明确的恢复协议，运行时并不知道它们存在。它们可能参与业务结果，却不会自动出现在 Checkpoint 中。

2.2 key-group 为什么是扩缩容的基础

Flink 不直接把每个业务 key 写进 Checkpoint 调度元数据，而是先把 key 映射到固定数量的 key-group。maxParallelism 决定 key-group 总数，当前 parallelism 只决定这些组怎样分给 Subtask。

扩缩容时，系统移动的是 key-group range 及其 State Handle，而不是重新扫描每个业务 key 决定归属。只要 maxParallelism 和 key 序列化/哈希语义稳定，同一个 key 就能找到原状态。第 8.1 节会用 M=12、P=3→4 的例子展示一个新 Subtask 怎样从多个旧 Handle 拼出自己的状态。

2.3 “被托管”不等于永远兼容

Checkpoint 还依赖三类身份：

1. Operator UID：恢复时把旧状态映射回哪个逻辑算子；
2. State Name：在算子内部找到哪份状态；
3. Serializer Snapshot：判断旧字节能否由新代码读取或迁移。

自动生成的算子 ID 会随 Job Graph 变化，任意修改 UID、状态名、key 类型或序列化格式，都可能让状态无法恢复。Managed State 提供迁移机制，但不承诺任意代码升级天然兼容。

三、论文的 Snapshot Model 与三个显式假设

3.1 Epoch、Marker 与 Barrier

论文把连续输入划分为逻辑 Epoch。为了避免编号偏一位，本文统一采用下面的定义：

Checkpoint N 包含 Barrier N 之前的记录及其状态影响；Barrier N 之后的记录不属于 Checkpoint N。

论文称这个控制消息为 Marker，现代 Flink 文档通常称为 Checkpoint Barrier。本文复述 Algorithm 1 时使用 Marker，其余场景使用 Barrier。

Source 收到协调器触发后，在同一个有序边界记录读取位置并向输出注入 Barrier。Barrier 与业务记录经过同一数据通道传播，不是一个可以越过任意记录的旁路 RPC。论文 Algorithm 1 对普通 Task 的抽象调用顺序在第 4.3 节单独展开，不把这里的 Source 描述外推成所有现代实现的固定方法次序。

3.2 三个假设不能省略

论文 §3.2.2 的协议建立在 fail-recovery、deterministic process model 上，并明确列出三项假设：

1. 输入可持久重放。 Source 能从某个逻辑位置重新消费，例如 Kafka Offset 或文件位置。
2. Task 间通道可靠、FIFO，并且可以阻塞或恢复。 通道阻塞期间，在途消息由系统缓冲，必要时 spill 到磁盘。
3. Task 能控制输入通道并向输出发送消息。 Task 可以触发输入的 block/unblock，并向输出发送记录或控制消息。

紧接着，论文另行说明 Marker 与普通记录由调用用户算子的同一底层线程顺序处理。这不是第三项假设的改写，而是 Algorithm 1 的本地执行顺序条件。

如果 FIFO 不成立，旧记录可能在 Barrier 之后到达；如果 Source 不可重放，回滚后无法补回 Checkpoint 之后的数据；如果用户逻辑依赖未记录的随机数、系统时间或不可重放外部调用，即使状态和 Offset 一致，重放结果也未必相同。

四、Barrier Alignment：逐条记录推演一致切面

4.1 单输入为什么简单

单输入通道中出现：

r1 -> r2 -> r3 -> Barrier 42 -> r4

由于 FIFO，看到 Barrier 42 时，r1..r3 已经完成本地处理，r4 尚未进入算子。此时固定本地状态版本，就得到了该通道上 Checkpoint 42 的输入前缀。

多输入算子不同：一个输入先越过边界，另一个输入还在旧 Epoch。如果继续同时消费，状态会混入两个输入前缀。

4.2 一个双输入账户聚合的完整时间线

继续使用本文的账户状态。Checkpoint 41 中 alice=900、bob=300，两个输入接下来分别出现：

Input A: P0@121 alice +50, Barrier 42, P0@122 alice +100
Input B: P1@81  bob   -20, Barrier 42, P1@82  bob   +200

合法的 Checkpoint 42 应是 alice=950、bob=280，不包含 Barrier 后的 +100 和 +200。假设 A 的 Barrier 先到：

如果不对齐，P0@122 alice+100 可能在 B 的 Barrier 到达前进入状态，使快照中的 alice 变成 1050；但 CP42 的 Source 位置仍会从 P0@122 开始。恢复后这条 +100 再执行一次，alice 变成错误的 1150。这正是论文中“关闭 Alignment”只提供 at-least-once 的原因。

4.3 Algorithm 1 到底做了什么

下面是论文 Algorithm 1 的等价伪代码，保留了关键顺序：

onMarker(marker, input):
  if input != NIL:
    blocked.add(input)
    input.block()

  if blocked == allInputs:
    for output in outputs:
      output.send(marker)

    triggerSnapshot()

    for input in allInputs:
      input.unblock()
    blocked.clear()

论文的抽象顺序是：阻塞到达 Marker 的输入 → 全部到齐 → 向下游发送 Marker → 触发本地快照 → 解除输入。 triggerSnapshot() 仍可能包含同步建立稳定视图的开销；可以异步的是随后把该视图复制、压缩并写入持久存储的物化阶段。

论文先发送 Marker 再触发本地快照，是为了让下游传播和本地物化并行。这个顺序用于解释论文协议，不应被当成现代 Flink 每种算子、Source 和 Backend 的公开调用契约。

4.4 为什么 DAG 中通常不用保存普通在途数据

对一个已对齐的多输入算子：

• 每条输入的 Barrier 之前记录都已处理，因为通道 FIFO；
• 先到 Barrier 的通道被阻塞，所以其 Barrier 之后记录没有进入状态；
• 最后一个 Barrier 到达后，所有输入前缀同时闭合；
• 同一线程中，旧 Epoch 记录产生的输出先于下游 Marker 发送。

因此，本地状态恰好对应所有输入在 Barrier 42 之前的前缀。普通 DAG 区域不必再把这些记录作为 Channel State 重复保存。

有环拓扑是例外：旧 Epoch 记录可能在环中长期流转。论文通过 IterationHead/IterationTail 只记录环内必要的在途记录，Marker 绕环返回后再停止日志。这个设计的重点不是某个已经具有版本背景的迭代 API，而是：一致切面无法排除的在途消息，必须成为快照的一部分。

4.5 从本地状态到 Completed Checkpoint

单个算子固定状态，不代表 Checkpoint 已经可以恢复；单个 Task 返回 State Handle/ACK，也只说明该 Task 的物化结果可用。Coordinator 收齐计划内所有参与者的 ACK，并把 Pending Checkpoint 原子地转换为 Completed 后，它才是合法恢复点。

不同 Task 的 Barrier 传播、对齐、同步快照和异步物化会流水重叠，所以 End-to-End Duration 不是把每个指标简单相加。全局耗时由跨 Task 的关键路径和最慢 Subtask 决定。只有 Coordinator 已确认的 Completed Checkpoint 才能作为恢复点；部分 Task 已 ACK 的半成品不能与旧 Checkpoint 拼接。

五、什么时候必须保存 Channel State

Aligned Checkpoint 在 DAG 中通过阻塞输入排除了普通在途数据；这不是说分布式快照永远不需要 Channel State，而是 Flink 利用 FIFO 数据流结构把保存范围降到了最小。

四种容易混淆的模式可以放在一张表中理解：

5.1 论文的“关闭对齐”为什么会退化

继续使用上一节的例子。如果 A 收到 Barrier 42 后仍处理 P0@122 alice+100，而 B 的旧 Epoch 记录尚未结束，那么快照可能包含这条记录的状态影响。恢复后，Source A 又会从 P0@122 重放；由于快照没有描述它已经混入状态，运行时无法消除第二次更新。

这是一种主动放宽一致性的模式：少等待，但允许恢复重放造成重复状态更新。

5.2 现代 Unaligned Checkpoint 用 I/O 换等待时间

Unaligned Checkpoint 不是“更名后的关闭对齐”。当第一个 Barrier 到达一个被背压的算子时，Barrier 可以越过部分排队数据继续传播，但这些被越过的输入/输出 Buffer 会作为 Channel State 写入 Checkpoint。恢复时，运行时先恢复相应在途数据，再继续普通输入处理，因此状态语义仍可保持 exactly-once。

它改变的是成本位置：

aligned:   等待慢通道追上 Barrier
unaligned: 保存并恢复 Barrier 越过的 Channel State

所以 unaligned 主要针对“Barrier 被拥堵数据长期阻挡”。如果瓶颈是单条用户函数执行几分钟、Checkpoint Storage 限流或状态物化 I/O 已饱和，它不会凭空消除瓶颈，反而可能因为额外 Channel State 增加写入量。

以 Flink 2.3 文档为基线，还应保留这些边界：

• unaligned 只用于 EXACTLY_ONCE Checkpoint Mode；
• 当前不支持多个 unaligned checkpoint 并发执行；
• configured alignment timeout 按 Checkpoint 触发后的已用时间判断是否从 aligned 切换，而不是只计算某一个输入的局部等待；
• pointwise、broadcast 等相应连接上会禁用 unaligned 路径，不能笼统表述成“所有连接都保存 Channel State”；
• Barrier 无法抢占正在执行的单条记录；
• 恢复时原有的 Watermark 与在途数据隐式顺序保证可能不再成立，部分算子可能得到不同结果，并非 Watermark 完全不可用；
• Savepoint 始终采用 aligned 方式。

选择 unaligned 之前，至少要同时查看 Barrier 传播/Alignment 时间、Channel State 大小和 Checkpoint Storage 余量。它是背压下的一种工程折中，不是全局更优模式。

六、状态怎样物化：Backend、Storage 与增量 SST

6.1 Barrier 决定 when，Backend 决定 how

Snapshot Protocol 只决定“Checkpoint 42 对应哪个逻辑状态版本”。State Backend 负责：

• 在线状态怎样组织和访问；
• 怎样固定一个不会被后续记录污染的 point-in-time view；
• 怎样把该视图转换成可恢复的 State Handle。

现代 Flink 自 1.13 起又把 Checkpoint Storage 从 State Backend 职责中明确拆出：

例如运行时状态在本地 Embedded RocksDB，而 Checkpoint 写到 S3，并不表示每次 state.get() 都远程访问 S3。论文中的 External State Backend 也不是 Checkpoint Storage 的旧名称：前者指运行期间状态访问由外部 KV/数据库承载。

6.2 同步阶段只固定稳定视图

如果对齐之后一直阻塞任务，直到数百 GB 状态全部上传完毕，周期性 Checkpoint 就会变成周期性停机。正确分层是：

同步阶段：确定 Checkpoint N 的稳定状态视图
异步阶段：压缩、复制并把该视图写入持久存储

解除输入后，在线状态已经可以继续处理下一个 Epoch，后台线程仍在物化旧视图。Backend 因此不能只把一个可变 Map 引用交给后台线程；它必须使用 Copy-on-Write、不可变版本、RocksDB Snapshot 或等价机制，确保后台看到的始终是 Barrier 时刻的内容。

异步不等于免费。上传仍会与前台竞争 CPU、磁盘、网络、对象存储请求额度以及 RocksDB Compaction 资源。Checkpoint 很慢时要区分：Barrier 没到、稳定视图建立慢，还是异步 I/O 慢。

6.3 增量 Checkpoint 的真实对象是共享文件

RocksDB 的 SST 文件不可变，天然适合作为复用单位。假设第一次增量 Checkpoint 建立完整基线：

C100 = {A, B, C}
C101 = {A, B, D}
C102 = {B, D, E}

创建 C101 时，A、B 已在共享存储中，通常只需上传新文件 D 和新的元数据；但恢复 C101 必须读取 A+B+D，不能只拿 D。

删除 C100 时，C 可以在没有其他引用后清理；A、B 仍被 C101 引用，不能一起删除。共享状态的生命周期必须跟随 Checkpoint 引用关系，而不是简单删除某个目录。

Compaction 还会把旧 SST 合并成新 SST。即使逻辑状态变化不大，新生成文件也可能需要重新上传。因此：

• 第一份增量 Checkpoint 需要建立基线；
• Checkpointed Data Size 在增量模式下表示本次 delta，不是完整逻辑状态大小；
• 增量快照减少的是重复上传，不保证恢复永远更快；
• 恢复快慢取决于文件数量、网络、CPU、IOPS 和本地 Backend 初始化；
• 异步快照、增量快照、本地恢复是不同优化，不能当成一个开关。

Flink 2.3 文档还列出 HashMap、Embedded RocksDB，并将面向存算分离的 ForSt 标记为 experimental。论文告诉我们为什么 Backend 可以替换；具体选型仍应以版本文档和自己的状态访问模式压测为准。

七、故障恢复与端到端 Exactly-Once：用一个事务走完所有窗口

7.1 Completed Checkpoint 保存的是一个恢复元组

回到本文的账户例子。假设 Checkpoint 41 已完成：

Source:
  P0.nextOffset = 121
  P1.nextOffset = 81

Operator State:
  balance(alice) = 900
  balance(bob)   = 300

Sink:
  transactions through T41 = COMMITTED

这里 nextOffset=121 明确表示下一条要读 121，之前的记录已经包含在该状态中。随后任务处理两条记录：

P0@121: alice +50  -> alice=950
P1@81:  bob   -20  -> bob=280

Checkpoint 42 的正常路径如下：

因此 CP42 不是三个互不相关的文件，而是一个逻辑元组：

CP42 = {
  sourceProgress: (P0=122, P1=82),
  operatorState:  (alice=950, bob=280),
  pendingSink:    T42,
  metadata:       handles + completion decision
}

只有 Coordinator 已确定 Completed 的元组才能恢复。TaskManager 磁盘上即使已经存在某些状态文件，如果 Completed Checkpoint 的元数据和 State Handle 不可用，它们也不是一个合法恢复点；这就是 JobManager/控制面高可用同样重要的原因。

7.2 Sink 需要的是可恢复状态机，不是一次 flush

一个抽象事务至少有这些状态：

下面是概念伪代码，不对应某个 Flink API 的固定方法签名：

onCheckpointBarrier(long checkpointId) {
    awaitOrFenceInflightRequests();
    TransactionHandle h = target.prepare(currentTransaction);
    pending.put(checkpointId, h); // pending 随本次状态一起持久化
    currentTransaction = target.begin(nextStableTransactionId());
}

onCheckpointCompleted(long checkpointId) {
    pending.upTo(checkpointId)
           .forEach(target::commitIdempotentlyOrQueryResult);
    // 只有确认 COMMITTED 后才能删除 pending；UNKNOWN 必须保留稳定身份
}

onCheckpointAborted(long checkpointId) {
    pending.exact(checkpointId)
           .forEach(target::abortIdempotently);
}

这里有三个不可省略的要求：

1. Pending Transaction 必须跟 Checkpoint 一起恢复；
2. commit 和 abort 必须幂等，或者能按稳定事务 ID 查询结果；
3. 新执行必须 fence 旧 Writer，防止失败实例在恢复后继续写。

flush() 只表示把 Buffer 送到外部系统或等待异步请求完成，不自动等于事务进入最终外部可见状态。只有当成功结果在 Source Progress 被确认前可判定，或 Pending Request 身份能够恢复并重试时，flush 才能参与建立可靠的 at-least-once；端到端 exactly-once 仍取决于外部提交协议。

7.3 五个失败窗口怎样收敛

最危险的是“外部 commit 成功、响应丢失”。调用方看到超时，并不知道应该重试还是回滚；但外部系统已经做出协议上的最终提交决定。稳定事务 ID、结果查询和幂等 commit 是解决模糊结果的必要条件。

完成通知也不应被假设为“每个 Checkpoint 恰好一次到达”。并发 Checkpoint 可能让较新的完成点覆盖较旧点，通知链路也可能失败。提交实现应遵守 subsuming 语义：确认完成 N 时，能够安全处理所有不大于 N 且仍待提交的结果。

论文的 Snapshot Notification、旧 TwoPhaseCommitSinkFunction 风格的 completion callback、现代 Sink V2 的 Writer/Committable/Committer，是不同年代和 API 的实现方式。它们共享的是状态机不变量，而不是同一条固定 Java 调用链。

7.4 Exactly-once 指效果，不是 CPU 只执行一次

如果 CP42 完成后又处理了 P0@122，随后 CP43 未完成就失败，系统会恢复 CP42 并再次执行 P0@122。记录物理上执行了两次，但第一次更新的在线状态被回滚，第一次外部事务也没有成为有效提交，所以最终效果可以等价于一次。

幂等 Upsert 也能吸收重放，但条件比“有主键”严格：主键必须稳定，写入值必须确定，而且旧重放不能覆盖更新版本。常见做法是在目标行中带上单调 Epoch/版本，使用条件更新拒绝版本回退。

反过来，如果用户函数读取未记录的系统时间、随机数或不可重放外部服务，第二次执行可能产生不同结果。Checkpoint 保护的是纳入协议的状态，不会自动把任意副作用变成确定性操作。

八、Rescale、Savepoint 与现代运行时职责

8.1 Rescale 实际上怎样读取旧 State Handle

前面已经说明 key-group 把逻辑分片与物理并行度解耦。连续 range 的计算可以抽象为：

start(i) = ceil(i * M / P)
end(i)   = ceil((i + 1) * M / P) - 1

M = maxParallelism
P = 当前 parallelism
i = subtask index

假设 M=12，旧并行度为 3：

old-0 -> [0..3]
old-1 -> [4..7]
old-2 -> [8..11]

扩容到 4 后，新 subtask-1 负责 [3..5]。恢复器必须从 old-0 的 State Handle 读取 key-group 3，再从 old-1 读取 4、5；它不能把“old-1 的整个本地数据库”简单复制过来。

下图只展示发生跨旧 Handle 读取的两个中间范围，省略没有交叉的 new-0 和 new-3：

Operator State 不能按 key-group 处理。Source Split、分区元数据等通常使用 list/union 等 redistribution contract；Pending Transaction 则需要稳定事务身份和明确的接管规则。把状态永久绑定到 taskIndex，会让 Failover 和 Rescale 都失去逻辑归属。

8.2 Checkpoint 与 Savepoint 共用基础设施，但合同不同

“能从快照启动”不等于“升级一定安全”。计划变更前至少检查 Operator UID、State Name、Serializer 兼容性、maxParallelism 和 Connector Pending State。Native Savepoint 往往创建/恢复更快，但可移植性与允许的变更范围要按具体版本能力矩阵判断。

8.3 论文概念到现代 Flink 只能映射职责

下面的类名用于理解 Flink 2.x 一代运行时，不是稳定用户 API，也不是论文伪代码的逐行调用栈：

现代 Source State 也不一定是一个 long offset。它可能包含 Enumerator 状态、已发现和已分配 Split、每个 Split 的读取位置以及 CDC Snapshot/Log 切换阶段。论文的 Source Offset 是恢复进度的最小模型，不应把 Connector 接口简化成一个 getter。

九、King 生产数据：论文到底证明了什么

论文使用 King 的 Rule-Based Event Aggregator（RBEA）展示真实大状态作业。查询规则广播到 Query Processor，事件按用户 ID 分区，算子维护每个用户状态，再把聚合结果写向数据库或 Kafka。

9.1 实验中真正公开的数据

最容易出现的错误解读是“500 GB 状态 1.3 秒就上传完”。论文测得的是平均 Alignment Delay，不是全部 SST 写入 HDFS、ACK 和全局确认的 End-to-End Duration。低 Alignment 说明异步快照可以把大部分物化成本移出前台一致性切面，不说明存储 I/O 没有成本。

论文还观察到：在其部署范围内，状态变大没有让 Alignment 显著增长；并行度和拓扑连接增加会带来一定对齐开销，但结果不是简单线性关系。这证明架构在真实生产中可行，却不是对所有云环境的通用 Benchmark。

实验没有给出大规模恢复 P99、对象存储尾延迟、严重持续背压下的 aligned 表现，也不可能覆盖后来出现的 unaligned、现代 Sink API 和 ForSt。今天仍需按自己的拓扑与存储压测。

9.2 Checkpoint 变慢时看哪一层

Timeout 从 10 分钟改到 30 分钟只能减少超时失败，不能解释为什么关键路径需要 20 分钟。应先定位 Barrier、Sync、Async、Storage 或 Restore 中的哪一段变慢，再选择扩容、Buffer Debloating、增量、unaligned 或存储调优。

十、对 SeaTunnel/Zeta 与 Connector 的工程推论

本节是从论文不变量推导出的设计检查表，不把 Flink 内部类名等同于 SeaTunnel 某个版本的 API。具体接口仍应以对应 SeaTunnel commit 为准。

10.1 跨越 Checkpoint 边界的东西必须有去处

并不是引擎队列、Sink Buffer 和所有异步请求都必须原样序列化进 Checkpoint。正确要求是：

任何跨越快照边界的状态或副作用，都必须可恢复、可重放、可撤销、可 fence，或可通过幂等/事务消除重复。

Source Progress 的不变量也不是“记录已经越过所有 Buffer”。在 aligned 模式下，Barrier 前记录可以仍在下游网络中；正确性来自：保存的位置描述了 Barrier 前已经按序发出的精确输入前缀，下游 FIFO 和 Alignment 会保证它们先于 Barrier 被处理。Unaligned 才会把必要的在途 Buffer 纳入快照。

10.2 后台线程必须服从 Epoch Fence

我在之前关于 Engine-Level FlushSignal 的文章中讨论过，为什么 Connector 自己启动定时线程会带来并发和异常传播问题。从 Checkpoint 角度看，还必须回答：

• 请求属于哪个 Epoch，Barrier 到来时是否还允许产生新请求；
• 已完成但未发射的结果保存在哪里，异步异常怎样回到 Task 生命周期；
• cancel/fail 后旧线程怎样失效，新 Writer 怎样 fence 旧 Writer；
• 重试使用什么稳定幂等键或事务 ID。

一个安全的边界通常包含 freeze/drain -> snapshot pending -> handoff -> resume，而不是在主线程保存一个 Buffer 后，让后台线程继续无约束地修改同一对象。

把第 7.2 节的事务状态机落到 SeaTunnel 时，还要增加两个引擎级约束。第一，事务身份不能只依赖当前 workerId/taskIndex，否则 Rescale 或 Failover 后可能重复创建事务，或让 PREPARED 事务失去接管者。第二，多 Writer 分别提交不自动等于跨分区原子可见；最终保证取决于外部系统以及是否存在引擎级的全局提交协调。

10.3 E2E 测试要控制协议阶段，而不是控制时间

最有价值的测试不是任务正常结束后比较一次行数，而是在第 7.3 节的模糊窗口精确停住系统。例如验证“外部 commit 已成功，但响应丢失”：

// 概念测试代码：服务端在持久提交后、返回 ACK 前暂停
commitServer.pauseAt(AFTER_DURABLE_COMMIT_BEFORE_ACK);

job.triggerCheckpoint(42);
commitServer.awaitPaused(42); // commit 已落盘，ACK 尚未返回
job.killCommitOwner();       // 具体可能是 Writer、Committer 或 Coordinator

job.restartFromLatestCompletedCheckpoint();
commitServer.resume();

assertThat(commitServer.commitAttempts(42)).isGreaterThanOrEqualTo(2);
assertThat(commitServer.logicalCommitCount(42)).isEqualTo(1);
assertThat(target.rows()).containsExactlyInAnyOrderElementsOf(expectedRows);

如果测试用 Thread.sleep(5000) 猜测“应该已经 commit”，它既容易 flaky，也无法证明失败发生在目标窗口。更可靠的测试使用 latch、Hook、可控代理或事务测试服务端，并对每个阶段做确定性断言：

这些测试验证的是协议不变量，而不是某次 CI 恰好通过。对于 Connector 稳定性，这比增加重试次数或放宽超时更有价值。

十一、结论：把 Checkpoint 看成可重新进入的世界

这篇论文最重要的贡献，不是某个 State API，也不是一个 Barrier 流程图，而是把状态归属、全局一致切面、异步物化、恢复重放和外部提交放进了同一个协议。

全文可以压缩成三条：

1. 一致性对象是输入前缀及其全部状态影响，不是若干独立状态文件。 Source、Operator、必要 Channel State 和 Sink 必须解释同一段历史。
2. 大状态系统的关键是把“确定逻辑切面”与“物化大量字节”解耦。 Barrier/Alignment 解决 when，Backend/Storage 解决 how；增量 SST 再减少重复传输。
3. 端到端 exactly-once 的最后边界在外部提交。 记录可以被重放，但 Pending Transaction、稳定事务身份、幂等 commit 和 fencing 必须让外部效果收敛到一次。

可重放 Source
  -> Barrier 定义输入前缀
  -> Alignment 或 Channel State 建立一致切面
  -> Backend 固定并物化状态版本
  -> Coordinator 确认 Completed Checkpoint
  -> 恢复时回滚状态并重放
  -> Sink 协议提交唯一外部结果

论文使用的是 Flink 1.2.0 时代的实现，今天的 Source/Sink API、State Backend 和 unaligned checkpoint 已经演进；但只要系统还需要在失败后继续处理无界输入，这条一致性链路就不会过时。

参考资料

1. Paris Carbone et al., State Management in Apache Flink: Consistent Stateful Distributed Stream Processing, PVLDB 10(12), 2017.
2. Apache Flink 2.3, Checkpointing.
3. Apache Flink 2.3, Checkpointing under backpressure.
4. Apache Flink 2.3, State Backends.
5. Apache Flink 2.3, Checkpoints vs. Savepoints.
6. Apache Flink 2.3, Tuning Checkpoints and Large State.
7. Apache Flink 2.3, Fault Tolerance Guarantees of Data Sources and Sinks.
8. Apache Flink 2.3, Deprecated API List.
9. Apache Flink 2.3, CheckpointListener API.
10. Apache Flink 2.3, SupportsCommitter API.