在云服务器上安装Java的最佳实践-java教程-PHP中文网

选择OpenJDK并通过包管理器安装，配置JAVA_HOME环境变量并验证版本与路径，可确保云服务器Java环境稳定安全。

在云服务器上安装java的最佳实践

在云服务器上安装Java，最核心的实践在于选择一个稳定、安全且易于维护的OpenJDK发行版，并利用操作系统的包管理器进行安装与管理，辅以环境变量的规范配置，这能最大化地保证系统的健壮性和后续的运维效率。

在云服务器上部署Java环境，这事儿看似简单，但真要做到“最佳实践”，里面门道可不少。我个人在这方面摸爬滚打多年，总结下来，核心思路就是：拥抱开源、善用工具、精细配置。

首先，关于选择哪种Java。我几乎总是推荐使用OpenJDK。原因很简单，Oracle JDK的许可条款越来越复杂，对于商业应用来说，可能带来不必要的法律风险和成本。而OpenJDK，尤其是由Adoptium (原AdoptOpenJDK)、Amazon Corretto、Azul Zulu等厂商提供的版本，它们都是基于OpenJDK的，性能和稳定性完全不输，甚至在某些方面还有优化。更重要的是，它们是免费且开源的，更新及时，社区支持也很好。

安装方式上，我强烈建议优先使用操作系统的包管理器（比如Ubuntu/Debian的

apt

登录后复制

，CentOS/RHEL的

yum

登录后复制

或

dnf

登录后复制

）。这种方式的好处是显而易见的：依赖关系处理、安全补丁更新、卸载都非常方便。你不需要手动下载压缩包、解压、配置PATH，省去了很多潜在的麻烦。

立即学习“Java免费学习笔记（深入）”；

举个例子，在Ubuntu上，你可能只需要：

sudo apt update
sudo apt install openjdk-17-jdk # 或者你需要的任何版本，比如 openjdk-11-jdk

登录后复制

这几行命令下去，Java环境基本就搭建好了。系统会自动处理好大部分环境变量，比如

java

登录后复制

和

javac

登录后复制

命令可以直接使用。

但如果你是开发者，或者需要频繁切换Java版本（比如一个项目用Java 8，另一个用Java 17），那么我个人会考虑引入SDKMAN!这样的工具。它能让你在同一台服务器上轻松安装、切换和管理多个JDK、Maven、Gradle等SDK版本，非常灵活，对开发效率的提升是巨大的。不过，这通常更多地出现在开发/测试环境，生产环境我还是倾向于一个稳定版本，由包管理器维护。

安装完成后，环境变量的配置是关键。

JAVA_HOME

登录后复制

这个变量，虽然不是所有应用都强制要求，但很多Java生态工具（如Maven、Gradle、Tomcat、Jenkins）都会依赖它来定位JDK安装路径。所以，即便包管理器已经让

java -version

登录后复制

能正常工作，我还是会手动设置

JAVA_HOME

登录后复制

。

通常，我会把它写入

/etc/profile.d/java.sh

登录后复制

（如果你的系统支持这种方式），或者用户的

~/.bashrc

登录后复制

或

~/.profile

登录后复制

文件中，确保每次登录都能生效。

# 假设你的JDK安装在 /usr/lib/jvm/java-17-openjdk-amd64
export JAVA_HOME="/usr/lib/jvm/java-17-openjdk-amd64"
export PATH="$JAVA_HOME/bin:$PATH"

登录后复制

然后

source

登录后复制

一下文件，或者重新登录。

最后一步是验证。运行

java -version

登录后复制

和

javac -version

登录后复制

，确保输出的版本是你期望的。同时，

echo $JAVA_HOME

登录后复制

也能确认环境变量是否正确设置。如果这些都正确，那么你的云服务器上的Java环境，就算是按照最佳实践搭建起来了。

为什么选择OpenJDK而不是Oracle JDK？

我遇到过不少朋友，在云服务器上部署Java时，习惯性地去下载Oracle JDK，但很快就会在许可问题上遇到困惑。在我看来，选择OpenJDK而非Oracle JDK，这不仅仅是一个技术选择，更是一个战略考量。最核心的原因在于许可协议的清晰度与自由度。

Oracle JDK在早期版本（如Java 8u202之前）对于商业使用是免费的，但从Java 11开始，其商业发行版就需要付费订阅才能获得更新和支持。这对于许多企业来说，无疑增加了额外的运营成本和潜在的法律风险。想象一下，如果你的生产环境跑着一个没有安全更新的Java版本，或者因为没有付费而面临合规性问题，那将是多么被动。

OpenJDK则完全不同。它是一个开源项目，其代码库是Java SE平台的基础。市面上众多的OpenJDK发行版（如Adoptium、Amazon Corretto、Azul Zulu、Red Hat OpenJDK等）都基于此，它们通常提供长期支持（LTS）版本，并且在许可上更加宽松，通常是GPLv2 with Classpath Exception。这意味着你可以在商业环境免费使用、分发和修改它们，无需担心许可费用或法律纠纷。

从技术角度看，现代的OpenJDK发行版在性能、稳定性、功能特性上，与Oracle JDK几乎没有差异，甚至在某些基准测试中表现更优。这些发行版通常由大型公司或社区维护，更新及时，安全补丁到位。比如，Amazon Corretto就承诺提供与Oracle JDK相同的LTS支持周期，并且在AWS生态中深度集成。

所以，我个人的建议是，除非你有非常特殊的需求，或者与Oracle有现成的企业级支持协议，否则，为了避免不必要的麻烦和成本，拥抱OpenJDK是更明智、更“安全”的选择。这不仅仅是省钱，更是省心。

如何通过包管理器安装Java并进行版本管理？

通过包管理器安装Java，在我看来，是云服务器上最省心、最推荐的方式，尤其是对于生产环境。它简化了安装过程，同时也方便了后续的更新和维护。不过，不同Linux发行版的操作会有所不同，这里我主要讲讲Ubuntu/Debian系和CentOS/RHEL系。

Ubuntu/Debian系 (使用

apt

登录后复制

)

在Ubuntu或Debian上，安装OpenJDK非常直接。

更新包列表：
```
sudo apt update
```
登录后复制
这是个好习惯，确保你获取到最新的软件包信息。
安装OpenJDK： 你可以安装特定版本的JDK，比如Java 17：
```
sudo apt install openjdk-17-jdk
```
登录后复制
如果你需要Java 11，就安装
```
openjdk-11-jdk
```
登录后复制
。通常，
```
jdk
```
登录后复制
包会包含
```
jre
```
登录后复制
和开发工具。
验证：
```
java -version
javac -version
```
登录后复制
这会显示你安装的Java版本。

版本管理 (Ubuntu/Debian)

如果你的系统上安装了多个Java版本，Ubuntu/Debian提供了一个非常方便的工具

update-alternatives

登录后复制

来管理默认的Java版本。

查看可用版本：
```
sudo update-alternatives --config java
```
登录后复制
系统会列出所有已安装的Java可执行文件，并让你选择一个作为默认。

帮衣帮-AI服装设计
AI服装设计神器，AI生成印花、虚拟试衣、面料替换

106

查看详情
切换版本： 输入对应的数字即可切换。例如，选择
```
1
```
登录后复制
来使用Java 17。你也可以对
```
javac
```
登录后复制
、
```
jar
```
登录后复制
等命令进行同样的操作。

CentOS/RHEL系 (使用

yum

登录后复制

或
dnf
登录后复制
)

在CentOS 7或RHEL 7上，你通常会使用

yum

登录后复制

；在CentOS 8+或RHEL 8+上，

dnf

登录后复制

是更现代的包管理器，但

yum

登录后复制

通常也作为

dnf

登录后复制

的别名存在。

更新包列表：

sudo yum update # 或者 sudo dnf update

登录后复制

安装OpenJDK： 安装Java 17的开发工具包：
```
sudo yum install java-17-openjdk-devel # 或者 sudo dnf install java-17-openjdk-devel
```
登录后复制
```
devel
```
登录后复制
后缀通常表示包含了JDK（开发工具包），而非仅仅是JRE。
验证：
```
java -version
javac -version
```
登录后复制

版本管理 (CentOS/RHEL)

CentOS/RHEL也提供类似的工具来管理多个Java版本，通常是

alternatives

登录后复制

命令。

查看可用版本：
```
sudo alternatives --config java
```
登录后复制
这会列出所有可用的Java运行时，你可以选择一个作为默认。
切换版本： 输入对应的数字进行选择。

SDKMAN!：更高级的版本管理

对于开发人员，或者那些需要在同一台服务器上频繁切换不同Java版本（甚至包括Maven、Gradle、Kotlin等）的场景，SDKMAN!是一个非常强大的工具。

安装SDKMAN!：

curl -s "https://get.sdkman.io" | bash
source "$HOME/.sdkman/bin/sdkman-init.sh"

登录后复制

列出可用JDK：
```
sdk list java
```
登录后复制
你会看到来自不同供应商（Adoptium, Oracle, Amazon等）的各种Java版本。

安装特定JDK：

sdk install java 17.0.9-tem # 举例安装Adoptium的Java 17

登录后复制

切换默认JDK：
```
sdk default java 17.0.9-tem
```
登录后复制
或者，在特定会话中临时使用：
```
sdk use java 11.0.20-tem
```
登录后复制
SDKMAN!的优势在于其灵活性和对多种SDK的支持。它将JDK安装在用户目录下，不会干扰系统级的Java安装，非常适合个人开发环境或CI/CD服务器。虽然它不属于“包管理器”范畴，但作为版本管理工具，它提供了一种非常高效的解决方案。

安装后如何配置Java环境并验证？

安装Java后，确保环境配置正确并进行验证，这是保障后续Java应用能顺利运行的关键一步。我发现很多新手会在这里犯错，导致各种“找不到Java”或者“版本不匹配”的问题。

1. 配置

JAVA_HOME

登录后复制

环境变量

这是最重要的一环。虽然包管理器安装的Java通常能让

java

登录后复制

和

javac

登录后复制

命令直接工作，但很多Java生态工具（如Apache Maven, Gradle, Apache Tomcat, Jenkins, Spring Boot打包工具等）都依赖

JAVA_HOME

登录后复制

这个环境变量来定位JDK的安装路径。如果它没有正确设置，这些工具就可能无法正常工作。

查找JDK安装路径： 在Ubuntu/Debian上，OpenJDK通常安装在
```
/usr/lib/jvm/
```
登录后复制
目录下，例如
```
/usr/lib/jvm/java-17-openjdk-amd64
```
登录后复制
。在CentOS/RHEL上，可能在
```
/usr/lib/jvm/java-17-openjdk
```
登录后复制
或
```
/usr/java/jdk-17.0.9
```
登录后复制
之类的路径。你可以通过
```
readlink -f $(which java)
```
登录后复制
来找到
```
java
```
登录后复制
命令的实际路径，然后向上追溯到JDK的根目录。
设置
```
JAVA_HOME
```
登录后复制
：为了让
```
JAVA_HOME
```
登录后复制
永久生效，我通常建议将其写入系统的配置文件中。
- 全局设置 (对所有用户生效)： 在
```
/etc/profile.d/
```
  登录后复制
  目录下创建一个脚本，比如
```
java.sh
```
  登录后复制
  。
```
sudo nano /etc/profile.d/java.sh
```
  登录后复制
  在文件中添加：
```
export JAVA_HOME="/usr/lib/jvm/java-17-openjdk-amd64" # 替换为你的实际路径
export PATH="$JAVA_HOME/bin:$PATH"
```
  登录后复制
  保存并退出。然后执行
```
source /etc/profile.d/java.sh
```
  登录后复制
  或者重新登录，让配置生效。
- 用户级设置 (只对当前用户生效)： 将上述两行
```
export
```
  登录后复制
  命令添加到当前用户的
```
~/.bashrc
```
  登录后复制
  或
```
~/.profile
```
  登录后复制
  文件中。
```
nano ~/.bashrc
# ... (文件末尾添加)
export JAVA_HOME="/usr/lib/jvm/java-17-openjdk-amd64" # 替换为你的实际路径
export PATH="$JAVA_HOME/bin:$PATH"
```
  登录后复制
  保存并退出。然后执行
```
source ~/.bashrc
```
  登录后复制
  或者重新登录。

2. 验证环境配置

配置完成后，务必进行验证，确保一切如预期般工作。

验证Java版本：
```
java -version
javac -version
```
登录后复制
这两条命令应该输出你安装的Java版本信息。如果
```
javac
```
登录后复制
命令找不到，那很可能是你安装了JRE而不是JDK，或者
```
PATH
```
登录后复制
环境变量没有包含
```
$JAVA_HOME/bin
```
登录后复制
。
验证
JAVA_HOME
登录后复制
：
```
echo $JAVA_HOME
```
登录后复制
这条命令应该输出你设置的JDK安装路径。如果输出为空或者路径不正确，说明
```
JAVA_HOME
```
登录后复制
没有正确设置或没有生效。
验证
PATH
登录后复制
：
```
echo $PATH
```
登录后复制
检查输出中是否包含
```
$JAVA_HOME/bin
```
登录后复制
的路径。如果
```
java
```
登录后复制
和
```
javac
```
登录后复制
命令能正常运行，通常说明
```
PATH
```
登录后复制
是正确的。

3. 常见问题及排查

java: command not found
登录后复制
或
javac: command not found
登录后复制
：这通常意味着
```
PATH
```
登录后复制
环境变量没有正确包含Java的
```
bin
```
登录后复制
目录。检查
```
PATH
```
登录后复制
设置，确保
```
$JAVA_HOME/bin
```
登录后复制
在其中。
JAVA_HOME
登录后复制
设置后不生效：确认你修改的是正确的配置文件（
```
~/.bashrc
```
登录后复制
、
```
~/.profile
```
登录后复制
或
```
/etc/profile.d/
```
登录后复制
下的文件），并且在修改后执行了
```
source
```
登录后复制
命令或重新登录。
运行
java -version
登录后复制
显示的版本与预期不符：这可能是因为系统中有多个Java版本，并且默认的版本不是你想要的。在Ubuntu/Debian上使用
```
sudo update-alternatives --config java
```
登录后复制
进行切换，在CentOS/RHEL上使用
```
sudo alternatives --config java
```
登录后复制
。
某些Java应用仍然找不到JDK： 有些应用可能在启动脚本中有自己的Java路径查找逻辑，或者会覆盖
```
JAVA_HOME
```
登录后复制
。检查应用的文档或启动脚本，看是否有特定的Java配置项。