1. 先把这个文件名拆开看：四个字段决定了它能不能用
jdk-8u311-linux-aarch64.tar.gz这个文件名信息量其实挺大，很多人拿到手第一反应是直接解压，结果在 x86 机器上跑出cannot execute binary file，或者在生产机上发现 glibc 版本不够，白折腾半天。我习惯先把文件名当成一张“身份证”来读，四个字段分别对应：产品、版本、操作系统、CPU 架构，任意一个对不上，后面的活都是无用功。
1.1 字段逐项拆解：jdk / 8u311 / linux / aarch64
jdk表示这是 Java Development Kit，不是 JRE。差别在于它自带javac、jar、jmap、jstack这些开发和诊断工具，体积也更大。如果你只是跑一个已经打包好的 Spring Boot fat jar，理论上 JRE 就够；但现实是线上排查问题离不开jstack抓线程栈、jmap看堆、jcmd打诊断，所以我的习惯是服务器上统一装 JDK，别为了省几十兆给自己挖坑。
8u311是版本号，主版本 8，Update 311，属于 Java 8 生命周期的后期补丁。这里有个容易被忽略的点：8u311不是一个“功能版本”，它和8u301、8u321在 API 层面几乎没区别，差别集中在安全补丁、时区数据、根证书库和少量 JVM 底层修复。也就是说，你从 8u301 升到 8u311，代码基本不用动，但证书链、TLS 握手、时区换算这些“看不见的地方”会变。
linux表示目标操作系统是 Linux，不适用其他系统。aarch64是重点，它是 ARMv8 架构的 64 位执行状态，和 Docker 生态里说的arm64是同一个东西，只是叫法不同——内核和工具链习惯写aarch64，容器镜像标签习惯写arm64。这个字段直接决定了二进制指令集，x86_64 的机器加载它会直接失败，没有任何兼容层可以救。
tar.gz是打包格式，gzip 压缩的 tar 归档。这类包是“绿色版”，解压即用，不写系统目录、不注册服务、不改注册表，删掉就是卸载。对生产环境来说这点很友好：出问题回滚只需要改一下软链接指向，不用走包管理器的事务流程。
提示：
aarch64和arm64混用是常见误判来源。写 Dockerfile 的--platform参数时用linux/arm64，写内核相关脚本时用aarch64，两个词指同一件事，别以为是两个架构。
1.2 为什么这个“老版本”还在被反复找
Java 8 是 2014 年发布的，到现在依然有大量系统跑在上面，原因不复杂：很多中间件客户端、老版本框架、企业内部 SDK 是照着 Java 8 的 API 写的，尤其是那些依赖sun.misc.Unsafe、老版字节码增强、或者用了被后续版本移除的内部 API 的组件，升到 11 或 17 就是一场大手术。项目周期紧的时候，没人愿意为了“技术先进性”去赌一次全链路回归。
而8u311这个具体版本被反复找，通常有三个场景。第一是存量环境对齐：某套系统在测试环境跑的就是这个版本，生产要复刻，版本号必须一致，否则压测数据对不上，出问题也说不清是代码还是环境差异。第二是基础镜像锁定：很多团队的基础镜像里预置了某个 JDK 8 小版本，新项目直接继承，久而久之整个集群都锁在这个号上。第三是ARM 平台适配：近几年 ARM 服务器在成本和能效上的优势被更多团队看见，一批原本跑在 x86 上的老 Java 8 应用要迁移过去，就得找对应架构的安装包。
这里必须提醒一句：老版本不等于安全版本。8u311之后还有若干补丁版本修了新的问题，如果条件允许，尽量选同一大版本里更新的补丁号；实在被环境锁死，至少要保证对外暴露的服务做了额外防护，别把“能跑”当成“安全”。
1.3 免费这件事，得看清楚“谁给的免费”
标题里带“免费”两个字，容易让人放松警惕。这里的“免费”通常指获取成本为零，不代表没有使用约束。JDK 的发行渠道很多：上游官方构建、基于 OpenJDK 源码的社区构建、各操作系统发行版仓库里的构建，它们的授权方式、支持周期、更新节奏都不一样。
我的做法是：先确认来源，再谈使用。如果是内部测试、个人学习、CI 构建机，大部分构建都能直接用；如果要进生产、要对外提供服务、要嵌入到商业产品里分发，就得花十分钟把发行方的说明读一遍，看清楚商用条款、是否有长期安全更新、是否提供技术支持。这十分钟比事后返工便宜太多。见过太多团队在压测前一天才发现镜像里的 JDK 构建不适合商用分发，临时换包，牵连一整条流水线。
另外，“免费”也不等于“可以随便从任何地方下”。这类压缩包体积在百兆量级，解压后三百兆上下，被篡改后极难通过肉眼发现——多一个类、改一个 so 文件，表面完全看不出来。所以来源可信度和完整性校验，是这个资源文件落地的第一道关。
2. 拿到文件之后别急着解压：校验与目录规划
我见过最典型的翻车方式是：文件传到服务器，tar -zxvf一把梭，解压报错一半，以为是包坏了，重新传了三遍。实际上大概率是传输过程中断导致包不完整。压缩包这种东西，缺一个字节都可能让解压在中途失败，而且报错信息往往指向文件内部某个条目，看着像是包本身有问题，实际是下载没下完。
2.1 完整性校验的标准动作
正确的顺序是先校验、再解压。发行方一般会在发布页给出对应文件的校验值（常见是 SHA-256），你把它复制下来，在本地算一遍对比。
# 计算本地文件的 SHA-256 sha256sum jdk-8u311-linux-aarch64.tar.gz # 输出形如：<64位十六进制串> jdk-8u311-linux-aarch64.tar.gz # 如果发行方给的是校验文件，可以直接比对 sha256sum -c jdk-8u311-linux-aarch64.tar.gz.sha256比对结果必须完全一致，包括大小写习惯（一般统一小写）。不一致就别往下走了，重新获取，不要心存侥幸。我自己的习惯是把校验值顺手记到部署文档里，下次换机器或者换人接手，直接照着核对，省得再去翻发布页。
还有个更省事的做法：把校验串写成脚本的一部分，和下载、解压串起来，任何一步失败就中断。流水线里尤其需要这个，人工比对在自动化场景下等于没有。
2.2 解压参数里的两个小陷阱
tar -zxvf是最常见的写法，但在服务器上我一般会加上两个参数：
tar -zxpvf jdk-8u311-linux-aarch64.tar.gz --no-same-owner -C /opt/java/--no-same-owner的作用是解压时不要把归档里的属主信息还原到本地。这个包里的文件属主是打包机器上的某个用户，如果你用 root 解压且不加这个参数，解出来的文件会带着一个本机不存在的 UID，后续用普通用户跑 Java 进程时可能读不到某些文件，排查起来很费劲。
-C指定解压目标目录，别在/root或者/tmp里解压完再mv。/tmp在部分系统上挂的是 tmpfs，重启就没了；/root权限是 700，其他用户访问不到，后面配置服务账号时又是一轮折腾。
-p保留权限位，-v输出进度方便看卡在哪。如果包特别大、传输不稳定，可以先用gzip -t单独测一下压缩流完整性：
gzip -t jdk-8u311-linux-aarch64.tar.gz && echo "压缩流完整"这个命令只验证 gzip 层，不解压，速度快，适合在正式解压前做一次快速体检。
2.3 目录规划：给未来的自己留条路
解压前先想清楚目录怎么放。我不推荐直接把 JDK 解压到/usr/local根下，因为解压出来的文件夹名带版本号（类似jdk1.8.0_311），时间一长，/usr/local下会堆好几个版本，谁也说不清哪个在用。
我的习惯是这样分层：
/opt/java/ # 所有 JDK 的家目录 ├── jdk1.8.0_311/ # 实际解压出来的目录 ├── jdk-8 -> jdk1.8.0_311 # 软链接，业务侧统一用这个路径 └── jdk-11 -> jdk-11.0.x/ # 多版本并存时再加业务侧的JAVA_HOME永远指向/opt/java/jdk-8，升级时只需要把软链接从jdk1.8.0_311切到jdk1.8.0_321，配置文件一行不用改，回滚也就是把链接切回去。这个做法在十几台机器的集群里价值最大——你改一处，所有引用方自动生效。
注意：软链接切换后，已经在跑的 Java 进程不会自动换 JDK。因为进程启动时已经把解释器、类库路径加载进内存了。切换软链接只影响新启动的进程，重启服务才算真正生效。
如果机器上还有别的 Java 应用跑在其他版本上，别急着改全局JAVA_HOME，先看看第 3.3 节的多版本共存方案。
3. 从解压到跑起来：环境配置的完整链路
解压完只是把文件放到了磁盘上，离“能用”还差几步：环境变量、命令可见性、验证。这几步看着简单，但配置方式的选择会影响后续运维体验。我见过把JAVA_HOME写进~/.bashrc的，结果换了个用户跑服务就找不到 Java；也见过直接改/etc/profile的，某次系统更新后被覆盖，全线告警。
3.1 系统级环境变量的正确写法
推荐用/etc/profile.d/下的独立脚本，而不是直接编辑/etc/profile。原因是/etc/profile是系统文件，升级时可能被覆盖或产生冲突；而/etc/profile.d/*.sh是约定俗成的扩展目录，每个工具一个文件，职责清晰，卸载时删文件就行。
# /etc/profile.d/java.sh export JAVA_HOME=/opt/java/jdk-8 export JRE_HOME=$JAVA_HOME/jre export PATH=$JAVA_HOME/bin:$PATH三个变量里，JAVA_HOME是核心，绝大多数构建工具、启动脚本、中间件都靠它定位 JDK；PATH把bin目录前置，保证java、javac命令能被找到；JRE_HOME在 Java 8 时代还有一些老脚本会读，加上无害，Java 9 之后这个目录结构变了，那时候就不用设了。
CLASSPATH我不建议在这里设。很多老教程会让你export CLASSPATH=.:$JAVA_HOME/lib/dt.jar:...，这在现代应用里是纯粹的负担：一旦全局设了CLASSPATH，所有 Java 进程启动时都会带上这些路径，某些场景下会和应用的依赖产生冲突，而且排查时极难想到是环境变量在捣鬼。让构建工具和启动脚本自己管理类路径，是更干净的做法。
写完文件记得给执行权限并让它生效：
chmod 644 /etc/profile.d/java.sh source /etc/profile.d/java.sh644就够，不需要执行权限，因为它是被source进来的，不是直接运行的。
3.2 验证不止java -version一条命令
java -version是最基础的验证，输出大概长这样：
java version "1.8.0_311" Java(TM) SE Runtime Environment (build 1.8.0_311-b11) Java HotSpot(TM) 64-Bit Server VM (build 25.311-b11, mixed mode)不同构建的措辞会有差异，社区构建可能显示 OpenJDK 字样，这都正常。关键是看第二行的版本号和第三行的64-Bit，说明是 64 位 JVM。
但这远远不够。我通常还会跑三条：
# 确认 java 命令实际来自哪个路径，防止 PATH 里有别的 JDK 抢先 which java readlink -f $(which java) # 确认 JVM 看到的架构和系统一致 java -XshowSettings:properties -version 2>&1 | grep -E "os.arch|java.version|java.home" # 确认编译器可用，说明是完整 JDK 而非 JRE javac -versionos.arch应该输出aarch64。如果这里显示amd64，说明你系统里存在另一个 x86 的 JDK 抢在前面了，PATH顺序有问题。java.home应该指向你配置的/opt/java/jdk-8，如果指向别处，同样是路径冲突。
再往下可以做一个“能编译能运行”的闭环验证：
cat > /tmp/Hello.java <<'EOF' public class Hello { public static void main(String[] args) { System.out.println("arch=" + System.getProperty("os.arch")); System.out.println("java=" + System.getProperty("java.version")); } } EOF javac -d /tmp /tmp/Hello.java && java -cp /tmp Hello能编译、能跑、打印出正确架构，这套 JDK 才算真正可用。别小看这一步，某些精简过的包里javac被裁掉了，或者tools.jar缺失，跑起来才发现，那时候业务已经在等你了。
3.3 多版本共存：用软链接而不是改环境变量
一台机器上同时跑 Java 8 和 Java 11 的应用很常见。这时候别去频繁改全局JAVA_HOME，容易误伤别人。两个方案：
方案一：软链接切换（推荐给整机统一版本）
ln -sfn /opt/java/jdk1.8.0_311 /opt/java/jdk-8 ln -sfn /opt/java/jdk-11.0.x /opt/java/jdk-11 # 切换默认版本 ln -sfn /opt/java/jdk-11 /opt/java/jdk-current然后JAVA_HOME=/opt/java/jdk-current。切版本只动一条命令，对所有引用方生效。
方案二：进程级指定（推荐给多应用混跑）
在启动脚本里直接写死JAVA_HOME，不依赖全局变量：
#!/bin/bash export JAVA_HOME=/opt/java/jdk1.8.0_311 exec $JAVA_HOME/bin/java -jar /opt/app/service.jar这种方式每个应用互不干扰，升级只改自己那一行。缺点是配置分散，需要一套配置管理来保证一致。我一般对核心服务用方案二，对构建机、跳板机用方案一。
如果系统里装了alternatives机制（部分发行版自带），也可以注册进去：
update-alternatives --install /usr/bin/java java /opt/java/jdk1.8.0_311/bin/java 100 update-alternatives --config java优先级数字大的默认选中。不过update-alternatives只管/usr/bin/java这个入口，JAVA_HOME还是得自己维护，所以我更倾向于软链接方案，控制点更少。
4. ARM 平台上跑 Java 8 的几个专属坑
这一节是重点。x86 上装 JDK 8 基本是“解压、配变量、跑”，到了 aarch64 平台上，坑的密度明显上升，而且很多问题不会在启动阶段报错，而是压测时、跑几天后才暴露。下面这些都是我在实际迁移里踩过的。
4.1 架构与系统底座的兼容性检查
第一个要确认的是系统底座。uname -m输出aarch64只是说明 CPU 架构对，还不代表能跑。Java 8 的二进制对系统 C 库有版本要求，通常需要 glibc 2.17 及以上。某些为极致精简做的容器基础镜像，glibc 版本偏低，启动时会直接报错：
/opt/java/jdk-8/bin/java: /lib64/libc.so.6: version `GLIBC_2.xx' not found遇到这个没有捷径，要么换一个 glibc 满足要求的基础镜像，要么换一个针对低版本 glibc 编译的 JDK 构建。别指望通过软链接伪造版本号，那是自找麻烦。
第二个是内存页大小。ARM 服务器上出于性能考虑，内核常用 64KB 页大小，而 x86 通常用 4KB。查一下：
getconf PAGESIZE # 输出 4096 或 65536部分 Java 8 的构建在 64K 页环境下会出现启动异常或者启动极慢，表现为启动时卡在初始化阶段或者直接报出与内存映射相关的错误。遇到这种情况，先确认是不是页大小导致的，可以尝试换一个更新的补丁版本，或者找一个明确说明适配大页的构建。这个坑比较隐蔽，因为同样的包在开发机（4K 页）上完全正常。
第三个是依赖库。完整 JDK 里带了 AWT、字体渲染、加密相关的本地库，某些库依赖libstdc++、fontconfig、freetype。如果应用只是纯后端服务，不碰图形界面，一般不受影响；但如果有报表生成、图片处理、验证码这类功能，可能在运行到某个功能时才报UnsatisfiedLinkError。提前装好这些基础库，比事后救火强。
ldd /opt/java/jdk-8/bin/java # 检查动态依赖是否都能解析 ldd /opt/java/jdk-8/jre/lib/aarch64/libfontmanager.so 2>/dev/nullldd输出里出现not found的条目，就是缺的库。
4.2 容器化部署时的 JDK 版本适配
8u311这个版本落在容器支持比较完善的区间里。Java 8 从 8u191 前后开始引入容器感知能力（UseContainerSupport），能读到 cgroup 限制，不再傻乎乎地按宿主机物理内存去算堆大小。这一点在 Kubernetes 里极其关键：如果你的 Pod 限制 2GB 内存，而 JVM 按宿主机 64GB 去算默认堆，容器会被 OOM Kill，日志里看不到任何 Java 异常，只有退出码 137。
确认容器感知是否生效：
# 在容器内执行 java -XX:+PrintFlagsFinal -version 2>/dev/null | grep -E "UseContainerSupport|MaxHeapSize"UseContainerSupport应该是true。堆大小可以通过-XX:MaxRAMPercentage来控制比例，比写死-Xmx更适合弹性环境：
java -XX:+UseContainerSupport \ -XX:MaxRAMPercentage=70.0 \ -XX:InitialRAMPercentage=70.0 \ -jar app.jar70% 这个比例不算随意拍的。JVM 的内存开销除了堆，还有元空间、线程栈、直接内存（Netty、NIO 用得多的时候不小）、代码缓存、GC 自身结构。经验上堆占容器限额的 65%~75% 比较稳，剩余部分留给非堆和系统。设 70% 之后再观察一段时间的 RSS，如果经常贴近上限，就往下降；如果远低于上限，可以适度上调。别一次拉到 90%，那是给自己埋雷。
4.3 影响运行质量的参数与配置项
除了内存，还有几个配置在 ARM 环境下值得单独拎出来。
编码问题。Java 8 的file.encoding默认取系统 locale，精简系统上经常是ANSI_X3.4-1968（本质是 ASCII），中文直接变问号。别指望改 locale 一劳永逸，最稳的是启动参数里显式指定：
-Dfile.encoding=UTF-8 -Dsun.jnu.encoding=UTF-8时区问题。容器里没有/etc/localtime或者 tzdata 缺失时，JVM 会回落到 UTC，业务上表现为时间差 8 小时。显式指定：
-Duser.timezone=GMT+8比挂载宿主机的时区文件更可控，也避免了镜像之间的不一致。
DNS 解析。部分环境里 IPv6 解析优先但实际不可达，表现为接口调用偶发超时，重试又好了。加一个参数可以规避：
-Djava.net.preferIPv4Stack=trueGC 选择。Java 8 默认是 Parallel GC，在中小堆（4GB 以下）场景下表现稳定、开销小，我一般不动它。堆大于 8GB 且对停顿敏感的服务，可以考虑 G1：
-XX:+UseG1GC -XX:MaxGCPauseMillis=200但要注意 Java 8 的 G1 成熟度和后续版本有差距，且 ARM 平台上 G1 的实际表现和 x86 不完全一致，必须压测验证后再上生产，别拿别人的 x86 调优参数直接抄。
5. 打包进镜像与生产部署的关键动作
tar.gz这种形态最大的好处是适合做镜像。但直接ADD一个压缩包进镜像，有几个细节不看会吃亏。
5.1 镜像构建中的解压与层级控制
Dockerfile 里ADD命令遇到.tar.gz会自动解压，这是很多人不知道的点，结果写了个RUN tar -zxvf又解了一遍，目录套目录。
FROM your-arm64-base:latest # ADD 会自动解压 tar.gz 到目标目录 ADD jdk-8u311-linux-aarch64.tar.gz /opt/java/ ENV JAVA_HOME=/opt/java/jdk1.8.0_311 ENV PATH=$JAVA_HOME/bin:$PATH ENV LANG=C.UTF-8 RUN java -version && javac -versionADD的自动解压行为只对本地 tar 归档有效，且不能指定解压后的目录名——它会把归档里的顶层目录原样放进去，所以JAVA_HOME必须写实际的目录名jdk1.8.0_311，不能写软链接名。
另一个细节是镜像层级。ADD一个百兆的包，解压后三百兆，如果后面又RUN删掉包文件，镜像体积不会变小，因为每一层都是只读的。正确做法是把下载和解压放在同一个RUN里，或者干脆在构建上下文外面准备好再COPY解压后的目录。前者适合自动化，后者适合内网构建。
如果基础镜像里已经有合适版本的 JDK，就别再塞一个了。多一份 JDK 就多一份安全补丁要跟，运维成本是翻倍的。
5.2 上线前的检查清单
从“能跑”到“敢上生产”，中间还有一段路。我在每次部署这类 JDK 资源时，会过一遍下面这张表：
| 检查项 | 命令/方式 | 通过标准 |
|---|---|---|
| 文件完整性 | sha256sum比对 | 与发布方一致 |
| CPU 架构匹配 | uname -m | 输出aarch64 |
| 系统库满足 | ldd $JAVA_HOME/bin/java | 无not found |
| 实际生效的 JDK | readlink -f $(which java) | 指向规划目录 |
| 版本与架构 | java -XshowSettings:properties -version | os.arch=aarch64 |
| 容器内存感知 | PrintFlagsFinal查UseContainerSupport | true |
| 编码与时间 | 打印中文和当前时间 | 无乱码、时区正确 |
| 非 root 运行 | 用服务账号启动 | 能正常读写日志目录 |
这张表我基本上是照着念的，花不了五分钟，但能挡掉八成的“上线后才发现”的问题。尤其是“非 root 运行”这一条，很多团队为了省事用 root 跑 Java，结果日志文件属主混乱，某天改配置改不动，又是一轮排查。
6. 问题速查：那些年踩过的报错
实际运维里遇到的报错，绝大多数能归到几类。我把高频的整理成表，附上判断依据和处理方向。
6.1 高频报错对照与定位思路
| 报错现象 | 大概率原因 | 处理方向 |
|---|---|---|
cannot execute binary file: Exec format error | 架构不匹配，x86 机器加载了 aarch64 包 | uname -m确认，换对应架构的包 |
version 'GLIBC_2.xx' not found | 系统 C 库版本过低 | 换基础镜像或换低依赖构建 |
Error occurred during initialization of VM | 内存不足、页大小不兼容、参数冲突 | 查getconf PAGESIZE，精简启动参数逐项排除 |
| 启动正常但几天后进程消失，退出码 137 | 容器内存超限被内核终止 | 调小MaxRAMPercentage，找非堆内存泄漏 |
| 中文输出问号 | 默认编码非 UTF-8 | 显式加-Dfile.encoding=UTF-8 |
| 时间差 8 小时 | 时区未指定或 tzdata 缺失 | 加-Duser.timezone=GMT+8 |
| 接口偶发超时，重试正常 | IPv6 优先但不可达 | 加-Djava.net.preferIPv4Stack=true |
UnsatisfiedLinkError | 依赖的本地库缺失 | ldd逐库检查，补齐系统库 |
OutOfMemoryError: Metaspace | 动态生成类过多，元空间不够 | 调-XX:MaxMetaspaceSize，排查类加载泄漏 |
| 启动极慢，卡在初始化 | 大页环境与 JVM 版本不兼容 | 换补丁版本或调整页大小策略 |
表格只是索引，真正定位还得靠日志和现场。我的习惯是：先看退出码，再看完整日志第一段，最后看系统层。退出码 137 就是被杀了，别在 Java 日志里找原因；日志第一段通常带着 JVM 的版本、参数、内存信息，抄下来对着看，比翻应用日志快得多。
6.2 我自己的三条排查经验
第一条，改了环境变量不生效，先查加载顺序。/etc/profile和/etc/profile.d/*.sh在登录 shell 里生效，但 systemd 启动的服务、cron 任务、容器入口脚本走的路径不一样，经常不读这些文件。服务类进程的环境变量，老老实实写进 unit 文件（Environment=）或者启动脚本里，别指望全局变量兜底。
第二条，怀疑架构问题时，别猜，直接问二进制。file $JAVA_HOME/bin/java会直接告诉你这个文件的目标平台，输出里带ARM aarch64还是x86-64一目了然。这个命令比查文档快，也比问人靠谱。
第三条，老版本 JDK 的问题，先怀疑证书和时区，再怀疑代码。8u311这类版本跑久了，最容易出问题的是根证书过期导致 HTTPS 握手失败，以及时区规则变更导致定时任务错乱。这两类问题的表现都像“代码有 bug”，实际和代码没关系。定期检查$JAVA_HOME/jre/lib/security/cacerts的有效期，提前规划升级，比半夜被告警叫醒强。
最后分享一个我在实际迁移中养成的习惯：每上一个新环境，先在/tmp里跑一个只打印os.arch、java.version、Runtime.maxMemory()、TimeZone.getDefault()四行信息的小程序，确认无误再部署业务。这四行字看着简陋，但架构、版本、内存、时区四个最容易出问题的点全在里面了，比任何文档都直观。
