aarch64 Linux 安装 JDK 8u232 完整指南

简介面向64位ARM架构的JDK 8u232 Linux安装包专为华为鲲鹏920处理器与银河麒麟V10操作系统准备适合在信创及国产化环境搭建Java运行平台的开发、运维人员。压缩包内共299个文件约96.63MB以so动态库、jar归档、properties配置文件、jdk相关命令行工具及man手册页为主体解压后即是一套相对完整的JDK 1.8.0_232开发运行环境。目前已有1194人学习/下载反映出该组合在国产平台部署中的常见需求。除了javac、java、jar、javadoc等基础工具包内还提供JVM运行所需的ARM64本地化动态库、安全管理相关证书库以及多个调试与监控命令可支撑Java应用的编译、打包、运行、排障和性能分析。对需要在鲲鹏920或银河麒麟V10上快速落地Java服务的团队而言这份离线安装包省去了自行寻找适配版本的麻烦能够直接解压配置后投入使用。 一个jdk-8u232-linux-aarch64.tar.gz文件放在下载目录里还没什么感觉等你真正站到一台 aarch64 的 Linux 服务器前面才会意识到这个包有多关键。我记得第一次在一台鲲鹏机器上部署 Java 服务随手拿了个 x86_64 的 JDK 就往上装结果 java 命令直接报Exec format error白折腾了半小时。这篇文章就把这个包从下载、校验、解压、配置到验证的完整链路讲清楚顺便把 aarch64 架构、8u232 版本这些容易踩坑的细节也一并说透。无论你是给国产化服务器装环境还是在 ARM 开发板上跑 Java这篇都适用。1. 版本与架构先搞清楚手里拿的是什么1.1 8u232 在 Java 8 版本序列中的位置Java 8 是目前为止生命周期最长的 LTS 版本之一。8u232 是 2019 年 10 月发布的一个 update 版本这个版本所处的阶段比较特殊——Oracle 从 8u211 开始把 JDK 的许可协议从 BCL 切换到了 OTN License Agreement商用场景需要订阅而 8u202 是最后一个可以免费商用的版本。所以如果你是在企业内部生产环境用要留意这个许可边界但个人开发、学习、测试或者使用 OpenJDK 发行版就没有这个问题。那 8u232 本身有什么好讲的它修复了一批安全漏洞包括一些可以在远程被利用的漏洞所以从纯安全性角度它比 8u202 更值得用。很多老项目的技术栈Spring Boot 1.x、老版本的 Dubbo、Hadoop 生态某些组件在 Java 8 上跑得最稳往上换 Java 11 或 17 会出现各种兼容性问题往下用 7 又太老。这就是为什么到现在还有大量项目钉死在 Java 8而 8u232 这个版本因为稳定性和安全修复的平衡成了很多人选择的落点。1.2 aarch64 到底是什么和 arm64 有什么区别aarch64 是 ARM 公司对 64 位执行状态ARMv8-A 及之后架构的官方称呼通常也叫 ARM64。在 Linux 世界里aarch64 和 arm64 这两个词经常混用指的是同一个东西。区别只是叫法来源不同aarch64 是 ARM 官方术语arm64 是 Linux 内核和 Debian/Ubuntu 等发行版在包管理里使用的名称。比如在 Ubuntu 上执行dpkg --print-architecture输出的就是arm64而uname -m输出的是aarch64。这个架构的硬件近几年越来越常见华为鲲鹏 920、飞腾 FT-2000/腾锐系列、Ampere Altra、AWS Graviton还有各类 ARM 开发板树莓派 4B 之后的 64 位系统也是 aarch64。在这些设备上跑 Java就必须用专门为 aarch64 编译的 JDK。x86_64 的 JDK 在 aarch64 上完全跑不了因为 CPU 指令集根本不同就像你不能把柴油加进汽油车里。这里顺便说一句不要因为网上有人说“aarch64 就是 arm64”就直接随便下一个arm64的包要去确认它真的是为 Linux aarch64 编译的。有些arm64的包可能是 macOS 的Apple Silicon 也是 ARM64 架构后缀不一样装上去同样报 Exec format error。认准linux-aarch64这个组合。2. 安装前的准备确认架构、下载与校验2.1 一条命令确认目标机器架构动手安装之前先确认你的目标机器到底是什么架构。这一条最容易被忽略但错一步后面全是坑。在终端执行uname -m如果输出aarch64那这个包就是对的。如果输出x86_64说明你拿错包了。还可以用lscpu看更详细的信息其中Architecture字段会显示aarch64。另外一个方法是看系统自带的二进制文件类型file /bin/ls输出里会包含ARM aarch64字样。这个命令在排查“为什么我的 java 跑不起来”的时候尤其有用。还有一个容易忽略的点如果你是在 Docker 容器里操作uname -m看到的是宿主机的内核架构。也就是说只要宿主机是 aarch64容器里即使没显式指定平台看到的也是aarch64。反过来在 x86_64 宿主机上用模拟器跑 aarch64 容器uname -m可能显示aarch64但性能会有损耗。确认了架构之后再往下走能省掉很多无谓的排查时间。2.2 下载渠道与文件完整性校验Oracle 官方下载需要注册账号这个流程比较烦但官方包的完整性和安全性最有保障。下载页面选择Java SE 8然后在产品列表里找Linux ARM 64 Compressed Archive文件名就是jdk-8u232-linux-aarch64.tar.gz。注意别选成Linux x64 Compressed Archive那是给 x86_64 用的。如果你不想注册 Oracle 账号也可以用开源的 OpenJDK 发行版比如 Eclipse TemurinAdoptium 项目、Azul Zulu、BellSoft Liberica它们都提供 aarch64 的 Linux 构建。选哪个取决于你们的合规要求和运维习惯。我个人在国产化服务器上遇到过只允许用特定发行版的客户这种情况要先问清楚再动手。下载完之后强烈建议做一次哈希校验。Oracle 官网上每一版都公布了 SHA-256 校验值把下载文件比对一下确定文件在传输过程中没有被破坏sha256sum jdk-8u232-linux-aarch64.tar.gz输出的哈希值和官网公布的值不一致说明文件不完整或者被篡改别用。这个习惯对所有软件安装都适用尤其是从非官方渠道下载的文件。3. 解压安装与环境变量配置3.1 目录规划把 JDK 放到哪里更合理解压之前先想好安装目录。Linux 下常见的选择是/usr/local/java或者/opt/java。我习惯用/usr/local/java因为这个目录通常用来放本机编译安装的软件符合 FHS文件系统层次结构标准的习惯。生产环境里建议把 JDK 放在独立分区或磁盘上避免系统分区满了影响运行这个属于运维层面的考量但提前规划不亏。解压命令很简单sudo mkdir -p /usr/local/java sudo tar -zxvf jdk-8u232-linux-aarch64.tar.gz -C /usr/local/java/解压之后/usr/local/java下会多出一个jdk1.8.0_232目录。这个目录名是固定的是 Oracle JDK 打包时的内部命名。为了避免以后升级版本时到处改路径我习惯再加一个软链接cd /usr/local/java sudo ln -s jdk1.8.0_232 jdk8这样JAVA_HOME可以直接指向/usr/local/java/jdk8后面切换到其他 8u 版本时只需要把软链接重新指一下环境变量完全不用动。3.2 JAVA_HOME、PATH、CLASSPATH 的配置细节环境变量配置是新手最容易出问题的地方。先说结论JAVA_HOME必须配PATH必须配CLASSPATH在绝大多数场景下可以不配。早年教程里爱写CLASSPATH.:$JAVA_HOME/lib/dt.jar:$JAVA_HOME/lib/tools.jar那是老黄历了。JDK 8 里这些 jar 已经不需要手动加进 classpath加上去反而可能引发一些奇怪的类加载问题。如果你只是运行普通的 Java 程序CLASSPATH配成.当前目录甚至不配都行。推荐的做法是在/etc/profile.d/下新建一个独立的脚本文件不要直接改/etc/profile或者~/.bashrc。原因很简单/etc/profile.d/下的脚本会在用户登录时被自动加载独立文件便于管理和卸载不会跟其他软件的配置产生冲突。sudo vim /etc/profile.d/java8.sh写入以下内容export JAVA_HOME/usr/local/java/jdk8 export PATH$JAVA_HOME/bin:$PATH保存后执行source /etc/profile.d/java8.sh注意PATH的拼接顺序$JAVA_HOME/bin要放在前面这样系统会优先使用我们配置的 JDK。有些机器上预装了 OpenJDK路径在/usr/bin/java如果你的PATH里/usr/bin排在前面java -version出来的可能还是旧版本这就是很多“我明明装好了为什么版本不对”问题的根源。3.3 用 alternatives 管理系统默认 JDK如果你所在的机器上同时存在多个 JDK或者你希望让整个系统的所有用户都能稳定使用这个 JDK推荐用update-alternatives来做管理。这套机制是 Debian/Ubuntu 系列发行版的标准做法它会维护一个符号链接指向当前选中的 JDK。注册刚才安装的 JDKsudo update-alternatives --install /usr/bin/java java /usr/local/java/jdk1.8.0_232/bin/java 1 sudo update-alternatives --install /usr/bin/javac javac /usr/local/java/jdk1.8.0_232/bin/javac 1然后查看当前选中状态sudo update-alternatives --config java如果系统里还有其他 JDK会在这里列出所有候选项输入编号即可切换。这个方式比手动改PATH更优雅因为它把“默认 JDK”的决定权统一交给了系统而不是依赖某个用户的 shell 配置。不过要注意update-alternatives只管理/usr/bin/java这个入口JAVA_HOME环境变量它管不到——如果你的程序是通过读取JAVA_HOME来找 JDK 的仍需单独配置。4. 验证安装与实测运行4.1 命令行验证三连配置完环境变量第一件事就是验证。执行下面三条命令java -version javac -version echo $JAVA_HOME正常输出应该是这样java version 1.8.0_232 Java(TM) SE Runtime Environment (build 1.8.0_232-b09) Java HotSpot(TM) 64-Bit Server VM (build 25.232-b09, mixed mode)注意Java HotSpot(TM) 64-Bit Server VM这一行说明你运行的是 64 位的 HotSpot 虚拟机。javac -version输出javac 1.8.0_232。echo $JAVA_HOME输出/usr/local/java/jdk8。如果你是在图形界面的 Linux 上装别忘了新开的终端才会重新加载配置文件已经开着的旧终端里环境变量可能还是旧的。要么重开终端要么手动source一下。4.2 一个最小测试程序跑通全流程光看版本号还不够写个测试程序跑一下确认编译和运行环节都没问题。在任意目录下创建HelloAarch64.javapublic class HelloAarch64 { public static void main(String[] args) { System.out.println(Hello, aarch64 JDK 8u232!); System.out.println(os.arch: System.getProperty(os.arch)); System.out.println(java.version: System.getProperty(java.version)); } }然后编译并运行javac HelloAarch64.java java HelloAarch64输出类似Hello, aarch64 JDK 8u232! os.arch: aarch64 java.version: 1.8.0_232到这里整个安装配置流程就算真正跑通了。os.arch输出aarch64说明 JVM 确实运行在 ARM 64 位环境下java.version确认了版本号。这个最小验证程序建议保留以后排查“JDK 是不是有问题”时可以直接复用。5. 常见问题与排查实战5.1 问题速查表这一段是给“装完发现不对劲”的人准备的。我把这几年的实操经验整理成一个表格按症状、原因、解决办法排列方便你对照排查。症状可能原因解决办法java: command not foundPATH 未配置或未生效检查/etc/profile.d/java8.sh内容重新source或开新终端cannot execute binary file: Exec format error架构不匹配uname -m确认真实架构换成对应的linux-aarch64或linux-x64包java -version显示的版本不是 8u232PATH 顺序不对系统里有旧 JDK用which java查看实际路径调整 PATH 顺序或用update-alternatives切换解压后找不到jdk1.8.0_232目录解压命令使用了错误的参数检查 tar 包内容tar -tzf jdk-8u232-linux-aarch64.tar.gzjavac: command not found只注册了 java 没注册 javac补上update-alternatives --install /usr/bin/javac ...程序启动报UnsupportedClassVersionError编译版本与运行版本不一致确认javac -version和java -version一致重新编译其中Exec format error出现频率最高而且最容易让人摸不着头脑。这个报错其实不是“文件损坏”而是内核在加载可执行文件时发现它的格式和当前架构不匹配。x86_64 的二进制在 aarch64 上跑或者反过来都会报这个错。遇到它先别急着重装file命令看一下可执行文件的架构往往一眼就能定位。5.2 多版本 JDK 共存与切换实际工作中一台机器上装两个甚至三个 JDK 是很常见的事。比如系统里原本有 OpenJDK 11新项目要求 JDK 8再后来又要 JDK 17。这时候建议彻底放弃“改JAVA_HOME环境变量”这种笨办法用update-alternatives统一管理。把每个版本的 java 和 javac 都注册进去然后随时切换sudo update-alternatives --config java sudo update-alternatives --config javac这个方式有一个天然的坑JAVA_HOME不会跟着变化。很多应用比如 Maven、Gradle、Tomcat启动脚本会优先读取JAVA_HOME。我自己常用的做法是写一个小的切换脚本放在/usr/local/bin下比如switch-jdk8.sh和switch-jdk11.sh内容就是重新设置/etc/profile.d/java.sh里的软链接目标然后提示用户重新登录。这种方式在团队协作的服务器上尤其好用因为每个人打开的 shell 可能已经加载了不同的环境变量谁也说不清谁是对的统一用脚本切换至少能保证文档可追溯。5.3 关于 glibc 和系统依赖的补充最后补充一个不太容易被注意到的问题Oracle JDK 8u232 的 aarch64 包对系统的 glibc 版本有最低要求通常是 glibc 2.17 或更新版本。如果你的系统是特别老的发行版比如 CentOS 6 的 ARM 版本可能装不上这个 JDK。排查方法很简单遇到version GLIBC_2.17 not found之类的报错说明系统 glibc 太旧要么升级系统要么换用更早的 JDK 版本。我个人在实际部署中的体会是JDK 安装这件事90% 的问题都出在“架构不匹配”和“环境变量没生效”这两个点上而不是 JDK 本身。所以每次在新的 aarch64 机器上装完我都会先把uname -m输出、java -version输出、echo $JAVA_HOME输出整整齐齐地贴到笔记里作为环境基线记录。以后机器出问题第一件事就是拿基线比对。最后再分享一个小技巧如果你要在一批同样的 aarch64 机器上批量部署先把jdk1.8.0_232目录整体打成 tar 包分发到目标机器后直接解压再执行一遍 alternatives 注册比每台机器都重新走一遍下载安装流程省事得多。本文还有配套的精品资源点击获取