需先确认系统架构与发行版：uname -m查cpu架构（如aarch64），cat /etc/os-release | grep -e "(name|version_id)"查发行版，ldd --version验glibc版本（openjdk 21+需≥2.28），避免exec format error或共享库错误。
确认系统架构与发行版是否匹配
OpenJDK 镜像或安装包对 x86_64、aarch64 等架构敏感，且不同发行版（如 Ubuntu 22.04、CentOS Stream 9、统信 UOS 1060）的 glibc 版本和包管理机制差异很大。直接用错镜像会导致 exec format error 或 cannot open shared object file 错误。
执行以下命令快速定位：
-
uname -m—— 查看实际 CPU 架构（注意：ARM 设备可能返回aarch64，而非arm64） -
cat /etc/os-release | grep -E "(NAME|VERSION_ID)"—— 明确发行版名称与版本号 -
ldd --version—— 检查 glibc 版本，OpenJDK 21+ 要求glibc >= 2.28，而 CentOS 7 默认是 2.17，不兼容
验证基础依赖是否就位
很多 OpenJDK 运行时错误（比如 java.lang.UnsatisfiedLinkError 或图形界面崩溃）其实不是 JDK 本身问题，而是缺底层库。尤其在 Alpine、OpenWRT 或最小化安装的 Linux 上容易遗漏。
常见缺失项及检查方式：
-
libz.so.1、libstdc++.so.6：运行ldd $(readlink -f $(which java)) | grep "not found" - 字体与图形支持（Swing/FX 应用）：Ubuntu/Debian 需
fonts-dejavu-core，CentOS 需fontconfig+dejavu-sans-fonts - 时区数据（
java.time行为异常）：确保/usr/share/zoneinfo/存在且可读，容器中常被精简掉
检查内存与文件描述符限制
Java 进程启动失败但无明确报错？大概率是资源硬限制卡住。特别是轻量服务器（如 2GB 内存的 OpenWRT 或云函数环境），JVM 默认堆参数可能直接触发 Cannot allocate memory。
关键检查点：
- 可用内存：
free -h—— OpenJDK 17+ 的 G1 GC 在 OutOfMemoryError: Compressed class space - 最大文件描述符：
ulimit -n—— Tomcat、Netty 类应用常需 >65535；若值为 1024，需改/etc/security/limits.conf或 systemdLimitNOFILE - swap 使用状态：
swapon --show—— JVM 倾向避免 swap，但某些嵌入式设备（如 OpenWRT）根本无 swap，需靠-XX:+UseZGC或调低堆
确认时间同步与证书信任库是否有效
看似无关的系统配置，却会引发 Java 应用静默失败：HTTPS 请求抛 javax.net.ssl.SSLHandshakeException，或 java.time.ZoneId.systemDefault() 返回 GMT 而非本地时区。
必须验证：
- 系统时间是否准确：
timedatectl status | grep "System clock"—— 误差 >5 秒可能导致 TLS 握手失败 - CA 证书路径是否被 JVM 识别：
keytool -list -cacerts | head -n 1—— 若提示Keystore was tampered with或空输出，说明JAVA_HOME/jre/lib/security/cacerts损坏或未更新 - 容器环境额外注意：
docker run默认不共享宿主机/etc/timezone和/etc/ssl/certs，需显式挂载或使用--cap-add=SYS_TIME
最容易被忽略的是：JDK 安装后没清空旧版本残留的 alternatives 配置或 /etc/profile.d/java.sh，导致 java -version 显示正确，但实际进程加载的是另一个 libjvm.so。建议部署前统一用 readlink -f $(which java) 和 lsof -p $(pgrep -f "java.*yourapp") | grep libjvm 双重确认。
