新项目应选jdk 17或jdk 21，二者均为lts版本，分别支持至2029年9月和2031年9月，全面适配主流框架并提供zgc、虚拟线程等现代特性；避免使用非lts的jdk 22/23/24，因其仅获6个月安全更新，维护成本高。
新项目直接选JDK 17或JDK 21，别碰非LTS版本
2026年还在用JDK 8启动新服务，等于主动放弃ZGC、虚拟线程（Thread.ofVirtual()）、record类等现代能力；而选JDK 22、23这类非LTS版本，6个月后官方就停止安全更新——你得在上线半年内重做兼容性测试和灰度发布，实际成本远高于初期多花两小时升级。
- JDK 17：LTS支持到2029年9月，Spring Boot 3.x、Hibernate 6+、Quarkus 3.x 全面适配，是当前企业落地最稳的基线
- JDK 21：LTS支持到2031年9月，原生支持虚拟线程（Project Loom），对高并发I/O密集型服务（如网关、消息消费）有明显吞吐提升
- 别选JDK 24（2025年3月发布）：非LTS，2025年9月起就不再接收补丁，生产环境部署即埋雷
老系统升级前先跑mvn dependency:tree查硬依赖
很多“升级失败”根本不是JDK问题，而是某一个被遗忘的jar包卡在JDK 8时代。比如com.thoughtworks.xstream:xstream:1.4.11在JDK 17下会因模块系统限制抛java.lang.NoClassDefFoundError: javax/xml/bind/annotation/XmlRootElement——它没声明对java.xml.bind模块的依赖，而该模块在JDK 9+已被移除。
- 执行
mvn dependency:tree -Dincludes=groupId:artifactId锁定可疑旧包 - 重点检查：xstream、commons-beanutils、joda-time、old spring-asm 相关组件
- 用
java --list-modules确认目标JDK实际加载了哪些模块，比“文档说支持”更可靠
Linux上用sdk install java管理多版本，别硬改/usr/bin/java
直接sudo ln -sf /opt/jdk-17/bin/java /usr/bin/java看似快，但一旦CI流水线里有服务仍需JDK 11编译（比如某个遗留子模块用到了sun.misc.Unsafe），整条构建链就断在UnsupportedClassVersionError上，错误日志还只报“class file version 61.0”，新人根本看不出是JDK 17编译、JDK 11运行。
- 推荐流程：
curl -s "https://get.sdkman.io" | bash→source "$HOME/.sdkman/bin/sdkman-init.sh"→sdk install java 17.0.10-tem→sdk use java 17.0.10-tem - 每个项目根目录放
.sdkmanrc，内容为java=17.0.10-tem，sdk current自动识别 - Dockerfile中显式写
FROM eclipse-temurin:17-jre-jammy，不依赖基础镜像默认JDK
java -version显示正常 ≠ 应用能跑，必须验证javac和java主版本一致
常见坑：开发机装了JDK 17，但PATH里/usr/lib/jvm/java-11-openjdk-amd64/bin排在前面，导致java -version输出11，而javac -version输出17——Maven编译用的是javac，运行时却用java，结果打出class文件版本61（JDK 17），却在JDK 11上启动失败。
立即学习“Java免费学习笔记（深入）”；
- 验证命令必须成对跑：
java -version && javac -version - IDE里也要检查：IntelliJ → Project Structure → Project SDK 和 Project language level 必须匹配
- Maven项目务必在
pom.xml中锁死：<maven.compiler.source>17</maven.compiler.source>+<maven.compiler.target>17</maven.compiler.target>
javac、java、IDE、CI、容器镜像、第三方库全部对齐同一主版本号——漏掉任意一环，都会在深夜告警里以Unsupported major.minor version的形式突然出现。 
