平台底层 OpenJDK 25 整体升级：从 LTS 换代到 ooderAgent 底座换装

Platform Base · JDK 25

平台底层 OpenJDK 25 整体升级：从 LTS 换代到 ooderAgent 底座换装

一次按「平台底座换代」立项的全栈升级。它同时回答四个问题：为什么是 JDK 25 这个 LTS、它到底强在哪、国内 Linux 是否撑得住、以及 ooderAgent 底座换装后得到了什么、怎么安全地切过去。

LTS 换代 · JDK 25 GA 2025-09-16

框架 · Spring Boot 2.7 → 3.5.x

迁移 · javax → jakarta

策略 · 框架/运行时解耦 · 灰度可回滚

摘要

1. 不是升级 JDK，是底座换代。真正的阻断项不是 JDK 25，而是已 EOL 的 Spring Boot 2.x；上 JDK 25 在技术上等价于上 Spring Boot 3.5.x，这一步占约 80% 工作量。
2. 一半收益来自「基线收敛」本身。仓库曾同时存在 JDK 11 / 21 / 25 三套基线（50+ 处硬编码），升级后归一为单一 JDK 25 基线。
3. JDK 25 是继 21 之后的下一个 LTS（GA 2025-09-16，JSR 400），带虚拟线程、AOT Cache、紧凑对象头、分代 GC 等生产级特性。
4. 国内 Linux 已普遍可用：龙芯、鲲鹏、昇腾、飞腾、海光、兆芯 + openEuler/UOS/麒麟 + 毕昇/龙芯 OpenJDK 25 + 国密。
5. 策略上把「框架迁移」与「运行时迁移」拆成两个独立变更，各自灰度、各自回滚，避免一个巨型变更叠加一次全量停机。

01引子：为什么是「底座换代」，不是「升级 JDK」

当一个平台已经在生产运行多年，「换 JDK」从来不是一个版本号问题，而是一次涉及框架、依赖、类加载链与部署拓扑的系统性工程。

ooderAgent 平台此前的真实状态，是三条相互咬合的技术债：上游已 EOL、JDK 基线三套分裂、国产化运行环境已成事实。把它们放在一起看，会发现一个结论：继续在 JDK 11 + Spring Boot 2.7 上修修补补，成本已经高于一次性换代。

本文的立场：这次升级的正确立项口径是「平台底座换代」——运行时（JDK 25）+ 框架（Spring Boot 3.5.x / jakarta）+ 工程基线（单一日线）三件事一起做，但在实施与灰度上必须解耦（见第 06 章）。

02大背景：JDK 25 是下一个 LTS 里程碑

Java 的 LTS 节奏决定了企业栈的换代周期。JDK 25 是继 JDK 21 之后的下一个长期支持版本，也是多个多年期项目（Loom / Amber / Leyden）的集大成落地。

事实 JDK 25 于 2025 年 9 月 16 日正式 GA（General Availability），是 Java SE Platform 版本 25 的参考实现（openjdk.org/projects/jdk/25，JSR 400）。作为 LTS，其官方 premier 支持延续到 2030 年 9 月前后，并另有延伸支持选项——这正好覆盖一个平台 4–6 年的服役周期。

事实 本版共落地 18 项 JEP（实验性 1 项、孵化 1 项、预览 4 项，其余转为永久特性）。这不是一次零敲碎打的迭代，而是把并发模型（Loom）、语言表达力（Amber）、启动/镜像（Leyden）三条主线的多年投入一次性转正。

LTS 换代的经济学：JDK 21 的 premier 支持窗口有限，生态正在向 JDK 25 迁移——例如 Ubuntu 26.04 LTS 已宣布默认搭载 OpenJDK 25 取代 OpenJDK 21。对企业而言，在下一个 LTS 上定型，意味着未来数年不用再为「追非 LTS 版本」反复付出迁移成本。

2.1 语言/运行时的三条主线

03核心优势：JDK 25 到底强在哪

下面这些不是「新玩具」，而是直接影响一个多实例、IO 密集、常驻内存平台的关键能力。

3.1 虚拟线程 + Scoped Values：高并发的新范式

虚拟线程（JEP 444 在 JDK 21 转正，JDK 25 延续并补强，JEP 491 消除固定/协调）让 JVM 可以廉价地创建百万级线程。对 ooderAgent 这种SSE 长连接、LLM 阻塞调用、A2A 跨节点委托密集的平台，意味着可以用最直观的阻塞式写法获得高吞吐，而不必把整条链路改成反应式。Scoped Values（作用域值）作为 ThreadLocal 的替代，能在父子线程间共享不可变数据且时空成本更低，与虚拟线程是天然搭档。

3.2 AOT Cache：冷启动的确定性收益

JEP 483/514/515 组成的 AOT Cache 让类加载、链接与方法剖析可以提前固化。平台有 11 个 fat-jar 服务 / 10+ 实例，冷启动速度直接决定弹性扩缩与故障恢复体验——这是本次升级中「高度可量化」的一块 判断（具体收益数字见第 07 章诚实口径）。

3.3 内存与 GC：更小的头、更低的停顿

• 紧凑对象头（JEP 519）：对象头压缩到 64 位，堆占用下降——对海量小对象（消息/事件/流程节点）尤其明显，可用 -XX:+UseCompactObjectHeaders 启用。
• 分代 GC 转正：分代式 Shenandoah（JEP 521）与 ZGC 分代（JEP 474/490）从实验转为稳定，在保持低停顿的同时改善内存利用率与稳定性。
• G1 增强：Region Pinning、Late Barrier Expansion，进一步压缩停顿。

3.4 安全与合规：PEM 与后量子

JEP 470 引入密码学对象（密钥/证书/CRL）的 PEM 编解码 API（预览），并纳入后量子算法——对企业级平台的密钥/证书管理与等保合规是实质利好。

与平台能力的映射：虚拟线程 → SSE/LLM/A2A 阻塞链路吞吐；AOT Cache → 11 个 fat-jar 冷启动；紧凑对象头 → 常驻堆下降；分代低停顿 GC → 长稳服务；PEM/后量子 → 密钥与合规。每一条都对应平台的一类真实负载，而非纸面参数。

04国内 Linux：JDK 25 已普遍可用

「换不换 LTS」的一个隐性门槛是国产运行环境撑不撑得住。答案是：JDK 25 已在国内主流芯片 + 操作系统上形成可用矩阵。

事实 JDK 25 GA 后，国产芯片与操作系统社区迅速跟进，主流组合均有对应构建或适配：

4.1 信创适配的三个关键点

• 国密：通过 --add-modules=jdk.crypto.sm 显式导入 SM2/SM3/SM4，或使用 jdk.crypto.cryptoki；满足信创与等保对国密算法的要求。
• 模块化裁剪：用 jlink 构建最小化运行时镜像（仅 java.base 等必需模块），既缩小分发体积，也强化模块边界隔离。
• 生态默认值在迁移：已有国产化数据库/搜索引擎套件（如 Easysearch 2.5.0）默认内置并推荐 JDK 25，并声明兼容 openEuler/UOS/麒麟/龙芯/申威/兆芯——说明「JDK 25 = 国产栈默认运行时」正在成为共识。

对 ooderAgent 的意义：生产已在麒麟 aarch64与 x86_64 多节点运行，且教育版外网、8098 form-agent 已在 Kylin aarch64 / systemd 实机上完成 JDK 25 + Spring Boot 3.5.3 升级验证——国产 Linux 不是升级的阻力，而是已被验证的落地面。

05ooderAgent 底座升级后的新特性

换装完成后，平台拿到的不是「更快一点的同一个东西」，而是一组结构性收益。

5.1 单一 JDK 25 基线（最确定的收益）

三套基线（11/21/25）归一为 JDK 25，根 POM 以 maven.compiler.release=${java.version} 单键真源收口；为绕过 JDK 不一致而存在的 -Pdesktop profile 可删除；50+ 处脚本 JDK 路径硬编码可收敛。判断 这是全部收益里最「确定」、最少争议的一块。

5.2 上游安全补丁回归

从已 EOL 的 Spring Boot 2.7.18 迁到 Spring Boot 3.5.3（jakarta），重新获得上游安全维护。javax→jakarta 迁移约 177 处 import（需白名单，见第 06 章），是本工程量的主体。

5.3 运行时能力直接兑现

5.4 已在新基线验证的事实

• 教育版13 个服务全部 JDK 25 + health 200，平台级迁移已完成。
• 8098 form-agent 已成功升级 JDK 25 + Spring Boot 3.5.3，E2E S1–S6 在 SB3 上全链路跑通。
• 内测已装 JDK 25（/usr/lib/jvm/java-25-openjdk-amd64，25.0.4.1），进入隔离灰度阶段。

这些是本博文少数可以标注为事实的落地证据，而非规划。

06升级步骤：解耦、灰度、可回滚

本方案最重要的设计决策，是把「框架迁移」与「运行时迁移」拆成两个独立变更，避免「一个巨型变更 + 一次全量停机」的高风险组合。

图 1 · 框架迁移与运行时迁移解耦：两类完全不同的故障域拆开，各自灰度、各自回滚。

6.1 变更 A：框架迁移（javax → jakarta）

1. jakarta 迁移约 177 处 import。必须用白名单而非全量替换——javax.crypto / javax.sql / javax.tools / javax.naming / javax.management 等 32 处属 JDK 自带，不需迁移，误伤即编译失败。
2. Hibernate 5 → 6 方言替换：Studio 主库 SQLite 方言从 org.sqlite.hibernate.dialect.SQLiteDialect 换为 org.hibernate.community.dialect.SQLiteDialect。改造面积不大，但验证面积最大——需一次数据级回归（ddl-auto=update 在 SQLite 上敏感）。
3. Spring Security 5 → 6：SecurityFilterChain DSL 大改，涉及自研过滤器（ScTokenAuthFilter / NorthboundAuthFilter / TraceFilter 等）。

6.2 变更 B：运行时迁移（JDK 21 → 25，代码零改动）

框架迁完并在 JDK 21 上稳定后，运行时切 25 是独立小变更。但有几条本仓特有的坑必须处理：

• 自研类加载链 + 运行期 javac（最高技术风险）：DynamicClassLoader / FileClassLoader / JarLoader 与运行期编译在强封装下需保证搜索路径完备（含 target/classes），否则会「改完没报错但流程静默断流」——这类缺陷只有端到端跑一轮才暴露。
• P6 ESB 扫描白名单：-Dooder.esb.scan.include=net/ooder/,view/，且空配置必须回落默认（否则 "".split("," 得 [""] 使白名单恒 false、ESB 全失效）。这是 v1 升级失败（端口长时间不监听）的根因修复。
• --add-opens 四项必带：java.base/java.lang、java.lang.reflect、java.io、java.util（JDK 17+ 下 cglib/反射库需要）。
• 高风险依赖：cglib（业务代码依赖 CGLIB 代理类名 $$EnhancerBySpringCGLIB$$）、lombok（JDK 25 需 ≥ 1.18.40）、javassist、mvel2、fastjson 1.x、netty 等逐一双击。

6.3 构建与部署纪律

# 平台件（Studio.jar）——两个必带参数
mvn -pl ooder-pro -am package -DskipTests -Dmdep.copy.skip=true

# -am：否则从 m2 取到 javax 旧 jar
# -Dmdep.copy.skip=true：不生成 target/lib（271 jar 会让 JDS 全目录扫描，启动数分钟）

启动以 JDK 25 绝对路径 + 上述 --add-opens + -Dloader.path=lib,lib/domain,lib/biz 起灰度实例。

6.4 四层隔离 + 灰度先行

灰度验收门控（缺一不可）

1. /actuator/health = 200 且 UP；启动耗时 ≤ j11 基线 +20%
2. flowDefinitions loadedCount > 0 且 degraded=false
3. 日志 [JarLoader] P6 scan include=… define=N skipNonBusiness=M，N>0
4. 业务 jar 命名空间 OK（外置 jar 与 jakarta 内核同代）
5. 域注册数与 j11 一致；/api/studio/projects = 200
6. 无新增类型 ERROR

结语：这次升级的价值，一半来自 JDK 25 的新特性，另一半来自「把三套混乱基线收敛成一条、把已 EOL 的上游换成有维护的上游」。前者让人兴奋，后者才让平台能在未来数年安全、可控地奔跑。