尧图网站建设 
简介面向需要在ARM Linux平台部署Java环境的开发者与运维人员jdk-8u391-linux-aarch64.tar是Oracle JDK 8u391针对64位ARM架构的官方Linux发行包可直接用于搭建Java 8运行与编译环境解决ARM设备上Java环境缺失或版本不兼容的问题。压缩包约71.23MB共403个文件含so动态库、jar库包、java源文件、properties配置文件、html文档及命令行工具等类型其中动态库与jar包支撑JVM底层调用和核心类库md与txt文档辅助安装排错整体为标准JDK目录布局便于定位bin、lib、jre等模块。已有1477人学习下载适合在树莓派、飞腾等ARM平台上进行Java应用开发、服务部署或容器镜像制作的用户。获取后可获得完整的JDK组件包括javac/java/jar等开发运行工具、jre运行环境、源码归档、安全配置与字体文件配合官方文档即可完成安装与环境变量配置后续还可参照同版本更新策略升级维护。 搞Java开发的朋友都知道JDK安装本该是最基础的活儿。但一旦机器换成了ARM架构整套流程就完全不是那么回事了。我最近在一台飞腾处理器的服务器上部署环境下载的正是jdk-8u391-linux-aarch64.tar这个安装包中间踩了不少坑也把整个流程彻底理顺了。这篇博文就围绕这个文件名展开聊聊ARM Linux环境下JDK 8u391从下载、校验、安装到配置的完整实操过程以及我在这个过程中遇到的各种问题和排查思路。如果你手头也是国产化服务器、ARM云主机或者树莓派这类ARM开发板这篇文章应该能帮你少走不少弯路。1. 认清你的环境aarch64到底是什么1.1 ARM、aarch64、ARM64这些叫法别搞混很多刚接触ARM服务器的人一上来就被这几个名词绕晕了。ARM是芯片架构的统称就像x86一样是设计指令集的公司名和架构名。aarch64则是ARM架构下的64位执行状态也叫ARM64这是Linux内核和大多数开源软件里通用的称呼。用uname -m命令查看当前系统架构如果输出aarch64说明你运行的是ARM 64位系统如果输出x86_64那就是Intel/AMD的64位环境。这里有个细节值得注意有些发行版会显示arm64这其实是同一个东西只是Linux发行版和上游项目各自的叫法差异。在下载JDK、编译软件、拉取Docker镜像时aarch64和arm64表示同一个平台目标。1.2 为什么JDK安装包要区分架构JDK不是纯文本脚本它包含大量本地代码比如HotSpot虚拟机、JIT编译器、垃圾回收器的底层实现这些都必须针对特定CPU指令集编译。x86用的是CISC复杂指令集ARM用的是RISC精简指令集二者完全不兼容。你不可能把x86的二进制扔到ARM机器上跑就像你不能把一把英制扳手用到公制螺丝上一样看似都是扳手接口对不上就是拧不动。常见的错误就是下载了jdk-8u391-linux-x64.tar.gz然后在ARM机器上解压执行结果报出Exec format error。这个问题我在第6节会详细说这里先提醒一句下载之前先跑uname -m确认架构这是所有后续操作的地基。2. 版本选型为什么偏偏是8u3912.1 8u391在JDK 8版本线里的位置JDK 8是Java历史上的一个里程碑版本2014年发布到现在已经十年多了依然是大量企业系统的默认运行时。Oracle对JDK 8的公开更新持续了很久8u391是其中一个比较后期的update版本修复了大量安全漏洞和稳定性问题。如果你所在的公司还在用Spring Boot 2.x、老版本的Dubbo、或者某些只兼容Java 8的国产中间件那么8u391就是一个安全性和兼容性都相对均衡的选择。它不是最新的但足够稳定它不会像JDK 7那样被主流框架抛弃也不会像JDK 17那样对老项目有较大的迁移成本。2.2 Oracle JDK与OpenJDK怎么选标题里写的是Oracle的JDK命名规范jdk-8u391但实际部署时你还有OpenJDK的选项比如Eclipse TemurinAdoptium项目、Azul Zulu、以及国内厂商做的龙井JDK等。Oracle JDK 8的许可协议是OTN License Agreement个人开发、测试和学习是免费的但生产环境需要审视授权问题。OpenJDK是开源的GPLv2CE协议商用基本没有顾虑。我的建议是如果只是自己搭环境做实验、写demo直接用Oracle JDK 8u391没问题如果是公司生产环境优先考虑OpenJDK发行版省去许可合规上的麻烦。安装步骤上二者几乎没有差别命令完全相同所以本文后续以Oracle命名的tar包为准讲解。2.3 文件名里的门道jdk-8u391-linux-aarch64.tar 逐段拆解这个文件名看着长其实信息量很大拆开看就一目了然jdkJava Development Kit包含JRE和开发工具如果是JRE包文件名会写jre。8u391Java 8的Update 391版本Oracle内部的build号是b13完整的版本字符串是1.8.0_391-b13。linux操作系统平台Linux内核。aarch64CPU架构64位ARM。.tar使用tar打包的文件没有gzip压缩或者文件名省略了.gz后缀。这里有个细节要留意Oracle官网实际下载到的通常是jdk-8u391-linux-aarch64.tar.gz也就是gzip压缩过的tar包。如果某个渠道给了你纯.tar文件要么是二次重新打包的要么是把.gz后缀去掉的解压时命令要对应调整。3. 下载与文件完整性校验3.1 官方下载路径与注意事项Oracle JDK的下载页面是Oracle官网的Java Downloads板块历史版本要去Java Archive页面翻找。这个过程有几个让人抓狂的点一是需要注册并登录Oracle账号不接受匿名下载二是页面上的文件列表很多很容易在x64和aarch64之间看花眼三是下载速度有时候很感人尤其是大文件。我的建议是如果网络条件受限优先使用国内的镜像源比如清华TUNA镜像、华为云镜像下载Eclipse Temurin或Liberica JDK的aarch64版本速度会快很多。另外提一句阿里巴巴Dragonwell和腾讯Kona也是国内团队维护的JDK发行版提供aarch64版本在国产化场景下优化做得不错如果公司有相关技术栈也可以按需选择。3.2 用sha256sum验证文件完整性下载完文件后千万别急着解压。我见过好几次因为下载过程中断或网络问题导致文件损坏解压时报错然后折腾半天发现源头就错了。正确的姿势是用校验和验证文件完整性。sha256sum jdk-8u391-linux-aarch64.tar.gz把输出的哈希值和官网提供的checksum对比一致说明文件下载完整。在镜像站下载OpenJDK时站点通常也会提供对应的SHA256值一样可以校验。这一步看起来多花了10秒钟实际上能帮你筛掉90%的安装后莫名其妙报错问题。4. 安装部署完整流程4.1 解压与目录规划我习惯把JDK统一放在/usr/local/java/目录下这样后续配置环境变量和管理多版本都方便。解压之前先确认文件是gz压缩还是纯tar# 查看文件类型 file jdk-8u391-linux-aarch64.tar.gz # 输出示例gzip compressed data # 如果文件名是.tar.gz sudo mkdir -p /usr/local/java sudo tar -zxvf jdk-8u391-linux-aarch64.tar.gz -C /usr/local/java/ # 如果文件名是纯.tar sudo tar -xvf jdk-8u391-linux-aarch64.tar -C /usr/local/java/解压完成后进入目录看一眼结构正常的JDK目录下应该包含bin、lib、jre、include等文件夹。建议顺手跑一下file /usr/local/java/jdk1.8.0_391/bin/java如果输出里包含ELF 64-bit LSB executable, ARM aarch64说明二进制架构正确这一步能帮你提前确认不是下载错版本。4.2 环境变量配置详解解压只是把软件放到磁盘上系统还不知道去哪找java命令。环境变量就是这个地址簿。如果你希望所有用户都能用编辑/etc/profilesudo vim /etc/profile在文件末尾追加export JAVA_HOME/usr/local/java/jdk1.8.0_391 export PATH$JAVA_HOME/bin:$PATH export CLASSPATH.:$JAVA_HOME/lib/dt.jar:$JAVA_HOME/lib/tools.jar保存退出后执行source /etc/profile让配置立即生效。如果只是给当前用户用把内容写到~/.bashrc里即可。有人会问为什么一定要配JAVA_HOME直接配PATH不就行了因为很多中间件不通过PATH找Java而是直接读取JAVA_HOME环境变量。比如Tomcat的catalina.sh脚本、Maven的mvn脚本、Gradle启动脚本都依赖JAVA_HOME来定位JDK路径。这个变量不配后面跑任何Java中间件都会出问题。4.3 验证安装是否成功配置完成后开一个新的终端窗口或者重新登录会话执行验证命令java -version javac -version echo $JAVA_HOME正常情况输出类似于java version 1.8.0_391 Java(TM) SE Runtime Environment (build 1.8.0_391-b13) Java HotSpot(TM) 64-Bit Server VM (build 25.391-b13, mixed mode)这里有个容易忽略的细节echo $JAVA_HOME必须输出你设置的路径。如果输出为空说明环境变量没生效或者写错文件了。另外注意看输出里有没有64-Bit Server VM如果是Client VM说明可能加载了错误的JVM配置在服务器场景下要留意。5. 多版本共存与切换管理5.1 update-alternatives 管理JDK实际工作中一台机器上可能需要多个JDK版本。比如系统自带的OpenJDK 11用来跑新应用我们自己装的JDK 8用来跑老系统。这时候硬改PATH很容易乱套更好的方案是用Linux自带的alternatives机制。先注册JDK 8sudo update-alternatives --install /usr/bin/java java /usr/local/java/jdk1.8.0_391/bin/java 300 sudo update-alternatives --install /usr/bin/javac javac /usr/local/java/jdk1.8.0_391/bin/javac 300如果系统里还有其他JDK比如OpenJDK 11也按同样方式注册然后通过命令切换sudo update-alternatives --config java执行后会出现一个带编号的列表让你选择默认的java版本输入数字回车即可。这个方法的好处是PATH里的java符号链接会自动指向你选择的版本不需要手动改profile文件全局一致且可控。5.2 按用户级别配置的另一种思路如果只想让某个特定的应用用户使用特定版本还有一个更灵活的做法把环境变量写进该用户的~/.bashrc然后在系统层面不配置全局JAVA_HOME。这样不同的用户各自用各自的JDK互不干扰适合多租户的部署场景。不过要注意shell加载顺序的问题非交互式登录shell会加载/etc/profile交互式登录shell会加载~/.bash_profile而~/.bashrc由交互式非登录shell加载。很多新手在~/.bashrc里配置完重启终端发现没生效就是因为这个加载顺序的差异。最简单的排查方式是在当前终端手动执行source ~/.bashrc如果生效了说明配置没问题只是shell没自动加载。6. 高频问题排查实录我把实际部署中遇到的高频问题整理成了一个速查表方便你对照排查。这些坑我基本都自己踩过写出来给大家省点时间。错误现象根本原因解决办法java: command not foundPATH没配好或者source没执行检查/etc/profile或~/.bashrc是否写对执行source用echo $PATH确认路径bash: ./java: cannot execute binary file: Exec format errorJDK架构不匹配比如x86的包放在ARM系统跑用uname -m确认系统架构改下aarch64版本解压时报gzip: stdin: not in gzip format文件命名是.tar.gz但实际不是gzip压缩或者文件损坏用file命令查看实际格式改成tar -xvf重新下载并校验sha256JAVA_HOME设置了但java还是旧版本which java指向了系统自带的OpenJDK且PATH顺序不对把$JAVA_HOME/bin放在PATH最前面或者用update-alternatives切换普通用户sudo时找不到java环境变量配置在用户级的~/.bashrcsudo环境不读取把JAVA_HOME配置写到/etc/profile或在sudo命令里手动指定PATH国产系统如麒麟、统信上安装后卡顿部分国产系统默认开启了SELinux或安全加固策略查看SELinux状态确认java路径在允许范围内必要时调整策略javac能运行但jar无法执行PATH只配了bin目录但jar工具依赖JAVA_HOME确认JAVA_HOME已导出jar在$JAVA_HOME/bin下6.1 重点说下架构不匹配的坑Exec format error这个报错特别能迷惑人。我第一次碰到的时候还以为是文件权限问题chmod x加了个执行权限还是不行又检查有没有损毁重新下载仍然报同样的错。折腾了半天才意识到是JDK包下错了x86的二进制文件放到ARM机器上内核根本不认识这个格式所以才会报无法执行二进制文件。这也提醒了我一个习惯拿到任何软件包先看文件名里的架构标识再对照uname -m的输出两者一致才动手。这个习惯在ARM生态环境下尤其重要因为很多软件在ARM上还在磨合期某个小细节不对就能浪费半天时间。6.2 解压后的目录权限问题还有一个容易被忽略的坑是权限。用sudo解压到/usr/local/java/后目录所有者是root。如果之后用普通用户执行java -version可能会遇到权限不足的问题。建议解压后顺手执行sudo chown -R $(whoami):$(whoami) /usr/local/java/jdk1.8.0_391或者至少保证bin目录对目标用户可读可执行。不要小看这个操作很多国产系统对文件权限管理比较严格少这一步后面启动应用时就可能莫名其妙报Permission denied。6.3 关于tar命令的几个细节既然标题里带了tar就多聊几句tar的常用用法。解压用-zxvf打包用-czvf这两个是最高频的参数组合其中z代表gzip压缩c是create创建x是extract解压v是verbose显示详细过程f指定文件名。ARM Linux服务器上还有一个常见需求把整个目录从x86机器拷贝到ARM机器那么直接拷贝即可但如果是源代码需要重新编译那就要在ARM机器上重新来一遍build流程因为二进制不互通。另外如果你在解压一个从Windows上传到Linux服务器的tar包可能会遇到中文文件名乱码的问题。解决办法是加上参数tar -xvf 文件名.tar --keep-directory-symlink或者用unzip -O GBK这类处理编码的工具不过JDK解压基本不会遇到这个情况其他文件场景可以留意。6.4 JDK版本内部的小细节8u391这个版本在ARM平台上的HotSpot已经相当成熟了但还是建议在部署完跑一个简单的服务测试一下比如用一个Spring Boot的jar包启动看看。我在飞腾服务器上实测8u391跑Spring Boot应用的启动时间比x86上稍慢一些这是正常的ARM平台在单核性能上跟同代x86比还是有点差距但胜在功耗低、核心多对Java这种多线程应用来说整体吞吐量并不吃亏。如果应用对性能特别敏感可以考虑调一下JVM参数比如-XX:UseG1GC、-XX:MaxRAMPercentage75.0这些让JVM在容器环境下也合理使用内存避免因为默认堆大小计算逻辑导致OOM。我这几次在ARM服务器上装8u391最大的体会是流程本身不复杂复杂的是各种版本和架构的组合判断。确认好aarch64架构、下载正确版本的tar包、校验文件完整性、配好环境变量这四个步骤环环相扣每一步都踏实了后面的应用部署才会顺畅。特别是国产化那批机器系统环境五花八门有的缺这个依赖、有的安全策略严格但JDK层面用二进制tar包直接解压反而是兼容性最好、最可控的方式比用系统包管理器安装要靠谱得多。本文还有配套的精品资源点击获取 ARM架构Linux服务器JDK 8u291 aarch64安装配置实战指南
简介面向需要在ARM Linux平台部署Java环境的开发者与运维人员jdk-8u391-linux-aarch64.tar是Oracle JDK 8u391针对64位ARM架构的官方Linux发行包可直接用于搭建Java 8运行与编译环境解决ARM设备上Java环境缺失或版本不兼容的问题。压缩包约71.23MB共403个文件含so动态库、jar库包、java源文件、properties配置文件、html文档及命令行工具等类型其中动态库与jar包支撑JVM底层调用和核心类库md与txt文档辅助安装排错整体为标准JDK目录布局便于定位bin、lib、jre等模块。已有1477人学习下载适合在树莓派、飞腾等ARM平台上进行Java应用开发、服务部署或容器镜像制作的用户。获取后可获得完整的JDK组件包括javac/java/jar等开发运行工具、jre运行环境、源码归档、安全配置与字体文件配合官方文档即可完成安装与环境变量配置后续还可参照同版本更新策略升级维护。 搞Java开发的朋友都知道JDK安装本该是最基础的活儿。但一旦机器换成了ARM架构整套流程就完全不是那么回事了。我最近在一台飞腾处理器的服务器上部署环境下载的正是jdk-8u391-linux-aarch64.tar这个安装包中间踩了不少坑也把整个流程彻底理顺了。这篇博文就围绕这个文件名展开聊聊ARM Linux环境下JDK 8u391从下载、校验、安装到配置的完整实操过程以及我在这个过程中遇到的各种问题和排查思路。如果你手头也是国产化服务器、ARM云主机或者树莓派这类ARM开发板这篇文章应该能帮你少走不少弯路。1. 认清你的环境aarch64到底是什么1.1 ARM、aarch64、ARM64这些叫法别搞混很多刚接触ARM服务器的人一上来就被这几个名词绕晕了。ARM是芯片架构的统称就像x86一样是设计指令集的公司名和架构名。aarch64则是ARM架构下的64位执行状态也叫ARM64这是Linux内核和大多数开源软件里通用的称呼。用uname -m命令查看当前系统架构如果输出aarch64说明你运行的是ARM 64位系统如果输出x86_64那就是Intel/AMD的64位环境。这里有个细节值得注意有些发行版会显示arm64这其实是同一个东西只是Linux发行版和上游项目各自的叫法差异。在下载JDK、编译软件、拉取Docker镜像时aarch64和arm64表示同一个平台目标。1.2 为什么JDK安装包要区分架构JDK不是纯文本脚本它包含大量本地代码比如HotSpot虚拟机、JIT编译器、垃圾回收器的底层实现这些都必须针对特定CPU指令集编译。x86用的是CISC复杂指令集ARM用的是RISC精简指令集二者完全不兼容。你不可能把x86的二进制扔到ARM机器上跑就像你不能把一把英制扳手用到公制螺丝上一样看似都是扳手接口对不上就是拧不动。常见的错误就是下载了jdk-8u391-linux-x64.tar.gz然后在ARM机器上解压执行结果报出Exec format error。这个问题我在第6节会详细说这里先提醒一句下载之前先跑uname -m确认架构这是所有后续操作的地基。2. 版本选型为什么偏偏是8u3912.1 8u391在JDK 8版本线里的位置JDK 8是Java历史上的一个里程碑版本2014年发布到现在已经十年多了依然是大量企业系统的默认运行时。Oracle对JDK 8的公开更新持续了很久8u391是其中一个比较后期的update版本修复了大量安全漏洞和稳定性问题。如果你所在的公司还在用Spring Boot 2.x、老版本的Dubbo、或者某些只兼容Java 8的国产中间件那么8u391就是一个安全性和兼容性都相对均衡的选择。它不是最新的但足够稳定它不会像JDK 7那样被主流框架抛弃也不会像JDK 17那样对老项目有较大的迁移成本。2.2 Oracle JDK与OpenJDK怎么选标题里写的是Oracle的JDK命名规范jdk-8u391但实际部署时你还有OpenJDK的选项比如Eclipse TemurinAdoptium项目、Azul Zulu、以及国内厂商做的龙井JDK等。Oracle JDK 8的许可协议是OTN License Agreement个人开发、测试和学习是免费的但生产环境需要审视授权问题。OpenJDK是开源的GPLv2CE协议商用基本没有顾虑。我的建议是如果只是自己搭环境做实验、写demo直接用Oracle JDK 8u391没问题如果是公司生产环境优先考虑OpenJDK发行版省去许可合规上的麻烦。安装步骤上二者几乎没有差别命令完全相同所以本文后续以Oracle命名的tar包为准讲解。2.3 文件名里的门道jdk-8u391-linux-aarch64.tar 逐段拆解这个文件名看着长其实信息量很大拆开看就一目了然jdkJava Development Kit包含JRE和开发工具如果是JRE包文件名会写jre。8u391Java 8的Update 391版本Oracle内部的build号是b13完整的版本字符串是1.8.0_391-b13。linux操作系统平台Linux内核。aarch64CPU架构64位ARM。.tar使用tar打包的文件没有gzip压缩或者文件名省略了.gz后缀。这里有个细节要留意Oracle官网实际下载到的通常是jdk-8u391-linux-aarch64.tar.gz也就是gzip压缩过的tar包。如果某个渠道给了你纯.tar文件要么是二次重新打包的要么是把.gz后缀去掉的解压时命令要对应调整。3. 下载与文件完整性校验3.1 官方下载路径与注意事项Oracle JDK的下载页面是Oracle官网的Java Downloads板块历史版本要去Java Archive页面翻找。这个过程有几个让人抓狂的点一是需要注册并登录Oracle账号不接受匿名下载二是页面上的文件列表很多很容易在x64和aarch64之间看花眼三是下载速度有时候很感人尤其是大文件。我的建议是如果网络条件受限优先使用国内的镜像源比如清华TUNA镜像、华为云镜像下载Eclipse Temurin或Liberica JDK的aarch64版本速度会快很多。另外提一句阿里巴巴Dragonwell和腾讯Kona也是国内团队维护的JDK发行版提供aarch64版本在国产化场景下优化做得不错如果公司有相关技术栈也可以按需选择。3.2 用sha256sum验证文件完整性下载完文件后千万别急着解压。我见过好几次因为下载过程中断或网络问题导致文件损坏解压时报错然后折腾半天发现源头就错了。正确的姿势是用校验和验证文件完整性。sha256sum jdk-8u391-linux-aarch64.tar.gz把输出的哈希值和官网提供的checksum对比一致说明文件下载完整。在镜像站下载OpenJDK时站点通常也会提供对应的SHA256值一样可以校验。这一步看起来多花了10秒钟实际上能帮你筛掉90%的安装后莫名其妙报错问题。4. 安装部署完整流程4.1 解压与目录规划我习惯把JDK统一放在/usr/local/java/目录下这样后续配置环境变量和管理多版本都方便。解压之前先确认文件是gz压缩还是纯tar# 查看文件类型 file jdk-8u391-linux-aarch64.tar.gz # 输出示例gzip compressed data # 如果文件名是.tar.gz sudo mkdir -p /usr/local/java sudo tar -zxvf jdk-8u391-linux-aarch64.tar.gz -C /usr/local/java/ # 如果文件名是纯.tar sudo tar -xvf jdk-8u391-linux-aarch64.tar -C /usr/local/java/解压完成后进入目录看一眼结构正常的JDK目录下应该包含bin、lib、jre、include等文件夹。建议顺手跑一下file /usr/local/java/jdk1.8.0_391/bin/java如果输出里包含ELF 64-bit LSB executable, ARM aarch64说明二进制架构正确这一步能帮你提前确认不是下载错版本。4.2 环境变量配置详解解压只是把软件放到磁盘上系统还不知道去哪找java命令。环境变量就是这个地址簿。如果你希望所有用户都能用编辑/etc/profilesudo vim /etc/profile在文件末尾追加export JAVA_HOME/usr/local/java/jdk1.8.0_391 export PATH$JAVA_HOME/bin:$PATH export CLASSPATH.:$JAVA_HOME/lib/dt.jar:$JAVA_HOME/lib/tools.jar保存退出后执行source /etc/profile让配置立即生效。如果只是给当前用户用把内容写到~/.bashrc里即可。有人会问为什么一定要配JAVA_HOME直接配PATH不就行了因为很多中间件不通过PATH找Java而是直接读取JAVA_HOME环境变量。比如Tomcat的catalina.sh脚本、Maven的mvn脚本、Gradle启动脚本都依赖JAVA_HOME来定位JDK路径。这个变量不配后面跑任何Java中间件都会出问题。4.3 验证安装是否成功配置完成后开一个新的终端窗口或者重新登录会话执行验证命令java -version javac -version echo $JAVA_HOME正常情况输出类似于java version 1.8.0_391 Java(TM) SE Runtime Environment (build 1.8.0_391-b13) Java HotSpot(TM) 64-Bit Server VM (build 25.391-b13, mixed mode)这里有个容易忽略的细节echo $JAVA_HOME必须输出你设置的路径。如果输出为空说明环境变量没生效或者写错文件了。另外注意看输出里有没有64-Bit Server VM如果是Client VM说明可能加载了错误的JVM配置在服务器场景下要留意。5. 多版本共存与切换管理5.1 update-alternatives 管理JDK实际工作中一台机器上可能需要多个JDK版本。比如系统自带的OpenJDK 11用来跑新应用我们自己装的JDK 8用来跑老系统。这时候硬改PATH很容易乱套更好的方案是用Linux自带的alternatives机制。先注册JDK 8sudo update-alternatives --install /usr/bin/java java /usr/local/java/jdk1.8.0_391/bin/java 300 sudo update-alternatives --install /usr/bin/javac javac /usr/local/java/jdk1.8.0_391/bin/javac 300如果系统里还有其他JDK比如OpenJDK 11也按同样方式注册然后通过命令切换sudo update-alternatives --config java执行后会出现一个带编号的列表让你选择默认的java版本输入数字回车即可。这个方法的好处是PATH里的java符号链接会自动指向你选择的版本不需要手动改profile文件全局一致且可控。5.2 按用户级别配置的另一种思路如果只想让某个特定的应用用户使用特定版本还有一个更灵活的做法把环境变量写进该用户的~/.bashrc然后在系统层面不配置全局JAVA_HOME。这样不同的用户各自用各自的JDK互不干扰适合多租户的部署场景。不过要注意shell加载顺序的问题非交互式登录shell会加载/etc/profile交互式登录shell会加载~/.bash_profile而~/.bashrc由交互式非登录shell加载。很多新手在~/.bashrc里配置完重启终端发现没生效就是因为这个加载顺序的差异。最简单的排查方式是在当前终端手动执行source ~/.bashrc如果生效了说明配置没问题只是shell没自动加载。6. 高频问题排查实录我把实际部署中遇到的高频问题整理成了一个速查表方便你对照排查。这些坑我基本都自己踩过写出来给大家省点时间。错误现象根本原因解决办法java: command not foundPATH没配好或者source没执行检查/etc/profile或~/.bashrc是否写对执行source用echo $PATH确认路径bash: ./java: cannot execute binary file: Exec format errorJDK架构不匹配比如x86的包放在ARM系统跑用uname -m确认系统架构改下aarch64版本解压时报gzip: stdin: not in gzip format文件命名是.tar.gz但实际不是gzip压缩或者文件损坏用file命令查看实际格式改成tar -xvf重新下载并校验sha256JAVA_HOME设置了但java还是旧版本which java指向了系统自带的OpenJDK且PATH顺序不对把$JAVA_HOME/bin放在PATH最前面或者用update-alternatives切换普通用户sudo时找不到java环境变量配置在用户级的~/.bashrcsudo环境不读取把JAVA_HOME配置写到/etc/profile或在sudo命令里手动指定PATH国产系统如麒麟、统信上安装后卡顿部分国产系统默认开启了SELinux或安全加固策略查看SELinux状态确认java路径在允许范围内必要时调整策略javac能运行但jar无法执行PATH只配了bin目录但jar工具依赖JAVA_HOME确认JAVA_HOME已导出jar在$JAVA_HOME/bin下6.1 重点说下架构不匹配的坑Exec format error这个报错特别能迷惑人。我第一次碰到的时候还以为是文件权限问题chmod x加了个执行权限还是不行又检查有没有损毁重新下载仍然报同样的错。折腾了半天才意识到是JDK包下错了x86的二进制文件放到ARM机器上内核根本不认识这个格式所以才会报无法执行二进制文件。这也提醒了我一个习惯拿到任何软件包先看文件名里的架构标识再对照uname -m的输出两者一致才动手。这个习惯在ARM生态环境下尤其重要因为很多软件在ARM上还在磨合期某个小细节不对就能浪费半天时间。6.2 解压后的目录权限问题还有一个容易被忽略的坑是权限。用sudo解压到/usr/local/java/后目录所有者是root。如果之后用普通用户执行java -version可能会遇到权限不足的问题。建议解压后顺手执行sudo chown -R $(whoami):$(whoami) /usr/local/java/jdk1.8.0_391或者至少保证bin目录对目标用户可读可执行。不要小看这个操作很多国产系统对文件权限管理比较严格少这一步后面启动应用时就可能莫名其妙报Permission denied。6.3 关于tar命令的几个细节既然标题里带了tar就多聊几句tar的常用用法。解压用-zxvf打包用-czvf这两个是最高频的参数组合其中z代表gzip压缩c是create创建x是extract解压v是verbose显示详细过程f指定文件名。ARM Linux服务器上还有一个常见需求把整个目录从x86机器拷贝到ARM机器那么直接拷贝即可但如果是源代码需要重新编译那就要在ARM机器上重新来一遍build流程因为二进制不互通。另外如果你在解压一个从Windows上传到Linux服务器的tar包可能会遇到中文文件名乱码的问题。解决办法是加上参数tar -xvf 文件名.tar --keep-directory-symlink或者用unzip -O GBK这类处理编码的工具不过JDK解压基本不会遇到这个情况其他文件场景可以留意。6.4 JDK版本内部的小细节8u391这个版本在ARM平台上的HotSpot已经相当成熟了但还是建议在部署完跑一个简单的服务测试一下比如用一个Spring Boot的jar包启动看看。我在飞腾服务器上实测8u391跑Spring Boot应用的启动时间比x86上稍慢一些这是正常的ARM平台在单核性能上跟同代x86比还是有点差距但胜在功耗低、核心多对Java这种多线程应用来说整体吞吐量并不吃亏。如果应用对性能特别敏感可以考虑调一下JVM参数比如-XX:UseG1GC、-XX:MaxRAMPercentage75.0这些让JVM在容器环境下也合理使用内存避免因为默认堆大小计算逻辑导致OOM。我这几次在ARM服务器上装8u391最大的体会是流程本身不复杂复杂的是各种版本和架构的组合判断。确认好aarch64架构、下载正确版本的tar包、校验文件完整性、配好环境变量这四个步骤环环相扣每一步都踏实了后面的应用部署才会顺畅。特别是国产化那批机器系统环境五花八门有的缺这个依赖、有的安全策略严格但JDK层面用二进制tar包直接解压反而是兼容性最好、最可控的方式比用系统包管理器安装要靠谱得多。本文还有配套的精品资源点击获取