面经策

Java LTS 版本怎么选型？8/11/17/21/25 各自的里程碑特性是什么？ ​

  • 标签：Java、新特性

🏛 业务架构师 ​

Java LTS 版本选型，我按"里程碑特性+升级决策"讲（2026 视角）：

  • Java 8（2014）：Lambda+Stream 的起点。2026 年仍在大量存量系统服役，但已严重落后（无虚拟线程、性能弱、安全补丁依赖付费或开源发行版）——该升级了，技术债的利息（安全风险、招聘困难、框架生态弃支持）正在超过迁移成本；
  • Java 11（2018）： HttpClient、var；模块化落地。作为中间跳板有价值，但 2026 年不应再作为目标版本；
  • Java 17（2021）：密封类、Record 转正、模式匹配开局、强封装 JDK 内部 API——Spring Boot 3 的最低要求。2022~2024 年的主流选择；
  • Java 21（2023）：虚拟线程转正（头号特性）、结构化并发预览、分代 ZGC、Switch 模式匹配、Record 模式——2026 年的主流推荐：Spring Boot 3.2+ 一键启用虚拟线程，吞吐红利直接兑现；
  • Java 25（2025，最新 LTS）：虚拟线程 synchronized pinning 修复（JEP 491）、结构化并发与 ScopedValue 转正路线、紧凑对象头、Gatherers 等——新项目的首选，激进团队直接上。

我的选型决策（可背诵）：新项目 → Java 25（一步到位，五年支持）；存量 Java 8/11 → 规划直迁 21 或 25（别逐级爬，直接目标版本+一次性回归测试更省）；已在 17 → 按 Spring Boot 3.2+ 虚拟线程需求升 21，成本一天、收益确定。

升级的商业账：升级窗口选择跟着框架生态强制力走——Spring Boot 3 断代（javax→jakarta）时借势迁移；升级成本主要在依赖兼容与回归测试，收益是性能、安全、人才市场、云成本（同硬件吞吐提升=省机器）。这笔账在 2026 年已经是"必须算、必须做"的年度议程。

🏗 系统架构师 ​

Java LTS 选型策略：跟随"主流 LTS 尾部"，而非追新——我按里程碑讲再给决策：

  • Java 8（2014）：Lambda + Stream——函数式的分水岭；存量系统的"WinXP"，仍在大量运行但生态已停止前进（Spring Boot 3 要求 17+）；策略：维持 + 计划迁移，不再新功能；
  • Java 11（2018）：HttpClient、var 成熟、单文件运行——首个"模块化稳定"LTS；策略：8→11 是历史包袱最重的一跳（javax 移除、内部 API 封装），已完成者的跳板；
  • Java 17（2021）：现代化分水岭——sealed classes、pattern matching（instanceof）、Records 全转正；Spring Boot 3 / Jakarta EE 10 的最低门槛——生态当前基线，新项目最低标准；
  • Java 21（2023）：并发模型革命——虚拟线程转正（架构级收益最大）、结构化并发/ScopedValue 预览、分代 ZGC、pattern matching for switch、Record patterns；当前升级的黄金目标；
  • Java 25（2025.9）：结构化并发与 ScopedValue 转正、紧凑对象头、AOT 缓存（类加载 AOT）、G1/ZGC 继续进化、AI 向 API（Vector API 持续 incubator）——下一个稳定基线，17/21 项目的下一站。

选型决策（2026 视角）：

  • 新项目：21 起步（保守稳妥）或 25（激进但已 LTS）；17 只在被依赖的框架卡住时选；
  • 存量 8/11：直接跳 17/21（逐级升级是伪省力，8→17 的主要坑一次面对）；
  • 依赖检查先行：Spring Boot 3.x→17+、最新中间件 client→21+ 的矩阵核实；
  • 升级收益排序：虚拟线程（吞吐质变）> 启动与内存（云成本）> 语言特性（可维护性）——用这个账本说服管理层投入升级。

纪律：LTS 升级是平台工程（CI 全矩阵回归 + 灰度），不是"换个版本号"。

💻 全栈开发专家 ​

LTS 选型线（2026 视角）：新项目 JDK 21 起步（生态全就绪），激进/绿色field项目 JDK 25（2025.9 发布的最新 LTS）。

各版本里程碑（一句话记忆版）：

  • JDK 8（2014）：Lambda + Stream + 新时间 API——至今存量最大；
  • JDK 11（2018）：HttpClient、var、单文件运行；Oracle 商业化许可变更引发 OpenJDK 发行版崛起（重要工程史）；内部 API 强封装开始（--illegal-access 警告）；
  • JDK 17（2021）：密封类、record、instanceof 模式匹配（三大语言特性）、Strongly encapsulate internals（sun.misc.Unsafe 等真锁死）、Switch 模式匹配 preview、ZGC/Shenandoah 转正——Spring Boot 3 的基线；
  • JDK 21（2023）：虚拟线程正式、分代 ZGC、record 模式匹配、switch 模式匹配正式、结构化并发 preview——当前升级的主流目标；
  • JDK 25（2025）：最新 LTS——结构化并发/Scoped Values 转正、分代 ZGC 默认+性能增强、 kompact object headers（JEP 519 生产可用）、AOT 类加载与预发布、稳定值（JEP 502 preview→...）等——下一个标准基座。

升级策略（实战）：8 → 21 直接跳（中间版本没必要停留），顺序：依赖升级（Spring Boot 3.x 强制 17+）→ 编译修 API（javax→jakarta、内部 API 替换）→ GC 与容器参数复核 → 压测。别在 2026 年新开 JDK 8 项目——除非有无法升级的老中间件锁死，那是历史遗留不是选型。