JDK 17是微服务生产环境最稳选择，因Spring Boot 3.x强制要求、容器镜像兼容性好、G1 GC调优成熟；JDK 21可小范围试用ZGC，JDK 8/11已不推荐新增服务。
微服务架构下选 JDK，核心不是追新，而是看 Spring Boot、服务网格、容器运行时和 GC 行为的兼容性。JDK 17 是当前生产环境最稳的选择，JDK 21 可小范围试水，JDK 8 已不建议新增服务。
Spring Boot 版本锁定了 JDK 下限
Spring Boot 3.x 要求 JDK 17+，彻底放弃对 JDK 8/11 的支持。如果你用的是 Spring Boot 2.7（EOL），它虽支持 JDK 11，但已停止维护，继续用等于裸奔。
-
spring-boot-starter-parent3.0.0+ → 必须 JDK 17 或更高 -
spring-boot-starter-parent2.7.18 → 最高支持 JDK 17，但不再接收安全补丁 - 若项目依赖
spring-cloud-starter-gateway4.x，底层基于 Spring Boot 3，同样绕不开 JDK 17
Docker 镜像与基础镜像的隐性约束
很多团队用 openjdk:17-jdk-slim 或 eclipse-temurin:17-jre-jammy，但要注意：Alpine 镜像默认用 musl libc，而 JDK 17+ 的某些 JNI 调用（如 Netty 的 epoll、gRPC 的 native transport）在 musl 下可能出问题。
- 生产推荐用
eclipse-temurin:17-jre-jammy（Debian base）或amazoncorretto:17-jre-alpine（经 Corretto 适配过 musl） - 避免直接用
openjdk:17-alpine，尤其当服务启用了netty-transport-native-epoll或grpc-netty-shaded -
JAVA_HOME必须指向完整 JRE/JDK 路径，Kubernetes 中常见因路径写成/usr/lib/jvm/java-17-openjdk-amd64/jre（旧结构）导致启动失败
G1 GC 在微服务场景下的实际表现差异
JDK 17 默认 GC 是 G1，但微服务实例通常内存小（256–1024MB）、生命周期短，G1 的并发标记阶段反而可能增加延迟毛刺。JDK 21 引入的 ZGC 已支持低至 128MB 堆，但需确认你的容器运行时（如 containerd）是否启用 --memory-limit 并透传给 JVM。
立即学习“Java免费学习笔记（深入）”；
- 堆 ≤ 512MB 时，
-XX:+UseZGC在 JDK 21 中比 G1 更平稳，但需加-XX:+UnlockExperimentalVMOptions（JDK 21 后已移除） - JDK 17 中若坚持用 G1，务必设
-XX:MaxGCPauseMillis=200，否则默认 200ms 可能被动态拉高到 500ms+ - 别信“ZGC 无停顿”——它仍有极短的 STW（
第三方 SDK 和 agent 的 JDK 兼容盲区
很多监控/链路追踪 agent（如 SkyWalking Java Agent 9.4+、Datadog JVM Profiler）宣称支持 JDK 21，但实际只测了 Linux x64。ARM64（如 AWS Graviton）或 Windows Server 容器里，java -javaagent 加载时可能报 UnsupportedClassVersionError 或静默失效。
- 检查 agent 的
META-INF/MANIFEST.MF中Created-By字段，它反映编译所用 JDK，而非运行时兼容性 - APM 类 agent 对
java.lang.instrument的使用深度不同：SkyWalking 重度依赖字节码重写，JDK 21 的 sealed classes 和强封装可能触发IllegalAccessError - 本地开发用 JDK 21 + 远程测试环境用 JDK 17？小心
javac编译的 class 文件在 JDK 17 上跑不起来（target bytecode 不匹配）
真正卡住升级的往往不是语言特性，而是某一个老版本的 Oracle JDBC Driver（ojdbc8.jar）或内部封装的加密 SDK —— 它们没声明模块依赖，却在 JDK 17+ 的强封装下拿不到 sun.misc.Unsafe。这类问题不会报错，只会默默降级到慢速路径，压测时才暴露。
