简介JDK 1.8 64位官方正式版jdk-8u45-linux-x64.tar.gz是Oracle面向64位Linux系统发布的Java开发工具包适用于需要编译、调试和运行Java程序的开发者尤其适合学习Java 8新特性或搭建企业级开发环境。压缩包共1666个文件以jar库文件、xml配置、png图标及so动态库为主包含javac、java、javadoc等完整开发工具链整体大小约165MB解压即可使用。已有3259人学习下载。该版本引入了Lambda表达式、Stream API、CompletableFuture异步编程及全新java.time日期时间API并改进了类型推断和接口默认方法能显著提升编码效率与可维护性。包内目录结构规范涵盖bin、lib、jre等核心模块适合系统学习Java 8核心特性或直接作为Linux服务器的标准JDK环境。1. jdk1.8 64 位官方正式版上手先回答“8u45 该不该装”再动手服务器要装 jdk1.8 64 位官方正式版时我一般先反问一句你是在复现老系统还是在搭新项目这个 jdk-8u45-linux-x64.tar.gz 属于 JDK 8 的早期更新发行方在 2015 年前后发布的正式版定位是给老系统做基线环境不是给新项目当默认。拆开这份资源看内容就是一个干净的 Linux 64 位 JDK 压缩包解压到固定目录配好 JAVA_HOME 和 PATHjava -version 就能跑通。适合的人群很明确——要复现某高校实验环境的同学、维护模拟项目X的开发者、以及在一台 64 位工作机上同时开发多套老工程的从业者。如果你是新项目直接选更高版本如果系统指定 Java 8这份 8u45 能少折腾不少。2. 安装前确认架构、旧环境和文件完整性三个前提2.1 先确认 Linux 是 x86_648u45 没有别的架构版本拿到 tar.gz 不要急着解压先看机器架构。8u45 这个版本只发布过 64 位 x86 版本没有 aarch64、没有 32 位版本。如果你的机器是 ARM 架构后面所有步骤都不用走直接找对应架构的 JDK 版本才是正路。uname -m # 输出 x86_64 才继续输出 aarch64 或 armv7l 就停逻辑说明uname -m 输出的是内核架构名x86_64 表示 64 位 x86 架构这是 jdk-8u45-linux-x64.tar.gz 唯一支持的架构。其他输出比如 aarch64说明主机是 ARM 处理器硬解压也能解但运行时直接报无法执行二进制文件翻车翻得很干脆。参数说明-m 是 machine 的意思也可以用 arch 命令输出结果相同。有些容器环境里 uname 输出会被隔离层改写建议顺手配合 lscpu 再看一眼 CPU 型号避免被那层壳骗过去。架构确认无误后再检查系统库依赖。JDK 8 运行时依赖 glibc而 8u45 的年代比较早最低要求是 glibc 2.2.5 以上常见 Linux 发行版都满足。不过如果你在精简过的容器镜像里跑下面这条命令值得执行一次。ldd --version | head -1 # 例如输出ldd (GNU libc) 2.31逻辑说明ldd --version 输出 glibc 版本。JDK 8 的启动器是动态链接的glibc 太老会报 GLIBC_2.x not found太新反而没问题。真正容易翻车的是精简容器里缺 libc 的某些符号这时候解压正常、一运行就崩。出现这类问题直接换完整版基础镜像少走弯路。2.2 检查系统已有的 Java别让 OpenJDK 抢先很多 Linux 发行版自带 OpenJDK或者之前部署别的系统时装过另一个 JDK。如果不先查清楚安装完成后 java -version 显示的还是旧环境这是最典型的翻车点也是新手最常见的困惑。which -a java java -version 21 update-alternatives --list java 2/dev/null逻辑说明第一条命令列出 PATH 里能找到的所有 java 可执行文件位置第二条看当前默认 Java 的版本第三条在 Debian/Ubuntu 系系统里列出系统级 Java 备选。如果 which -a 输出两个以上路径说明环境里有多个 JDK 在抢占配置新 JDK 时必须把 PATH 顺序理清楚。参数说明java -version 的输出会打到标准错误所以加了 21 才能正确显示update-alternatives 在 CentOS/RHEL 系可能不存在命令不存在时报错所以用 2/dev/null 静默忽略。我一般会顺手看下系统里有没有老 JDK 的残留目录。/usr/lib/jvm 下如果有一堆目录说明这台机器之前被反复折腾过。对这类机器我倾向不动系统包管理器里的 JDK而是把新装的 8u45 放在独立目录通过环境变量优先级覆盖这样卸载或切换都干净。盲目卸载系统自带的 JDK可能影响系统里其他依赖 Java 的工具这是常见误用。比如某个系统监控组件用的是 /usr/bin/java你把它卸了监控组件也一起罢工。2.3 校验文件完整性与包结构解压之前先看清单下载资源最容易出问题的是文件损坏。tar.gz 解压到一半报错比不解压更难受。我习惯解压前先做两个动作看文件格式、列压缩包内容。file jdk-8u45-linux-x64.tar.gz ls -l jdk-8u45-linux-x64.tar.gz md5sum jdk-8u45-linux-x64.tar.gz逻辑说明file 输出会告诉你这个文件是不是真正的 gzip 压缩数据ls -l 看体积JDK 8u45 的 Linux x64 包大约 130 MB 左右如果只有几十 KB说明下载被中断了md5sum 算出校验值和发行方公布的校验码对一下确认文件没有在传输过程中被改写。这三个检查在团队内分发文件时尤其有用能直接排除“包坏了”这个嫌疑。参数说明md5sum 是绝大多数发行版自带的工具输出 32 位十六进制字符串。安全性要求高的场景建议用 sha256sum不过在确认一份老版本 JDK 的完整性上md5 足够排除下载损坏。解压前还可以用 tar 的列表模式快速确认包内容不用真的解压tar -tzf jdk-8u45-linux-x64.tar.gz | head -20逻辑说明-t 是列出内容-z 是解 gzip-f 指定文件。输出第一行一般是 jdk1.8.0_45/这是解压后的顶层目录名。看到这个目录名后面配置 JAVA_HOME 就知道该写什么路径。这一步也顺便验证了压缩包能正常读取确认 gzip 层没坏。参数说明head -20 只显示前 20 行避免目录列表太长刷屏。顶层目录名 jdk1.8.0_45 对应的是 Java 8 Update 45也就是 8u45这是两套命名体系在排错时经常混用记一下没坏处。到这里三个前提都确认完了架构对、系统里的旧 Java 不影响、文件完整。接下来就可以动手解压。3. 解压安装与环境变量配置三行配置把 JDK 8 跑通3.1 目录规划与解压/usr/local/java 下的软链管理JDK 8 的 tar.gz 解压即用不需要编译这也是这份资源最大的便利。目录规划上我习惯统一放 /usr/local/java这样 JAVA_HOME 好写、备份好找。不要解压到 /root 或某个普通用户的家目录下换用户跑程序时权限问题会让你怀疑人生到时候再搬家更麻烦。sudo mkdir -p /usr/local/java sudo tar -xzf jdk-8u45-linux-x64.tar.gz -C /usr/local/java cd /usr/local/java sudo ln -sfn jdk1.8.0_45 jdk8 ls -l /usr/local/java逻辑说明第一条创建目标目录第二条把压缩包解开并放到 /usr/local/java 下解压出来的目录名是 jdk1.8.0_45第三条用软链 jdk8 指向这个版本目录好处是以后升级 JDK 不用改环境变量只需要把软链换到新目录。ls -l 会看到 jdk8 - jdk1.8.0_45 的链接关系。参数说明tar 的 -x 是解压、-z 处理 gzip、-f 指定文件-C 指定解压目标目录。ln -sfn 中 -s 建软链、-f 强制覆盖已有链接、-n 把目标当普通文件处理避免链接套链接。这套软链管理方式比直接改环境变量里的版本号要安全和可逆。有的系统里 /usr/local 可能没有写权限所以 mkdir 和解压都带了 sudo。权限这块特别注意JDK 解压出来的文件默认属主是当前用户如果当前用户不是 root后面其他账号执行 java 时可能读不了。稳妥做法是解压后统一收一次权限。sudo chown -R root:root /usr/local/java/jdk1.8.0_45逻辑说明把 JDK 目录属主统一改成 root任何用户执行 java 都是只读访问不涉及写。如果让普通用户拥有 JDK 目录该用户上传的脚本可以替换 lib 下的 jar等于直接接管 Java 运行时。用最小权限跑 Java 服务是基本习惯尤其在多人共用的服务器上。3.2 JAVA_HOME、PATH、CLASSPATH三行的取舍环境变量配置是 JDK 安装里争议最多的部分。先说结论JAVA_HOME 必须设PATH 必须加上 $JAVA_HOME/binCLASSPATH 我建议不设。很多老教程教你把 CLASSPATH 设成 .:/usr/local/java/jdk8/lib这在 Java 8 里是给自己挖坑。# 打开 /etc/profile 或 /etc/profile.d/java.sh追加以下内容 export JAVA_HOME/usr/local/java/jdk8 export PATH$JAVA_HOME/bin:$PATH # export CLASSPATH.:$JAVA_HOME/lib # 不推荐别加逻辑说明JAVA_HOME 指向 JDK 根目录很多构建工具都依赖它PATH 加在最前面让系统优先找到 jdk8/bin 下的命令。CLASSPATH 是 Java 5 之前的遗产8u45 时代 java 和 javac 会自动加载核心库手动指定还容易把当前目录 . 塞进去造成类加载黑匣子——某个类从当前目录读到旧版本运行行为诡异。真需要额外 classpath 时用 java -cp 显式指定更可控。参数说明JAVA_HOME 用软链路径 /usr/local/java/jdk8 而不是 /usr/local/java/jdk1.8.0_45之后换版本只动软链。PATH 必须把 $JAVA_HOME/bin 放在最前否则系统自带的 OpenJDK 会在前面被优先找到这就是很多人装完 JDK 发现 java -version 没变的直接原因。配置文件的选型也是一个点。写在 /etc/profile 里所有用户生效适合服务器写在 ~/.bashrc 只对当前用户生效适合开发机。我一般写 /etc/profile.d/java.sh理由是发行版约定俗成的机制登录 shell 会自动加载而且不污染主 profile。文件里每行一个 export注释写明版本号半年后回头看也不会一脸茫然。3.3 验证安装java -version 只是第一步配置完环境变量后新开一个终端或重新登录然后验证。source /etc/profile echo $JAVA_HOME which java java -version javac -version逻辑说明echo 确认变量生效which java 确认 PATH 里第一个 java 是不是 /usr/local/java/jdk8/bin/javajava -version 输出应该包含 1.8.0_45 字样javac -version 确认编译器和 JDK 版本一致。四步都通过安装才算完成。很多人只跑 java -version结果 javac 用不了构建工具跟着崩。参数说明source 是当前 shell 重新加载 profile 文件但定时任务、systemd 服务都不读它那是后面避坑章要讲的内容。这里插一句验证时如果 java -version 显示的是 openjdk 版本先别急着改 profile用 type -a java 看哪个路径被抢占了。type -a java逻辑说明type 命令列出系统会执行的 java 路径顺序。如果输出第一行是 /usr/bin/java说明 PATH 里系统目录排在 /usr/local/java/jdk8/bin 前面。解决方法是检查 3.2 里的 export PATH 写法是不是把 $JAVA_HOME/bin 放在 $PATH 前面。这个命令在排查多 JDK 冲突时几乎每次都用到。参数说明type 显示的是命令解析结果比 which 更可靠因为 which 在某些 shell 里只找 PATH 第一个匹配。养成用 type -a 的习惯排查顺序问题能少踩不少坑。4. 解压后的目录与 JVM 参数8u45 的默认值和常用调优边界4.1 目录结构bin、lib、jre、db 各管什么解压后 jdk1.8.0_45 下有十几个子目录新手容易把它们当成可以随便改的黑匣子。拆过这份 tar.gz 就知道顶层目录里除了标准工具目录还有 jre、db、include 这些。下面这个表格是实际解压后就能看到的目录/文件作用常见误用binjava、javac、jar、keytool 等可执行工具把它从 PATH 里漏掉libJDK 自身的库rt.jar、tools.jar手动改这里的 jarjreJava 运行时环境含 java 启动器把 JAVA_HOME 指向 jredb内置的 Java DBDerby拿它存业务数据include本地接口头文件JNI 开发用普通开发不需要动关键点在 jre 目录。很多教程让你把 JAVA_HOME 设成 /usr/local/java/jdk8/jre这是错误做法。JAVA_HOME 必须是 JDK 根目录因为 javac、jar 这些工具在根目录的 bin 下而 jre/bin 里只有 java。把 JAVA_HOME 指到 jre编译类工具直接找不到。老报 command not found: javac 的排查思路就该落到这。lib 目录在 Java 8 里有一个时代特征rt.jar、tools.jar 还以 jar 形式存在Java 9 之后这些都被模块化拆分了。8u45 上如果遇到找不到 tools.jar 的问题多半是 classpath 里少了 JDK 根目录下的 lib。再次提醒不要往 lib 里塞第三方 jar那是类加载混乱的开始出了诡异问题根本查不出。4.2 JVM 参数基线8u45 能吃什么参数默认值到哪8u45 是 JDK 8 早期版本JVM 参数体系已经全面切到 Metaspace但某些新参数还不认。常见的调优写法如下java -Xms512m -Xmx2048m -XX:MetaspaceSize256m -XX:MaxMetaspaceSize512m -XX:UseG1GC -jar app.jar逻辑说明-Xms 指定堆初始大小-Xmx 指定最大堆这两个是 8u45 最常动的参数。-XX:MetaspaceSize 是元空间初始阈值JDK 7 时代的 PermSize 在 8 里已经废弃设了会被忽略。-XX:UseG1GC 启用 G1 收集器8u45 这块已经稳定多核大内存服务推荐开。参数说明8u45 默认堆初始大小约是物理内存的 1/64最大堆是 1/4在容器环境下这个默认值很容易超配额所以容器里必须显式指定 -Xms 和 -Xmx。G1 在 8u45 里不是默认收集器需要手动 -XX:UseG1GC 打开不打开则用 Parallel 收集器适合吞吐优先但延迟表现一般的场景。再补一个踩坑点8u45 时代 -XX:MaxPermSize 参数还能识别但无意义因为 8 已经用 Metaspace 替代了 PermGen。有些老项目的启动脚本从 JDK 7 迁移过来还带着 PermSize参数会被忽略但不报错造成内存上限和预期不符。排查方法是看实际元空间用量而不是盯着启动日志里的参数发呆。4.3 多版本 JDK 共存update-alternatives 还是 PATH 排序开发机或测试机上经常要 JDK 7 和 JDK 8 并存或者 8 和 11 并存。我不推荐频繁改 /etc/profile 来切换那是在给自己制造后悔药需求。Debian/Ubuntu 系有 update-alternativesCentOS 系也有 alternatives但更通用的做法是手动管理软链和 PATH。sudo update-alternatives --install /usr/bin/java java /usr/local/java/jdk8/bin/java 2025 sudo update-alternatives --set java /usr/local/java/jdk8/bin/java逻辑说明--install 把新 JDK 的 java 注册进系统备选优先级 2025--set 直接指定当前默认。这种做法的好处是只影响 java 命令不影响 JAVA_HOME。但注意update-alternatives 不管理 JAVA_HOMEIDE 和构建工具认的是环境变量。所以服务器场景我一般只靠 PATH 顺序开发机场景才用 alternatives。参数说明优先级数字越大越靠前2025 是为了明显高于系统自带的 OpenJDK 优先级。--set 指定的路径必须和 --install 注册的一致否则切换无效。如果同时跑两个 Java 版本的程序千万不要改全局默认而是各服务的启动脚本里各自声明。某个模拟项目曾因为有人把全局 java 切到新版本导致同机另一个老服务直接启动失败。血泪教训全局默认版本尽量不动需要特定版本就写在服务的启动脚本里用绝对路径调用。4.4 运行时确认怎么知道 JVM 真的吃到了参数配置完参数别急着说调优成功。用下面的命令确认当前进程实际生效的 JVM 参数避免参数写错位置被静默忽略。jps -l jcmd pid VM.flags逻辑说明jps 列出当前 Java 进程及 PIDjcmd 查询指定进程的 JVM flags输出的是实际生效参数包括显式和默认的。这个验证能直接发现 -Xmx 是否被识别、G1 是否真的启用比看启动脚本要靠谱得多。参数说明jcmd 是 8u45 自带的诊断工具路径在 jdk8/bin 下。如果进程不是当前用户启动的可能需要加 sudo 才能读取。查完记得核对输出里的 MaxHeapSize 和 GC 收集器名称这两个是确认参数生效的最直观证据。5. 避坑清单8u45 版本相关的五个典型坑5.1 java -version 显示的是 OpenJDK现象安装完成后执行 java -version输出 openjdk version 1.8.0_... 而不是 sun 的 1.8.0_45。原因系统包管理器自带的 OpenJDK 已经在 /usr/bin/java 注册PATH 里 /usr/bin 排在 /usr/local/java/jdk8/bin 前面。环境变量配置没有被当前 shell 重新加载也是常见原因。解决重新登录或 source /etc/profile然后 type -a java 查看路径顺序如果 /usr/bin/java 仍靠前把 export PATH$JAVA_HOME/bin:$PATH 里的顺序确认改成 JAVA_HOME 开头。最后 java -version 验证输出变成 java version 1.8.0_45。5.2 解压报 gzip: stdin: not in gzip format现象tar -xzf 执行到一半报错说文件不是 gzip 格式。原因下载被中断或者浏览器把下载地址解析成了 HTML 错误页并保存下来。file 命令会显示这个文件其实是 ASCII text 或 HTML 文档根本不是 gzip 数据。解决不要盲目重新下载再试先跑 file、md5sum 校验确认体积在 130 MB 级别。下载时选支持断点续传的下载工具。解压前用 tar -tzf 预览列表能列出内容说明包结构完好这一步能省下后续所有排查。5.3 启动服务时找不到 java但手动执行 java -version 正常现象在终端手工测试 java 没问题systemd 服务或 crontab 里一执行就报 java: command not found。原因systemd 和 crontab 的环境不加载 /etc/profile也不读 ~/.bashrc它们的 PATH 是系统默认路径不包含 /usr/local/java/jdk8/bin。解决在 Unit 文件里显式写 EnvironmentPATH 和 EnvironmentJAVA_HOMEcrontab 脚本开头先 export 路径或脚本里直接用 /usr/local/java/jdk8/bin/java 绝对路径调用。这里绝对路径最省事也最不容易被环境差异影响。5.4 JAVA_HOME 指到了 jrejavac 和 jar 全部失踪现象java 能用javac、jar 报 command not found。原因JAVA_HOME 被设成了 .../jrePATH 自然变成了 .../jre/bin而 jre/bin 下只有一个 java工具命令都在 JDK 根目录的 bin 里。这类配置相当常见因为老教程时代 jdk 和 jre 是分开下载的两个目录各有 bin。解决把 JAVA_HOME 改回 /usr/local/java/jdk8确认根目录下有 bin、lib、jre 三个兄弟目录而不是只有 jre。配置后 echo $JAVA_HOME 复查同时验证 javac -version。这套组合检查一次性解决。5.5 8u45 连不上只开 TLS 1.3 的服务现象用 8u45 写的小程序访问某个 HTTPS 接口报 SSLHandshakeException但用浏览器或新版 JDK 能正常访问。原因8u45 的年代 TLS 1.3 还没有普及这个版本的安全协议栈最高只支持到 TLS 1.2。对端如果只开启 TLS 1.3版本匹配失败。解决一是对端兼容 TLS 1.2二是如果业务允许升级到 8 后期版本。这里要提醒8u45 作为老版本 JDK安全基线较低不是生产环境首选只适合复现老系统或临时验证。从安全角度考虑下载方要明确这个版本的使用边界别拿它做公网服务。6. 再多做一步把 JDK 8 基线验证脚本固化下来6.1 verify_jdk8.sh一个可复用的基线检查脚本JDK 装好后我习惯把验证过程固化成一个脚本新机器、新服务器都跑这一遍。脚本检查五件事架构、JAVA_HOME 是否配置、JAVA_HOME 目录是否存在、java 版本、javac 版本。#!/bin/bash # JDK 8 基线验证脚本验证架构、JAVA_HOME、java/javac 版本 e0 [ $(uname -m) x86_64 ] || { echo FAIL: 架构不是 x86_64; e1; } [ -n $JAVA_HOME ] || { echo FAIL: JAVA_HOME 未设置; e1; } [ -d $JAVA_HOME ] || { echo FAIL: JAVA_HOME 目录不存在; e1; } java -version 21 | grep -q 1.8.0_45 || { echo FAIL: java 版本不是 1.8.0_45; e1; } javac -version 21 | grep -q 1.8.0_45 || { echo FAIL: javac 版本不是 1.8.0_45; e1; } [ $e -eq 0 ] echo PASS: JDK 8 基线检查全部通过 exit $e逻辑说明脚本用一条计数器 e 汇总检查结果任何一项失败就置为 1最后统一退出。每个检查项输出 FAIL 时带上具体原因一眼定位问题。java 和 javac 的版本检查通过管道把输出交给 grep匹配到 1.8.0_45 才通过。参数说明grep -q 是静默匹配不输出匹配内容只返回退出码21 把版本输出合并到标准输出因为 java -version 打的是标准错误。如果检查的是其他 8u 版本把两处 1.8.0_45 改成对应版本号即可。脚本保存为 verify_jdk8.sh 后用 bash 执行记得先 source /etc/profile 让 JAVA_HOME 在当前 shell 生效。6.2 把基线变成习惯换版本、迁移环境时怎么改这套脚本的价值在于把版本、路径、工具链三个最容易翻车的点用一条命令跑完。每次部署新环境后执行一次脚本输出全部 PASS 才进行下一步。如果某个检查项 FAIL按上面避坑清单逐项排查。迁移环境时脚本里的版本号改成目标版本JAVA_HOME 指向新软链其余逻辑不用动。多台机器同时升级时脚本还能当巡检工具批量跑输出里哪个 FAIL 一目了然。从那以后我在任何机器上装完 JDK 8都会强制走一遍这个脚本确认版本、架构、路径三个基线再交付避免“手动 java -version 正常但构建工具用不了”这类尴尬场景。希望这份 8u45 的拆解和脚本能帮到你至少下载之后别在环境变量和路径上再花冤枉时间。本文还有配套的精品资源点击获取 
长河君 · 2026/10/21 21:38:37 · 阅读 1.2k JDK 1.8 64位官方版Linux安装配置：从环境变量到JVM参数避坑指南
简介JDK 1.8 64位官方正式版jdk-8u45-linux-x64.tar.gz是Oracle面向64位Linux系统发布的Java开发工具包适用于需要编译、调试和运行Java程序的开发者尤其适合学习Java 8新特性或搭建企业级开发环境。压缩包共1666个文件以jar库文件、xml配置、png图标及so动态库为主包含javac、java、javadoc等完整开发工具链整体大小约165MB解压即可使用。已有3259人学习下载。该版本引入了Lambda表达式、Stream API、CompletableFuture异步编程及全新java.time日期时间API并改进了类型推断和接口默认方法能显著提升编码效率与可维护性。包内目录结构规范涵盖bin、lib、jre等核心模块适合系统学习Java 8核心特性或直接作为Linux服务器的标准JDK环境。1. jdk1.8 64 位官方正式版上手先回答“8u45 该不该装”再动手服务器要装 jdk1.8 64 位官方正式版时我一般先反问一句你是在复现老系统还是在搭新项目这个 jdk-8u45-linux-x64.tar.gz 属于 JDK 8 的早期更新发行方在 2015 年前后发布的正式版定位是给老系统做基线环境不是给新项目当默认。拆开这份资源看内容就是一个干净的 Linux 64 位 JDK 压缩包解压到固定目录配好 JAVA_HOME 和 PATHjava -version 就能跑通。适合的人群很明确——要复现某高校实验环境的同学、维护模拟项目X的开发者、以及在一台 64 位工作机上同时开发多套老工程的从业者。如果你是新项目直接选更高版本如果系统指定 Java 8这份 8u45 能少折腾不少。2. 安装前确认架构、旧环境和文件完整性三个前提2.1 先确认 Linux 是 x86_648u45 没有别的架构版本拿到 tar.gz 不要急着解压先看机器架构。8u45 这个版本只发布过 64 位 x86 版本没有 aarch64、没有 32 位版本。如果你的机器是 ARM 架构后面所有步骤都不用走直接找对应架构的 JDK 版本才是正路。uname -m # 输出 x86_64 才继续输出 aarch64 或 armv7l 就停逻辑说明uname -m 输出的是内核架构名x86_64 表示 64 位 x86 架构这是 jdk-8u45-linux-x64.tar.gz 唯一支持的架构。其他输出比如 aarch64说明主机是 ARM 处理器硬解压也能解但运行时直接报无法执行二进制文件翻车翻得很干脆。参数说明-m 是 machine 的意思也可以用 arch 命令输出结果相同。有些容器环境里 uname 输出会被隔离层改写建议顺手配合 lscpu 再看一眼 CPU 型号避免被那层壳骗过去。架构确认无误后再检查系统库依赖。JDK 8 运行时依赖 glibc而 8u45 的年代比较早最低要求是 glibc 2.2.5 以上常见 Linux 发行版都满足。不过如果你在精简过的容器镜像里跑下面这条命令值得执行一次。ldd --version | head -1 # 例如输出ldd (GNU libc) 2.31逻辑说明ldd --version 输出 glibc 版本。JDK 8 的启动器是动态链接的glibc 太老会报 GLIBC_2.x not found太新反而没问题。真正容易翻车的是精简容器里缺 libc 的某些符号这时候解压正常、一运行就崩。出现这类问题直接换完整版基础镜像少走弯路。2.2 检查系统已有的 Java别让 OpenJDK 抢先很多 Linux 发行版自带 OpenJDK或者之前部署别的系统时装过另一个 JDK。如果不先查清楚安装完成后 java -version 显示的还是旧环境这是最典型的翻车点也是新手最常见的困惑。which -a java java -version 21 update-alternatives --list java 2/dev/null逻辑说明第一条命令列出 PATH 里能找到的所有 java 可执行文件位置第二条看当前默认 Java 的版本第三条在 Debian/Ubuntu 系系统里列出系统级 Java 备选。如果 which -a 输出两个以上路径说明环境里有多个 JDK 在抢占配置新 JDK 时必须把 PATH 顺序理清楚。参数说明java -version 的输出会打到标准错误所以加了 21 才能正确显示update-alternatives 在 CentOS/RHEL 系可能不存在命令不存在时报错所以用 2/dev/null 静默忽略。我一般会顺手看下系统里有没有老 JDK 的残留目录。/usr/lib/jvm 下如果有一堆目录说明这台机器之前被反复折腾过。对这类机器我倾向不动系统包管理器里的 JDK而是把新装的 8u45 放在独立目录通过环境变量优先级覆盖这样卸载或切换都干净。盲目卸载系统自带的 JDK可能影响系统里其他依赖 Java 的工具这是常见误用。比如某个系统监控组件用的是 /usr/bin/java你把它卸了监控组件也一起罢工。2.3 校验文件完整性与包结构解压之前先看清单下载资源最容易出问题的是文件损坏。tar.gz 解压到一半报错比不解压更难受。我习惯解压前先做两个动作看文件格式、列压缩包内容。file jdk-8u45-linux-x64.tar.gz ls -l jdk-8u45-linux-x64.tar.gz md5sum jdk-8u45-linux-x64.tar.gz逻辑说明file 输出会告诉你这个文件是不是真正的 gzip 压缩数据ls -l 看体积JDK 8u45 的 Linux x64 包大约 130 MB 左右如果只有几十 KB说明下载被中断了md5sum 算出校验值和发行方公布的校验码对一下确认文件没有在传输过程中被改写。这三个检查在团队内分发文件时尤其有用能直接排除“包坏了”这个嫌疑。参数说明md5sum 是绝大多数发行版自带的工具输出 32 位十六进制字符串。安全性要求高的场景建议用 sha256sum不过在确认一份老版本 JDK 的完整性上md5 足够排除下载损坏。解压前还可以用 tar 的列表模式快速确认包内容不用真的解压tar -tzf jdk-8u45-linux-x64.tar.gz | head -20逻辑说明-t 是列出内容-z 是解 gzip-f 指定文件。输出第一行一般是 jdk1.8.0_45/这是解压后的顶层目录名。看到这个目录名后面配置 JAVA_HOME 就知道该写什么路径。这一步也顺便验证了压缩包能正常读取确认 gzip 层没坏。参数说明head -20 只显示前 20 行避免目录列表太长刷屏。顶层目录名 jdk1.8.0_45 对应的是 Java 8 Update 45也就是 8u45这是两套命名体系在排错时经常混用记一下没坏处。到这里三个前提都确认完了架构对、系统里的旧 Java 不影响、文件完整。接下来就可以动手解压。3. 解压安装与环境变量配置三行配置把 JDK 8 跑通3.1 目录规划与解压/usr/local/java 下的软链管理JDK 8 的 tar.gz 解压即用不需要编译这也是这份资源最大的便利。目录规划上我习惯统一放 /usr/local/java这样 JAVA_HOME 好写、备份好找。不要解压到 /root 或某个普通用户的家目录下换用户跑程序时权限问题会让你怀疑人生到时候再搬家更麻烦。sudo mkdir -p /usr/local/java sudo tar -xzf jdk-8u45-linux-x64.tar.gz -C /usr/local/java cd /usr/local/java sudo ln -sfn jdk1.8.0_45 jdk8 ls -l /usr/local/java逻辑说明第一条创建目标目录第二条把压缩包解开并放到 /usr/local/java 下解压出来的目录名是 jdk1.8.0_45第三条用软链 jdk8 指向这个版本目录好处是以后升级 JDK 不用改环境变量只需要把软链换到新目录。ls -l 会看到 jdk8 - jdk1.8.0_45 的链接关系。参数说明tar 的 -x 是解压、-z 处理 gzip、-f 指定文件-C 指定解压目标目录。ln -sfn 中 -s 建软链、-f 强制覆盖已有链接、-n 把目标当普通文件处理避免链接套链接。这套软链管理方式比直接改环境变量里的版本号要安全和可逆。有的系统里 /usr/local 可能没有写权限所以 mkdir 和解压都带了 sudo。权限这块特别注意JDK 解压出来的文件默认属主是当前用户如果当前用户不是 root后面其他账号执行 java 时可能读不了。稳妥做法是解压后统一收一次权限。sudo chown -R root:root /usr/local/java/jdk1.8.0_45逻辑说明把 JDK 目录属主统一改成 root任何用户执行 java 都是只读访问不涉及写。如果让普通用户拥有 JDK 目录该用户上传的脚本可以替换 lib 下的 jar等于直接接管 Java 运行时。用最小权限跑 Java 服务是基本习惯尤其在多人共用的服务器上。3.2 JAVA_HOME、PATH、CLASSPATH三行的取舍环境变量配置是 JDK 安装里争议最多的部分。先说结论JAVA_HOME 必须设PATH 必须加上 $JAVA_HOME/binCLASSPATH 我建议不设。很多老教程教你把 CLASSPATH 设成 .:/usr/local/java/jdk8/lib这在 Java 8 里是给自己挖坑。# 打开 /etc/profile 或 /etc/profile.d/java.sh追加以下内容 export JAVA_HOME/usr/local/java/jdk8 export PATH$JAVA_HOME/bin:$PATH # export CLASSPATH.:$JAVA_HOME/lib # 不推荐别加逻辑说明JAVA_HOME 指向 JDK 根目录很多构建工具都依赖它PATH 加在最前面让系统优先找到 jdk8/bin 下的命令。CLASSPATH 是 Java 5 之前的遗产8u45 时代 java 和 javac 会自动加载核心库手动指定还容易把当前目录 . 塞进去造成类加载黑匣子——某个类从当前目录读到旧版本运行行为诡异。真需要额外 classpath 时用 java -cp 显式指定更可控。参数说明JAVA_HOME 用软链路径 /usr/local/java/jdk8 而不是 /usr/local/java/jdk1.8.0_45之后换版本只动软链。PATH 必须把 $JAVA_HOME/bin 放在最前否则系统自带的 OpenJDK 会在前面被优先找到这就是很多人装完 JDK 发现 java -version 没变的直接原因。配置文件的选型也是一个点。写在 /etc/profile 里所有用户生效适合服务器写在 ~/.bashrc 只对当前用户生效适合开发机。我一般写 /etc/profile.d/java.sh理由是发行版约定俗成的机制登录 shell 会自动加载而且不污染主 profile。文件里每行一个 export注释写明版本号半年后回头看也不会一脸茫然。3.3 验证安装java -version 只是第一步配置完环境变量后新开一个终端或重新登录然后验证。source /etc/profile echo $JAVA_HOME which java java -version javac -version逻辑说明echo 确认变量生效which java 确认 PATH 里第一个 java 是不是 /usr/local/java/jdk8/bin/javajava -version 输出应该包含 1.8.0_45 字样javac -version 确认编译器和 JDK 版本一致。四步都通过安装才算完成。很多人只跑 java -version结果 javac 用不了构建工具跟着崩。参数说明source 是当前 shell 重新加载 profile 文件但定时任务、systemd 服务都不读它那是后面避坑章要讲的内容。这里插一句验证时如果 java -version 显示的是 openjdk 版本先别急着改 profile用 type -a java 看哪个路径被抢占了。type -a java逻辑说明type 命令列出系统会执行的 java 路径顺序。如果输出第一行是 /usr/bin/java说明 PATH 里系统目录排在 /usr/local/java/jdk8/bin 前面。解决方法是检查 3.2 里的 export PATH 写法是不是把 $JAVA_HOME/bin 放在 $PATH 前面。这个命令在排查多 JDK 冲突时几乎每次都用到。参数说明type 显示的是命令解析结果比 which 更可靠因为 which 在某些 shell 里只找 PATH 第一个匹配。养成用 type -a 的习惯排查顺序问题能少踩不少坑。4. 解压后的目录与 JVM 参数8u45 的默认值和常用调优边界4.1 目录结构bin、lib、jre、db 各管什么解压后 jdk1.8.0_45 下有十几个子目录新手容易把它们当成可以随便改的黑匣子。拆过这份 tar.gz 就知道顶层目录里除了标准工具目录还有 jre、db、include 这些。下面这个表格是实际解压后就能看到的目录/文件作用常见误用binjava、javac、jar、keytool 等可执行工具把它从 PATH 里漏掉libJDK 自身的库rt.jar、tools.jar手动改这里的 jarjreJava 运行时环境含 java 启动器把 JAVA_HOME 指向 jredb内置的 Java DBDerby拿它存业务数据include本地接口头文件JNI 开发用普通开发不需要动关键点在 jre 目录。很多教程让你把 JAVA_HOME 设成 /usr/local/java/jdk8/jre这是错误做法。JAVA_HOME 必须是 JDK 根目录因为 javac、jar 这些工具在根目录的 bin 下而 jre/bin 里只有 java。把 JAVA_HOME 指到 jre编译类工具直接找不到。老报 command not found: javac 的排查思路就该落到这。lib 目录在 Java 8 里有一个时代特征rt.jar、tools.jar 还以 jar 形式存在Java 9 之后这些都被模块化拆分了。8u45 上如果遇到找不到 tools.jar 的问题多半是 classpath 里少了 JDK 根目录下的 lib。再次提醒不要往 lib 里塞第三方 jar那是类加载混乱的开始出了诡异问题根本查不出。4.2 JVM 参数基线8u45 能吃什么参数默认值到哪8u45 是 JDK 8 早期版本JVM 参数体系已经全面切到 Metaspace但某些新参数还不认。常见的调优写法如下java -Xms512m -Xmx2048m -XX:MetaspaceSize256m -XX:MaxMetaspaceSize512m -XX:UseG1GC -jar app.jar逻辑说明-Xms 指定堆初始大小-Xmx 指定最大堆这两个是 8u45 最常动的参数。-XX:MetaspaceSize 是元空间初始阈值JDK 7 时代的 PermSize 在 8 里已经废弃设了会被忽略。-XX:UseG1GC 启用 G1 收集器8u45 这块已经稳定多核大内存服务推荐开。参数说明8u45 默认堆初始大小约是物理内存的 1/64最大堆是 1/4在容器环境下这个默认值很容易超配额所以容器里必须显式指定 -Xms 和 -Xmx。G1 在 8u45 里不是默认收集器需要手动 -XX:UseG1GC 打开不打开则用 Parallel 收集器适合吞吐优先但延迟表现一般的场景。再补一个踩坑点8u45 时代 -XX:MaxPermSize 参数还能识别但无意义因为 8 已经用 Metaspace 替代了 PermGen。有些老项目的启动脚本从 JDK 7 迁移过来还带着 PermSize参数会被忽略但不报错造成内存上限和预期不符。排查方法是看实际元空间用量而不是盯着启动日志里的参数发呆。4.3 多版本 JDK 共存update-alternatives 还是 PATH 排序开发机或测试机上经常要 JDK 7 和 JDK 8 并存或者 8 和 11 并存。我不推荐频繁改 /etc/profile 来切换那是在给自己制造后悔药需求。Debian/Ubuntu 系有 update-alternativesCentOS 系也有 alternatives但更通用的做法是手动管理软链和 PATH。sudo update-alternatives --install /usr/bin/java java /usr/local/java/jdk8/bin/java 2025 sudo update-alternatives --set java /usr/local/java/jdk8/bin/java逻辑说明--install 把新 JDK 的 java 注册进系统备选优先级 2025--set 直接指定当前默认。这种做法的好处是只影响 java 命令不影响 JAVA_HOME。但注意update-alternatives 不管理 JAVA_HOMEIDE 和构建工具认的是环境变量。所以服务器场景我一般只靠 PATH 顺序开发机场景才用 alternatives。参数说明优先级数字越大越靠前2025 是为了明显高于系统自带的 OpenJDK 优先级。--set 指定的路径必须和 --install 注册的一致否则切换无效。如果同时跑两个 Java 版本的程序千万不要改全局默认而是各服务的启动脚本里各自声明。某个模拟项目曾因为有人把全局 java 切到新版本导致同机另一个老服务直接启动失败。血泪教训全局默认版本尽量不动需要特定版本就写在服务的启动脚本里用绝对路径调用。4.4 运行时确认怎么知道 JVM 真的吃到了参数配置完参数别急着说调优成功。用下面的命令确认当前进程实际生效的 JVM 参数避免参数写错位置被静默忽略。jps -l jcmd pid VM.flags逻辑说明jps 列出当前 Java 进程及 PIDjcmd 查询指定进程的 JVM flags输出的是实际生效参数包括显式和默认的。这个验证能直接发现 -Xmx 是否被识别、G1 是否真的启用比看启动脚本要靠谱得多。参数说明jcmd 是 8u45 自带的诊断工具路径在 jdk8/bin 下。如果进程不是当前用户启动的可能需要加 sudo 才能读取。查完记得核对输出里的 MaxHeapSize 和 GC 收集器名称这两个是确认参数生效的最直观证据。5. 避坑清单8u45 版本相关的五个典型坑5.1 java -version 显示的是 OpenJDK现象安装完成后执行 java -version输出 openjdk version 1.8.0_... 而不是 sun 的 1.8.0_45。原因系统包管理器自带的 OpenJDK 已经在 /usr/bin/java 注册PATH 里 /usr/bin 排在 /usr/local/java/jdk8/bin 前面。环境变量配置没有被当前 shell 重新加载也是常见原因。解决重新登录或 source /etc/profile然后 type -a java 查看路径顺序如果 /usr/bin/java 仍靠前把 export PATH$JAVA_HOME/bin:$PATH 里的顺序确认改成 JAVA_HOME 开头。最后 java -version 验证输出变成 java version 1.8.0_45。5.2 解压报 gzip: stdin: not in gzip format现象tar -xzf 执行到一半报错说文件不是 gzip 格式。原因下载被中断或者浏览器把下载地址解析成了 HTML 错误页并保存下来。file 命令会显示这个文件其实是 ASCII text 或 HTML 文档根本不是 gzip 数据。解决不要盲目重新下载再试先跑 file、md5sum 校验确认体积在 130 MB 级别。下载时选支持断点续传的下载工具。解压前用 tar -tzf 预览列表能列出内容说明包结构完好这一步能省下后续所有排查。5.3 启动服务时找不到 java但手动执行 java -version 正常现象在终端手工测试 java 没问题systemd 服务或 crontab 里一执行就报 java: command not found。原因systemd 和 crontab 的环境不加载 /etc/profile也不读 ~/.bashrc它们的 PATH 是系统默认路径不包含 /usr/local/java/jdk8/bin。解决在 Unit 文件里显式写 EnvironmentPATH 和 EnvironmentJAVA_HOMEcrontab 脚本开头先 export 路径或脚本里直接用 /usr/local/java/jdk8/bin/java 绝对路径调用。这里绝对路径最省事也最不容易被环境差异影响。5.4 JAVA_HOME 指到了 jrejavac 和 jar 全部失踪现象java 能用javac、jar 报 command not found。原因JAVA_HOME 被设成了 .../jrePATH 自然变成了 .../jre/bin而 jre/bin 下只有一个 java工具命令都在 JDK 根目录的 bin 里。这类配置相当常见因为老教程时代 jdk 和 jre 是分开下载的两个目录各有 bin。解决把 JAVA_HOME 改回 /usr/local/java/jdk8确认根目录下有 bin、lib、jre 三个兄弟目录而不是只有 jre。配置后 echo $JAVA_HOME 复查同时验证 javac -version。这套组合检查一次性解决。5.5 8u45 连不上只开 TLS 1.3 的服务现象用 8u45 写的小程序访问某个 HTTPS 接口报 SSLHandshakeException但用浏览器或新版 JDK 能正常访问。原因8u45 的年代 TLS 1.3 还没有普及这个版本的安全协议栈最高只支持到 TLS 1.2。对端如果只开启 TLS 1.3版本匹配失败。解决一是对端兼容 TLS 1.2二是如果业务允许升级到 8 后期版本。这里要提醒8u45 作为老版本 JDK安全基线较低不是生产环境首选只适合复现老系统或临时验证。从安全角度考虑下载方要明确这个版本的使用边界别拿它做公网服务。6. 再多做一步把 JDK 8 基线验证脚本固化下来6.1 verify_jdk8.sh一个可复用的基线检查脚本JDK 装好后我习惯把验证过程固化成一个脚本新机器、新服务器都跑这一遍。脚本检查五件事架构、JAVA_HOME 是否配置、JAVA_HOME 目录是否存在、java 版本、javac 版本。#!/bin/bash # JDK 8 基线验证脚本验证架构、JAVA_HOME、java/javac 版本 e0 [ $(uname -m) x86_64 ] || { echo FAIL: 架构不是 x86_64; e1; } [ -n $JAVA_HOME ] || { echo FAIL: JAVA_HOME 未设置; e1; } [ -d $JAVA_HOME ] || { echo FAIL: JAVA_HOME 目录不存在; e1; } java -version 21 | grep -q 1.8.0_45 || { echo FAIL: java 版本不是 1.8.0_45; e1; } javac -version 21 | grep -q 1.8.0_45 || { echo FAIL: javac 版本不是 1.8.0_45; e1; } [ $e -eq 0 ] echo PASS: JDK 8 基线检查全部通过 exit $e逻辑说明脚本用一条计数器 e 汇总检查结果任何一项失败就置为 1最后统一退出。每个检查项输出 FAIL 时带上具体原因一眼定位问题。java 和 javac 的版本检查通过管道把输出交给 grep匹配到 1.8.0_45 才通过。参数说明grep -q 是静默匹配不输出匹配内容只返回退出码21 把版本输出合并到标准输出因为 java -version 打的是标准错误。如果检查的是其他 8u 版本把两处 1.8.0_45 改成对应版本号即可。脚本保存为 verify_jdk8.sh 后用 bash 执行记得先 source /etc/profile 让 JAVA_HOME 在当前 shell 生效。6.2 把基线变成习惯换版本、迁移环境时怎么改这套脚本的价值在于把版本、路径、工具链三个最容易翻车的点用一条命令跑完。每次部署新环境后执行一次脚本输出全部 PASS 才进行下一步。如果某个检查项 FAIL按上面避坑清单逐项排查。迁移环境时脚本里的版本号改成目标版本JAVA_HOME 指向新软链其余逻辑不用动。多台机器同时升级时脚本还能当巡检工具批量跑输出里哪个 FAIL 一目了然。从那以后我在任何机器上装完 JDK 8都会强制走一遍这个脚本确认版本、架构、路径三个基线再交付避免“手动 java -version 正常但构建工具用不了”这类尴尬场景。希望这份 8u45 的拆解和脚本能帮到你至少下载之后别在环境变量和路径上再花冤枉时间。本文还有配套的精品资源点击获取