开发与生产环境的Java配置差异是刻意设计，核心差异包括JAVA_HOME、java -version、JVM参数、CLASSPATH和安全策略；强行统一易引发故障。
开发与生产环境的 Java 配置通常不一致，这不是疏忽，而是有意为之——差异点集中在 JAVA_HOME、java -version 输出、JVM 参数、类路径（CLASSPATH）和安全策略上，强行统一反而容易引发故障。
为什么 JAVA_HOME 和 java -version 经常不同
开发机常装多个 JDK（如 JDK 17 用于编码，JDK 21 试新特性），而生产环境严格锁定一个 LTS 版本（如 JDK 17.0.10）。CI/CD 流水线构建时若未显式指定 JDK_VERSION，可能用错版本；容器镜像中若写死 openjdk:21-jre-slim，但应用只兼容 JDK 17 的字节码版本（class file major version 61），启动就会报 java.lang.UnsupportedClassVersionError。
实操建议：
- 在
pom.xml中用maven-compiler-plugin显式声明source和target，例如设为17 - 生产部署脚本开头加校验：
if [ "$($JAVA_HOME/bin/java -version 2>&1 | head -1 | cut -d' ' -f2 | tr -d '"' | cut -d'.' -f1-2)" != "17.0" ]; then echo "JDK mismatch"; exit 1; fi
- Spring Boot 应用可在
application.yml中加spring.jvm.version-check: true（需自定义逻辑）或用Runtime.version()在启动时断言
-Xmx 和 -XX:+UseG1GC 等 JVM 参数为何不能照搬
开发机内存小（16GB）、CPU 少（4 核），设 -Xmx4g 可能占满系统资源；生产机 64GB 内存、32 核，同样参数会导致 GC 频繁、吞吐下降。更关键的是：G1 垃圾收集器在 JDK 8u202+ 后才稳定，若生产 JDK 是 8u191，启用 -XX:+UseG1GC 会静默回退到 Parallel GC，但日志里不报错，仅表现为 STW 时间异常长。
立即学习“Java免费学习笔记（深入）”；
实操建议：
- 把 JVM 参数拆成配置文件（如
jvm-prod.options/jvm-dev.options），通过启动脚本按环境加载 - 避免硬编码
-Xms和-Xmx相同值，生产环境建议设为-Xms4g -Xmx16g并配合-XX:MaxRAMPercentage=75.0（JDK 10+） - 用
jstat -gc <pid>对比两环境 GC 行为，重点关注YGCT（Young GC 耗时）和FGCT（Full GC 次数）
类路径（CLASSPATH）和依赖冲突的真实表现
开发时用 IDE 自动管理依赖，logback-classic 版本是 1.4.14；生产打包用 Maven Shade 插件，却漏排除了传递依赖里的 slf4j-api 1.7.32，导致运行时报 java.lang.NoSuchMethodError: org.slf4j.MDC.getCopyOfContextMap()——因为新版 logback 调用了 2.0+ 的 MDC 方法，而老版 slf4j-api 没有。
实操建议：
- 执行
mvn dependency:tree -Dverbose | grep slf4j检查冲突，用<exclusion>显式剔除 - 生产 JAR 启动前先跑
jar -tf app.jar | grep -i "slf4j\|logback"，确认最终打进包里的只有预期版本 - 避免在
CLASSPATH中追加目录（如export CLASSPATH=$CLASSPATH:/opt/lib/*），通配符在 JDK 6~8 下行为不一致，改用-cp或模块路径（--module-path）
最易被忽略的一点：JDK 自带的 java.security 策略文件。开发默认用宽松策略，生产可能启用了 security.manager 或自定义策略限制反射、文件读写，导致 sun.misc.Unsafe 调用失败或 System.setProperty 抛 SecurityException——这类问题不会在编译或单元测试暴露，只在上线后触发。
