jdk 21 是当前生产环境事实标准，因其已完成 spring boot 3.5+、quarkus 3.12 等主流框架的 lts 生态适配，且分代 zgc 和自动元空间调优已解决大堆场景下的稳定性问题。
生产环境直接用 JDK 21，除非你被老系统死死卡在 JDK 8；JDK 17 是过渡期最稳妥的中间选择，但已不是“新项目首选”；JDK 11 仅建议用于极轻量服务或遗留容器化迁移中的临时兼容层。
为什么 JDK 21 是当前生产环境事实标准
截至 2026 年 8 月，JDK 21 已完成全部 LTS 生态适配：Spring Boot 3.5+、Quarkus 3.12、Micrometer 1.14、GraalVM CE 21.3 均默认要求或深度优化该版本。关键点不是“它有虚拟线程”，而是：ZGC 在 JDK 21.0.10 中已稳定支持亚毫秒级 GC 停顿（实测 99.9% Virtual Threads 不再是预览特性，Thread.ofVirtual() 可直接用于生产网关和消息消费模块；更重要的是，JDK 21 是首个永久免费商用的 LTS 版本（NFTC 许可），无需订阅即可用于任何规模生产系统。
常见误判：JDK 17 的 ZGC 虽已“正式”，但在超大堆（>64GB）场景下仍偶发 OutOfMemoryError: ZGC failed to allocate，而 JDK 21 的分代 ZGC 和自动元空间调优已解决该问题。
JDK 8 还能用吗？哪些场景真不能动
JDK 8 不是“不能用”，而是“不该新增使用”。它仍在大量存量系统中运行，但必须满足以下全部条件才可继续维持：
- 系统未接入 Spring Boot 3.x 或任何依赖
java.base模块强封装的库 - 未使用容器编排（如 Kubernetes）的自动内存限制（
JVM无法正确识别cgroup v2内存限额） - 安全团队接受每月手动打补丁（OpenJDK 8 社区维护已于 2025 年底终止，仅部分商业发行版提供有限更新）
- 监控体系不依赖
JFR（Java Flight Recorder）实时分析——JDK 8u381+的JFR无持续采样能力
典型不可退场场景：银行核心交易系统的 COBOL-Java 桥接层、工业 SCADA 系统的 JNI 插件、某些国产中间件的硬编码类加载逻辑。
切换 JDK 11/17/21 时最常踩的三个坑
不是语法报错，而是运行时静默失败或性能倒退：
-
java.lang.ClassNotFoundException或NoClassDefFoundError：源于JPMS模块系统收紧。例如JDK 11+默认移除了java.xml.bind模块，但旧项目pom.xml里没显式添加jakarta.xml.bind:jakarta.xml.bind-api -
java.lang.IllegalAccessError：反射调用被拦截。从JDK 9开始，--add-opens成为刚需，比如spring-core早期版本需加--add-opens java.base/java.lang=ALL-UNNAMED - 容器内存超限 OOMKilled：
JDK 8忽略cgroup内存限制，而JDK 10+默认启用-XX:+UseContainerSupport，但若 JVM 参数未同步调整（如未设-XX:MaxRAMPercentage），会导致堆内存计算错误
本地多版本共存的关键操作点
Windows 上装多个 JDK 后 java -version 不变？大概率是 Oracle 安装器偷偷往 Path 顶部塞了 C:\Program Files\Common Files\Oracle\Java\javapath。删掉它，再确保 %JAVA_HOME%\bin 在 Path 最前面。
Linux/macOS 用户别用 update-alternatives 管理 JAVA_HOME——它只改 java 命令软链，不影响 JAVA_HOME 环境变量，IDEA 和 Maven 仍会读错。正确做法是：
- 所有 JDK 解压到统一目录（如
/opt/jdks/jdk-21.0.10） - 用 shell 函数切换：
jdk() { export JAVA_HOME=/opt/jdks/jdk-$1; export PATH=$JAVA_HOME/bin:$PATH; }，然后执行jdk 21 - IDEA 中每个项目单独配置
Project SDK，不依赖全局JAVA_HOME
真正复杂的是跨版本调试：JDK 21 的 jstack 无法解析 JDK 8 的线程 dump，反之亦然；线上问题定位时，dump 文件必须与生成它的 JDK 版本严格匹配。
