Java服务器运行环境的核心组件是JDK、应用服务器（如Tomcat/Jetty）、系统级服务管理（如systemd或supervisord）和基础OS依赖（glibc、locale等），缺一不可。
Java服务器运行环境的核心组件是什么
Java服务器运行环境不是“装个JDK就行”，而是由 JDK、应用服务器（如Tomcat/Jetty）、系统级服务管理（如systemd或supervisord） 和 基础OS依赖（glibc、locale等） 共同构成。缺任何一层，都可能在启动时卡在 NoClassDefFoundError、UnsupportedClassVersionError 或进程秒退却无日志的状况里。
如何验证JDK版本与应用兼容性
很多线上问题源于JDK大版本不匹配：用JDK 17编译的WAR包部署到JDK 8服务器上，会直接报 java.lang.UnsupportedClassVersionError: Unsupported major.minor version；反过来（JDK 8编译 → JDK 17运行）虽能启动，但若用了 javax.* 包且没加 --add-modules=ALL-SYSTEM，也会在运行时抛 NoClassDefFoundError。
- 检查编译目标版本：
javap -v YourClass.class | grep "major version"（52=JDK 8，55=JDK 11，61=JDK 17） - 确认服务器JDK实际版本：
/usr/lib/jvm/java-17-openjdk-amd64/bin/java -version，注意别只看java -version—— 可能是软链接指向旧版本 - Tomcat 9+ 要求最低JDK 11；Spring Boot 3.x 强制要求JDK 17+，且需启用
--enable-preview（如用到虚拟线程）
Tomcat部署时CLASSPATH和JAVA_HOME为什么总出错
Tomcat本身不读系统级 JAVA_HOME 环境变量，它优先读 $CATALINA_HOME/bin/setenv.sh 中显式声明的 JAVA_HOME。如果没这个文件，它会 fallback 到 which java 找到的第一个 java，而该命令结果常被 /usr/bin/java（系统默认OpenJDK 11）污染，哪怕你已用 update-alternatives 切换过。
#!/bin/sh # $CATALINA_HOME/bin/setenv.sh export JAVA_HOME=/usr/lib/jvm/java-17-openjdk-amd64 export CLASSPATH=$JAVA_HOME/lib/tools.jar:$CATALINA_HOME/lib/servlet-api.jar # 注意：不要在这里追加应用jar，应放WEB-INF/lib下
-
setenv.sh必须有执行权限：chmod +x setenv.sh -
CLASSPATH在这里只用于Tomcat自身启动类（如Bootstrap），不影响Web应用 —— Web应用的类路径由WEB-INF/classes和WEB-INF/lib/决定 - 若用
systemd启动Tomcat，必须在.service文件中用Environment=JAVA_HOME=...显式设置，否则setenv.sh可能不生效
为什么服务起来后访问404或500却看不到日志
最常见原因是日志输出被重定向或权限阻断：Tomcat默认把 catalina.out 写入 $CATALINA_HOME/logs/，但如果该目录属主是 root，而Tomcat以普通用户（如 tomcat）运行，就会静默失败；另外，logging.properties 中的 1catalina.org.apache.juli.AsyncFileHandler.level = FINE 若设为 OFF，连启动异常都不会记。
- 检查日志目录权限：
ls -ld $CATALINA_HOME/logs，确保运行用户有写权限 - 强制刷新日志配置：
echo 'org.apache.catalina.core.ContainerBase.[Catalina].[localhost].level = FINE' >> $CATALINA_HOME/conf/logging.propert
ies
- 临时绕过日志重定向排查：
sudo -u tomcat $CATALINA_HOME/bin/catalina.sh run（前台运行，错误直接打屏） - Spring Boot应用若打成
jar直接运行，要加--logging.config=classpath:logback-prod.xml，否则默认只输出INFO以上
真正麻烦的从来不是“怎么装”，而是“哪个环节悄悄覆盖了前一个环节的配置”。比如 systemd 的 EnvironmentFile 会覆盖 setenv.sh，而 setenv.sh 又会覆盖 /etc/environment —— 配置层级多，但每层都只做一件事，漏查一层就卡半天。
