Eliya 25 为 OpenJDK 25 LTS 带来 JVM 级诊断配置文件

2026年6月29日 4分钟阅读 由 A N M Bazlur Rahman

Asymm Systems 发布了 Eliya 25.0.3，这是一个 OpenJDK 25 LTS 发行版，通过可选的 -XX:EliyaProfile=Production 标志引入了 JVM 级别的生产诊断策略点。Eliya 自 2026 年 6 月起可用，专为需要从生产工作负载中获取可靠的崩溃、内存和运行时诊断数据的 Java 团队设计，特别是在诊断工件可能用于审计或事件分析的监管环境中。

Eliya 被定位为一个保守的 OpenJDK 发行版，而不是一个新的 Java 框架、语言扩展或应用程序 API。当前的 Production 配置文件将多个现有的 HotSpot 功能整合到一个单一控制点下。它配置了内存溢出错误时的堆转储到结构化按服务路径、启用 OOM 退出以实现干净的编排重启、将原生内存跟踪设置为摘要模式、确保可预测的 hs_err 崩溃日志位置，并解锁 JFR 采样和性能分析器附加所需的诊断 VM 选项。该配置文件还维护容器支持（JDK 25 中已默认启用），以确保未来兼容性。

在一篇 介绍 Eliya 的 Foojay 文章 中，Asymm Systems 首席架构师 Fahim Farook 解释说，第一阶段并没有引入任何无法通过现有 JVM 标志实现的运行时行为。本次发布中 EliyaProfile 的主要价值在于为未来可能需要 VM 变更的能力在运行时内建立一个策略点。

Eliya 的设计基于这样一个原则：大多数生产策略应保持在 JVM 之外。服务认证、网络控制、调度、密钥注入、资源限制、堆大小和 GC 选择最好由 Kubernetes、服务网格、准入控制器、包装脚本或平台默认值管理。该项目认为，仅当满足以下两个条件之一时，JVM 级策略才合适：一是“可达性”（行为没有可用的外部接口），二是“不可覆盖性”（行为可以在外部访问但随后在运行时内被更改或绕过）。该项目将堆转储和致命错误日志作为示例，在这些情况下敏感数据可能在外部清理程序作用之前由 JVM 内部写入。

一个相关的例子是 JEP 536，JFR 进程内数据编辑，它在数据离开进程之前对命令行参数、环境变量和系统属性进行编辑。JEP 536 计划用于 JDK 27（2026 年 9 月正式发布），未包含在 JDK 25 或当前的 Eliya 版本中。Eliya 团队引用这一点来支持某些诊断编辑最好在进程内处理的观点，同时指出 Eliya 仍处于第一阶段，并非所有讨论的场景都已实现。

根据产品页面，Eliya 的标准构建遵循上游 openjdk/jdk25u 维护分支，并保持 Java API、标准库行为、JIT 行为、类加载和模块系统语义。该页面还指出，上游 OpenJDK 25 源代码通过了 Java SE 25 TCK，Eliya 二进制的独立 TCK 运行计划在第二阶段进行。此外，标准构建中的 java.security 与上游 JDK 25 在二进制上完全相同，可通过 diff 验证。计划在第二阶段作为独立工件提供 FIPS 变体，而不是作为标准构建中的开关。

该项目承诺每季度进行关键补丁更新，在每次上游 OpenJDK 发布后的 2 周内，并致力于在 1 周内解决关键 CVE。Eliya 在 GPLv2 加 Classpath Exception 下分发，与上游 OpenJDK 许可一致。支持持续到 JDK 25 LTS 窗口期（2029 年 9 月），并计划在 Eliya 25 退役前与 JDK 29 LTS 有 24 个月的重叠。产品页面目前从 GitHub Releases 提供多架构 Docker 镜像、tar.gz、DEB 和 RPM 下载，托管 apt/yum 包仓库计划于 2026 年第四季度推出。

路线图将第二阶段安排在 2026 年下半年，将包括捆绑的诊断工具、FIPS 变体、包仓库、持续 JFR 记录、统一的 GC 日志记录和扩展的 CLI 支持。未来的阶段将引入 JVM 诊断取证平台和针对受监管行业的按需合规配置文件。

InfoQ 与 Asymm Systems 首席架构师 Fahim Farook 就 Eliya 的动机、策略边界和迁移路径进行了交流。

InfoQ：包装脚本和 Java Agent 何时不再足够？

Fahim： 在大多数情况下，包装脚本和 Java Agent 是足够的，并且该项目坚持认为大多数操作控制应保留在外部层。例外情况是外部工具只能在 JVM 采取行动后观察到结果。例如，堆转储和致命错误日志写入器在后期处理工具介入之前产生数据。我经常引用 JEP 536 作为证据，证明进程内编辑可能优于事后擦除；但这只支持特定类别的运行时放置参数，并不支持整个 Eliya 路线图。

InfoQ：团队应如何决定策略属于 Kubernetes、平台工具还是 JVM？

Fahim： 团队采用分层方法。跨进程关注点应在 Kubernetes 或服务网格中管理，而进程特定默认值应属于包装器或意见性默认值。VM 补丁保留给满足可达性或不可覆盖性标准的情况。Eliya 区分运营商拥有的策略和监管机构拥有的策略。运营商拥有的配置（如当前的 Production 配置）允许在标准 JVM 优先级下通过命令行显式覆盖。未来的合规配置设计为如果运行时配置违反外部拥有的约束则关闭失败。

InfoQ：从其他 OpenJDK 发行版迁移时，Java 团队应期待哪些实际变化？

Fahim： 对于开发人员，预期的变化最小：没有新的语言特性、应用程序 API、构建更改或必需的框架迁移。运维团队应审查配置文件的默认更改，特别是诊断路径和 OOM 行为，并确定单个配置文件标志是否优于维护自定义 JVM 标志列表。团队建议企业用户监控独立 TCK 验证状态，这计划在第二阶段进行。Eliya 最适用于需要结构化本地取证数据、可审计运行时状态或合规性导向诊断控制的 Java 团队。对现有 OpenJDK 发行版和外部平台强制感到满意的团队可能看不到直接好处，因为当前的 Production 配置文件主要选择现有的 HotSpot 行为，而不是引入新的面向应用的 Java 特性。

关于作者

[LOADING...]

A N M Bazlur Rahman

A N M Bazlur Rahman 是 Java Champion 和 Hammerspace 的高级员工软件工程师，专攻 Java 及相关现代技术。除了日常工程工作，Bazlur 还作为导师、作者、演讲者和开源贡献者深入参与全球 Java 社区。他创立并主持孟加拉国 Java 用户组（JUGBD），自 2013 年以来组织 meetup 和会议推广 Java 知识。Bazlur 还是 InfoQ 的特约编辑和 Foojay.io 的编辑，这两个是 Java 专业人士最受尊敬的平台。他用孟加拉语撰写了多本 Java 编程书籍，包括畅销书《Java 编程》，帮助数千名开发者用母语学习该语言。他最新的英文著作《现代 Java 并发》（O'Reilly Media）探讨了使用虚拟线程和结构化并发的 Java 并发模型的演进。