眠子子子刚接触Linux的人总以为“在Ubuntu上装好Java”就是执行一条安装命令，等到真正部署项目的时候，发现java -version虽然能输出版本号，可javac找不到、JAVA_HOME是空的、进程一启动就内存异常，最后才明白环境搭建这件事远没有表面那么简单。我早期从Windows切到Ubuntu时踩过几乎全套的坑，后来在不同的云服务器、虚拟机、Docker环境里反复部署过几十次，才慢慢形成一套“一次搭对、长期不折腾”的方法。这篇文章就围绕“Ubuntu + Java部署环境”这件事，把系统准备、JDK选型、环境变量、生产部署、高频坑位一次说透。
文章默认使用Ubuntu 22.04 LTS和Java 17组合，如果你用的是20.04或24.04，思路完全一致，只是软件源里可用版本号略有差异。零基础用户可以按章节顺序操作，已经有一定经验的人可以直接跳到第4和第5章看部署实践和踩坑思路。
1. 敲安装命令之前，先把系统层面的三件事确认清楚
很多人一进系统就急着sudo apt install openjdk-17-jdk，装完才发现系统版本老、源没换、连Java包都装成自己不想要的版本。磨刀不误砍柴工，系统层面的准备反而最影响后续体验。
1.1 确认Ubuntu版本：生产部署优先选LTS
Java环境不是装在越新的Ubuntu上越好，而是越“稳”越好。Ubuntu有几个不同的发布节奏，长期支持版本叫LTS，通常每两年出一个，桌面版和服务器版都提供五年的标准支持，这个周期几乎覆盖了一个项目的生存期。对部署环境来说，必须优先选择LTS版本。
先执行下面命令看看当前系统版本：
bash复制lsb_release -a
# 或者
cat /etc/os-release
如果你正在选云服务器镜像或者准备装虚拟机系统，我建议选22.04 LTS或24.04 LTS。以Ubuntu 22.04为例，软件源里默认带有Java 11和Java 17，运行Spring Boot 3项目绰绰有余；24.04默认带Java 21，适合想直接上最新LTS特性的人。
有个新手常见的误区：看到“最新版Ubuntu 24.10”就去装，其实非LTS版本的软件源和官方技术支持只有九个月，等你把环境搭好、项目跑起来，系统可能就停止维护了，到时候被迫强制升级，非常被动。部署环境不是追求桌面尝鲜的地方，稳定和生命周期才是第一优先级。
1.2 桌面版还是服务器版：学Java开发不等于必须装图形界面
许多人被“Ubuntu”这个词误导，以为装系统就一定会有桌面窗口，于是新手在虚拟机里装Desktop版本，服务器上也跟着装Desktop版本。其实Ubuntu官方提供两种镜像：Desktop桌面版和Server服务器版，二者内核一致，区别只是服务器版默认没有图形桌面，安装包更小、内存占用更低。
如果你是在本地虚拟机里学了Java基础、连Linux操作都还不熟，我建议先装桌面版，有图形界面会让前期压力小很多；如果目标是把Java项目部署到云服务器或公司测试机器上，请直接使用Server版，因为生产环境根本不需要桌面占用的几百MB内存，也减少了图形组件带来的安全风险。
这里还要提一句权限习惯：安装过程中创建的用户通常已经在sudo组里，日常操作直接用它就好，不要一上来就sudo su切到root，更不要禁止普通用户登录。用root操作一时爽，等文件权限错乱、某个服务因为目录属主问题起不来时，排查过程会让你怀疑人生。
1.3 换apt源：装软件前先把手动挡换成自动挡
Ubuntu安装软件主要靠apt工具，apt会读取系统配置的软件源地址。默认官方源虽然在境外，在国内访问速度确实很慢，延迟高的时候执行apt update都像卡住一样。解决方法是把软件源替换成国内镜像源，比较常用的是阿里云镜像和清华TUNA镜像。
从22.04开始，部分版本的apt源配置文件路径发生了变化，已经不完全是传统/etc/apt/sources.list单文件结构，而是采用/etc/apt/sources.list.d/ubuntu.sources的deb822格式。建议先看一下自己机器上的文件结构：
bash复制ls -l /etc/apt/sources.list*
cat /etc/apt/sources.list.d/*.sources 2>/dev/null | head -20
如果看到的是/etc/apt/sources.list，可以这样替换为阿里云源：
bash复制sudo sed -i 's@//.*archive.ubuntu.com@//mirrors.aliyun.com@g' /etc/apt/sources.list
sudo sed -i 's@security.ubuntu.com@mirrors.aliyun.com@g' /etc/apt/sources.list
sudo apt update
如果看到的是ubuntu.sources，也可以用sed把其中http://archive.ubuntu.com/ubuntu/整体替换为http://mirrors.aliyun.com/ubuntu/。替换后记得执行：
bash复制sudo apt update && sudo apt upgrade -y
apt upgrade会把系统已有的安全补丁和依赖更新到软件源中的最新版本，这一步很值得做，Java相关的依赖在更新后能减少很多奇怪的兼容性问题。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. JDK选型和三种安装方式：部署环境里的决定没有想象中纠结
Java的环境组件叫JDK，但JDK本身又分成好几种发行版，很多刚接触的人会在这个选择上卡住。我直接把我现在的决策逻辑跟大家说清楚。
2.1 OpenJDK和Oracle JDK到底差多少
早期Oracle JDK和OpenJDK确实存在行为差异，但从Java 11之后，特别是Java 17时代，两者在代码层面已经高度一致，日常开发和生产运行几乎感觉不到区别。比较大的不同在许可协议上：Oracle JDK从Java 17开始采用Oracle No-Fee Terms and Conditions协议，个人使用没问题，但一些企业使用场景需要仔细核对条款；OpenJDK则始终是GPL协议，部署上少一层顾虑。
所以我的默认建议是：没有特殊情况，直接用发行版软件仓库里的OpenJDK。如果你所在公司对JDK供应商有明确规范，或者项目依赖某些需要特定构建版本的第三方库，再考虑Eclipse Temurin、Azul Zulu这些其他OpenJDK发行版。绝大多数Spring Boot项目、普通Java服务，用OpenJDK完全够用。
2.2 三种安装方式对比：按场景对号入座
在你搜索的资料里很可能看到三种主流安装方式：apt安装、tar包手动解压、SDKMAN工具安装。这里放一张对比表，方便直观理解：
| 安装方式 | 适合场景 | 优点 | 缺点 |
|---|---|---|---|
| apt install | 新手入门、临时环境、测试服务器 | 命令简单，自动配置alternatives和系统路径 | 版本受发行版仓库限制，想装官方新版要额外找源 |
| tar.gz手动解压 | 生产部署、企业内部标准目录管理 | 版本灵活可控，目录结构统一，不依赖发行版仓库 | 需要自己配置环境变量和命令软链 |
| SDKMAN | 本地开发、需要频繁切换多个Java版本 | 多版本管理方便，一键切换 | 依赖curl和unzip等前置工具，不适合作为生产服务核心依赖 |
简单说：如果你是零基础，先走apt路线；如果你要给生产服务器搭一个长期稳定、目录规范的环境，手动解压也没多复杂；SDKMAN很适合个人笔记本上今天做Java 8项目、明天切Java 17的情况。
2.3 apt方式安装：零基础最不容易出错的路子
在Ubuntu 22.04上，安装Java 17的命令非常简单：
bash复制sudo apt update
sudo apt install openjdk-17-jdk -y
这里请注意包名，要装的是openjdk-17-jdk，而不是openjdk-17-jre。JDK里包含了编译工具javac和完整的运行环境JRE；只装JRE的话java命令虽然能用，但javac不存在，后面会专门讲这个坑。
安装完成后先做一次基础验证：
bash复制java -version
javac -version
which java
readlink -f $(which java)
java -version能看到类似openjdk version "17.0.12"这样的输出，javac -version能看到编译器版本，这说明JDK已经生效。readlink -f会展示Java命令最终指向的真实目录，一般会落到/usr/lib/jvm/java-17-openjdk-amd64/bin/java。
可能会有人问：要不要从Oracle官网下载官方tar.gz包？除非公司的安全合规要求你使用某个特定供应商版本，否则没必要给自己增加后续手工维护的负担。apt安装的JDK会随系统软件源自动获得安全更新，这对生产环境来说是一个很大的优势。
2.4 手动tar.gz安装：目录和版本都自己掌控
虽然apt安装很省事，但如果你需要的是一个“不随apt升级而波动”的固定JDK版本，或者要统一把所有必要组件放在/opt或/usr/local目录下方便运维管理，tar.gz解压安装是更合适的选择。
下载好类似jdk-17.0.12_linux-x64_bin.tar.gz的包后，按下面步骤执行：
bash复制sudo mkdir -p /usr/local/java
sudo tar -zxf jdk-17.0.12_linux-x64_bin.tar.gz -C /usr/local/java
sudo ln -sfn /usr/local/java/jdk-17.0.12 /usr/local/java/jdk-17
ls -l /usr/local/java/
这里做了一步软链接，把带版本号的目录映射成不带版本号的jdk-17。这样以后如果升级到17.0.13，只需要解压新包然后修改软链接指向，其他脚本和配置都不用动。
注意一个问题：JDK bin目录下的工具不会自动出现在命令搜索路径里。你需要在第3章完成环境变量配置，或者用update-alternatives机制把java和javac注册到系统命令目录中。只有环境变量配置好了，执行java命令才能被找到。
3. JAVA_HOME和PATH配置：这一章比想象中更有含金量
环境变量配置是“Ubuntu安装Java环境”的核心分水岭。很多人觉得把三行export粘到配置文件里就完了，实际上一旦系统里出现多个Java版本、某些终端能识别某些终端不能识别的问题，基本都是配置位置或配置方式有问题。
3.1 JAVA_HOME到底在干什么
JAVA_HOME环境变量用来告诉系统目前“默认的Java安装目录在哪”，它是一个约定俗成的路径标记。许多构建工具如Maven、Gradle、IDEA，以及运行脚本和服务管理工具，都会主动读取JAVA_HOME来定位JDK。
可以用一个生活化类比来理解：JAVA_HOME相当于告诉系统“我家在哪个地址”，PATH则相当于餐厅门口的服务员名单——当你在终端输入java这个词时，系统就按照PATH里的路径挨个找，看有没有叫java的可执行程序；而真正的可执行程序一般住在$JAVA_HOME/bin目录下，所以配置PATH时要写上$JAVA_HOME/bin:$PATH。
还有一个常被误解的概念CLASSPATH，很多老教程让你手动配.:$JAVA_HOME/lib/dt.jar:$JAVA_HOME/lib/tools.jar，那是Java 8时代的历史遗留做法。从Java 9开始引入模块化系统，运行javac和java时已经能正确加载核心类库，配错CLASSPATH反而可能引发各种找不到类的怪问题。新手直接不要配CLASSPATH就是最正确的做法。
3.2 配置文件也别乱选：六个文件的区别和适用场景
系统里和登录配置相关的文件很多，新手最常踩的坑就是把内容写错位置，导致终端里不生效。我帮你整理了一下，实际用得最多的是这几个：
| 配置文件 | 加载时机 | 推荐用途 |
|---|---|---|
| /etc/environment | 系统启动、登录进程早期 | 不推荐把export写入这里，语法太受限 |
| /etc/profile | 交互式登录shell启动时加载 | 全局配置，但不建议直接改，容易升级冲突 |
| /etc/profile.d/*.sh | /etc/profile加载完后自动遍历 | 推荐全局Java环境变量放这 |
| ~/.profile | 用户登录shell时加载 | 偏用户级配置 |
| ~/.bashrc | 交互式非登录shell启动时加载 | 用户终端环境配置，新手最常修改的文件 |
这里有个细节值得单独说：很多教程让你直接改/etc/profile，但Ubuntu在系统升级时可能覆盖它，所以更稳妥的做法是把环境变量隔离到/etc/profile.d/java.sh，既达到了全局生效的目的，又方便单独管理。
如果你只是在本地临时验证一下，也可以直接在终端执行export设定，当前会话立刻生效，但关闭终端后就失效了：
bash复制export JAVA_HOME=/usr/lib/jvm/java-17-openjdk-amd64
export PATH="$JAVA_HOME/bin:$PATH"
3.3 配置JAVA_HOME的完整实操
假设你用的是apt安装，JDK真实路径是/usr/lib/jvm/java-17-openjdk-amd64；假设你用的是手动解压安装，路径改成你实际软链接目录/usr/local/java/jdk-17。创建全局配置文件：
bash复制sudo tee /etc/profile.d/java.sh >/dev/null <<'EOF'
export JAVA_HOME=/usr/lib/jvm/java-17-openjdk-amd64
export PATH="$JAVA_HOME/bin:$PATH"
EOF
接着让配置在当前终端生效：
bash复制source /etc/profile.d/java.sh
验证：
bash复制echo $JAVA_HOME
which java
java -version
javac -version
为什么这里用source而不是重启系统？因为source会在当前shell里重新执行文件内容，让环境变量立刻加载进内存，不用为了一个路径配置重启服务器。但要注意，source只对当前终端有效，其他已经打开的终端窗口不会自动感知，它们仍然保留启动时继承的环境变量。此时你有两种选择：关闭重开终端，或者在新终端里再执行一次source。如果你通过SSH登录，新开的SSH会话通常会自动加载/etc/profile.d/下的脚本。
很多人会问，Java装好之后还要不要额外配置JRE_HOME？在现代JDK安装中，JRE已经不是独立目录结构，JDK内部自带完整的运行组件，你不再需要配置JRE_HOME。网上的旧博客不会告诉你这些，但它们的信息可能停留在五六年前。
3.4 多版本切换：update-alternatives比手动改PATH可靠得多
生产机器上偶尔会同时存在多个Java版本，例如某个老项目还需要Java 8。有人图省事，不断改~/.bashrc里的路径，这样切来切去非常容易出错。
Ubuntu提供了一个标准的管理机制叫update-alternatives，简单理解就是系统软链接的管理器。它通过在/usr/bin下放置java、javac这样的软链接指向实际版本。apt安装的JDK一般会自动注册，你可以这样查看当前版本优先级：
bash复制sudo update-alternatives --list java
sudo update-alternatives --config java
sudo update-alternatives --config javac
执行--config后会显示一个交互式列表，输入数字就能切换默认版本。对于手动解压的JDK，也可以手动注册到alternatives机制：
bash复制sudo update-alternatives --install /usr/bin/java java /usr/local/java/jdk-17/bin/java 2000
sudo update-alternatives --install /usr/bin/javac javac /usr/local/java/jdk-17/bin/javac 2000
注册时的数字代表优先级，越大越容易被系统自动选中。这种方式的优势在于：Java命令最终落在/usr/bin/java下，sudo场景和普通用户场景都能正常找到，不会出现第5章会讲到的“sudo下找不到java”的尴尬情况。
4. 部署一个Java服务：从“能跑命令”到“能稳定跑进程”
环境搭好之后，下一步就是真正把一个Java服务跑起来。很多人以为“部署Java服务”等于执行java -jar app.jar，让程序在前台窗口滚动日志，然后就可以收工。实际情况远比我预想的复杂，尤其当服务器重启或SSH断开时，前台进程会直接消失。
4.1 先验证编译和运行：连最小Java程序都跑不通就继续排查
在部署复杂项目之前，建议先写一个最简程序验证JDK链路是否完整。用下面的方式创建一个测试文件：
bash复制mkdir -p ~/test && cd ~/test
cat > Main.java <<'EOF'
public class Main {
public static void main(String[] args) {
System.out.println("Java deployment environment OK");
}
}
EOF
javac Main.java
java Main
看到Java deployment environment OK输出，说明从编译到运行整条链路都是通的。这一步能帮你把问题范围缩小：如果javac这一步报错，是JDK没装好；如果java执行时报找不到主类，可能是环境变量或classpath的问题。很多新手一上来就部署几十MB的Spring Boot项目，万一报错根本分不清是Java环境问题还是项目配置问题。
顺带说一个观念问题：现在Java Web项目大多用Spring Boot，这种项目把Tomcat内嵌在进程里，直接打成一个可执行jar就能运行，并不需要额外装一个独立Tomcat。所以部署环境的重点是把JVM配好，而不是费劲去解压一个Tomcat到服务器再配置一堆XML。
4.2 systemd托管Java服务：别再用nohup硬扛了
网上很多教学会让你用nohup java -jar app.jar > app.log 2>&1 &启动服务，这在临时测试时还算实用，但生产部署里有一个明显问题：nohup启动的进程没有一个标准守护机制来管理它的重启、开机自启和崩溃恢复，一旦服务器自己重启，服务不会自动回来。
Ubuntu自带的systemd是管理后台服务的第一选择。下面是一套我反复使用的部署方式。
先在服务器上创建应用目录并准备jar包：
bash复制sudo mkdir -p /opt/myapp/logs
sudo cp app.jar /opt/myapp/
如果希望不通过root运行服务，可以单独创建一个普通用户并授权目录，生产环境里这一步很有必要，避免Java进程权限过大：
bash复制sudo useradd -r -s /usr/sbin/nologin appuser
sudo chown -R appuser:appuser /opt/myapp
然后创建systemd服务单元文件：
bash复制sudo tee /etc/systemd/system/myapp.service >/dev/null <<'EOF'
[Unit]
Description=My Java Application
After=network-online.target
Wants=network-online.target
[Service]
User=appuser
WorkingDirectory=/opt/myapp
ExecStart=/usr/bin/java -Xms256m -Xmx1024m -XX:+UseG1GC -jar /opt/myapp/app.jar
Restart=on-failure
RestartSec=5
StandardOutput=journal
StandardError=journal
[Install]
WantedBy=multi-user.target
EOF
启动并设置开机自启：
bash复制sudo systemctl daemon-reload
sudo systemctl enable --now myapp
sudo systemctl status myapp
sudo journalctl -u myapp -f
这里有个systemd细节值得注意：很多运维教程会在单元文件里写Environment=JAVA_OPTS="-Xms256m -Xmx1024m"，然后在ExecStart中写$JAVA_OPTS，期望它像在shell里一样把参数拆开传入。但systemd对变量展开不做空格分词，环境变量引号里的所有内容会被当成一个参数传给java，结果JVM根本不会按预期解析内存参数。如果你的JVM参数比较多，建议把这些参数直接写在ExecStart里，或者把启动逻辑放到一个单独脚本里去执行，在脚本里再进行参数展开。这样的坑没有亲手踩过，可能只在线上遇到服务启动后内存不对时才会反应过来。
4.3 Docker部署Java应用的推荐姿势
现在越来越多的生产服务跑在容器里，如果你的机器已经安装了Docker，用容器部署Java应用是另一个主流选择。这里给一个可直接参考的Dockerfile：
dockerfile复制FROM eclipse-temurin:17-jre
WORKDIR /app
COPY app.jar /app/app.jar
EXPOSE 8080
ENTRYPOINT ["java", "-XX:MaxRAMPercentage=75.0", "-jar", "app.jar"]
为什么推荐eclipse-temurin:17-jre基础镜像而不是直接用完整的Ubuntu再装一个OpenJDK？因为部署容器的一个核心原则是镜像尽量小、组件尽量少。Temurin是Adoptium项目维护的OpenJDK发行版，它的jre镜像经过压缩后体积远小于在Ubuntu基础镜像里执行apt install得到的最终结果，而且官方维护更新及时。
-XX:MaxRAMPercentage=75.0是容器场景里非常重要的一个参数。默认情况下，JVM会读取宿主机总内存来决定最大堆。但容器里运行JVM时，它可能看到的物理内存不是容器被限制后的内存，而是宿主机的全部内存，这样JVM启动后会以为有足够的内存，直到扩容到超过容器限制才被操作系统强制杀掉，现象就是服务突然消失，排查日志却找不到OOM错误。
使用MaxRAMPercentage后，JVM会感知到容器cgroup限制，最多只会用到容器内存上限的75%，剩下的留给Metaspace、线程栈、JIT等非堆内存，这样更保险。普通物理机部署时你可以用固定的-Xmx，容器里则优先考虑百分比策略。
如果项目有多个模块或者用了不同环境配置，可以用docker-compose管理。简单示例如下：
yaml复制version: "3.8"
services:
myapp:
build: .
image: myapp:latest
container_name: myapp
restart: unless-stopped
ports:
- "8080:8080"
environment:
- SPRING_PROFILES_ACTIVE=prod
执行docker compose up -d --build即可完成构建和启动。用容器方式部署时，第4.2节里的systemd服务就不再需要了，因为Docker本身已经承担了进程托管和重启策略这一层职责。
5. 零基础最容易踩的坑：每一条都是我见过的真实现场
这部分想写得更像排查笔记。下面这些故障场景，任何人都可能遇到，我尽量还原“现象 → 猜测 → 定位 → 解决”的完整链路，而不是只丢结论。
5.1 java -version正常，javac却提示command not found
这个坑非常典型，通常发生在你从网上拷贝了一条安装命令，安装的其实是default-jre或openjdk-17-jre-headless，这只能提供运行环境，不包含编译器。很多教程只让安装JRE，因为对“跑别人已经编译好的jar”来说确实够了，但你要开发和编译Java程序，就必须有JDK。
查看系统里实际装了什么包：
bash复制dpkg -l | grep -E "openjdk|jre|jdk"
代码里可能看到openjdk-17-jre-headless，这时直接补上JDK包：
bash复制sudo apt install openjdk-17-jdk -y
再用javac -version验证。以后凡是遇到类似“某命令还是command not found”的报错，第一反应不要是去环境变量文件里乱加内容，而是先确认软件包本身是否完整安装，或者用apt-file search查看该命令属于哪个包，这比瞎猜高效得多。
5.2 明明写了环境变量文件，新开终端还是不生效
很多人按教程把export写进了~/.bashrc，然后执行source ~/.bashrc，当前窗口正常了。可是一登录服务器、打开新终端，又打回原形。
最可能的原因有两个：第一，那个新终端启动时因为是non-login shell，只读~/.bashrc，但你的内容其实写进了~/.profile或/etc/profile，而图形界面下默认打开的终端未必会加载这两个文件；第二，写的是~/.profile，但这个文件只在登录shell里加载，而不是所有终端都加载。
更好的做法是：
- 用户级配置写在
~/.bashrc末尾，并在.profile里判断是否通过bash执行时引用它； - 全局配置写成
/etc/profile.d/java.sh，登录shell都会加载； - 改完文件先确认语法没有错误，然后执行
source加载再验证。
如果你确实需要的是一个“所有用户、所有场景都能找到Java命令”的部署环境，真正稳妥的方案仍是使用update-alternatives把java、javac注册进/usr/bin，因为无论是sudo、systemd还是其他服务启动方式，都会从系统PATH中搜索可执行程序。
5.3 sudo执行命令时找不到java，普通用户却正常
这种现象很迷惑：切到普通用户执行java -version没问题，但加上sudo之后却报sudo: java: command not found。
原因在于sudo工具默认有一个安全路径机制secure_path，它在执行sudo时会把PATH重置为系统预设的几个目录，而不是继承你当前用户自行添加的路径。如果你把Java装在/opt/java/jdk-17/bin，并且只通过~/.bashrc里export了PATH，普通用户能识别，但sudo执行时PATH里没有这个目录，自然找不到java。
不要把export PATH=$PATH:/opt/java/jdk-17/bin填进.bashrc后觉得问题解决，因为sudo环境下它根本没读这个文件。标准解法是用alternatives注册命令软链接：
bash复制sudo update-alternatives --install /usr/bin/java java /opt/java/jdk-17/bin/java 2000
sudo update-alternatives --install /usr/bin/javac javac /opt/java/jdk-17/bin/javac 2000
注册后，/usr/bin/java已经存在，sudo自然能找到。如果你确认自己的Java命令在这个secure_path包含的目录里，仍然报错，再考虑执行sudo visudo查看Defaults secure_path是否需要追加目录，不过这种做法优先级更低，因为改错了sudo配置会影响整机命令执行。
5.4 编译项目时提示“源发行版 17 需要目标发行版 17”
这个中文提示经常出现在刚导入Maven项目或执行mvn compile时，比如你在Java 8环境里强行用源码版本17编译，或者Java 17环境下Maven编译器插件配置成了低版本却要求目标发行版17，都会出现类似警告或错误。还有一种常见情况是安装了Java 17，但项目pom里设置了maven.compiler.source=1.8，也会提示语法不兼容。
出现“源发行版17需要目标发行版17”这类问题时，不要急着去卸载重装Java，先确认三方面：IDEA或命令行里当前使用的JDK版本是什么；项目pom.xml或build.gradle里设置的Java编译版本是什么；Maven运行的JDK与项目要求的JDK是否一致。通常执行以下命令查看Maven当前使用的Java版本：
bash复制mvn -version
mvn -version输出第一行会明确显示它运行在哪个Java版本上。如果这里显示的是Java 8，项目要求Java 17，那你需要的不是调pom，而是让Maven用JDK 17启动，常见手段是修改Maven安装目录下的setenv.sh或bin/mvn脚本里的JAVA_HOME指向。
这里也提醒新手：不要同时打开好几个不同版本的IDEA项目，然后在一个IDEA里反复切换Project SDK，忘记自己当前终端环境用的是哪个版本。在很多情况下，终端报错不一定是服务器问题，而是你本机工具链版本错配。
5.5 Java进程提示insufficient memory或容器被突然杀掉
错误提示里带OutOfMemoryError: insufficient memory时，很多人的第一反应是把-Xmx调大，但偶尔调大之后仍然报错，甚至容器直接退出。这里的本质是：Java进程的“内存不足”有时不是堆内存不够，而是操作系统或容器已经无法再分配本机内存了。JVM除了堆内存，还需要Metaspace、线程栈、JIT编译缓存等大量本地内存，如果容器内存上限是1GB，而你把-Xmx设为1024m，那这个堆上限几乎占满了全部容器内存，JVM自己都没空间启动其他组件。
排查时先看机器的真实内存情况：
bash复制free -h
docker stats # 如果是容器
查看JVM实际内存占用：
bash复制ps aux | grep java
jcmd