简介面向Linux运维与后端开发者的JDK 8u321 AArch64平台部署资源专为ARM64架构服务器场景准备可解决Java运行环境在64位ARM服务器上的安装配置与日常维护问题适合具备一定Linux基础、需要搭建分布式服务或容器化环境的运维人员。压缩包共406个文件约71.02MB以可执行程序、so动态库、jar包、properties配置、md文档及ttf字体等为主涵盖编译器、运行环境与jstat、jmap、jstack等诊断工具目录结构完整。已有1676人学习下载。资源围绕AArch64平台优化展开读者可据此完成环境变量配置、JVM参数调优与内存溢出排查并了解其在微服务、分布式数据库及Hadoop集群中的一致性部署思路是ARM服务器上构建稳定Java运行环境的实用参考。1. 一次 aarch64 服务器上装 JDK 的翻车现场上周帮某实验室迁移一套分布式日志采集服务机器是 ARM 架构的 Linux 服务器运维同事图省事直接拿 x86 的 JDK 包往上怼java -version报cannot execute binary file服务起不来排查了半小时才发现是架构不对。这种坑在国产化服务器、云厂商 ARM 实例越来越多的今天特别常见。jdk-8u321-linux-aarch64.tar.gz就是给这类机器准备的Linux 系统、aarch64 架构、JDK 8 第 321 更新版。这篇笔记按我实际部署的顺序写从确认架构、选版本到解压、配环境变量、验证再到装坏了怎么救新手能照着走通熟手能对照参数取舍。2. 装前先对账架构、版本和依赖三件事动手解压之前有三件事必须先确认清楚否则后面全是白费功夫。这一章不讲大道理只讲怎么在服务器上把这三件事查明白以及查出来不对时怎么决策。2.1 用 uname 和 ldd 确认 aarch64 架构第一步永远是确认 CPU 架构。很多人以为uname -m看到x86_64才是常态其实现在 ARM 服务器不少aarch64就是 64 位 ARM 的标识。登录服务器后先跑# 查看内核架构aarch64 才说明这个包能用 uname -m # 再看一眼内核版本和发行版确认 glibc 版本不会太老 uname -r cat /etc/os-releaseuname -m输出aarch64才能继续如果输出x86_64说明你拿错包了得换 x64 版本别硬装。/etc/os-release主要看ID和VERSION_IDCentOS 7、Ubuntu 18.04 以上基本都没问题。JDK 8 对 glibc 的要求不高常见做法是用ldd --version看一眼2.17 以上就稳。这里有个血泪经验有些精简版容器镜像里uname正常但缺libc的某些符号装完java能跑、javac报错所以架构确认完顺手把ldd --version也跑了一次查清。2.2 JDK 8u321 这个版本号意味着什么8u321拆开看8是大版本u321是 update 321属于 JDK 8 后期的一个补丁版本。选它而不是随便一个 8u 版本主要看两点。一是这个版本已经包含了到 2021 年前后的安全补丁比 8u151、8u191 这些老版本在 TLS 协议支持、证书校验上更完整跑分布式组件时不容易遇到握手失败。二是 aarch64 的官方构建在 8u 后期才比较稳定太早的版本在 ARM 上偶发 JIT 相关问题运维圈里一般建议 aarch64 环境至少用 8u2xx 之后的包。版本对照可以看这张表方便你判断手上的包合不合适版本号大致时间aarch64 支持情况建议8u151 及更早2017 前后构建不完整不建议 ARM 使用8u191 ~ 8u2512018 ~ 2020基本可用可用但补丁偏旧8u3212021 前后稳定推荐8u3xx 之后2022 起稳定也可注意与业务兼容需要说明的是JDK 8 各 update 之间 API 兼容业务代码一般不用改差异主要在安全补丁和少量行为修正。所以升级到 8u321 的风险很低反而是从更老版本升上来能少踩不少证书和加密套件的坑。2.3 依赖检查别让 glibc 和磁盘空间背锅除了架构还有两个容易被忽略的前置条件。一是磁盘空间JDK 解压后大约 300MB 上下但/usr/local或/opt所在分区如果只剩几十兆解压到一半就失败报No space left on device。装之前先看# 看目标分区剩余空间建议至少留 1G df -h /usr/local # 确认没有旧版 java 抢占 PATH which java java -version 21df -h看Avail列低于 500M 就先清理。which java如果指向/usr/bin/java说明系统可能自带了一个 OpenJDK后面配环境变量时要注意 PATH 顺序否则你装的新 JDK 会被旧版覆盖。我一般会先把旧版路径记下来装完对比java -version的输出确认切换成功。这两步花不了一分钟但能省掉后面排查「为什么版本没变」的时间。3. 解压与目录规划把 JDK 放到该放的位置架构和版本都对上了接下来是落地。这一章讲目录怎么选、解压命令怎么写、权限怎么设以及为什么我不建议直接解压到当前用户目录。3.1 选 /usr/local 还是 /opt目录约定Linux 上装第三方软件常见两个位置/usr/local和/opt。我的习惯是 JDK 这类基础运行时放/usr/local/因为很多脚本和文档默认从这个路径找/opt更适合放带完整目录结构的商业软件。两种都行关键是全公司统一别这台机器/usr/local/jdk8、那台/opt/java后面写部署脚本会疯。确定根目录后解压目标定为/usr/local/jdk1.8.0_321这个命名和包内顶层目录一致方便识别。先建目录再解压# 进入存放安装包的目录假设包已上传到 /tmp cd /tmp # 解压到 /usr/local-C 指定目标目录 sudo tar -zxvf jdk-8u321-linux-aarch64.tar.gz -C /usr/local/ # 确认解压结果 ls -ld /usr/local/jdk1.8.0_321tar的参数含义-z走 gzip 解压-x是解包-v打印过程方便看进度-f指定文件名。-C一定要放在文件名前面顺序错了会报错。解压完ls能看到目录就说明包完整。如果报gzip: stdin: not in gzip format多半是上传时文件损坏重新传一遍别怀疑命令。3.2 权限与属主别让 root 和普通用户打架解压出来的目录默认属主是执行解压的用户。如果当时用的是sudo属主就是 root普通业务用户读得到但改不了一般够用。但如果你的服务以某个专用用户运行又需要往 JDK 目录写东西比如临时文件就得调整。常见做法是保持 root 属主、目录权限 755业务用户只读执行# 属主设为 root组设为 root权限 755 sudo chown -R root:root /usr/local/jdk1.8.0_321 sudo chmod -R 755 /usr/local/jdk1.8.0_321 # 验证 java 可执行 /usr/local/jdk1.8.0_321/bin/java -versionchown -R递归改属主chmod -R 755保证目录可进入、文件可读可执行。这里有个细节不要图省事chmod -R 777JDK 目录被任意用户可写等于给提权留了口子运维规范里这是大忌。验证时直接用绝对路径跑java -version能输出java version 1.8.0_321就说明二进制本身没问题接下来才轮到环境变量。4. 配置环境变量JAVA_HOME 和 PATH 的写法JDK 装好只是文件躺在磁盘上要让所有用户和脚本都能用得配环境变量。这一章讲清楚JAVA_HOME、PATH、CLASSPATH三个变量的作用和写法以及全局配置和单用户配置的取舍。4.1 全局配置 /etc/profile.d 的做法环境变量配在/etc/profile里对所有用户生效但直接改这个文件容易和系统升级冲突。更规范的做法是在/etc/profile.d/下新建一个jdk.sh系统登录时会自动加载该目录下所有.sh# 新建全局 JDK 环境变量文件 sudo tee /etc/profile.d/jdk.sh /dev/null EOF # JDK 8u321 aarch64 环境变量 export JAVA_HOME/usr/local/jdk1.8.0_321 export PATH$JAVA_HOME/bin:$PATH export CLASSPATH.:$JAVA_HOME/lib/dt.jar:$JAVA_HOME/lib/tools.jar EOF # 让当前会话立即生效 source /etc/profile.d/jdk.sh逐行说明JAVA_HOME指向 JDK 根目录很多中间件Tomcat、Kafka、Hadoop启动脚本靠它找 javaPATH把$JAVA_HOME/bin放在最前面保证java、javac优先用新装的CLASSPATH里的.表示当前目录dt.jar和tools.jar是 JDK 8 自带的工具类库虽然现在很多项目用 Maven 管理依赖但老脚本仍可能依赖它。tee加 heredoc 的写法比echo 更清晰也避免引号转义问题。4.2 单用户配置与 PATH 顺序的坑如果服务器多人共用、你只想给自己配改~/.bashrc或~/.bash_profile即可内容同上把export三行追加进去再source。但这里有个高频坑PATH的拼接顺序。写成export PATH$PATH:$JAVA_HOME/bin就把新 JDK 放到了末尾系统自带的/usr/bin/java会先被命中java -version还是旧版本。正确写法一定是$JAVA_HOME/bin:$PATH新路径在前。另一个坑是source了但新开终端不生效。原因通常是写进了~/.bashrc而登录 shell 读的是~/.bash_profile或者反过来。稳妥做法是两个文件都加或者在~/.bash_profile里显式source ~/.bashrc。配完用echo $JAVA_HOME和which java双重确认which输出应该是/usr/local/jdk1.8.0_321/bin/java不是/usr/bin/java。5. 避坑与排查装完起不来的五种情况这一章是我这些年装 JDK 攒下的排查清单每条按「现象 → 原因 → 解决」写遇到问题直接对号入座比从头猜快得多。5.1 现象cannot execute binary file原因包架构和机器架构不匹配最常见是 x86 包放到 aarch64 机器上或者反过来。解决uname -m确认架构aarch64 机器必须用linux-aarch64的包重新下载对应版本别试图用兼容层硬跑JDK 这种底层运行时兼容层问题更多。5.2 现象java -version 报错找不到 libjli.so原因JAVA_HOME配了但PATH没生效或者用相对路径启动了 java导致运行时找不到同目录的库。解决用绝对路径/usr/local/jdk1.8.0_321/bin/java -version先验证二进制完好再检查echo $PATH里$JAVA_HOME/bin是否在最前必要时重新source环境变量文件。5.3 现象解压报 No space left on device原因目标分区空间不足tar 解压到一半写不进去。解决df -h看分区清理日志或临时文件腾出至少 1G删掉解压了一半的残留目录再重来。注意别只删包不删残留半截目录会让后续ls判断出错。5.4 现象java -version 显示的还是旧版本原因系统自带 OpenJDK 的路径在PATH里排前面或者alternatives机制接管了java命令。解决先which -a java列出所有 java确认新 JDK 路径如果是alternatives管理用update-alternatives --config java切换或者直接把$JAVA_HOME/bin提到PATH最前。5.5 现象普通用户能跑 java服务启动脚本报 JAVA_HOME not set原因环境变量只配在了某个用户的~/.bashrc而服务以另一个用户如app运行读不到。解决把变量放到/etc/profile.d/jdk.sh做全局配置或者在该服务的启动脚本里显式export JAVA_HOME...。分布式服务尤其要注意不同节点用户可能不一致统一走全局配置最省心。6. 装完怎么验证三条命令跑通再交付装完不验证等于没装。我交付前固定跑三条命令再加一个实际编译运行的小测试确认这套 JDK 在 aarch64 上真的能用而不是只有java -version好看。第一条版本与架构核对# 输出应包含 1.8.0_321 和 aarch64 字样 java -version 21java -version的输出里第二行会带64-Bit Server VMaarch64 的包通常还会在构建信息里体现架构。如果只看到版本号没看到架构用java -XshowSettings:properties -version 21 | grep os.arch精确确认输出os.arch aarch64才算对。第二条编译运行一个最小程序验证javac和 JVM 都正常# 写一个最小测试类 cat /tmp/HelloJdk.java EOF public class HelloJdk { public static void main(String[] args) { System.out.println(jdk ok: System.getProperty(os.arch)); } } EOF # 编译并运行 cd /tmp javac HelloJdk.java java HelloJdk预期输出jdk ok: aarch64。这一步能同时验证编译器、类加载和运行时比单看版本号可靠。如果javac报找不到类检查CLASSPATH里有没有多余的旧路径干扰。第三条确认环境变量在干净会话里也生效# 用登录 shell 模拟新会话确认全局配置生效 bash -lc echo $JAVA_HOME; which java输出应该是/usr/local/jdk1.8.0_321和对应的 bin 路径。这一步专门抓「当前终端能用、新开终端失效」的问题分布式环境批量部署时尤其重要因为服务进程往往不是从你的交互终端启动的。三条都过了再跑一个业务侧的小验证拿项目里一个最简单的启动脚本或java -jar跑一下看日志里 JVM 参数是否正常加载。我一般还会顺手jps看一眼进程确认没有残留的旧 JDK 进程。从那以后我每次装 JDK不管多急都强制走一遍「架构确认 → 绝对路径验证 → 干净会话验证」这三步宁可多花五分钟也不让服务在半夜因为一个架构不匹配挂掉。这套包和流程在 aarch64 的 Linux 服务器上跑分布式组件足够稳需要的话按上面的步骤复现一遍即可。希望帮到你。本文还有配套的精品资源点击获取