简介面向需要在 Linux 64 位环境中部署 Java 11 运行时的开发者与运维人员这份 OpenJDK 11.0.24 的 Microsoft Build 发行包是一个理想的免费选择。其基于开放源码构建提供长期支持可直接用于服务器或桌面环境的 Java 应用开发、部署与调试也可作为离线安装介质使用。压缩包共含509个文件整体约188.13MB核心可执行程序包括 java、javac、javadoc、jmod、jar、jshell 等同时附带大量 .1 手册页、.so 动态库、policy 与 security 安全配置文件、cacerts 证书库等便于开发者查阅命令用法、理解运行时组成或排查配置问题。这一发布包目前已有366人学习下载。解压后即可获得完整规范的 JDK 目录结构涵盖 bin、lib、conf、legal、include 等模块适合需要快速配置 JDK 11 环境、搭建本地开发或生产运行环境的中高级用户直接使用省去自行编译与收集依赖的麻烦。1. 认识 OpenJDK 11.0.24这次部署到底在装什么先说结论Linux 64 位 OpenJDK 11.0.24就是 Java 11 长期支持版LTS在 Linux x86_64 架构下的开源实现具体版本号是 11.0.24。这个版本在 2024 年 7 月发布属于 Oracle 公开的 OpenJDK 11 代码库的常规安全更新主要修复了之前版本里发现的漏洞和稳定性问题同时没有引入新的语言特性。很多朋友一看到 OpenJDK 和 Oracle JDK 就头疼其实从 Java 11 开始Oracle 调整了授权模式Oracle JDK 变成商业订阅制而 OpenJDK 继续保持开源免费。官方明确表示两者的代码库几乎一致Java 11 之后 Oracle JDK 和 OpenJDK 在功能上基本没有区别区别主要在于长期支持周期、更新频率和商业服务。所以现在生产环境里跑 OpenJDK 11 已经是绝对主流。这篇文章适合谁看如果你是刚接手一台 Linux 服务器、需要部署 Java 应用但还没弄清楚 JDK 怎么装或者你正在从 Java 8 往 Java 11 迁移、想搞清楚新版 JDK 和旧版的差异再或者你只是想在自己的云服务器上搭个干净的 Java 运行环境——这篇内容都能让你少走弯路。我不会只丢给你几条命令而是把每一步背后的逻辑讲明白包括版本选型、目录规划、环境变量、多版本共存以及我在生产环境里踩过的那些坑。2. 为什么偏偏选 OpenJDK 11而不是 8 或者 172.1 版本选型背后的真实考量在我自己的实践里版本选择这件事看似简单实际上决定了后面两三年的运维节奏。现在公开的 OpenJDK 版本很多从 8 到 25 都有但生产环境真正值得认真考虑的其实就三个 LTS 版本8、11、17。先说 Java 8。它太经典了以至于很多老项目到现在还跑在 Java 8 上。但问题是Oracle 对 Java 8 的免费公共更新很早就停了虽然 Amazon Corretto、AdoptiumEclipse Temurin这些发行版还在维护但 Java 8 的生态整体已经过了巅峰期。如果你的项目是从零开始我不推荐再选 8。Java 17 是目前最新的 LTS性能优化明显比如 JIT 编译器升级到了 C2 GraalVM 的过渡阶段垃圾回收器也有更多选择。但 17 的普及度在存量系统里还不够高很多企业中间件、老框架还停留在兼容 Java 11 的阶段。Java 11 则处在最微妙的平衡点既有 Java 9 引入的模块化系统JPMS改进也有新的 API 和性能提升同时向下兼容大部分 Java 8 项目向上对 17 的迁移路径也比较平滑。引用一个常见的说法Java 11 是 Java 8 之后最值得选的过渡 稳定版本它补齐了 Java 9/10 埋下的坑又不像 17 那样变动剧烈。所以当我看到你这个项目标题直接指定了 11.0.24我会认为这是一个成熟、稳健的选型不激进也不落后。2.2 OpenJDK 各发行版怎么选OpenJDK 是一个开源项目但实际可下载的发行版有很多。标题里只说 OpenJDK 11.0.24没有指定厂商这其实会带来一个常见困惑到底该去官网下载还是用系统包管理器安装还是用 Amazon Corretto / Eclipse Temurin / Liberica JDK我的建议是这样的发行版维护方特点适用场景Oracle OpenJDKOracle官方开源版生命周期较短开发测试、快速验证Eclipse Temurin (Adoptium)Eclipse 基金会社区驱动免费 LTS 支持好生产环境推荐Amazon CorrettoAmazon免费长期支持内部大量使用AWS 环境、企业生产Liberica JDKBellSoft带 JavaFX 版本桌面应用系统自带的 openjdk发行版维护方安装简单但版本可能滞后非生产、快速安装如果你要问我个人经验在 CentOS / Ubuntu 服务器上跑生产应用我最推荐的是 Eclipse Temurin 或者 Amazon Corretto因为它们都有明确的免费长期支持承诺。但如果你只是需要一个标准的测试环境直接用 apt 或 yum 安装系统自带的 openjdk-11-jdk 也没问题。不过有一点我必须提醒你不同发行版的版本号编排可能略有差异。比如 Ubuntu 的openjdk-11-jdk包实际对应的可能是 11.0.238 这类小版本不一定正好是 11.0.24。如果你的应用对具体的小版本号有严格依赖那最好下载官方发布的二进制包手动安装而不是依赖系统仓库。3. 安装前必须明确的几个关键点3.1 确认系统架构和现有环境动手安装之前先确认目标机器的环境和现状。我见过太多人上来就复制粘贴安装命令结果装完发现架构不对、权限不够、或者和已有的 JDK 冲突。第一件事是确认架构。Linux 64 位通常指的是 x86_64、amd64 这种架构但现在 ARM 架构的服务器也越来越多了比如 AWS Graviton、华为鲲鹏。如果架构不匹配你下载的 rpm 或 tar.gz 包根本跑不起来。用uname -m看一下输出如果是x86_64或amd64就是通用的 64 位 x86 架构如果是aarch64那就得选 ARM64 版本。第二件事是查看是否已经装了 Java。用java -version和which java检查。如果系统里已经有一个旧版本的 JDK比如 Java 8你需要决定是共存还是替换。我强烈建议不要直接卸载旧 JDK因为很多系统工具比如某些版本的 Gradle、Tomcat 管理脚本可能依赖特定版本直接卸载容易引发连锁问题。更好的方式是让新 JDK 共存通过环境变量和alternatives机制管理默认版本。第三件事是确认当前用户权限。安装 JDK 到系统目录比如/usr/local/java需要 root 权限。如果你只有普通用户权限建议装到用户目录下比如~/jdk这样完全不依赖系统目录权限也不会影响其他用户。3.2 JDK 和 JRE 的认知误区Java 11 之后有一个很多人没意识到的变化不再提供独立的 JRE 下载包。以前 Java 8 时代你可以只装一个 JRE 来跑 Java 程序体积小够用。但从 Java 9 开始官方调整了发布结构JDK 本身就包含了完整的运行环境单独的 JRE 包被取消了。这就导致很多新手在找Linux 64 位 JRE 11的时候发现官方根本不下发这种包了于是误以为 Java 11 不能精简安装。实际上你可以用 JDK 自带的jlink工具来自定义生成一个精简运行时镜像把不需要的模块裁掉。一些有经验的人会在 Docket 镜像里用jlink做小体积运行环境比如只保留java.base、java.sql等核心模块最终运行时体积可以从 300MB 压缩到 50MB 左右。所以在你安装 JDK 的时候不要纠结我只想装个运行环境JDK 太大了这个问题。直接装 JDK 是最稳妥的方案开发、编译、运行都够用。如果你后续觉得体积是个问题再考虑 jlink 裁剪而不是一开始就去搜什么精简版 JRE。4. 实测安装过程从下载到环境变量配置4.1 官方二进制包的手动安装方案我先讲一个最通用、最可控的方案直接下载官方编译好的 tar.gz 包手动安装。这个方案不依赖系统包管理器无论你是 CentOS、Ubuntu、Debian 还是其他发行版操作流程基本一致。第一步去 OpenJDK 官方构建站或镜像站下载OpenJDK 11.0.24的 Linux x86_64 tar.gz 包。我通常从 Adoptium 的 API 或者清华镜像站下载速度稳定。假设你下载的文件名是OpenJDK11U-jdk_x64_linux_hotspot_11.0.24_8.tar.gz注意看一下文件名里的架构标识。第二步解压到统一管理目录。我个人习惯把所有 JDK 都放在/usr/local/java/下这样只需要维护/etc/profile或/etc/environment里的一个路径sudo mkdir -p /usr/local/java sudo tar -zxvf OpenJDK11U-jdk_x64_linux_hotspot_11.0.24_8.tar.gz -C /usr/local/java/ cd /usr/local/java/ # 解压后会有一个 jdk-11.0.248 目录建议做一个软链 sudo ln -s jdk-11.0.248 latest软链这一步是个小技巧。如果你以后升级到 11.0.25只需要重新解压新包然后把latest指过去/etc/profile里的路径完全不用改动。这个习惯让我在升级 JDK 小版本时省了很多事。第三步配置环境变量。编辑/etc/profile文件在末尾追加以下内容export JAVA_HOME/usr/local/java/latest export PATH$JAVA_HOME/bin:$PATH export CLASSPATH.:$JAVA_HOME/lib/dt.jar:$JAVA_HOME/lib/tools.jar等一下这里我要特别提醒CLASSPATH那段配置是 Java 8 时代的写法。Java 9 之后引入了模块化系统JDK 内部的 lib 目录结构发生了巨大变化很多.jar文件被移到了jmods目录里而且dt.jar、tools.jar在 Java 11 里已经不是常规路径了。如果你完全照搬 Java 8 教程里的 CLASSPATH启动时反而可能产生 ClassNotFound 异常。实际上Java 9 大多数情况下根本不需要手动设置 CLASSPATH编译器javac和运行时java默认就能处理类路径。所以更干净的写法是export JAVA_HOME/usr/local/java/latest export PATH$JAVA_HOME/bin:$PATH第四步让环境变量立即生效source /etc/profile java -version看到输出里有openjdk version 11.0.24和OpenJDK 64-Bit Server VM就说明装好了。4.2 系统包管理器安装方案快速但受限如果你的服务器不想折腾手动解压也可以用系统包管理器安装。以 Ubuntu/Debian 为例sudo apt update sudo apt install openjdk-11-jdk -yCentOS/RHEL 7/8 上则是sudo yum install java-11-openjdk-devel -y这个方案的优点是省心系统会自动处理好路径、权限和依赖缺点是版本不可控。Ubuntu 的仓库里可能滞后一两个小版本而且安装路径分散在/usr/lib/jvm/java-11-openjdk-amd64这种地方路径规则不统一。如果你是在开发机或者个人服务器上快速搭个环境这个方案足够但如果你是要统一管理多台生产服务器我建议你还是用第一种手动方案确保所有机器版本完全一致。4.3 配置 alternatives让系统命令指向正确的 Java在 Linux 上安装多个 JDK 后系统全局的java命令默认不会自动指向新装的版本。Ubuntu 里可以用update-alternatives来配置sudo update-alternatives --install /usr/bin/java java /usr/local/java/latest/bin/java 1 sudo update-alternatives --install /usr/bin/javac javac /usr/local/java/latest/bin/javac 1 sudo update-alternatives --config java执行--config之后系统会列出当前所有已注册的 Java 路径让你选择默认项。我建议把新装的 11.0.24 设为手动选择并保证其优先级最高。这个机制就像 Windows 里的默认程序设置你装了多个浏览器需要指定哪个是默认的。这里有个细节容易踩坑update-alternatives配置的是/usr/bin/java这个软链的指向但很多应用启动脚本会直接读JAVA_HOME环境变量而不会去解析/usr/bin/java。所以你在配置完 alternatives 之后依然要确认JAVA_HOME指向正确。两套机制是互补关系不是替代关系。5. 验证、优化与常见问题排查5.1 安装完成后的完整性验证装完环境变量配置好不要急着跑应用先做一轮验证。除了java -version我还会执行这三个命令# 验证编译器是否可用 javac -version # 验证 JVM 实际加载的运行时信息 java -XshowSettings:properties -version 21 | grep -E java.home|java.version|os.arch # 验证关键模块是否完整 java --list-modules | grep -E java.sql|java.management|jdk.management我自己在部署后一般还会写一个最基础的 Java 类测试编译和运行链路cat /tmp/Test.java EOF public class Test { public static void main(String[] args) { System.out.println(Java home: System.getProperty(java.home)); System.out.println(Version: System.getProperty(java.version)); } } EOF cd /tmp javac Test.java java Test这一步可以快速发现环境变量是否完全生效以及 JAVA_HOME 路径是否正确。5.2 性能调优与 JVM 参数参考OpenJDK 11.0.24 在默认配置下已经能良好运行大多数应用但如果你要在生产环境部署 Spring Boot、Tomcat 或大数据组件JVM 参数还是值得针对机器配置做一轮调优。我的基础模板是这样的java -Xms2g -Xmx2g \ -XX:UseG1GC \ -XX:MaxGCPauseMillis200 \ -XX:HeapDumpOnOutOfMemoryError \ -XX:HeapDumpPath/data/logs/java_heap.hprof \ -XX:PrintGCDetails \ -XX:PrintGCDateStamps \ -Xloggc:/data/logs/gc.log \ -jar yourapp.jar解释一下几个关键参数-Xms和-Xmx分别指定 JVM 初始堆大小和最大堆大小。我建议两者设为相同的值这样 JVM 启动时直接申请好全部堆内存运行过程中不需要动态扩容GC 行为更容易预测。设置多少要根据服务器物理内存来比如 8GB 内存的机器留 2GB 给系统和其他进程JVM 堆可以给到 4GB。-XX:UseG1GC指定 G1 垃圾回收器。Java 11 里 G1 已经是默认收集器但显式声明参数可以让运维排查问题时更明确。HeapDumpOnOutOfMemoryError这个参数尤其重要。生产环境一旦发生 OOM没有 heap dump 就只能瞎猜内存泄漏点有了 dump 文件可以直接用 MAT 分析。这个习惯让我排查线上问题的时间从半天缩短到半小时。Java 11 还引入了一个重要特性ZGC可扩展低延迟垃圾回收器但它默认是实验性的虽然 11.0.24 版本已经成熟许多我依然建议生产环境保守使用 G1因为 ZGC 对内存换 CPU 的消耗比较大在低配机器上反而可能拖慢吞吐。5.3 常见问题速查表我在多年部署经验里把最新一次部署遇到的相关情况整理成一张速查表以后复制排查步骤就能快速定位问题问题现象可能原因解决方案java: command not foundPATH 未配置或未 source检查/etc/profile确认 exported PATH执行source /etc/profileError: could not open .../lib/amd64/server/libjvm.soJDK 目录被移动或软链失效检查 JAVA_HOME 是否指向正确的实际路径重建软链javac -version正常但java -version报错系统里存在多个 JDKjava命令指向了旧版用which java查看实际路径用 update-alternatives 调整程序启动非常慢CPU 占用不正常JVM 在解析大量 jar 包或者 DNS 反查添加-Djava.net.preferIPv4Stacktrue检查/etc/resolv.conf配置Unable to locate an executable at /usr/bin/java/bin/java (-1)JAVA_HOME 设置重复叠加了路径检查是否在 PATH 里重复写入了$JAVA_HOME/bin和多层bin/binDocker 容器里 java 无法启动提示内存不足容器内存限制和 JVM 检测不匹配使用-XX:UseContainerSupportJava 11 默认开启或者显式设置-Xmx5.4 多版本 JDK 共存的实践心得最后的经验补充也是我在实际运维中体会最深的一点永远不要在生产服务器上只装一个 JDK 版本除非你有 100% 的把握未来不会迁移。我的做法是在/usr/local/java/下同时保留多个版本目录比如/usr/local/java/jdk-11.0.248/ /usr/local/java/jdk-17.0.127/ /usr/local/java/latest - jdk-11.0.248/然后每一个应用使用独立的启动脚本脚本里显式指定它要用的 JDK 路径#!/bin/bash export JAVA_HOME/usr/local/java/jdk-17.0.127 export PATH$JAVA_HOME/bin:$PATH nohup java -jar /data/app/your-app.jar /data/logs/your-app.log 21 这样每个应用都被钉死在确定的 JDK 版本上系统默认的java命令变了也不会影响线上应用。这个思路类似于 Docker 镜像里把特定版本打包进一层保证环境一致性和可复现性。如果你是用 Systemd 管理 Java 应用也可以在 service 文件里的Environment字段单独指定 JAVA_HOME效果一样。记住一个原则系统全局的 java 是给运维用的应用自己的 java 是给应用用的二者尽量不要混为一谈。本文还有配套的精品资源点击获取 Linux 64位 OpenJDK 11.0.24 部署实战：从版本选型到环境配置
简介面向需要在 Linux 64 位环境中部署 Java 11 运行时的开发者与运维人员这份 OpenJDK 11.0.24 的 Microsoft Build 发行包是一个理想的免费选择。其基于开放源码构建提供长期支持可直接用于服务器或桌面环境的 Java 应用开发、部署与调试也可作为离线安装介质使用。压缩包共含509个文件整体约188.13MB核心可执行程序包括 java、javac、javadoc、jmod、jar、jshell 等同时附带大量 .1 手册页、.so 动态库、policy 与 security 安全配置文件、cacerts 证书库等便于开发者查阅命令用法、理解运行时组成或排查配置问题。这一发布包目前已有366人学习下载。解压后即可获得完整规范的 JDK 目录结构涵盖 bin、lib、conf、legal、include 等模块适合需要快速配置 JDK 11 环境、搭建本地开发或生产运行环境的中高级用户直接使用省去自行编译与收集依赖的麻烦。1. 认识 OpenJDK 11.0.24这次部署到底在装什么先说结论Linux 64 位 OpenJDK 11.0.24就是 Java 11 长期支持版LTS在 Linux x86_64 架构下的开源实现具体版本号是 11.0.24。这个版本在 2024 年 7 月发布属于 Oracle 公开的 OpenJDK 11 代码库的常规安全更新主要修复了之前版本里发现的漏洞和稳定性问题同时没有引入新的语言特性。很多朋友一看到 OpenJDK 和 Oracle JDK 就头疼其实从 Java 11 开始Oracle 调整了授权模式Oracle JDK 变成商业订阅制而 OpenJDK 继续保持开源免费。官方明确表示两者的代码库几乎一致Java 11 之后 Oracle JDK 和 OpenJDK 在功能上基本没有区别区别主要在于长期支持周期、更新频率和商业服务。所以现在生产环境里跑 OpenJDK 11 已经是绝对主流。这篇文章适合谁看如果你是刚接手一台 Linux 服务器、需要部署 Java 应用但还没弄清楚 JDK 怎么装或者你正在从 Java 8 往 Java 11 迁移、想搞清楚新版 JDK 和旧版的差异再或者你只是想在自己的云服务器上搭个干净的 Java 运行环境——这篇内容都能让你少走弯路。我不会只丢给你几条命令而是把每一步背后的逻辑讲明白包括版本选型、目录规划、环境变量、多版本共存以及我在生产环境里踩过的那些坑。2. 为什么偏偏选 OpenJDK 11而不是 8 或者 172.1 版本选型背后的真实考量在我自己的实践里版本选择这件事看似简单实际上决定了后面两三年的运维节奏。现在公开的 OpenJDK 版本很多从 8 到 25 都有但生产环境真正值得认真考虑的其实就三个 LTS 版本8、11、17。先说 Java 8。它太经典了以至于很多老项目到现在还跑在 Java 8 上。但问题是Oracle 对 Java 8 的免费公共更新很早就停了虽然 Amazon Corretto、AdoptiumEclipse Temurin这些发行版还在维护但 Java 8 的生态整体已经过了巅峰期。如果你的项目是从零开始我不推荐再选 8。Java 17 是目前最新的 LTS性能优化明显比如 JIT 编译器升级到了 C2 GraalVM 的过渡阶段垃圾回收器也有更多选择。但 17 的普及度在存量系统里还不够高很多企业中间件、老框架还停留在兼容 Java 11 的阶段。Java 11 则处在最微妙的平衡点既有 Java 9 引入的模块化系统JPMS改进也有新的 API 和性能提升同时向下兼容大部分 Java 8 项目向上对 17 的迁移路径也比较平滑。引用一个常见的说法Java 11 是 Java 8 之后最值得选的过渡 稳定版本它补齐了 Java 9/10 埋下的坑又不像 17 那样变动剧烈。所以当我看到你这个项目标题直接指定了 11.0.24我会认为这是一个成熟、稳健的选型不激进也不落后。2.2 OpenJDK 各发行版怎么选OpenJDK 是一个开源项目但实际可下载的发行版有很多。标题里只说 OpenJDK 11.0.24没有指定厂商这其实会带来一个常见困惑到底该去官网下载还是用系统包管理器安装还是用 Amazon Corretto / Eclipse Temurin / Liberica JDK我的建议是这样的发行版维护方特点适用场景Oracle OpenJDKOracle官方开源版生命周期较短开发测试、快速验证Eclipse Temurin (Adoptium)Eclipse 基金会社区驱动免费 LTS 支持好生产环境推荐Amazon CorrettoAmazon免费长期支持内部大量使用AWS 环境、企业生产Liberica JDKBellSoft带 JavaFX 版本桌面应用系统自带的 openjdk发行版维护方安装简单但版本可能滞后非生产、快速安装如果你要问我个人经验在 CentOS / Ubuntu 服务器上跑生产应用我最推荐的是 Eclipse Temurin 或者 Amazon Corretto因为它们都有明确的免费长期支持承诺。但如果你只是需要一个标准的测试环境直接用 apt 或 yum 安装系统自带的 openjdk-11-jdk 也没问题。不过有一点我必须提醒你不同发行版的版本号编排可能略有差异。比如 Ubuntu 的openjdk-11-jdk包实际对应的可能是 11.0.238 这类小版本不一定正好是 11.0.24。如果你的应用对具体的小版本号有严格依赖那最好下载官方发布的二进制包手动安装而不是依赖系统仓库。3. 安装前必须明确的几个关键点3.1 确认系统架构和现有环境动手安装之前先确认目标机器的环境和现状。我见过太多人上来就复制粘贴安装命令结果装完发现架构不对、权限不够、或者和已有的 JDK 冲突。第一件事是确认架构。Linux 64 位通常指的是 x86_64、amd64 这种架构但现在 ARM 架构的服务器也越来越多了比如 AWS Graviton、华为鲲鹏。如果架构不匹配你下载的 rpm 或 tar.gz 包根本跑不起来。用uname -m看一下输出如果是x86_64或amd64就是通用的 64 位 x86 架构如果是aarch64那就得选 ARM64 版本。第二件事是查看是否已经装了 Java。用java -version和which java检查。如果系统里已经有一个旧版本的 JDK比如 Java 8你需要决定是共存还是替换。我强烈建议不要直接卸载旧 JDK因为很多系统工具比如某些版本的 Gradle、Tomcat 管理脚本可能依赖特定版本直接卸载容易引发连锁问题。更好的方式是让新 JDK 共存通过环境变量和alternatives机制管理默认版本。第三件事是确认当前用户权限。安装 JDK 到系统目录比如/usr/local/java需要 root 权限。如果你只有普通用户权限建议装到用户目录下比如~/jdk这样完全不依赖系统目录权限也不会影响其他用户。3.2 JDK 和 JRE 的认知误区Java 11 之后有一个很多人没意识到的变化不再提供独立的 JRE 下载包。以前 Java 8 时代你可以只装一个 JRE 来跑 Java 程序体积小够用。但从 Java 9 开始官方调整了发布结构JDK 本身就包含了完整的运行环境单独的 JRE 包被取消了。这就导致很多新手在找Linux 64 位 JRE 11的时候发现官方根本不下发这种包了于是误以为 Java 11 不能精简安装。实际上你可以用 JDK 自带的jlink工具来自定义生成一个精简运行时镜像把不需要的模块裁掉。一些有经验的人会在 Docket 镜像里用jlink做小体积运行环境比如只保留java.base、java.sql等核心模块最终运行时体积可以从 300MB 压缩到 50MB 左右。所以在你安装 JDK 的时候不要纠结我只想装个运行环境JDK 太大了这个问题。直接装 JDK 是最稳妥的方案开发、编译、运行都够用。如果你后续觉得体积是个问题再考虑 jlink 裁剪而不是一开始就去搜什么精简版 JRE。4. 实测安装过程从下载到环境变量配置4.1 官方二进制包的手动安装方案我先讲一个最通用、最可控的方案直接下载官方编译好的 tar.gz 包手动安装。这个方案不依赖系统包管理器无论你是 CentOS、Ubuntu、Debian 还是其他发行版操作流程基本一致。第一步去 OpenJDK 官方构建站或镜像站下载OpenJDK 11.0.24的 Linux x86_64 tar.gz 包。我通常从 Adoptium 的 API 或者清华镜像站下载速度稳定。假设你下载的文件名是OpenJDK11U-jdk_x64_linux_hotspot_11.0.24_8.tar.gz注意看一下文件名里的架构标识。第二步解压到统一管理目录。我个人习惯把所有 JDK 都放在/usr/local/java/下这样只需要维护/etc/profile或/etc/environment里的一个路径sudo mkdir -p /usr/local/java sudo tar -zxvf OpenJDK11U-jdk_x64_linux_hotspot_11.0.24_8.tar.gz -C /usr/local/java/ cd /usr/local/java/ # 解压后会有一个 jdk-11.0.248 目录建议做一个软链 sudo ln -s jdk-11.0.248 latest软链这一步是个小技巧。如果你以后升级到 11.0.25只需要重新解压新包然后把latest指过去/etc/profile里的路径完全不用改动。这个习惯让我在升级 JDK 小版本时省了很多事。第三步配置环境变量。编辑/etc/profile文件在末尾追加以下内容export JAVA_HOME/usr/local/java/latest export PATH$JAVA_HOME/bin:$PATH export CLASSPATH.:$JAVA_HOME/lib/dt.jar:$JAVA_HOME/lib/tools.jar等一下这里我要特别提醒CLASSPATH那段配置是 Java 8 时代的写法。Java 9 之后引入了模块化系统JDK 内部的 lib 目录结构发生了巨大变化很多.jar文件被移到了jmods目录里而且dt.jar、tools.jar在 Java 11 里已经不是常规路径了。如果你完全照搬 Java 8 教程里的 CLASSPATH启动时反而可能产生 ClassNotFound 异常。实际上Java 9 大多数情况下根本不需要手动设置 CLASSPATH编译器javac和运行时java默认就能处理类路径。所以更干净的写法是export JAVA_HOME/usr/local/java/latest export PATH$JAVA_HOME/bin:$PATH第四步让环境变量立即生效source /etc/profile java -version看到输出里有openjdk version 11.0.24和OpenJDK 64-Bit Server VM就说明装好了。4.2 系统包管理器安装方案快速但受限如果你的服务器不想折腾手动解压也可以用系统包管理器安装。以 Ubuntu/Debian 为例sudo apt update sudo apt install openjdk-11-jdk -yCentOS/RHEL 7/8 上则是sudo yum install java-11-openjdk-devel -y这个方案的优点是省心系统会自动处理好路径、权限和依赖缺点是版本不可控。Ubuntu 的仓库里可能滞后一两个小版本而且安装路径分散在/usr/lib/jvm/java-11-openjdk-amd64这种地方路径规则不统一。如果你是在开发机或者个人服务器上快速搭个环境这个方案足够但如果你是要统一管理多台生产服务器我建议你还是用第一种手动方案确保所有机器版本完全一致。4.3 配置 alternatives让系统命令指向正确的 Java在 Linux 上安装多个 JDK 后系统全局的java命令默认不会自动指向新装的版本。Ubuntu 里可以用update-alternatives来配置sudo update-alternatives --install /usr/bin/java java /usr/local/java/latest/bin/java 1 sudo update-alternatives --install /usr/bin/javac javac /usr/local/java/latest/bin/javac 1 sudo update-alternatives --config java执行--config之后系统会列出当前所有已注册的 Java 路径让你选择默认项。我建议把新装的 11.0.24 设为手动选择并保证其优先级最高。这个机制就像 Windows 里的默认程序设置你装了多个浏览器需要指定哪个是默认的。这里有个细节容易踩坑update-alternatives配置的是/usr/bin/java这个软链的指向但很多应用启动脚本会直接读JAVA_HOME环境变量而不会去解析/usr/bin/java。所以你在配置完 alternatives 之后依然要确认JAVA_HOME指向正确。两套机制是互补关系不是替代关系。5. 验证、优化与常见问题排查5.1 安装完成后的完整性验证装完环境变量配置好不要急着跑应用先做一轮验证。除了java -version我还会执行这三个命令# 验证编译器是否可用 javac -version # 验证 JVM 实际加载的运行时信息 java -XshowSettings:properties -version 21 | grep -E java.home|java.version|os.arch # 验证关键模块是否完整 java --list-modules | grep -E java.sql|java.management|jdk.management我自己在部署后一般还会写一个最基础的 Java 类测试编译和运行链路cat /tmp/Test.java EOF public class Test { public static void main(String[] args) { System.out.println(Java home: System.getProperty(java.home)); System.out.println(Version: System.getProperty(java.version)); } } EOF cd /tmp javac Test.java java Test这一步可以快速发现环境变量是否完全生效以及 JAVA_HOME 路径是否正确。5.2 性能调优与 JVM 参数参考OpenJDK 11.0.24 在默认配置下已经能良好运行大多数应用但如果你要在生产环境部署 Spring Boot、Tomcat 或大数据组件JVM 参数还是值得针对机器配置做一轮调优。我的基础模板是这样的java -Xms2g -Xmx2g \ -XX:UseG1GC \ -XX:MaxGCPauseMillis200 \ -XX:HeapDumpOnOutOfMemoryError \ -XX:HeapDumpPath/data/logs/java_heap.hprof \ -XX:PrintGCDetails \ -XX:PrintGCDateStamps \ -Xloggc:/data/logs/gc.log \ -jar yourapp.jar解释一下几个关键参数-Xms和-Xmx分别指定 JVM 初始堆大小和最大堆大小。我建议两者设为相同的值这样 JVM 启动时直接申请好全部堆内存运行过程中不需要动态扩容GC 行为更容易预测。设置多少要根据服务器物理内存来比如 8GB 内存的机器留 2GB 给系统和其他进程JVM 堆可以给到 4GB。-XX:UseG1GC指定 G1 垃圾回收器。Java 11 里 G1 已经是默认收集器但显式声明参数可以让运维排查问题时更明确。HeapDumpOnOutOfMemoryError这个参数尤其重要。生产环境一旦发生 OOM没有 heap dump 就只能瞎猜内存泄漏点有了 dump 文件可以直接用 MAT 分析。这个习惯让我排查线上问题的时间从半天缩短到半小时。Java 11 还引入了一个重要特性ZGC可扩展低延迟垃圾回收器但它默认是实验性的虽然 11.0.24 版本已经成熟许多我依然建议生产环境保守使用 G1因为 ZGC 对内存换 CPU 的消耗比较大在低配机器上反而可能拖慢吞吐。5.3 常见问题速查表我在多年部署经验里把最新一次部署遇到的相关情况整理成一张速查表以后复制排查步骤就能快速定位问题问题现象可能原因解决方案java: command not foundPATH 未配置或未 source检查/etc/profile确认 exported PATH执行source /etc/profileError: could not open .../lib/amd64/server/libjvm.soJDK 目录被移动或软链失效检查 JAVA_HOME 是否指向正确的实际路径重建软链javac -version正常但java -version报错系统里存在多个 JDKjava命令指向了旧版用which java查看实际路径用 update-alternatives 调整程序启动非常慢CPU 占用不正常JVM 在解析大量 jar 包或者 DNS 反查添加-Djava.net.preferIPv4Stacktrue检查/etc/resolv.conf配置Unable to locate an executable at /usr/bin/java/bin/java (-1)JAVA_HOME 设置重复叠加了路径检查是否在 PATH 里重复写入了$JAVA_HOME/bin和多层bin/binDocker 容器里 java 无法启动提示内存不足容器内存限制和 JVM 检测不匹配使用-XX:UseContainerSupportJava 11 默认开启或者显式设置-Xmx5.4 多版本 JDK 共存的实践心得最后的经验补充也是我在实际运维中体会最深的一点永远不要在生产服务器上只装一个 JDK 版本除非你有 100% 的把握未来不会迁移。我的做法是在/usr/local/java/下同时保留多个版本目录比如/usr/local/java/jdk-11.0.248/ /usr/local/java/jdk-17.0.127/ /usr/local/java/latest - jdk-11.0.248/然后每一个应用使用独立的启动脚本脚本里显式指定它要用的 JDK 路径#!/bin/bash export JAVA_HOME/usr/local/java/jdk-17.0.127 export PATH$JAVA_HOME/bin:$PATH nohup java -jar /data/app/your-app.jar /data/logs/your-app.log 21 这样每个应用都被钉死在确定的 JDK 版本上系统默认的java命令变了也不会影响线上应用。这个思路类似于 Docker 镜像里把特定版本打包进一层保证环境一致性和可复现性。如果你是用 Systemd 管理 Java 应用也可以在 service 文件里的Environment字段单独指定 JAVA_HOME效果一样。记住一个原则系统全局的 java 是给运维用的应用自己的 java 是给应用用的二者尽量不要混为一谈。本文还有配套的精品资源点击获取