Eliya 25：把生产诊断前移到 JVM 发行版层

Asymm Systems 发布了 Eliya 25.0.3，这是一个面向 OpenJDK 25 LTS 的发行版。它的重点不是换一套 Java 语法，也不是给应用框架加插件，而是把若干 HotSpot 诊断能力收拢到一个可选择启用的 Production profile 中，让生产环境里的 Java 问题更容易留下可靠证据。

这件事对线上 Java 团队有现实意义：很多事故不是没有诊断工具，而是工具分散、启动参数不一致、合规环境下临时开探针又很麻烦。Eliya 的方向，是把这些诊断能力尽量做成 JVM 发行版层面的约定。

诊断能力为什么适合下沉到 JVM 层

Java 生产故障常见的难点不是“不会分析”，而是“事后没有材料”。一次延迟尖刺、一次 Full GC、一次线程池卡死，如果 JVM 启动时没有打开合适的日志、JFR、dump 或事件采样，事故窗口过去之后只能靠猜。

Eliya 25.0.3 的定位是 OpenJDK 25 LTS 发行版，并把若干 HotSpot 特性整合进可选的 Production profile。这个设计有两个直接效果：

• 诊断配置从“每个服务各写一套参数”变成“平台侧给出统一基线”。
• 生产环境可以在启用诊断和控制开销之间做明确选择，而不是默认把所有开关散落在启动脚本里。

尤其在受监管环境里，诊断数据是否可信、是否可复现、是否由受控配置产生，往往和技术细节一样重要。JVM 发行版层面的 profile 比临时手工操作更容易审计。

Production profile 的价值：不是更多开关，而是更少临场决策

HotSpot 本身已经有不少生产诊断能力：JFR、统一日志、GC 日志、线程 dump、heap dump、Native Memory Tracking 等。问题在于它们分布在不同参数、工具和运行时命令里。

Eliya 的 Production profile 可以理解为一个“诊断基线”的承载点。来源摘要没有给出具体启用参数，因此不能假设它的 profile 开关名称或默认内容。但这个方向值得关注：团队可以把 JVM 诊断从应用代码中剥离出来，让运行平台统一管理。

这类 profile 最适合解决三类问题：

• 事故复盘需要稳定证据，例如 JFR 文件、GC 日志、错误文件。
• 多服务、多团队共用同一套 Java 运行时，需要减少启动参数漂移。
• 合规要求高，不能随意在线上节点临时安装或执行诊断组件。

边界也很清楚：profile 不能替代应用指标、分布式追踪和业务日志。JVM 能告诉你线程、内存、GC、锁、编译和运行时事件，不能自动解释业务请求为什么慢。

可以这样实践：先做一套可迁移的 OpenJDK 25 诊断启动模板

下面示例不假设 Eliya 的具体 Production profile 参数；它使用 OpenJDK/HotSpot 常见诊断能力。你可以把 JAVA_HOME 改成 Eliya 25 的安装目录，把 app.jar 改成你的服务包，然后再根据 Eliya 文档把 Production profile 开关补进去。

#!/usr/bin/env bash
set -euo pipefail

export JAVA_HOME="/opt/eliya-25"
export PATH="$JAVA_HOME/bin:$PATH"

APP_JAR="./app.jar"
LOG_DIR="./jvm-diagnostics"
mkdir -p "$LOG_DIR"

java \
  -XX:StartFlightRecording=name=prod,settings=profile,dumponexit=true,filename="$LOG_DIR/app.jfr" \
  -Xlog:gc*,safepoint:file="$LOG_DIR/gc.log":time,uptime,level,tags:filecount=5,filesize=50M \
  -XX:+HeapDumpOnOutOfMemoryError \
  -XX:HeapDumpPath="$LOG_DIR" \
  -XX:ErrorFile="$LOG_DIR/hs_err_pid%p.log" \
  -jar "$APP_JAR"

运行前需要调整三处：

• /opt/eliya-25：改成 Eliya 25 或其他 OpenJDK 25 发行版的安装路径。
• ./app.jar：改成你的实际应用 jar。
• ./jvm-diagnostics：改成生产环境允许写入并会被采集的目录。

如果你只是想验证当前 JVM 是否支持这些能力，可以运行：

java -version
java -XX:+PrintFlagsFinal -version | grep -E "FlightRecorder|HeapDump|ErrorFile"
java -Xlog:help | head -40

在容器里，可以把诊断目录挂出来，避免 Pod 重启后材料丢失：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: java-app
spec:
  replicas: 1
  selector:
    matchLabels:
      app: java-app
  template:
    metadata:
      labels:
        app: java-app
    spec:
      containers:
        - name: app
          image: example/java-app:latest
          env:
            - name: JAVA_HOME
              value: /opt/eliya-25
          args:
            - "java"
            - "-XX:StartFlightRecording=name=prod,settings=profile,dumponexit=true,filename=/diag/app.jfr"
            - "-Xlog:gc*,safepoint:file=/diag/gc.log:time,uptime,level,tags:filecount=5,filesize=50M"
            - "-XX:+HeapDumpOnOutOfMemoryError"
            - "-XX:HeapDumpPath=/diag"
            - "-XX:ErrorFile=/diag/hs_err_pid%p.log"
            - "-jar"
            - "/app/app.jar"
          volumeMounts:
            - name: diagnostics
              mountPath: /diag
      volumes:
        - name: diagnostics
          emptyDir: {}

这个 YAML 里的 emptyDir 只适合演示或短期排障。生产环境更常见的做法是挂载持久卷，或者由日志/制品采集系统及时拉走 /diag 下的文件。

落地时要看三件事

引入一个带诊断 profile 的 JDK 发行版，不应该只看“能不能启动应用”。更稳妥的评估清单是：

• 启动参数是否可审计：profile 怎么启用、谁能改、变更记录在哪里。
• 诊断数据是否可控：JFR、heap dump、错误日志可能包含敏感信息，需要定义保留期和访问权限。
• 开销是否可接受：JFR profile、GC 日志和 dump 策略要在压测环境验证，不能只凭默认值上线。
• 与现有平台是否冲突：容器镜像、基础镜像扫描、Kubernetes 探针、日志采集路径都要一起检查。

Eliya 25.0.3 的价值点在于把生产诊断作为 JVM 发行版的能力来组织，而不是让每个服务各自拼参数。后续 Phase 2 计划还会继续增强，但现在就可以做的一步，是把 Java 运行时诊断基线标准化：统一 JDK、统一 profile、统一采集路径、统一复盘材料。这样下一次事故发生时，团队拿到的不是零散线索，而是一组能直接分析的 JVM 证据。