简介面向 Linux x64 平台的 JDK 24 官方二进制构建包专为需要在 64 位 Linux 系统中搭建 Java 开发或运行环境的开发者、运维人员及进阶学习者准备适合离线安装、内网隔离和自动化部署等场景省去源码编译和依赖下载环节。全包共 405 个文件压缩后约 231.9MB内部模块规划清晰jmod 模块文件与 so 动态链接库负责模块化运行时和底层调用license、copyright 明确使用条款md 文档和 35 个 man 帮助页可辅助查阅 java、javac、jshell、keytool 等命令。开发工具链覆盖完整javac、java、javadoc、jlink、jpackage 支撑日常编译、运行、文档生成与打包jcmd、jstack、jmap、jfr 等命令则用于性能诊断、线程分析和故障排查配合 security 安全策略、properties 配置和 policy 权限文件可快速调整运行环境。两个 jar 文件与 template/dat 等支持文件进一步补全了容器化或桌面场景的常用配置。目前已有 116 人学习/下载适合想在本地体验 JDK 24 新特性、构建定制运行镜像或建立离线 Java 知识库的用户。1. 拿到jdk-24_linux-x64_bin.tar.gz先别急着解压看到这个文件名说明你正在给一台 Linux x64 服务器手动安装 JDK 24。相比双击安装包tar.gz 是 Oracle 官方提供的绿色压缩包不依赖系统的包管理器解压即用更适合生产环境里对目录结构有洁癖的人。这个文件同时牵出三个高频问题JDK 24 到底能不能直接替代手上的 17 或 21tar.gz 和 rpm、deb 装出来的有什么区别装完之后java -version为什么还显示老版本这篇文章会把这些点一次讲透按一条可复现的路径走完下载、校验、解压、配环境变量、多版本切换最后附上我踩过的几个坑。适合刚接手 Linux 服务器、被各种 Java 环境问题折腾过的开发者和运维也适合只是想把手动安装流程固化下来的老手。2. 下载与校验从官网拿到可信的jdk-24_linux-x64_bin.tar.gz2.1 先读文件名on-linux-x64 到底匹配不匹配文件名拆开看是四段jdk-24是版本号linux代表操作系统x64是 CPU 架构bin表示二进制发行版tar.gz是压缩方式。很多人在这一步就翻车——拿 x64 的包往 ARM 服务器上装解压能成功但java -version直接报Exec format error。确认架构用一条命令uname -m输出x86_64就匹配 x64 素材输出aarch64说明这台机器是 ARM需要去官网找linux-aarch64的包。另外要注意文件名里的linux不分 glibc 还是 musl但如果你用的是 Alpine 这类 musl 发行版Oracle 官方 JDK 通常不直接支持常见做法是改用 OpenJDK 的 alpine 构建或者换 Debian/Ubuntu/CentOS 这类 glibc 系系统。为什么推荐 tar.gz 而不是 rpm 或 debrpm 和 deb 会往系统目录里散落文件卸载时依赖包管理器的记录一旦你同时装了多个 JDKrpm -qa | grep jdk会列出一串切版本要靠alternatives。而 tar.gz 解压到自建目录后整个 JDK 就是一个目录想换版本就改环境变量想删就rm -rf没有任何残留。对多环境隔离来说这是最可控的安装方式。2.2 用 wget 拉取安装包并用 sha256sum 校验完整性去 Java 官网的下载页选 Linux x64 分卷下载按钮给的就是jdk-24_linux-x64_bin.tar.gz。先不要急着点把文件下载到服务器上用命令行拉mkdir -p /opt/java cd /opt/java wget --no-check-certificate https://download.oracle.com/java/24/latest/jdk-24_linux-x64_bin.tar.gz这里的 URL 是 Oracle 长期维护的 latest 路径每次点开官网下载页看到的实际下载地址就是这一类。如果你在浏览器里下载再传到服务器也建议先放到同一个固定目录避免后面找不到文件。校验是很多人跳过的关键步骤。JDK 是基础运行环境一旦被篡改后续所有 Java 程序都可能被植入恶意逻辑。从官网页面复制对应的 SHA256 校验值然后执行sha256sum jdk-24_linux-x64_bin.tar.gz把输出和官网给出的值做比对。如果一致会输出一行完整的哈希不一致时会有类似FAILED的提示。注意别只比对前几位要整串一致才算通过。这个步骤能过滤掉下载被劫持、镜像源污染、文件下载不全三类问题我每次装 JDK 都会做成本不到十秒没必要省。3. 解压安装到指定目录路径规划与权限配置3.1 解压命令与目录约定为什么我推荐放到 /opt/java把校验通过的压缩包解压过程没有任何交互tar -xzf jdk-24_linux-x64_bin.tar.gz -C /opt/java参数说明-x表示解压-z表示通过 gzip 解压-f指定文件名-C指定解压目标目录。解压完成后/opt/java下会多出一个jdk-24目录这就是完整的 JDK 根目录。目录规划上我一般不会直接解压到/usr/local而是使用/opt/java作为统一父目录。/opt本来就是给第三方软件预留的位置语义清晰。将来你装第二个、第三个 JDK 时所有包都平铺在/opt/java下通过环境变量切换查看时一目了然ls -l /opt/java执行后你会看到类似jdk-24的目录名。如果解压出来是jdk-24.0.x这种带小版本号的目录建议你把它重命名成不带小版本的形式或者建立一个软链接比如ln -s jdk-24.0.1 jdk-24。原因是后续环境变量里写死路径时小版本号升级后你不需要改配置只更新软链接就行。3.2 配置 JAVA_HOME 与 PATH三种方式与适用场景解压完并不代表装完系统默认还找不到java命令。你需要把 JDK 的bin目录加进 PATH同时把 JAVA_HOME 指到 JDK 根目录。这里有三种配置方式场景不同选择也不同。第一种是临时生效适合只在这个 shell 里用一下重启就失效export JAVA_HOME/opt/java/jdk-24 export PATH$JAVA_HOME/bin:$PATH第二种是写进当前用户的~/.bashrc每次打开终端自动生效适合个人开发机echo export JAVA_HOME/opt/java/jdk-24 ~/.bashrc echo export PATH$JAVA_HOME/bin:$PATH ~/.bashrc source ~/.bashrc第三种是写进/etc/profile.d/java.sh对所有用户生效适合服务器统一配置cat /etc/profile.d/java.sh EOF export JAVA_HOME/opt/java/jdk-24 export PATH$JAVA_HOME/bin:$PATH EOF chmod x /etc/profile.d/java.sh source /etc/profile.d/java.sh第三种方式在生产环境更推荐因为它不侵入个人用户配置也不依赖某个用户是否登录。脚本文件名java.sh会在系统登录时被/etc/profile自动 source。注意我用的是EOF而不是EOF加单引号是为了防止 shell 展开$JAVA_HOME确保变量名字面写入脚本。关于 CLASSPATH现代 Java 基本不需要手动设置。JDK 9 引入模块化后类路径自动从-classpath命令行参数和当前目录推导全局设置 CLASSPATH 反而会干扰某些框架的类加载。我见过不少老教程让用户设CLASSPATH.:$JAVA_HOME/lib这在新版本里已经不是必要配置不设也不影响javac和java的正常使用。配置完成后需要确认环境变量是否真的读到了正确位置echo $JAVA_HOME which javawhich java应该输出/opt/java/jdk-24/bin/java。如果还是/usr/bin/java说明系统里有其他 JDK 优先级更高这涉及alternatives或 PATH 顺序问题放在第 4 章专门处理。4. 验证与多版本切换让java -version听你的4.1 最小验证命令确认编译器和运行时都可用环境变量配完最直接的验证就是版本命令java -version javac -version第一次执行时你可能会看到java -version显示 17而javac -version显示 24。原因很简单which java和which javac指向了两个不同目录。这种情况常见于系统预装了 OpenJDK 17并且/usr/bin/java排在 PATH 前面。确认到底是哪个目录在生效用ls -l $(which java) ls -l $(which javac)看这两个命令的软链接指向。如果/usr/bin/java依然指向系统自带的旧 JDK而我们的 JDK 24 在/opt/java/jdk-24/bin说明默认 PATH 里/usr/bin排在/opt/java/jdk-24/bin前面。解决办法是把我们的路径插入到 PATH 最前而不是追加在末尾。export PATH/opt/java/jdk-24/bin:$PATH注意这里把 JDK 的 bin 放在冒号前面让 shell 优先找到它。如果修改后which java变了但新开的终端又变回去请检查/etc/profile.d/java.sh是否真的生效以及该脚本是否在/usr/bin之前导出 PATH。4.2 用 update-alternatives 管理多版本 JDK服务器上装了多个 JDK 是常态比如业务要跑 JDK 8 的老程序你又要用 JDK 24 编译新代码。这种场景下直接改 PATH 显然不够灵活。常见做法是利用系统自带的update-alternatives机制统一管理。先把 JDK 24 注册为系统运行时之一update-alternatives --install /usr/bin/java java /opt/java/jdk-24/bin/java 2024 update-alternatives --install /usr/bin/javac javac /opt/java/jdk-24/bin/javac 2024后面的2024是优先级数字越大越优先。注册完成后用交互菜单切换update-alternatives --config java update-alternatives --config javac执行后屏幕上会列出所有已注册的 JDK 路径输入编号回车即可切换。切换后java -version立即生效不用改环境变量也不用考虑 PATH 顺序。这套方案的好处是/usr/bin/java会变成一个指向/etc/alternatives/java的软链接后者再指向当前选中的 JDK。系统层面的命令访问始终走同一入口对所有用户一致。代价是你需要用同样的--install语法注册每个 JDK 的java和javac如果你还要用jar、jlink等工具也建议一并注册。4.3 切换或降级到 JDK 17一条命令把默认版本改回去很多项目还在 JDK 17LTS上装了 24 之后又怕影响旧应用。最常见需求是系统默认仍用 17只在编译新工程时用 24。这时不需要卸载 24只需要调整优先级。如果你把 JDK 17 的优先级设得比 24 高它就会成为默认update-alternatives --install /usr/bin/java java /usr/lib/jvm/jdk-17/bin/java 2025 update-alternatives --install /usr/bin/javac javac /usr/lib/jvm/jdk-17/bin/javac 2025这里假设你的 JDK 17 安装在/usr/lib/jvm/jdk-17实际路径要用update-alternatives --list java查看。设置完成后不想交互确认的话可以非交互指定update-alternatives --set java /usr/lib/jvm/jdk-17/bin/java update-alternatives --set javac /usr/lib/jvm/jdk-17/bin/javac--set直接指定路径无需等待交互。这个方式比手动改环境变量更稳健因为它是系统层面的链接切换不依赖某个用户的.bashrc。5. 避坑JDK 24 在 Linux x64 上安装的 5 个高频问题5.1 解压时报 gzip: stdin: not in gzip format现象执行tar -xzf jdk-24_linux-x64_bin.tar.gz后终端报错gzip: stdin: not in gzip format随后解出乱码或失败。原因下载的文件不是 tar.gz最常见是文件被重定向到了 HTML 页面。如果你用wget时没加--content-disposition有些镜像站点会把下载请求跳转到登录页保存下来的其实是 HTML。解决先看文件类型file jdk-24_linux-x64_bin.tar.gz它会显示实际格式。如果是 HTML 文本删掉重新下载并优先使用官网下载地址下载完成后立刻做 sha256 校验能一次性过滤这个问题。5.2java找到了javac却找不到现象java -version正常显示 24但执行javac -version提示command not found。原因java是 JRE 入口javac是 JDK 编译器入口。正常情况下两者都在bin目录里。出现这个现象多半是 PATH 配置只加了java的快捷方式或者alternatives只注册了java没注册javac。解决检查ls /opt/java/jdk-24/bin/javac是否存在。如果文件存在检查 PATH 里有没有把 24 的bin加进去如果用的是update-alternatives把javac也按同样参数注册一遍。5.3 环境变量配好了新开的终端里java -version还是旧版本现象source /etc/profile.d/java.sh后当前 shell 正常但新开的连接窗口又回到旧 JDK。原因/etc/profile.d/下的脚本只对登录 shell 生效。某些终端模拟器或自动化工具启动的是非登录非交互 shell不会读取/etc/profile或者读取顺序在/etc/profile.d之前。解决确认你的 shell 类型和启动模式。对绝大多数 SSH 登录来说/etc/profile.d/java.sh应该有效如果无效把它同时写进/etc/bash.bashrc或每个用户的.bashrc。更稳妥的做法是使用update-alternatives它不需要任何 shell 启动脚本直接从/usr/bin/java层面控制。5.4 启动 Java 程序报 libfreetype.so.6: cannot open shared object file现象运行图形相关或依赖 AWT/Swing 的程序时JVM 抛出libfreetype.so.6 ... cannot open shared object file而纯命令行程序正常。原因JDK 24 的 AWT 库在运行时需要系统字体渲染库但最小化安装的 Linux 服务器通常没装这些图形库。解决安装依赖后重启程序apt install -y libfreetype6 libfontconfig1 # Debian/Ubuntu yum install -y freetype fontconfig # CentOS/RHEL不过说实话服务器上跑无头 Java 应用一般用-Djava.awt.headlesstrue规避图形库需求不一定需要装这些包。5.5 从 24 降级到 17 后Maven 或 Gradle 仍然显示 24现象执行java -version显示 17但mvn -v或gradle -version里的 Java 版本还是 24。原因Maven 和 Gradle 通常读取JAVA_HOME环境变量而不是系统默认java命令。你切换了alternatives但JAVA_HOME还指向 24 的路径。解决确认两者指向一致mvn -version echo $JAVA_HOME如果JAVA_HOME还是/opt/java/jdk-24就把它改到 17 的根目录。这里我建议你的构建工具环境变量单独写在/etc/profile.d/maven.sh里不要与全局JAVA_HOME混用否则业务开发和构建工具之间容易产生这种“一个版本、两个入口”的混乱。6. 把安装过程固化成脚本一条命令装完并切换默认版本如果你觉得上面的步骤繁琐可以把它写成一个幂等脚本放到服务器上随时复用。核心思路是脚本负责下载、校验、解压然后通过update-alternatives指定默认版本不依赖任何交互。#!/bin/bash set -e JDK_DIR/opt/java JDK_VERSIONjdk-24 DOWNLOAD_URLhttps://download.oracle.com/java/24/latest/jdk-24_linux-x64_bin.tar.gz ARCHIVE/tmp/${JDK_VERSION}_linux-x64_bin.tar.gz EXPECTED_SHA256粘贴官网实际SHA256值 mkdir -p $JDK_DIR wget -O $ARCHIVE $DOWNLOAD_URL echo $EXPECTED_SHA256 $ARCHIVE | sha256sum -c - || exit 1 tar -xzf $ARCHIVE -C $JDK_DIR update-alternatives --install /usr/bin/java java $JDK_DIR/$JDK_VERSION/bin/java 2100 update-alternatives --install /usr/bin/javac javac $JDK_DIR/$JDK_VERSION/bin/javac 2100 update-alternatives --set java $JDK_DIR/$JDK_VERSION/bin/java update-alternatives --set javac $JDK_DIR/$JDK_VERSION/bin/javac脚本里set -e的作用是任何一条命令失败就立即退出避免后续步骤在残缺环境下继续执行。sha256sum -c -从标准输入读入格式为“哈希值 文件名”的校验文本比对通过才继续。最后四行把 JDK 24 注册到 system alternatives并直接设为默认无需手动选择。这条脚本每次跑完都会保证系统默认 JDK 是 24。如果你想让 JDK 17 重新成为默认只要在脚本最后追加两条--set命令指向 17 的路径即可这比反复改/etc/profile.d要直观得多。我自己的习惯是在/opt/java下保留所有历史 JDK用软链接current指向当前默认版本ln -s /opt/java/jdk-24 /opt/java/current export JAVA_HOME/opt/java/current这样升级时只需要把current重新指向新目录所有依赖JAVA_HOME的工具自动跟随环境变量里的路径永远不变。这套做法帮我省掉了无数次改配置和切版本的操作也推荐你试试。希望帮到你。本文还有配套的精品资源点击获取
