sha256sum校验是验证OpenJDK安装包完整性的首要步骤：下载后运行sha256sum命令比对官网提供的SHA-256值，不匹配即说明文件未下载完整或被篡改，应直接删除重下。
直接用 sha256sum 校验下载文件是否完整
下载完 OpenJDK 的 tar.gz 或 .zip 包后，别急着解压。官方发布页（如 Microsoft Build of OpenJDK、Adoptium、Eclipse Temurin）几乎都提供 SHA-256 哈希值。用 sha256sum 对比是最可靠的第一步：
- Linux/macOS：运行
sha256sum openjdk-11.0.24_linux-x64_bin.tar.gz，输出的哈希值必须与官网列出的完全一致 - Windows（PowerShell）：用
Get-FileHash -Algorithm SHA256 openjdk-11.0.24_windows-x64_bin.zip - 哈希不匹配 = 文件下载中断或被篡改，不是“损坏”，是“根本没下全”——直接删掉重下，别尝试修复
tar -tzf 能否列出内容，是判断 tar 包是否可解压的关键信号
如果校验通过但解压失败（比如 tar: Unexpected EOF in archive 或报错“truncated”），说明压缩层已损。此时用 tar -tzf 测试是否能读取目录结构：
- 运行
tar -tzf openjdk-11.0.24_linux-x64_bin.tar.gz | head -n 5 - 正常应快速输出前几行路径，如
jdk-11.0.24/bin/java、jdk-11.0.24/lib/libjvm.so - 若卡住、报
gzip: stdin: unexpected end of file或直接退出无输出，说明 gzip 流损坏，解压必然失败 - 这种损坏无法用
tar --skip-compressed或其他参数绕过，重下是唯一选择
解压后 java -version 报 “corrupted” 或共享库缺失，大概率不是文件损坏，而是 ABI 不兼容
很多用户把 error while loading shared libraries: libz.so.1: cannot open shared object file 误判为安装包损坏。实际上，OpenJDK 11.0.24 等版本在构建时链接了较新的 glibc 符号，而 CentOS 7、Ubuntu 18.04 等旧系统自带的 libz 或 libstdc++ 版本太低：
- 先确认系统 glibc 版本：
ldd --version和strings /lib64/libz.so.1 | grep ZLIB_VERSION - 再检查 JDK 二进制依赖：
ldd jdk-11.0.24/bin/java | grep "not found" - 如果只在特定老系统上出问题，其他机器正常，基本可排除文件损坏，属于发行版适配问题
- 临时绕过方法：用
patchelf替换 rpath（不推荐生产环境），或降级使用 OpenJDK 11.0.22（已知对 glibc 2.17 兼容）
Windows 上双击 .exe 安装包提示“已损坏”或“不是有效 Win32 应用程序”，优先查架构和数字签名
这类提示常被当成文件损坏，实则多为环境不匹配：
- 检查安装包是否为 x64 版本却在 ARM64 设备（如 Surface Pro X）上运行——会直接报错，而非弹窗提示“损坏”
- 右键安装包 → “属性” → “数字签名” 选项卡：若显示“此数字签名在该文件中无效”或空白，说明下载中途被代理/杀软拦截并重写，需换网络重下
- 用
file命令（WSL 或 Cygwin）查看真实格式：file jdk-11.0.24_windows-x64_bin.exe，输出应含PE32+ executable (GUI) x86-64；若显示data或HTML document，说明下载到的是错误响应（如 403 页面） - 不要用第三方“修复工具”强行打开 .exe，这类操作可能触发安全软件误报或破坏原始字节
