Java环境需确保版本匹配、JVM参数合理、构建链路一致及系统依赖完备，任一环节脱节都会导致启动失败或性能严重下降。
Java环境版本不匹配会导致运行时异常
项目编译用的是 Java 17，但服务器上只装了 Java 8，运行时会直接抛出 java.lang.UnsupportedClassVersionError。这不是性能问题，而是根本跑不起来。反过来，用低版本 JDK 编译、高版本运行一般能兼容，但可能触发额外的类验证或默认行为变更（比如 String::strip 在 Java 11+ 才有，Java 8 运行会报 NoSuchMethodError）。
- 确认项目
pom.xml或build.gradle中的sourceCompatibility和targetCompatibility版本 - 检查运行环境：执行
java -version和javac -version（如有） - 避免混用不同厂商 JDK（如 Oracle JDK / OpenJDK / Zulu / Temurin），某些 GC 行为或 JIT 策略差异会影响稳定性
JDK自带JVM参数对吞吐量和延迟影响显著
没调参的默认 JVM（尤其是堆大小）在生产环境几乎必然拖慢项目。比如 Spring Boot 默认启动用 -Xms 和 -Xmx 都是 256MB，而中等规模服务常需 2GB+ 堆；若堆太小，GC 频繁，Full GC 可能每分钟发生多次，请求平均延迟飙升。
- 必须显式设置
-Xms和-Xmx相同值，避免运行时扩容带来的停顿 - Java 11+ 推荐用
-XX:+UseZGC（低延迟场景）或-XX:+UseG1GC（平衡吞吐与响应），别用已废弃的ParallelGC或SerialGC - 添加
-XX:+PrintGCDetails -Xloggc:gc.log观察真实 GC 压力，而不是凭感觉调参
IDE里配置的JDK和项目实际打包用的JDK可能不一致
IntelliJ IDEA 的 Project SDK 只控制编辑和本地运行，Maven 构建仍由 MAVEN_OPTS 或 pom.xml 中的 maven-compiler-plugin 决定。常见现象：IDE 里调试正常，CI 打出的 jar 在服务器启动失败，报错 Unsupported major.minor version。
- 检查
pom.xml中是否明确声明了编译插件版本和目标字节码：
org.apache.maven.plugins maven-compiler-plugin 3.11.0 17 17
- CI 脚本中应指定 JDK 版本，例如 GitHub Actions 用
actions/setup-java@v4并设java-version: '17' - 用
java -cp your-app.jar MainClass -version验证 jar 包内嵌的字节码版本（需反编译或用javap -verbose）
Java环境中的系统级依赖容易被忽略
有些项目依赖 libstdc++、glibc 或本地库（如 netty-transport-native-epoll），在 Alpine Linux 上用 openjdk:17-jre-slim 镜像会因缺少 libc 报 UnsatisfiedLinkError；或者用 OpenJDK 17 但系统 glibc ，导致 java.nio.file.Files.walkFileTree 在某些路径下崩溃。
立即学习“Java免费学习笔记（深入）”；
- 生产容器优先选
temurin:17-jre-focal（基于 Ubuntu 22.04）而非alpine，除非你明确控制所有 native 依赖 - 若必须用 Alpine，改用
azul/zulu-openjdk-alpine:17，它自带 musl 兼容层 - 检查
/proc/sys/vm/max_map_count（Elasticsearch/Kafka 类服务需要 ≥262144），这不属于 JDK 范畴，但缺它会让 JVM 进程启动失败
jstat -gc 看 5 分钟真实 GC，比读十篇调优文章更管用。 
