JDK版本选择应基于项目生命周期、依赖支持和运行环境约束，当前生产推荐JDK 17（LTS），新项目可选JDK 21（LTS）；需重点验证依赖兼容性、构建配置与实际运行时JDK一致性。
选 JDK 版本不是看最新，而是看项目生命周期、依赖库支持和运行环境约束。JDK 17（LTS）是当前最稳妥的生产选择，JDK 21（LTS）适合新项目且需虚拟线程等特性，JDK 8 已不建议新增项目使用。
怎么看项目依赖是否支持某个JDK
关键不是“能不能跑”，而是“会不会出隐性问题”。很多老库在 JDK 11+ 上会因模块系统（java.base 默认强封装）、移除 API（如 javax.xml.bind）或反射限制（--illegal-access=deny）而失败。
- 检查构建日志里是否有
WARNING: Using incubator modules或ClassNotFoundException: javax.xml.bind.JAXBContext - Maven 项目运行
mvn dependency:tree，再搜索是否含已弃用的依赖，例如com.sun.xml.bind:jaxb-impl（JDK 11+ 需显式引入） - 用
java -XX:+ShowHiddenFrames -version启动应用，观察是否触发InaccessibleObjectException
JDK 8 / 11 / 17 / 21 的核心差异点
版本跳变带来的是兼容性断层，不是功能叠加。比如从 JDK 8 升到 11，java.awt.HeadlessException 可能在无 GUI 环境下突然抛出；从 17 到 21，VirtualThread 默认调度策略变更可能影响 ExecutorService 行为。
-
JDK 8：默认使用Parallel GC，无模块系统，String内部是char[] -
JDK 11：首次 LTS 含HTTP Client (java.net.http)，移除Java EE和Corba模块，JVMCI接口开放 -
JDK 17：密封类（sealed）、强封装internal.*包、Switch表达式正式化、G1成为默认 GC -
JDK 21：虚拟线程（VirtualThread）正式可用、ScopedValue替代InheritableThreadLocal、String Templates（预览转正式）
如何验证本地 JDK 是否真被项目使用
IDE 或构建工具常缓存旧配置，导致你以为用了 JDK 21，实际编译/运行仍是 JDK 11。
立即学习“Java免费学习笔记（深入）”；
- Maven：检查
pom.xml中maven-compiler-plugin的 - Gradle：确认
java.toolchain.version = "21"，而非仅sourceCompatibility = JavaVersion.VERSION_21 - 运行时验证：在启动类加
System.out.println(System.getProperty("java.version"));，或执行ps aux | grep java查看进程实际加载的java路径
public class JdkCheck {
public static void main(String[] args) {
System.out.println("JDK version: " + System.getProperty("java.version"));
System.out.println("Java home: " + System.getProperty("java.home"));
System.out.println("Runtime name: " + System.getProperty("java.runtime.name"));
}
}
真正容易被忽略的是 CI/CD 环境中的 JDK 版本——它往往和本地开发不一致，而且错误日志里不会直接写“你用了错的 JDK”，只会报 NoClassDefFoundError 或 UnsupportedClassVersionError，得倒推排查。
