简介JDK 8u321针对Linux AArch64ARM64架构服务器而准备的安装包面向运维工程师、分布式系统管理员及需要在ARM平台部署Java应用的开发人员。凭借高效能与低功耗特性AArch64已越来越多地用于数据中心和云基础设施这一压缩包正是为简化Java环境在此类服务器上的交付与部署而设计。压缩包共含406个文件大小约71.02MB以核心可执行文件java、javac、keytool、jstack、jmap等、动态链接库so、jar包及man手册为主体同时附带配置文件、安全证书cacerts与许可文档。解压后即可得到完整的JDK目录结构覆盖编译、运行、监控与调优等场景其中unpack200、pack200等辅助工具和properties资源也便于后续调整JVM参数与安全策略。目前已有1672人学习或下载。相比自行编译或跨平台适配此安装包能大幅缩短Java环境搭建时间在容器化部署或集群节点初始化时也能有效保障各节点环境一致性。深入理解包内工具与配置更有助于排查JVM性能瓶颈和内存溢出问题是AArch64服务器上构建分布式服务时值得留存的Java基础组件。1. 在 ARM64 服务器上装 JDK 8u321先搞清 aarch64 版本和 x64 版本不是一回事做 Linux 运维的人早晚会遇到一台 ARM 架构的服务器。某次我给一台基于鲲鹏处理器的机器配 Java 环境习惯性去官网下了 x64 的 JDK结果 java -version 直接报 Exec format error。那一刻才意识到JDK 的 tar.gz 包不是随便解压就能用的aarch64 和 x64 是两套完全不同的二进制。这个 jdk-8u321-linux-aarch64.tar.gz 就是专门给 ARM64 架构 Linux 用的 JDK 8 更新 321 版本解决的是「在 ARM 服务器上跑 Java 应用」这个具体问题。它不是给个人电脑装开发环境用的而是给服务器、分布式节点、容器镜像做基础运行时用的。适合两类人一类是在 ARM 云服务器或鲲鹏、飞腾等国产化机器上部署业务的运维和研发另一类是维护多架构 CI/CD 流水线、需要保证测试环境和生产环境 JDK 一致的平台工程师。接下来我会从选型、安装、验证到排错完整走一遍。2. 为什么需要 ARM64 版本的 JDK架构差异、版本选择与文件格式2.1 架构差异aarch64 到底是什么为什么不能通用aarch64 是 ARM 64 位架构的官方名称也叫 ARMv8-A。x86_64也叫 amd64是 Intel 和 AMD 用的架构两者的 CPU 指令集完全不同。Java 编译产物是字节码跨架构没问题但 JVM 本身是本地程序必须针对特定 CPU 架构编译。所以同一个 JDK 8 的 tar.gz有 x86_64 版本、aarch64 版本甚至还有 ARM 32 位版本。判断当前机器架构用uname -m。如果是 aarch64就下 aarch64 的包如果是 x86_64就下 x64 的包。混用的结果就是执行任何 Java 命令都报 cannot execute binary file: Exec format error。这个报错本身没有歧义就是在告诉你二进制格式不对不是文件损坏。2.2 为什么选 8u321补丁版本的价值与边界8u321 是 2022 年 1 月发布的 JDK 8 安全更新。这里要说清楚JDK 8 的版本号规则是 8u{补丁号}补丁号越大累积的安全修复和 bug 修复越多。如果你正在维护的是一个跑了好几年的老系统生产环境用的就是 JDK 8那选择一个较新的补丁版本是合理的。但如果你要新起一个项目我不会推荐 JDK 8——JDK 11 或 17 的长期支持版本更合适。8u321 的定位是存量系统的升级替换尤其是等保检查要求修复高危漏洞时把 JDK 从 8u252 之类更新到 8u321是一种常见操作。2.3 tar.gz 格式选型与 rpm、deb、zip 的对比格式适用场景特点tar.gz多版本共存、自定义路径、容器镜像解压即用不污染系统卸载靠删目录rpm / deb系统包管理统一安装自动注册环境变量但多版本管理麻烦zipWindows 习惯Linux 下少见权限位容易丢我一般首选 tar.gz原因是可控性强。rpm 装完你也不知道文件散落在哪tar.gz 解压到一个目录就算完事。对于需要同时跑 JDK 8 和 JDK 11 的场景tar.gz 几乎是唯一不折腾的选项。3. 服务器安装 JDK 8u321 的完整流程从校验到环境变量3.1 下载与完整性校验这一步不能跳过拿到 tar.gz 后第一件事不是解压而是校验文件完整性。官网通常会提供 SHA256 校验值。操作如下# 先确认系统已安装 sha256sum which sha256sum || yum install -y coreutils # 计算文件哈希 sha256sum jdk-8u321-linux-aarch64.tar.gz # 输出示例仅为演示格式实际值请以官方发布为准 # a3c52e26d4b5ebf5d2b1e7e5a1e3c5d7f9a2b4c6d8e0f1a2b3c4d5e6f7a8b9c0d jdk-8u321-linux-aarch64.tar.gz然后把输出结果和官方公布的 SHA256 对照。如果一致说明下载过程没有损坏如果不一致大概率是下载中断或镜像源文件有问题重新下载不要强行解压。这一步在真实工作中容易被忽略但服务器上环境变量都配好了才发现 Java 启动失败排查成本远高于花十秒钟算一次哈希。3.2 解压与目录规划约定优于配置# 创建统一的 JDK 安装目录 mkdir -p /usr/local/java # 解压到目标目录 tar -zxvf jdk-8u321-linux-aarch64.tar.gz -C /usr/local/java # 重命名去掉版本号后缀方便后续升级切换 ln -sfn /usr/local/java/jdk1.8.0_321 /usr/local/java/current我的习惯是保留解压出来的原目录名再用一个current软链接指向实际要用的版本。这样做的好处是将来升级 8u341 时只需要解压新版、改软链接然后重启应用。如果直接把目录名改成 jdk升级时要么先删旧目录要么面临目录名冲突。解压后可以看一眼目录结构是否完整ls /usr/local/java/current/bin/java ls /usr/local/java/current/jre/bin/java正常输出是包含 java 可执行文件的路径。如果 bin 目录下没有 java说明解压有问题。3.3 环境变量配置JAVA_HOME 和 PATH 的三种写法环境变量配置有三种层级适合不同场景。我按优先级从高到低说明。第一种写在/etc/profile.d/java.sh系统级生效适合所有用户都要用 Java 的情况cat /etc/profile.d/java.sh EOF export JAVA_HOME/usr/local/java/current export PATH$JAVA_HOME/bin:$PATH export CLASSPATH.:$JAVA_HOME/lib/dt.jar:$JAVA_HOME/lib/tools.jar EOF # 使配置立即生效 source /etc/profile.d/java.sh第二种写在用户家目录的.bashrc里只对当前用户生效。适合机器上有多个用户但只有你一个人需要 Java 的情况。写法相同只是文件位置不同。第三种不写环境变量直接在启动脚本里用绝对路径。适合你只需要在某个服务脚本中指定 Java 路径的情况/usr/local/java/current/bin/java -jar myapp.jar这种写法的好处是完全不依赖环境变量状态避免「手动执行启动脚本没问题但 systemd 服务起不来」的经典问题。我强烈建议在服务器上使用/etc/profile.d/方案这是 Linux 发行版预留的用户级环境变量扩展点包管理安装的软件也会往这里写配置。3.4 验证安装是否生效四步检查法# 第一步确认输出架构 java -version # 期望输出 # java version 1.8.0_321 # Java(TM) SE Runtime Environment (build 1.8.0_321-b07) # Java HotSpot(TM) 64-Bit Server VM (build 25.321-b07, mixed mode) # 第二步确认 javac 可用 javac -version # 期望输出javac 1.8.0_321 # 第三步确认 JAVA_HOME 变量正确 echo $JAVA_HOME # 期望输出/usr/local/java/current # 第四步确认实际执行的 java 来自你安装的路径 which java # 期望输出/usr/local/java/current/bin/java第四步最容易发现问题。如果 which java 输出的是/usr/bin/java说明系统里还有另一个 JDK可能是 yum 装的你的 JAVA_HOME 配置没有生效或者生效顺序不对。写一个简单的测试类验证编译和运行cat /tmp/Test.java EOF public class Test { public static void main(String[] args) { System.out.println(JDK install OK, arch: System.getProperty(os.arch)); } } EOF cd /tmp javac Test.java java Test输出中出现aarch64就说明当前运行的 JVM 确实是 ARM64 原生版本。4. 避坑指南ARM64 JDK 的六个常见问题排查4.1 问题一报错 Exec format error现象执行java -version直接报bash: exec: java: cannot execute binary file: Exec format error。原因JDK 的二进制架构和系统架构不匹配。最典型的场景是把 x64 的 JDK 包解压到了 aarch64 的机器上。还有一种可能file命令查看能发现文件本身没问题但程序无法加载。解决先uname -m确认架构再重新下载对应架构的 JDK。同时检查一下file /usr/local/java/jdk1.8.0_321/bin/java输出应包含ARM aarch64字样。4.2 问题二配了 JAVA_HOME 但 java 还是旧版本现象echo $JAVA_HOME输出正确但java -version显示的版本不是 8u321。原因/etc/profile.d/java.sh的配置生效时间晚于 PATH 中已有条目。另有一种可能.bashrc中后续有别的 export 语句覆盖了 PATH。解决在/etc/profile.d/java.sh末尾强制把 JAVA 路径放到最前export PATH$JAVA_HOME/bin:/usr/local/java/current/jre/bin:$PATH然后重新source /etc/profile.d/java.sh再验证。如果还不行检查/etc/profile和~/.bash_profile中是否有 PATH 重置逻辑。常见的情况是某些安装脚本执行了export PATH/usr/bin:/bin这类操作把之前配好的路径全部冲掉了。4.3 问题三解压后文件权限不对现象解压目录里的bin/java没有执行权限或者运行时报Permission denied。原因用某些 zip 工具或从 Windows 传输的 tar 包导致文件权限位丢失。tar.gz 在压缩时保留 Unix 权限位但如果下载过程经过某些不规范的传输工具权限可能被重置。解决接管整个目录的权限归属显式赋权chown -R root:root /usr/local/java/current chmod -R urX /usr/local/java/current # X 表示只对目录和已有执行权限的文件加执行位如果需要让非 root 用户也能执行再执行chmod -R orX。4.4 问题四系统里同时存在多个 JDK来回切换混乱现象tomcat 用的 JDK 8但某个脚本执行时调到了 JDK 11应用启动就报错。原因系统里安装了多个 JDKPATH 查找顺序混乱。JAVA_HOME 只影响用 JAVA_HOME 显式启动的程序不影响直接用 java 开头的命令。解决统一使用软链接管理。我只保留/usr/local/java/current作为唯一入口所有启动脚本都引用这个路径。如果是用 systemd 启动的服务在 service 文件的[Service]段加EnvironmentJAVA_HOME/usr/local/java/current EnvironmentPATH/usr/local/java/current/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin这样 systemd 启动的进程不会受用户环境变量影响。这是运维中最容易忽略的差异systemd 服务不读用户的.bashrc。4.5 问题五内存和 GC 参数在 ARM 上的默认行为差异现象同样的-Xmx参数和 GC 配置在 x86 服务器上稳定运行迁到 ARM64 机器后频繁 Full GC应用响应变慢。原因JDK 8 的默认 GC 是 ParallelGC其在 ARM64 上的行为与 x86 上不完全一致的问题已基本解决但部分应用直接使用老旧的 JVM 参数如-XX:UseParNewGC搭配 CMSCMS 在 JDK 8 中已在 8u321 后被废弃标记同时 ARM 上的内存带宽不占优势GC 卡顿会被放大。解决建议在 ARM64 上调整 GC 策略。我一般先试-XX:UseG1GC观察停顿时间。同时把 JVM 的启动参数完整打印到日志里java -XX:PrintFlagsFinal -version 21 | grep -i UseG1GC\|UseParallelGC调整后需要压测验证不要只改参数不回归。4.6 问题六native library 不兼容现象应用依赖某些本地库如加密模块、硬件驱动迁移到 ARM64 后启动报java.lang.UnsatisfiedLinkError。原因应用依赖的 so 文件是 x86_64 版本无法被 aarch64 的 JVM 加载。解决联系依赖库提供方获取 ARM64 版本。这是个前置问题不只是 JDK 层面能解决的。如果你负责的应用有 native 依赖迁移到 ARM 前必须先盘点所有 so 文件是否提供 aarch64 版本。这个环节的缺失是很多迁移项目延期的主因。5. 验证与进阶用检查脚本和容器构建固定下来这套安装方式5.1 一段自检脚本环境有没有异常一眼看清把前面的验证方法串成一个脚本适合在新机器上执行一次快速确认 JDK 环境是否正常#!/bin/bash # jdk_check.sh - ARM64 JDK 环境自检脚本 echo 系统架构检查 uname -m echo Java 版本 java -version 21 echo JAVA_HOME echo $JAVA_HOME echo 正在执行的 java 路径 which java echo 编译测试 cat /tmp/JdkCheck.java EOF public class JdkCheck { public static void main(String[] args) { System.out.println(Arch: System.getProperty(os.arch)); System.out.println(Java Version: System.getProperty(java.version)); } } EOF cd /tmp javac JdkCheck.java java JdkCheck rm -f JdkCheck.java JdkCheck.class echo 完成 我把这脚本放在/usr/local/bin/jdk_check.sh每台新服务器装完 JDK 后执行一遍输出一眼就能看出架构、版本和路径有没有问题。如果输出aarch64和1.8.0_321都对上安装就算通过。5.2 多节点一致性的保障用同一份 tar.gz不要每台单独下载在分布式场景下如果每台服务器单独下载安装很容易出现不同节点 JDK 版本不一致的问题。我的做法是把 tar.gz 放到内网对象存储或 HTTP 服务上初始化脚本统一拉取#!/bin/bash # install_jdk_internal.sh - 内网统一安装脚本 JDK_TARjdk-8u321-linux-aarch64.tar.gz INSTALL_DIR/usr/local/java # 从内网源下载 curl -fsSL http://internal.example.com/download/${JDK_TAR} -o /tmp/${JDK_TAR} # 解压并建立软链接 mkdir -p ${INSTALL_DIR} tar -zxvf /tmp/${JDK_TAR} -C ${INSTALL_DIR} ln -sfn ${INSTALL_DIR}/jdk1.8.0_321 ${INSTALL_DIR}/current # 写入环境变量 cat /etc/profile.d/java.sh EOF export JAVA_HOME/usr/local/java/current export PATH${JAVA_HOME}/bin:$PATH export CLASSPATH.:${JAVA_HOME}/lib/dt.jar:${JAVA_HOME}/lib/tools.jar EOF # 验证 source /etc/profile.d/java.sh java -version注意我特意把内网地址写成internal.example.com实际使用时要替换成你的内网服务地址。这个脚本解决的是「每台机器手动下载可能拿到不同版本」的问题。哈希校验可以加也可以依赖内网源本身的可信度。如果是追求严谨我会在脚本里加一段 SHA256 比对但只要内网源足够规范不比对也能接受。5.3 容器环境这个 tar.gz 适合做基础镜像层另一个我常用的场景是构建 ARM64 基础镜像。比如一个基于 ARM 平台的 Java 应用镜像Dockerfile 可以是FROM lcr.example.com/distroless/static:debian12 WORKDIR /app COPY jdk-8u321-linux-aarch64.tar.gz /tmp/ RUN tar -zxf /tmp/jdk-8u321-linux-aarch64.tar.gz -C /opt \ rm -rf /tmp/jdk-8u321-linux-aarch64.tar.gz \ ln -sfn /opt/jdk1.8.0_321 /opt/current ENV JAVA_HOME/opt/current \ PATH/opt/current/bin:$PATH COPY --frombuild /app/app.jar /app/ ENTRYPOINT [/opt/current/bin/java, -jar, /app/app.jar]构建出来的镜像架构取决于基础镜像架构。在 ARM64 机器上构建时Docker 会自动选择 linux/arm64 的基础镜像COPY 进去的 JDK 包必须是 aarch64 版本否则容器运行同样会报 Exec format error。这个脚本式的处理方式对团队协作特别有价值。我当年有次手忙脚乱地在一台 ARM 服务器上装完 JDK结果第二天机器重启后java命令找不到了。排查了半天发现是因为我当时把环境变量写在了某个用户的.bashrc里而那个用户是 CI 账号重启后根本不走交互式 shell。从那以后我每次在服务器上装 JDK都强制走/etc/profile.d/ 自检脚本的流程不管这台机器是生产环境还是临时搞实验的。希望帮到你。本文还有配套的精品资源点击获取