简介OpenJDK 8_322 Linux 解压安装版面向需要在 Linux 环境下搭建 Java 开发与运行环境的开发者尤其适合偏好免安装、开箱即用的中初级 Java 工程师与运维人员。该版本基于 OpenJDK 8u322-b06 构建完整包含 JRE、javac 编译器、jdb 调试器及 jar、javadoc 等工具链支持 Lambda 表达式、Stream API、默认方法与全新 java.time 日期时间 API 等 Java 8 核心特性可直接用于开发、部署和运行 Java 应用。压缩包共 445 个文件以 91 个 java 源码、120 个无扩展名可执行文件、39 个 so 动态库、25 个 jar 包及 properties、xml 配置为主整体约 98.29MB解压后配置 JAVA_HOME 与 PATH 即可使用。目前已有 1226 人学习下载适合希望快速获得稳定开源 JDK 环境、免去在线安装步骤的读者参考使用。1. 解压即用的 OpenJDK 8_322为什么老项目还在死磕这个版本手里维护着一套跑了五六年的 Java 服务新机器上装完系统第一件事不是配数据库而是把 JDK 装明白。你可能也遇到过这种场景运维丢过来一台内网 Linux 机器没有外网yum 源里只有 OpenJDK 11 甚至 17但项目编译脚本里写死了source 1.8Maven 插件也只认 8 的字节码。这时候一个解压就能用的 OpenJDK 8_322 安装包比任何在线安装命令都省心。OpenJDK 8_322 对应的是8u322-b06这个构建属于 Java 8 后期的一个稳定更新。它和 Oracle JDK 8 在绝大多数 API 上行为一致区别主要在许可和少量商业特性上。这个包是 Linux 解压安装版意味着不需要 root 权限去动系统包管理器解压、挪目录、配环境变量三步就能跑起来。适合谁一是还在维护 Java 8 遗留系统的后端二是需要固定 JDK 版本做 CI 构建的工程化同学三是教学或实验环境里要批量部署统一版本的情况。下面从目录结构开始把这份资源拆开看。2. 拆开压缩包目录结构、核心命令与版本核对拿到jdk8u322-b06.tar.gz之后别急着解压到/usr/lib/jvm先看一眼里面的东西确认没下错架构、没缺文件。这一步花两分钟能省掉后面排查java: command not found的半小时。2.1 解压后的目录长什么样用tar -tzf先列出压缩包内容不实际解压# 只列出压缩包内文件不解压确认顶层目录名 tar -tzf jdk8u322-b06.tar.gz | head -20常见输出顶层目录是jdk1.8.0_322下面挂bin、jre、lib、include、man等。bin目录里是你天天打交道的可执行文件java、javac、jar、javadoc、keytool、jdb、jps等。jre是运行环境子集lib放tools.jar、rt.jar这类核心库。man目录里是手册页项目正文里提到的javadoc.1、java.1、keytool.1就是这些手册页文件装完之后man java能直接看。确认顶层目录名很重要因为后面JAVA_HOME要指到这一层指错了就是JAVA_HOME无效。如果输出里顶层是jdk8u322-b06而不是jdk1.8.0_322那JAVA_HOME就得跟着改别照抄网上的路径。2.2 解压与放置路径选择有讲究解压命令本身不复杂关键是放哪# 解压到当前目录生成 jdk1.8.0_322 文件夹 tar -zxvf jdk8u322-b06.tar.gz # 建标准 JVM 目录有 sudo 就用没有就放用户目录 sudo mkdir -p /usr/lib/jvm # 移动并重命名保持路径干净 sudo mv jdk1.8.0_322 /usr/lib/jvm/jdk1.8.0_322参数说明-z走 gzip 解压-x解包-v显示过程-f指定文件名。这四个字母顺序无所谓但-f必须紧跟文件名。放置路径我一般选/usr/lib/jvm/这是多数 Linux 发行版约定俗成的 JVM 目录后续如果装多个 JDK用update-alternatives切换也方便。没有 sudo 权限的机器放到~/jdk/jdk1.8.0_322一样能用只是环境变量路径要对应改。注意不要解压到/tmp或桌面目录就配环境变量重启或清理临时目录后 JDK 就没了这种翻车我见过不止一次。2.3 环境变量配置与版本验证环境变量写进当前用户的 shell 配置文件别直接改/etc/profile除非你确定要全局生效# 追加到 ~/.bashrc只对当前用户生效 echo export JAVA_HOME/usr/lib/jvm/jdk1.8.0_322 ~/.bashrc echo export PATH$JAVA_HOME/bin:$PATH ~/.bashrc echo export CLASSPATH.:$JAVA_HOME/lib/dt.jar:$JAVA_HOME/lib/tools.jar ~/.bashrc # 立即生效 source ~/.bashrcJAVA_HOME指向 JDK 根目录很多构建工具Maven、Gradle、Tomcat 启动脚本靠它找 JDK。PATH把$JAVA_HOME/bin放最前面保证java命令优先用这个版本而不是系统自带的。CLASSPATH现在多数项目用构建工具管理但老项目手动javac编译时还依赖它加上没坏处。验证分三层别只看一个# 看运行时版本 java -version # 看编译器版本确认 javac 也是 8 javac -version # 看 JAVA_HOME 是否指对 echo $JAVA_HOMEjava -version输出里应该出现openjdk version 1.8.0_322和OpenJDK 64-Bit Server VM。如果显示的是别的版本说明PATH里系统 JDK 排在前面检查echo $PATH里$JAVA_HOME/bin的位置。javac -version和java -version不一致是经典坑后面避坑章节细说。3. 从 javac 到 keytool把 JDK 自带工具链跑通一遍装完不是java -version对了就完事JDK 的价值在那一堆命令行工具上。这一章把编译、打包、签名、文档生成这条链路走一遍确认工具链完整可用。3.1 编译与运行一个最小可复现例子写个用到 Java 8 特性的类验证编译和运行都正常// Demo.java用到 lambda 和 Stream验证 Java 8 特性可用 import java.util.Arrays; import java.util.List; import java.util.stream.Collectors; public class Demo { public static void main(String[] args) { ListString names Arrays.asList(alpha, beta, gamma); // lambda Stream 过滤并转大写 ListString upper names.stream() .filter(s - s.length() 4) .map(String::toUpperCase) .collect(Collectors.toList()); System.out.println(upper); } }编译运行# 编译-encoding 防止中文注释乱码 javac -encoding UTF-8 Demo.java # 运行注意不带 .class 后缀 java Demojavac的-encoding参数在源码含中文时必加否则可能报unmappable character。运行时的类名不带.class带包名的话要写全限定名。输出[ALPHA, GAMMA]说明 lambda 和 Stream 都正常这个 JDK 的核心特性没问题。3.2 jar 打包与 javadoc 生成jar和javadoc是交付环节常用的两个工具# 打包成 jar-c 创建-v 显示-f 指定文件名 jar -cvf demo.jar Demo.class # 查看 jar 内容确认打进去了 jar -tvf demo.jar # 生成 API 文档到 doc 目录 javadoc -d doc -encoding UTF-8 Demo.javajar -cvf里c是创建、v是 verbose、f指定输出文件这三个参数顺序固定f后面紧跟文件名。javadoc -d指定输出目录生成后打开doc/index.html能看到类和方法说明。项目正文里提到的javadoc.1手册页装完后man javadoc可以查所有参数比在线搜靠谱。3.3 keytool 与证书老项目 HTTPS 常踩的一环keytool是 JDK 自带的密钥和证书管理工具Java 应用配 HTTPS、生成自签证书都靠它# 生成一个自签证书存到 keystore.jks keytool -genkeypair -alias demo -keyalg RSA -keysize 2048 \ -validity 365 -keystore keystore.jks \ -storepass changeit -keypass changeit \ -dname CNdemo, OUdev, Otest, Lcity, STstate, CCN # 查看 keystore 里的条目 keytool -list -v -keystore keystore.jks -storepass changeit-genkeypair生成密钥对-keyalg RSA指定算法-validity是有效天数-dname是证书主体信息。-storepass和-keypass在较新版本里要求一致不一致会报错。-list -v能看证书指纹、有效期、算法排查证书问题时先跑这个。项目正文里keytool.1出现多次说明这个工具在资源里是重点实际运维中证书过期、别名冲突都靠它定位。提示keytool生成的 keystore 默认格式在新版本里是 PKCS12Java 8 里还是 JKS跨版本迁移时注意格式差异用-storetype显式指定能避免玄学问题。4. 多版本共存与切换别让系统 JDK 抢了 PATH生产机器上往往不止一个 JDK系统自带一个项目要求一个CI 镜像里可能还有第三个。这一章讲怎么让 OpenJDK 8_322 在需要的时候稳定生效不被别的版本截胡。4.1 update-alternatives 管理多版本Debian/Ubuntu 系用update-alternatives注册多个 JDK按优先级切换# 注册 java 命令优先级 1080 表示 1.8 sudo update-alternatives --install /usr/bin/java java /usr/lib/jvm/jdk1.8.0_322/bin/java 1080 # 注册 javac sudo update-alternatives --install /usr/bin/javac javac /usr/lib/jvm/jdk1.8.0_322/bin/javac 1080 # 交互式选择当前版本 sudo update-alternatives --config java--install的最后一个数字是优先级数字大的默认选中。--config会列出所有已注册版本让你选。这种方式比手改PATH干净切换时不用动 shell 配置文件。但注意它只管/usr/bin/java这个入口JAVA_HOME还是得单独设两者要一致否则 Maven 编译用一个版本、运行用另一个版本问题很难查。4.2 项目级 JDK 隔离脚本里锁死 JAVA_HOME更稳妥的做法是在项目启动脚本里显式指定JAVA_HOME不依赖全局环境#!/bin/bash # start.sh项目级锁定 JDK 版本 export JAVA_HOME/usr/lib/jvm/jdk1.8.0_322 export PATH$JAVA_HOME/bin:$PATH # 确认版本后再启动 java -version 21 | grep 1.8.0_322 || { echo JDK 版本不对退出; exit 1; } # 启动应用 java -jar app.jar这个脚本先设JAVA_HOME再用grep校验版本不对就退出。21是因为java -version输出到标准错误不重定向grep抓不到。这种写法在 CI 流水线里特别有用镜像里装了多个 JDK 也不会跑错版本。我一般把这段校验放在所有构建脚本开头宁可启动失败也不要带着错误版本跑出诡异结果。4.3 验证清单装完必须过的五道关装完别急着交付按这个清单过一遍检查项命令期望结果运行时版本java -version1.8.0_322编译器版本javac -version1.8.0_322JAVA_HOMEecho $JAVA_HOME指向 jdk1.8.0_322工具可用jar --help正常输出帮助证书工具keytool -help正常输出帮助五道关全过说明这份解压版 JDK 在当前机器上可用。任何一项不对回到对应章节查路径和PATH顺序。这张表我一般直接贴到部署文档里交接时新人照着跑一遍就知道环境有没有问题。5. 避坑与排查解压版 JDK 最容易翻车的五个地方解压安装看着简单但因为没有包管理器帮你处理依赖和链接坑反而比apt install多。下面五条都是实际环境里反复出现的按「现象 → 原因 → 解决」写清楚。5.1 java 和 javac 版本不一致现象java -version显示 1.8.0_322但javac -version显示 11 或 17。原因PATH里$JAVA_HOME/bin没排在系统/usr/bin前面java走了 JDK 8javac走了系统自带的另一个版本。或者update-alternatives只注册了java没注册javac。解决echo $PATH确认$JAVA_HOME/bin在最前用which java和which javac看实际指向两个都注册到update-alternatives并选同一版本。5.2 解压后目录名和 JAVA_HOME 对不上现象配完环境变量source了java -version还是报command not found。原因压缩包解压出来的顶层目录名不一定是jdk1.8.0_322可能是jdk8u322-b06或带其他后缀JAVA_HOME指了一个不存在的路径。解决ls /usr/lib/jvm/看实际目录名JAVA_HOME严格对应。用ls $JAVA_HOME/bin/java验证路径下确实有可执行文件。5.3 权限不足导致工具无法执行现象java -version报Permission denied。原因解压时用了 root之后普通用户没有执行权限或者从别处拷贝过来时权限位丢了。解决chmod x $JAVA_HOME/bin/*给 bin 下所有文件加执行权限确认当前用户对$JAVA_HOME目录有读和执行权限。5.4 CLASSPATH 污染导致类加载异常现象编译能过运行时报NoClassDefFoundError或加载了错误版本的类。原因CLASSPATH里残留了旧 JDK 的rt.jar或tools.jar路径或者手动加了不该加的目录。解决echo $CLASSPATH检查清掉指向其他 JDK 的条目现代项目尽量不设全局CLASSPATH交给 Maven/Gradle 管理。5.5 证书 keystore 格式跨版本不兼容现象Java 8 里生成的 keystore换到高版本 JDK 读取时报Invalid keystore format。原因Java 8 默认 JKS 格式Java 9 之后默认 PKCS12格式不匹配。解决生成时显式加-storetype JKS或-storetype PKCS12迁移时用keytool -importkeystore转换格式别直接拷贝文件。注意这五条里前两条占了实际问题的八成装完先跑which java和which javac比什么都快。6. 进阶技巧用脚本一键校验与批量部署单机装 JDK 手动几步无所谓但如果要给十台机器统一环境或者 CI 镜像里固化版本就得脚本化。这一章给一个可复用的校验脚本和一个批量部署思路都是实际项目里沉淀下来的。6.1 一键校验脚本把前面章节的检查项写成一个脚本部署后跑一次就知道环境合不合格#!/bin/bash # check_jdk.sh校验 OpenJDK 8_322 环境 EXPECTED1.8.0_322 FAIL0 # 检查 JAVA_HOME if [ -z $JAVA_HOME ]; then echo FAIL: JAVA_HOME 未设置 FAIL1 elif [ ! -x $JAVA_HOME/bin/java ]; then echo FAIL: JAVA_HOME 下没有可执行的 java FAIL1 fi # 检查 java 版本 JAVA_VER$(java -version 21 | head -1 | awk -F {print $2}) if [[ $JAVA_VER ! *$EXPECTED* ]]; then echo FAIL: java 版本为 $JAVA_VER期望 $EXPECTED FAIL1 fi # 检查 javac 版本 JAVAC_VER$(javac -version 21 | awk {print $2}) if [[ $JAVAC_VER ! *$EXPECTED* ]]; then echo FAIL: javac 版本为 $JAVAC_VER期望 $EXPECTED FAIL1 fi # 检查关键工具是否存在 for tool in jar javadoc keytool; do if ! command -v $tool /dev/null 21; then echo FAIL: $tool 不可用 FAIL1 fi done if [ $FAIL -eq 0 ]; then echo PASS: OpenJDK 8_322 环境正常 else echo 环境校验未通过请检查上述 FAIL 项 exit 1 fi脚本逻辑先查JAVA_HOME是否设置且指向有效目录再分别抓java和javac的版本号做字符串匹配最后遍历jar、javadoc、keytool确认工具存在。awk -F {print $2}从openjdk version 1.8.0_322里提取版本号21处理java -version输出到标准错误的问题。任何一项失败就exit 1方便 CI 流水线判断。6.2 批量部署的目录约定多机部署时统一目录结构和环境变量写法能省很多事。我一般约定项目约定值说明安装根目录/usr/lib/jvm/所有 JDK 放一起版本目录jdk1.8.0_322与解压顶层目录一致环境变量文件/etc/profile.d/jdk8.sh全局生效便于统一管理校验脚本/opt/scripts/check_jdk.sh部署后自动执行/etc/profile.d/下的脚本登录时自动加载比改/etc/profile干净也方便按 JDK 版本拆文件。批量部署时把压缩包和脚本一起推过去解压、移动、写环境变量、跑校验四步串成一条命令新机器上线几分钟搞定。6.3 一个我踩过的坑有次给一批机器装 JDK脚本里JAVA_HOME写的是/usr/lib/jvm/jdk1.8.0_322但压缩包解压出来是jdk8u322-b06脚本没校验目录名就直接配了环境变量。结果java -version全部报command not found十台机器挨个登上去改。从那以后我每次写部署脚本第一步都是ls确认实际目录名再动态生成JAVA_HOME绝不硬编码。这个习惯后来帮我省了无数次返工。希望帮到你。本文还有配套的精品资源点击获取