生产环境Java部署必须严格校验JDK版本兼容性、Tomcat类加载顺序、JVM参数配置及安全端口管理。需确保java/javac版本一致，Spring Boot 3.x要求JDK 17，log4j-core等依赖需同步升级；Tomcat中jar应按层级规范放置，避免WEB-INF/lib冲突；JVM堆内存须显式设定，禁用默认端口与明文管理界面，并彻底清理残留旧版jar和错误JAVA_HOME路径。

Java生产环境必须确认JDK版本与应用兼容性

很多线上问题根源是JDK版本错配——比如用JDK 17编译的record类，在JDK 8上直接抛java.lang.UnsupportedClassVersionError。生产环境不能只看“有JDK”，而要看java -version输出是否匹配构建时的source和target参数。

• Spring Boot 3.x 要求最低 JDK 17，老项目升级前必须验证所有依赖（如log4j-core 2.17+才完全支持JDK 17）
• 使用javac -version和java -version分别检查编译器与运行时版本，二者不一致极易埋雷
• 推荐在/opt/java下并行安装多个JDK，并通过update-alternatives --config java切换，避免全局污染

Tomcat部署WAR包时CLASSPATH加载顺序很关键

Tomcat的类加

• 禁止在WEB-INF/lib中打包javax.servlet-api或tomcat-jdbc等容器已提供的API
• 数据库驱动统一放在$CATALINA_HOME/lib，而非每个WAR里重复打包，便于连接池统一管理
• 若需隔离日志实现（如Logback），确保WEB-INF/lib中只有logback-classic.jar和logback-core.jar，删掉冲突的slf4j-log4j12.jar

启动脚本必须显式指定JVM参数而非依赖默认值

Linux服务默认以root用户启动，但JVM堆内存不设上限时，-Xms和-Xmx会取物理内存的1/4，一台64G机器可能直接分配16G——这会挤占系统缓存、触发频繁GC甚至OOM Killer杀进程。

• 在$CATALINA_HOME/bin/setenv.sh中写死参数：

  export JAVA_OPTS="-Xms2g -Xmx2g -XX:+UseG1GC -Dfile.encoding=UTF-8"

• 务必添加-Duser.timezone=GMT+8，否则new Date()在日志或定时任务中可能跨天错乱
• 禁用-server（JDK 8u212+已废弃），改用-XX:+AlwaysPreTouch提前触碰内存页，减少首次请求延迟

生产环境禁止使用默认端口和明文管理界面

刚解压的Tomcat默认开放8005（shutdown端口）、8080（HTTP）、8009（AJP），且manager应用未设密码——这等于把服务器大门敞开。

• 修改$CATALINA_HOME/conf/server.xml：将port="8005"改为非标准端口（如8015），并在shutdown属性加随机字符串
• 注释掉conf/tomcat-users.xml中默认的admin角色，新增带manager-gui权限的独立用户，并用digest.bat/sh加密密码
• 如无需远程管理，直接删掉webapps/manager和webapps/host-manager目录，比“改密码”更彻底

真正麻烦的从来不是装不上，而是某个log4j-core-2.14.1.jar藏在某个子模块的lib目录里没被清理干净，或者JAVA_HOME指向了/usr/bin/java这个符号链接而非真实JDK路径——这些细节不会报错，但会让问题在凌晨三点突然爆发。