💻 computer science

JEDI: Java Evaluation of Declarative and Imperative Queries

本文介绍了 JEDI，这是一个自动生成的基准测试套件，它将 SQL 查询转换为 Java 代码，以评估和比较声明式 Stream API 实现与命令式基准的性能，旨在识别低效的代码模式并指导 Java Stream API 的优化。

原作者： Filippo Schiavio, Walter Binder

发布于 2026-05-25

📖 1 分钟阅读☕ 轻松阅读

原作者： Filippo Schiavio, Walter Binder

原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 ✨ 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。阅读完整免责声明

想象一下，你有一个堆满箱子（数据）的巨大仓库，你需要找到特定物品、对它们进行排序并计数。你有两种向工人下达指令的方式：

“经理”方法（命令式）：你走到每个工人面前，逐一说道：“拿起这个箱子。检查它是否是红色的。如果是，把它放进一堆；如果不是，就扔掉。现在拿起下一个。”这种方式非常直接且迅速，但需要大量的口头沟通，如果你有成千上万名工人，场面可能会变得混乱。
“工头”方法（Java Stream API）：你写下一张简洁优雅的便条：“取走所有箱子，筛选出红色的，按大小排序，然后计数。”你将这张便条交给一位工头，由他负责安排工人如何执行。这对你来说编写和阅读都容易得多，但工头需要将你的便条转化为具体行动，这有时会耗费额外时间。

这篇题为JEDI的论文，旨在测试“工头”（Java Stream API）的表现与“经理”（传统代码）相比如何，并研究如何让工头工作得更快。

问题所在

Java Stream API 之所以流行，是因为它让代码看起来整洁且易于理解（就像给工头的便条）。然而，开发人员一直怀疑，这种“整洁”的编码方式比“杂乱”的传统方式更慢。问题在于，没有人拥有一个合适的赛道（基准测试）来公平地测试这一点。没有赛道，构建 Java 语言的人（“机械师”）就不知道引擎究竟在哪里出现卡顿，开发人员也不知道哪些指令能带来最佳速度。

解决方案：JEDI

作者构建了JEDI（声明式与命令式查询的 Java 评估）。可以将 JEDI 想象成一个巨大的自动化工厂，它接收标准的数据库查询（用一种称为 SQL 的语言编写，这就像一种通用的请求表单），并立即将它们翻译成两组不同的指令：

一组使用“工头”风格（流）。
一组使用“经理”风格（命令式循环）。

由于该工厂将完全相同的查询翻译成两种风格，因此比较是绝对公平的。这就像让两名跑步者跑完全相同的路线，并计时看谁更快。

他们的发现

1. 微小的调整带来巨大的差异（“过滤器融合”）
有时，如果你给工头三张单独的便条：“检查红色”、“检查大”、“检查重”，工头会感到困惑。

解决方法：作者发现，将这些便条合并成一张大便条（“检查红色且大且重”）会让工头快得多。这就像给工人一条清晰的指令，而不是三条令人困惑的指令。
结果：在某些情况下，这一简单改变使代码运行速度提高了2.6 倍。

2. “一对多”技巧
有时，一个箱子里装有许多更小的物品。

旧方法：工头会拿起箱子，打开它，取出一个物品，放入一堆，再回去取出下一个，如此重复。
新方法：作者发现了一种特殊工具（称为 mapMulti），它允许工头打开箱子，一次性将所有物品平滑地倾倒出来。
结果：这甚至比第一个技巧更有效，通常能使速度翻倍。

3. 并行性谜题（使用多名工人）
当你拥有一个巨大的仓库时，你希望同时使用多名工人（并行处理）。该论文测试了四种不同的组织这些工人的方式：

“严格顺序”团队：所有人排成一队，依次传递箱子。这有利于保持秩序，但速度较慢。
“混乱”团队：所有人随机抓取箱子。速度快，但难以管理。
“共享白板”团队：所有人将结果写在一张巨大的共享白板上。
“原子”团队：所有人使用一种特殊的、高科技的笔，即使两人同时书写也不会弄脏。

裁决：没有单一的“最佳”团队。

如果你只有非常少的组需要排序（例如只排序 4 种水果），“严格顺序”或“混乱”团队最快，因为“共享白板”会变得过于拥挤（关于谁先写的争论太多）。
如果你有数千个组（例如排序 10,000 种不同的水果），“共享白板”团队获胜，因为争论停止了，每个人都可以书写自己的部分而不会相互碰撞。

4. 速度差距
核心问题：“工头”（流）是否比“经理”（命令式）慢？

是的。传统的“经理”代码始终更快，通常快约30% 到 40%。
为什么？ “工头”必须花时间将你那优雅的便条转化为行动。而“经理”则立即开始工作。
好消息：差距并不像人们过去认为的那么大。Java 团队一直在改进引擎。然而，对于绝对最快的性能，“经理”风格仍然胜出。

5. 权衡：速度与理智
该论文还考察了代码的阅读难度。

“经理”代码（最快）就像一本密集且令人困惑的说明书。它难以阅读，且容易出错。
“工头”代码（较慢）就像一篇清晰简短的故事。它更容易理解，且出错的可能性更小。
教训：你必须做出选择。你是希望代码运行速度快 30%，还是希望它对于人类来说更容易阅读和维护（快 2.5 倍）？该论文建议，对于大多数人来说，“工头”风格值得付出微小的速度代价，因为它节省了调试和维护的时间。

总结

JEDI 是一个新工具，帮助开发人员理解使用现代、易读的 Java Stream API 的“成本”。它证明，虽然易读的代码比老式代码稍慢，但你可以通过使用特定技巧（如合并过滤器）使其快得多。它还根据数据量的多少，明确告诉开发人员如何组织他们的工人（并行策略）。最终，它为开发人员提供了一条路线图，以编写既具有可读性又相当快速的代码。

技术摘要：JEDI——声明式与命令式查询的 Java 评估

问题陈述

Java 8 引入的 Java Stream API 提供了一种用于处理集合和无限数据源的声明式语法，旨在与传统基于命令式循环的代码相比，提高开发者的生产力、代码可读性和可维护性。虽然该 API 通过高级抽象简化了并行计算，但现有文献表明，与等效的命令式代码相比，基于 Stream 的实现往往存在性能损耗。

本工作指出的一个关键缺口是缺乏针对 Stream API 的专用基准测试套件。没有此类基准测试，以下群体将难以开展工作：

研究人员和库开发者：难以优化 Java 类库（JCL）中 Stream API 的实现。
应用开发者：难以理解不同流操作和并行化策略的性能特征，从而编写高效的代码。

当前的基准测试要么未明确针对 Stream API，要么依赖于无法反映复杂现实世界数据处理工作负载的简单合成流水线。

方法论

为了弥补这一缺口，作者提出了 JEDI（声明式与命令式查询的 Java 评估），这是一个通过将 SQL 查询转换为 Java 源代码而自动生成的基准测试套件。

生成过程

源材料：作者利用 TPC-H 基准测试，这是一个广泛使用的数据分析基准测试，由涵盖各种数据处理功能（连接、聚合、过滤、排序）的复杂查询组成。
代码转换：作者扩展了现有工具 S2S（SQL 到 Stream），将 SQL 查询转换为多个语义等效的 Java 实现。
- 模式映射：SQL 表被映射为内存中的对象数组。
- 查询翻译：
  - SELECT 投影 $\rightarrow$ map(...)
  - WHERE 谓词 $\rightarrow$ filter(...)
  - ORDER BY $\rightarrow$ sorted(...)
  - LIMIT $\rightarrow$ limit(...)
  - GROUP BY 和聚合 $\rightarrow$ 使用生成的收集器进行 collect(...)。
  - JOIN $\rightarrow$ 通过 flatMap（为构建侧构建哈希图）或 mapMulti 实现。
实现变体：对于单个 SQL 查询，JEDI 生成多个变体以比较不同的编码模式和执行策略：
- 顺序变体：
  - O1（过滤器融合）：将多个谓词合并为单个 filter 调用与多个链式调用进行对比。
  - O2（连接实现）：在连接操作中使用 mapMulti 与 flatMap 进行对比。
- 并行变体（O3）：
  - P：有序并行流（parallel()）。
  - PU：无序并行流（parallel().unordered()）。
  - CG：使用 groupingByConcurrent 的无序并行流（基于锁同步的共享状态）。
  - CGCC：带有线程安全下游收集器的 CG（无锁原子操作）。
- 命令式基线：使用与流版本完全相同的数据结构和操作顺序的基于循环的实现，以衡量"Stream API 的开销”。

评估设置

硬件：两种不同的架构：Intel Xeon Gold（16 核）和 ARM Neoverse-N1（80 核）。
JVM：Oracle JDK 24 和 GraalVM 24。
数据集：TPC-H 规模因子为 1（1GB）用于顺序分析，规模因子为 10（10GB）用于并行分析。
工具：Java Microbenchmark Harness (JMH)，包含预热和测量迭代以确保稳态性能。

主要贡献

JEDI 基准测试套件：发布了一个源自 TPC-H 的开源基准测试套件，自动生成语义等效的流式和命令式实现。
代码生成器：扩展版的 S2S，支持多种实现策略（顺序优化和各种并行归约模式）。
性能指南：基于实证数据得出的一组高效使用 Stream API 的最佳实践。
开销分析：使用相同的数据结构和操作顺序，直接比较基于流与基于命令式的代码，以隔离 API 抽象的性能成本。

结果与发现

RQ1：顺序优化（过滤器融合与连接实现）

过滤器融合（O1）：将谓词合并为单个 filter 调用可提高性能，特别是在存在多个谓词时（例如，在具有 7 个谓词的微基准测试中加速比为 3.54 倍）。
连接实现（O2）：在连接操作中使用 mapMulti 代替 flatMap 可带来显著改进（在 Intel JDK 上的几何平均加速比为 1.38 倍）。
结论：开发者应尽可能应用 O1 和 O2。

RQ2：并行化策略

无通用赢家：没有单一的并行策略能主导所有场景。性能高度依赖于数据特征，特别是聚合组的数量和聚合的性质。
标量聚合与分组聚合：
- 对于标量聚合（无分组）或少量组，有序（P）或无序（PU）并行流由于竞争较低，性能优于共享状态策略（CG、CGCC）。
- 对于具有大量组的分组聚合，CG（使用 groupingByConcurrent）通常是最佳策略。随着组数量的增加，锁竞争减少，使得基于锁的同步变得高效。
无锁与基于锁：CGCC（无锁）并未始终优于 CG（基于锁），且引入了实现复杂性。然而，对于组数非常少且 CG 遭受高竞争的情况，CGCC 更为稳健。
去重操作：虽然通常建议使用无序流（PU）进行 distinct 操作，但研究发现，对于去重元素数量较少的流，有序并行流（P）可能快达 2 倍，这是因为无序流中管理共享 ConcurrentHashMap 的开销所致。

RQ3：流与命令式性能

命令式优势：基于命令式循环的代码始终优于基于流的代码。
幅度：在不同 JVM 和架构下，命令式代码相对于最佳顺序流实现的几何平均加速比范围为 1.28 倍至 1.41 倍。
背景：虽然这证实了之前的发现，但作者指出该差距比某些先前的研究要小，表明 Stream API 实现随时间有所改进。然而，对于性能关键型代码，命令式代码仍然显著更快。

RQ4：代码复杂度

可读性：尽管存在性能差距，但基于流的代码表现出显著更低的复杂度指标。
指标：基线流代码的认知复杂度比命令式代码低 2.43 倍。即使经过优化（O1+O2），流代码的复杂度仍比命令式代码低 1.62 倍。
权衡：优化流代码（例如融合过滤器）会增加其复杂度指标，但仍保持在命令式等效代码的复杂度之下。

意义与主张

本文将 JEDI 定位为 Java 社区和 JVM 实现者的重要工具：

对于开发者：它提供了数据驱动的指南，以最小化 Stream API 的性能开销，建议根据工作负载特征采用特定模式（例如，对于大组使用 mapMulti、groupingByConcurrent）。
对于库实现者：基准测试套件和已识别的“开销”为优化 Stream API 实现以缩小与命令式代码的性能差距提供了基准。
对于研究人员：它提供了一个可复现的复杂工作负载（源自 TPC-H），用于评估未来的优化、重构工具或并行化策略。

作者谦逊地承认了局限性，指出 JEDI 目前专注于基于数组的数据源和特定的 SQL 到流转换模式。他们计划在未来的工作中扩展生成器，以涵盖更多的 Stream API 方法并变化数据源（例如 List、Set）。