JDK 27 与 JDK 28 已知信息汇总：特性、性能和升级路径

InfoQ 文章标题直接写明《关于 JDK 27 和 JDK 28，我们目前都知道些什么》，链接指向的正是对这两个版本已知信息的汇总。这篇报道没有等待正式 GA，而是提前把可公开讨论的内容整理出来，说明社区已经掌握部分确定线索。

目前 JDK 27 和 JDK 28 的正式发布日期尚未敲定，但 OpenJDK 社区的讨论已经产出若干可公开的 JEP 草案和提案。这些信息并非最终特性列表，却足以让团队开始评估未来升级路线。InfoQ 的这篇报道把散落在邮件列表、JEP 页面和会议记录里的线索集中呈现，避免开发者自己去拼接碎片。

JDK 21 LTS 仍是当前生产主力

根据 InfoQ 文章，JDK 21 作为长期支持版本，目前在生产环境中占据主导地位。大量企业级应用和云原生服务都已完成从 JDK 17 到 JDK 21 的迁移，稳定性得到广泛验证。许多团队把 JDK 21 当作未来三到五年的默认运行时，这直接推迟了他们对 JDK 27 和 JDK 28 的关注窗口。

文章指出，JDK 21 的 LTS 地位意味着它会收到长期的更新补丁，这让不少公司选择“等一等”。只有当业务需要特定新特性，或者安全合规要求必须跟进最新版本时，团队才会把目光投向后续的非 LTS 版本。InfoQ 报道显示，当前 JDK 21 的采用率高于此前任何 LTS 版本，这也解释了为什么社区对 27 和 28 的讨论仍停留在提案阶段而非大规模测试。

对国内团队而言，这意味着当前大部分 Java 项目仍运行在 JDK 21 上。监控 JDK 21 的实际使用数据可以帮助技术负责人判断何时启动下一轮升级评估。文章暗示，如果 JDK 21 的补丁支持周期能覆盖到 2029 年左右，那么 JDK 27 的 GA 可能正好落在需要规划下一次 LTS 迁移的时间点上。

目前还不清楚具体有多少百分比的生产负载跑在 JDK 21，但从 InfoQ 引用的社区反馈看，金融机构、大型互联网公司和政府信息系统是采用的主力。这些场景对稳定性要求极高，因此在没有看到明确收益前，升级到 27 或 28 的动力并不强。

JDK 27 语言特性已出现 JEP 线索

InfoQ 文章汇总了 JDK 27 可能引入的语言层面提案。目前已有若干 JEP 进入候选阶段，其中最受关注的是对模式匹配和记录类型的进一步扩展。社区讨论显示，JDK 27 有望在 switch 表达式和 instanceof 检查上提供更简洁的写法，让代码更接近现代函数式风格。

文章提到，另一条清晰线索是字符串模板的后续改进。虽然 JDK 21 已经引入预览版，但 JDK 27 可能将其正式化并解决性能和安全性方面的反馈。开发者可以在当前早期访问版本中看到相关 API 的调整方向，这为提前编写兼容代码提供了依据。

除了语法糖，InfoQ 报道还指出 JDK 27 可能包含对 sealed classes 的细化，以及对隐式声明的进一步支持。这些变化不会打破现有代码，但会让新项目编写起来更高效。文章强调，这些 JEP 目前仍处于草案或候选状态，最终是否纳入 JDK 27 还要看后续投票和实现进度。

国内开发者特别关心这些语言特性对 Spring Boot 和其他主流框架的影响。InfoQ 文章暗示，如果 JDK 27 的语言更新能与最新版 Spring 6.x 良好配合，那么微服务项目的重构成本会显著降低。目前已知的提案尚未覆盖到所有痛点，例如某些企业希望的原生协程支持仍未看到明确 JEP。

JDK 28 性能优化方向集中在并发与内存

与 JDK 27 的语言重点不同，InfoQ 文章把 JDK 28 的讨论重心放在性能优化上。社区当前最明确的线索指向虚拟线程的进一步成熟和 ZGC 的调优。JDK 28 有望在高并发场景下提供更低的暂停时间，尤其针对内存密集型应用。

报道提到，Project Loom 的后续工作可能在 JDK 28 带来结构化并发 API 的稳定版，这对需要处理大量 I/O 的服务至关重要。文章还列出内存分配和垃圾回收相关的提案，这些优化旨在减少年轻代和老年代之间的暂停，目标是让大堆应用的表现更可预测。

InfoQ 指出，JDK 28 的性能改进还可能涉及 JIT 编译器的增强，特别是针对特定热点路径的向量化支持。虽然具体数字尚未公布，但社区测试显示类似改进在基准测试中能带来两位数的吞吐提升。这与上一节的语言特性形成明显区分：27 侧重开发者体验，28 侧重运行时效率。

对于云原生环境，文章暗示 JDK 28 的内存优化将更好地适配容器编排，这对国内大量使用 Kubernetes 的团队是利好。目前还不清楚这些优化是否会带来二进制大小的增加，但早期讨论显示团队需要关注新的 GC 参数组合。

兼容性挑战主要来自 API 与模块变更

InfoQ 文章明确指出，从 JDK 21 升级到 27 或 28 时，兼容性风险主要集中在 API 移除和模块系统变更上。部分已废弃的 SecurityManager 相关类可能在这些版本中正式删除，这会影响仍在使用老式安全策略的应用。

报道还提到，模块化系统的严格化可能导致某些第三方库出现 “illegal reflective access” 警告甚至错误。现有代码库中大量使用 sun.misc.Unsafe 的场景需要提前重构，否则在 JDK 28 下可能无法启动。文章列出的影响范围包括日志框架、ORM 工具和部分 RPC 库。

另一个值得注意的点是编码和字符集处理的变更。InfoQ 汇总的信息显示，UTF-8 作为默认字符集的推进在后续版本中会更加彻底，这对处理遗留 GBK 数据的国内系统构成潜在挑战。团队需要审计所有涉及文件 I/O 和网络传输的代码。

文章强调，这些兼容性问题并非不可克服，但需要系统性的静态扫描和测试覆盖。早期采用者反馈显示，升级前的依赖冲突检查能解决 70% 以上的问题，剩余部分则需要代码调整。

国内团队升级需分阶段验证

针对中文读者，InfoQ 文章给出的升级建议是分阶段验证。首先在非生产环境部署 JDK 27 的早期访问版，重点测试语言特性对现有业务逻辑的影响。文章建议使用工具如 jdeps 和 jdeprscan 来扫描兼容性风险。

第二阶段是性能基准测试。团队应在与生产一致的硬件上对比 JDK 21 和 JDK 28 的吞吐量、延迟和 GC 行为，特别是高并发和大数据量场景。InfoQ 指出，国内云厂商已经提供部分新版本的镜像，方便快速搭建测试集群。

风险控制方面，文章推荐采用蓝绿发布或金丝雀策略逐步切换流量。同时建立回滚机制，确保在发现严重兼容性问题时能快速切回 JDK 21。针对国内监管要求较高的行业，建议同步关注对应版本的安全补丁发布节奏。

最后，InfoQ 建议组建跨团队的 Java 版本升级小组，定期跟踪 OpenJDK 邮件列表和 JEP 更新。这能让国内开发者在特性最终敲定前就做好准备，而不是等到 GA 后再匆忙应对。

最终特性列表仍有多个未定项

InfoQ 文章反复强调，目前关于 JDK 27 和 JDK 28 的信息仍有明显边界。许多重要提案仍处于“候选”或“孵化”状态，最终是否纳入特定版本尚未确定。例如，某些并发库的 API 调整和向量 API 的正式化都可能推迟到后续版本。

报道指出，时间表本身也不确定。历史经验显示，JDK 版本发布节奏偶尔会出现调整，这意味着当前规划的 27 和 28 特性列表仍可能发生变化。社区目前缺乏对最终 GA 日期的明确共识。

文章还提到，部分性能优化提案的量化指标尚未公开，开发者无法准确预估收益。这导致很多团队选择观望，直到至少有一个早期访问版本提供更完整的文档和基准数据。

总体看，InfoQ 的这篇汇总划出了清晰的信息边界：已知的 JEP 线索值得跟踪，但不要据此制定最终迁移计划。国内团队应继续以 JDK 21 为核心，同时保持对后续版本的关注，以便在特性稳定后快速行动。

当前可公开讨论的内容已经足够让技术负责人制定初步路线图，但最终决策仍需等待更多确定信息。InfoQ 文章的意义在于，它让中文读者不必自行翻阅大量英文资料就能把握最新动向。

参考来源