本文导读本文是系列第 17 篇正式进入Java SaaS 部署实战阶段。JVM 环境配置看似简单实则暗藏诸多陷阱环境变量只对当前 Shell 生效、JDK 版本与 Spring Boot 版本的兼容矩阵、JVM 启动参数在生产环境的正确配置。本文覆盖 JDK 选型、多版本管理、生产级 JVM 调优参数以及常见的 OOM 排查思路。关键词Linux安装JDK教程、Java环境变量配置、JVM调优参数、SDKMAN多版本管理、JAVA_HOME配置、Spring Boot JVM参数目录一、JDK 选型OpenJDK、Oracle JDK 还是 GraalVM二、三种 JDK 安装方式2.1 方式一通过 apt 包管理器安装最简单适合快速上手2.2 方式二下载 Eclipse Temurin 预编译包推荐生产环境使用2.3 配置 JAVA_HOME 和 PATH 环境变量三、SDKMAN多版本 JDK 管理的最佳工具四、生产环境 JVM 启动参数每一行都有讲究4.1 内存相关参数4.2 GC垃圾回收器选择4.3 GC 日志与 OOM 转储排查问题的必备配置4.4 完整的生产环境 JVM 启动参数示例五、JVM 版本与 Spring Boot 兼容性矩阵六、常见 JVM 问题快速排查七、常见问题解答FAQ❓ Q1java -version 显示的版本和 JAVA_HOME 指向的不一致是什么原因❓ Q2服务器内存是 8GB-Xmx 应该设置多少❓ Q3Full GC 频繁发生怎么排查❓ Q4Spring Boot 应用启动时报 Could not reserve enough space for object heap是什么原因❓ Q5开发机是 macOS/Windows生产服务器是 Linux有没有可能因为平台差异导致 JVM 行为不同本篇小结与系列导航 参考资料一、JDK 选型OpenJDK、Oracle JDK 还是 GraalVM在正式安装之前先把装哪个 JDK这个问题搞清楚能避免后续因为选型不当带来的麻烦。Java 生态目前的主要 JDK 发行版发行版维护方授权适用场景OpenJDK社区Red Hat 主导GPL通用首选免费社区活跃Oracle JDKOracle商业生产需付费需要 Oracle 官方支持的企业Eclipse Temurin (Adoptium)Eclipse 基金会GPLOpenJDK 的高质量预编译版强烈推荐GraalVM CommunityOracle / 社区GPL需要原生镜像Native Image或多语言运行时的场景Alibaba Dragonwell阿里巴巴GPL针对阿里内部场景优化国内部分企业使用对于绝大多数 Java SaaS 项目Eclipse Temurin即 Adoptium 项目的 OpenJDK 预编译版是最推荐的选择完全开源免费、构建质量高、提供长期支持LTS版本的预编译二进制、社区活跃。如果你的项目有阿里云的合规要求或者在国内云环境部署Dragonwell 也是一个务实的选项。JDK 版本选择策略 新项目 优先选 JDK 21当前最新 LTS 版本长期支持至2031年 已有项目维护 评估迁移成本可以继续用 JDK 17LTS支持至2029年 旧项目无法迁移JDK 11LTS支持至2026年接近末期尽快规划升级 避免使用 非 LTS 的中间版本如 JDK 18/19/20生命周期只有6个月⚠️ 踩坑记录Oracle JDK 从 JDK 17 开始将授权改为 NFTCNo-Fee Terms and Conditions个人和商业使用都免费但有一个非常重要的约束必须始终使用最新版本一旦新版本发布旧版本就不再允许免费使用否则属于违规使用。这对生产环境来说是一个不小的运维压力被迫频繁升级可能引入兼容性问题。因此对于需要长期稳定运行、不想被强制升级约束的生产服务器OpenJDK / Eclipse Temurin 是更安全的选择版本完全由你自己控制没有任何授权方面的顾虑。二、三种 JDK 安装方式2.1 方式一通过 apt 包管理器安装最简单适合快速上手# 安装 OpenJDK 17系统仓库版本Ubuntu 22.04 默认提供 sudo apt install -y openjdk-17-jdk # 查看 apt 仓库里有哪些可用的 JDK 版本 apt search openjdk | grep openjdk-[0-9]*-jdk # 验证安装 java -version javac -version # 通过 apt 安装后JAVA_HOME 自动指向 # Ubuntu: /usr/lib/jvm/java-17-openjdk-amd64通过包管理器安装是最省心的方式但版本可能落后官方最新几个小版本且对 JDK 版本的精确控制能力较弱——如果你需要精确到我要用 JDK 17.0.9 而不是 17.0.12包管理器就做不到了。2.2 方式二下载 Eclipse Temurin 预编译包推荐生产环境使用这种方式能精确控制 JDK 版本也方便未来的版本管理# 第一步从 Adoptium 官方下载指定版本的 JDK以 JDK 21 为例 # 官方地址https://adoptium.net/temurin/releases/ # 也可以用 API 方式获取下载链接更适合脚本化 JDK_VERSION21.0.511 ARCHx64 OSlinux cd /tmp wget https://github.com/adoptium/temurin21-binaries/releases/download/jdk-${JDK_VERSION}/OpenJDK21U-jdk_${ARCH}_${OS}_hotspot_21.0.5_11.tar.gz # 第二步解压到规范目录第02篇讲到的 /opt 是手动安装软件的标准位置 sudo mkdir -p /opt/jdk sudo tar -xzf OpenJDK21U-jdk_*.tar.gz -C /opt/jdk/ sudo mv /opt/jdk/jdk-21.0.511 /opt/jdk/jdk-21 # 第三步查看解压后的目录结构确认安装正确 ls /opt/jdk/jdk-21/ # 应该能看到bin/ conf/ include/ jmods/ legal/ lib/ release解压完成后此时/opt/jdk/jdk-21/bin/java已经可以执行但直接调用需要输入完整路径不方便。下面的环境变量配置解决这个问题。2.3 配置 JAVA_HOME 和 PATH 环境变量这一步是新手最容易踩坑的地方核心问题是写在哪个配置文件里决定了这个变量对谁生效、在什么情况下生效。# 系统级环境变量对所有用户的所有 Shell 会话都生效推荐用于服务器环境 sudo tee /etc/profile.d/jdk.sh EOF export JAVA_HOME/opt/jdk/jdk-21 export PATH$JAVA_HOME/bin:$PATH export CLASSPATH.:$JAVA_HOME/lib EOF # 让配置立即在当前会话生效新开 SSH 连接后也会自动加载无需再次执行 source /etc/profile.d/jdk.sh # 验证 java -version echo $JAVA_HOME which java⚠️ 踩坑记录极其高频几乎人人都会踩source /etc/profile.d/jdk.sh让环境变量在当前 SSH 会话里立即生效但有三种情况下你会发现明明配好了 JAVA_HOME命令却找不到 java情况一打开了一个新的 SSH 连接但没有 source以为当前窗口自动生效了——其实新连接会在登录时自动加载/etc/profile.d/下的所有脚本所以新连接不需要手动 source但刚执行 source 的那个旧连接的 cd 状态和新连接是独立的这两件事不要搞混。情况二systemd Service 文件里的ExecStart用了java命令但 systemd 启动服务时不会加载/etc/profile.d/导致 systemd 找不到 java。解决办法是在.service文件的[Service]区块里显式配置EnvironmentJAVA_HOME/opt/jdk/jdk-21和EnvironmentPATH/opt/jdk/jdk-21/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin或者在ExecStart里直接用 java 的绝对路径/opt/jdk/jdk-21/bin/java。情况三crontab 里的脚本用到了 java但 cron 环境同样不加载/etc/profile.d/——这正是第14篇讲到的 cron 环境变量陷阱在脚本开头source /etc/profile或者用绝对路径解决。理解环境变量对谁生效这个问题的本质是 Linux 运维中非常基础但容易长期混淆的知识点花时间搞清楚一次后续类似问题能举一反三。三、SDKMAN多版本 JDK 管理的最佳工具当你的服务器上同时运行着 JDK 17 的旧项目和 JDK 21 的新项目或者需要在本地开发机上频繁在不同 JDK 版本间切换SDKMAN是管理这种复杂场景的利器。# 安装 SDKMAN会修改 ~/.bashrc 或 ~/.zshrc安装后需要重开终端或 source curl -s https://get.sdkman.io | bash source $HOME/.sdkman/bin/sdkman-init.sh # 查看可用的 JDK 发行版列表很长筛选 Temurin 版本 sdk list java | grep tem # 安装指定版本以 Temurin JDK 21 为例 sdk install java 21.0.5-tem # 安装多个版本 sdk install java 17.0.13-tem # 切换当前 Shell 会话使用的 JDK 版本临时切换只影响当前终端窗口 sdk use java 17.0.13-tem # 设置全局默认 JDK 版本影响所有新开的终端 sdk default java 21.0.5-tem # 查看当前使用的 JDK 版本 sdk current java # 卸载某个版本 sdk uninstall java 17.0.13-temSDKMAN 的工作原理是把所有 JDK 版本统一安装在~/.sdkman/candidates/java/目录下通过修改当前 Shell 的PATH变量指向不同版本的bin目录来实现版本切换。这比手动维护多个JAVA_HOME配置文件优雅很多切换操作是即时生效且可逆的。 生产提示SDKMAN 主要面向开发者的本地环境对于生产服务器建议用第二种方式手动解压到/opt/jdk/目录并配置/etc/profile.d/jdk.sh更显式地管理 JDK 版本——生产服务器的 JDK 版本不应该频繁切换明确的目录结构和配置文件更便于运维审计和问题排查不依赖 SDKMAN 这样的第三方工具也能减少一个潜在的故障点。四、生产环境 JVM 启动参数每一行都有讲究用 systemd 或脚本启动 Spring Boot 应用时java -jar app.jar前面可以附加大量 JVM 参数来调整运行行为这些参数对应用的稳定性和性能有直接影响。4.1 内存相关参数# 堆内存配置最重要的两个参数 -Xms2g # 初始堆大小启动时就分配这么多 -Xmx2g # 最大堆大小堆不会超过这个值 # 生产实践-Xms 和 -Xmx 设成相同的值避免堆在运行期动态扩缩导致的停顿 # 具体数值通常设为服务器物理内存的 50-70%为操作系统和其他进程留出余量 # 元空间Metaspace配置JDK 8存放类元数据 -XX:MetaspaceSize256m # 初始元空间大小 -XX:MaxMetaspaceSize512m # 最大元空间大小如果不设理论上无限增长这里要理解为什么-Xms和-Xmx建议设成相同值。如果两者不同比如-Xms512m -Xmx2gJVM 初始只分配 512MB随着对象增多再向 OS 申请内存动态扩展到 2GB每次堆扩展都会触发一次 Full GC垃圾回收产生额外的 GC 停顿。对于服务器应用启动时就直接分配好-Xmx指定的内存量-Xms-Xmx可以完全避免这种因堆扩展触发的 GC代价只是启动时多占一些内存对服务器来说这个代价完全可以接受。4.2 GC垃圾回收器选择# G1GCJDK 9 默认的 GC在吞吐量和停顿时间之间取得良好平衡推荐绝大多数场景使用 -XX:UseG1GC -XX:MaxGCPauseMillis200 # 目标最大 GC 停顿时间G1 会尽力控制在这个范围内 # ZGCJDK 15 进入生产可用极低延迟停顿通常1ms适合对响应时间极敏感的场景 # 代价吞吐量略低于 G1内存开销略高 -XX:UseZGC # Parallel GC吞吐量优先适合批处理类应用 -XX:UseParallelGC对于 Java SaaS Web 应用G1GC 是首选——它在控制停顿时间避免因 GC 导致的请求超时和保持较高吞吐量之间取得了很好的平衡。如果你的应用对延迟极度敏感比如实时通信、金融交易且运行在 JDK 17 上可以考虑迁移到 ZGC。4.3 GC 日志与 OOM 转储排查问题的必备配置# GC 日志分析 GC 行为、排查内存问题的重要数据来源 -Xlog:gc*:file/var/log/myapp/gc.log:time,uptime,level,tags:filecount5,filesize20m # OOM 时自动生成堆转储文件JVM 即将因 OOM 崩溃前先把堆内存快照保存下来供后续分析 -XX:HeapDumpOnOutOfMemoryError -XX:HeapDumpPath/var/log/myapp/heapdump.hprof # OOM 后自动重启配合前面第08篇的 systemd Restarton-failure 使用 -XX:OnOutOfMemoryErrorkill -9 %p⚠️ 踩坑记录-XX:HeapDumpOnOutOfMemoryError这个参数经常因为可能影响性能而被生产环境的工程师关掉这是一个错误的做法。这个参数在正常运行期间的性能开销为零只有在真正发生 OOM 时才会触发堆转储操作——而此时不管你有没有这个参数OOM 本身已经让应用无法正常工作了生成一个堆转储文件的额外时间在这种极端情况下完全可以接受。关掉这个参数的代价是OOM 发生后你没有任何堆快照只能靠猜测来分析是什么导致了内存溢出而有了 heapdump.hprof 文件用 Eclipse Memory AnalyzerMAT几分钟内就能定位到是哪种对象在泄漏。这个参数永远应该开着特别是在生产环境。4.4 完整的生产环境 JVM 启动参数示例把上面各类参数整合成一份完整的生产级配置放入 systemd Service 文件# /etc/systemd/system/myapp.service[Service] 区块的关键配置 [Service] Typesimple Usermyapp Groupmyapp WorkingDirectory/opt/myapp/current ExecStart/opt/jdk/jdk-21/bin/java \ -server \ -Xms2g -Xmx2g \ -XX:MetaspaceSize256m \ -XX:MaxMetaspaceSize512m \ -XX:UseG1GC \ -XX:MaxGCPauseMillis200 \ -XX:HeapDumpOnOutOfMemoryError \ -XX:HeapDumpPath/var/log/myapp/heapdump.hprof \ -XX:OnOutOfMemoryErrorkill -9 %p \ -Xlog:gc*:file/var/log/myapp/gc.log:time,uptime:filecount5,filesize20m \ -Djava.security.egdfile:/dev/./urandom \ -Dspring.profiles.activeproduction \ -Dspring.config.location/opt/myapp/config/application-prod.yml \ -jar /opt/myapp/current/app.jar-Djava.security.egdfile:/dev/./urandom这个参数解决了 Java 应用在 Linux 上一个经典的启动慢问题——Java 的SecureRandom默认读取/dev/random生成随机数而/dev/random在熵池不足时会阻塞等待导致应用启动时卡几秒甚至更长。改用/dev/urandom注意路径里的./是特意为了绕过 JVM 内部对/dev/urandom路径的特殊判断逻辑不会阻塞是生产环境的标准做法对安全性几乎没有实质影响。五、JVM 版本与 Spring Boot 兼容性矩阵选错了 JDK 版本和 Spring Boot 版本的组合会遇到各种奇怪的兼容性报错Spring Boot 版本最低 JDK 要求推荐 JDK备注3.xJDK 17JDK 21Spring Boot 3 完全拥抱 Java 17 特性2.7.xJDK 8JDK 17最后一个 2.x 版本已停止维护2023年11月2.6.x 及以下JDK 8JDK 11/17已停止维护不推荐继续使用# 检查当前运行的 Spring Boot 应用使用的 JDK 版本在应用已启动的情况下 jps -v | grep app.jar # 列出 Java 进程及其启动参数 # 检查 JAR 包编译时使用的 JDK 版本通过 class 文件版本号推断 javap -verbose -classpath app.jar org.springframework.boot.SpringApplication | grep major version # major version: 61 对应 JDK 17 # major version: 65 对应 JDK 21 # 实战场景生产服务器收到报错 Unsupported class file major version 65 # 这意味着编译时用了 JDK 21但生产服务器上安装的是 JDK 17 或更低版本无法运行这个字节码 生产提示在 CI/CD 流水线里明确锁定编译用的 JDK 版本是避免在开发机用新 JDK 编译、部署到装了旧 JDK 的生产服务器这类问题的最直接手段。Maven 项目在pom.xml里通过maven.compiler.source和maven.compiler.target指定字节码版本或者更现代的方式是用.sdkmanrc文件SDKMAN 支持或.java-version文件jenv 支持在项目根目录锁定 JDK 版本让团队所有成员和 CI/CD 环境都用相同的 JDK 版本从源头消除版本不一致的隐患。六、常见 JVM 问题快速排查# 查看 JVM 的运行时参数确认 -Xmx 等参数是否真的生效 jps # 列出所有 Java 进程的 PID jinfo -flags PID # 显示该进程的所有 JVM 参数 # 查看 GC 频率和停顿时间简要统计 jstat -gcutil PID 2000 10 # 每2秒输出一次共10次 # jstat 输出关键字段解读 # S0C/S1CSurvivor 0/1 区容量(KB) # ECEden 区容量(KB) # OCOld 区容量(KB) # YGCYoung GC 发生次数 # YGCTYoung GC 累计耗时(秒) # FGCFull GC 发生次数这个数值持续增长是内存问题的重要信号 # FGCTFull GC 累计耗时(秒) # 获取线程堆栈排查 CPU 高、死锁等问题——结合第12篇的性能排查思路 jstack PID /tmp/threaddump_$(date %Y%m%d_%H%M%S).txt # 获取堆内存对象统计排查内存泄漏 jmap -histo PID | head -30七、常见问题解答FAQ❓ Q1java -version显示的版本和 JAVA_HOME 指向的不一致是什么原因java -version执行的是PATH里第一个找到的java命令这可能是通过 apt 安装在/usr/bin/java一个指向 alternatives 的符号链接也可能是你JAVA_HOME/bin/java取决于PATH里哪个路径排在前面。which java能告诉你当前实际执行的是哪个路径的 javaecho $JAVA_HOME告诉你环境变量指向哪里。如果两者不一致说明PATH配置有问题$JAVA_HOME/bin没有排在其他 java 安装路径前面检查/etc/profile.d/jdk.sh里PATH的拼接顺序$JAVA_HOME/bin:$PATH要保证 JAVA_HOME 在前。❓ Q2服务器内存是 8GB-Xmx 应该设置多少没有放之四海皆准的公式但常用的经验原则是-Xmx设为可用内存的 50%-70%为操作系统、其他进程如果同一台机器上还有 Nginx、MySQL以及 JVM 的非堆内存Metaspace、直接内存等预留空间。8GB 内存的单应用服务器-Xmx4g到-Xmx6g是合理区间具体值需要结合实际的堆使用率监控数据来调整先上线收集 GC 日志观察堆的实际峰值使用量在峰值的 1.5-2 倍设置-Xmx是比较稳健的策略。❓ Q3Full GC 频繁发生怎么排查用jstat -gcutil PID 2000持续观察如果FGCFull GC 次数和FGCTFull GC 总时间持续增长说明 Full GC 确实频繁。常见根因老年代Old Gen内存被慢慢填满——用jmap -histo:live PID | head -20看哪些类的对象数量最多结合应用日志判断是业务逻辑导致对象无法被回收内存泄漏还是单纯的-Xmx设置太小、老年代空间不足两者的解决方案完全不同。❓ Q4Spring Boot 应用启动时报 Could not reserve enough space for object heap是什么原因-Xmx设置的值超过了当前系统实际可用的内存JVM 无法申请到足够的连续内存空间来创建堆。解决方法一是降低-Xmx值二是检查系统实际可用内存free -h看available列三是检查是否有其他进程已经占用了大量内存四是检查是否配置了 swap 分区增加 swap 能缓解这个问题但不能从根本解决。❓ Q5开发机是 macOS/Windows生产服务器是 Linux有没有可能因为平台差异导致 JVM 行为不同有但很少见。最常遇到的平台差异① 文件路径分隔符/和\Java 的File.separator能屏蔽这个差异② 换行符\nvs\r\n涉及文本文件读写时需要显式指定字符编码和行结束符③ 时区JVM 默认读取操作系统时区开发机是北京时间、服务器是 UTC 时区时日期计算结果会不一样生产服务器应该通过 JVM 参数-Duser.timezoneAsia/Shanghai显式指定时区而不依赖操作系统配置。本篇小结与系列导航 核心结论JDK 选型推荐 Eclipse TemurinAdoptium版本优先选 LTS 版本当前为 JDK 21。环境变量配置的核心问题是对谁生效——/etc/profile.d/对交互式 Shell 生效systemd Service 需要在[Service]里显式声明Environmentcron 需要在脚本内source /etc/profile。生产 JVM 参数的要点-Xms-Xmx避免堆扩展 GC、选对 GCG1GC 通用、ZGC 低延迟、永远开启-XX:HeapDumpOnOutOfMemoryError、-Djava.security.egd解决启动阻塞。SDKMAN 适合开发机多版本管理生产服务器推荐手动解压/etc/profile.d/配置的显式方式。 参考资料Eclipse Temurin JDK 下载页SDKMAN 官方文档JVM 参数完整参考 - OracleG1GC 官方调优指南如果本文对你有帮助请点赞 收藏 ⭐ 支持一下欢迎在评论区留言交流。系列标签LinuxJDK安装JAVA_HOMEJVM调优GC参数Spring BootSDKMANJava运维
本文导读本文是系列第 17 篇正式进入Java SaaS 部署实战阶段。JVM 环境配置看似简单实则暗藏诸多陷阱环境变量只对当前 Shell 生效、JDK 版本与 Spring Boot 版本的兼容矩阵、JVM 启动参数在生产环境的正确配置。本文覆盖 JDK 选型、多版本管理、生产级 JVM 调优参数以及常见的 OOM 排查思路。关键词Linux安装JDK教程、Java环境变量配置、JVM调优参数、SDKMAN多版本管理、JAVA_HOME配置、Spring Boot JVM参数目录一、JDK 选型OpenJDK、Oracle JDK 还是 GraalVM二、三种 JDK 安装方式2.1 方式一通过 apt 包管理器安装最简单适合快速上手2.2 方式二下载 Eclipse Temurin 预编译包推荐生产环境使用2.3 配置 JAVA_HOME 和 PATH 环境变量三、SDKMAN多版本 JDK 管理的最佳工具四、生产环境 JVM 启动参数每一行都有讲究4.1 内存相关参数4.2 GC垃圾回收器选择4.3 GC 日志与 OOM 转储排查问题的必备配置4.4 完整的生产环境 JVM 启动参数示例五、JVM 版本与 Spring Boot 兼容性矩阵六、常见 JVM 问题快速排查七、常见问题解答FAQ❓ Q1java -version 显示的版本和 JAVA_HOME 指向的不一致是什么原因❓ Q2服务器内存是 8GB-Xmx 应该设置多少❓ Q3Full GC 频繁发生怎么排查❓ Q4Spring Boot 应用启动时报 Could not reserve enough space for object heap是什么原因❓ Q5开发机是 macOS/Windows生产服务器是 Linux有没有可能因为平台差异导致 JVM 行为不同本篇小结与系列导航 参考资料一、JDK 选型OpenJDK、Oracle JDK 还是 GraalVM在正式安装之前先把装哪个 JDK这个问题搞清楚能避免后续因为选型不当带来的麻烦。Java 生态目前的主要 JDK 发行版发行版维护方授权适用场景OpenJDK社区Red Hat 主导GPL通用首选免费社区活跃Oracle JDKOracle商业生产需付费需要 Oracle 官方支持的企业Eclipse Temurin (Adoptium)Eclipse 基金会GPLOpenJDK 的高质量预编译版强烈推荐GraalVM CommunityOracle / 社区GPL需要原生镜像Native Image或多语言运行时的场景Alibaba Dragonwell阿里巴巴GPL针对阿里内部场景优化国内部分企业使用对于绝大多数 Java SaaS 项目Eclipse Temurin即 Adoptium 项目的 OpenJDK 预编译版是最推荐的选择完全开源免费、构建质量高、提供长期支持LTS版本的预编译二进制、社区活跃。如果你的项目有阿里云的合规要求或者在国内云环境部署Dragonwell 也是一个务实的选项。JDK 版本选择策略 新项目 优先选 JDK 21当前最新 LTS 版本长期支持至2031年 已有项目维护 评估迁移成本可以继续用 JDK 17LTS支持至2029年 旧项目无法迁移JDK 11LTS支持至2026年接近末期尽快规划升级 避免使用 非 LTS 的中间版本如 JDK 18/19/20生命周期只有6个月⚠️ 踩坑记录Oracle JDK 从 JDK 17 开始将授权改为 NFTCNo-Fee Terms and Conditions个人和商业使用都免费但有一个非常重要的约束必须始终使用最新版本一旦新版本发布旧版本就不再允许免费使用否则属于违规使用。这对生产环境来说是一个不小的运维压力被迫频繁升级可能引入兼容性问题。因此对于需要长期稳定运行、不想被强制升级约束的生产服务器OpenJDK / Eclipse Temurin 是更安全的选择版本完全由你自己控制没有任何授权方面的顾虑。二、三种 JDK 安装方式2.1 方式一通过 apt 包管理器安装最简单适合快速上手# 安装 OpenJDK 17系统仓库版本Ubuntu 22.04 默认提供 sudo apt install -y openjdk-17-jdk # 查看 apt 仓库里有哪些可用的 JDK 版本 apt search openjdk | grep openjdk-[0-9]*-jdk # 验证安装 java -version javac -version # 通过 apt 安装后JAVA_HOME 自动指向 # Ubuntu: /usr/lib/jvm/java-17-openjdk-amd64通过包管理器安装是最省心的方式但版本可能落后官方最新几个小版本且对 JDK 版本的精确控制能力较弱——如果你需要精确到我要用 JDK 17.0.9 而不是 17.0.12包管理器就做不到了。2.2 方式二下载 Eclipse Temurin 预编译包推荐生产环境使用这种方式能精确控制 JDK 版本也方便未来的版本管理# 第一步从 Adoptium 官方下载指定版本的 JDK以 JDK 21 为例 # 官方地址https://adoptium.net/temurin/releases/ # 也可以用 API 方式获取下载链接更适合脚本化 JDK_VERSION21.0.511 ARCHx64 OSlinux cd /tmp wget https://github.com/adoptium/temurin21-binaries/releases/download/jdk-${JDK_VERSION}/OpenJDK21U-jdk_${ARCH}_${OS}_hotspot_21.0.5_11.tar.gz # 第二步解压到规范目录第02篇讲到的 /opt 是手动安装软件的标准位置 sudo mkdir -p /opt/jdk sudo tar -xzf OpenJDK21U-jdk_*.tar.gz -C /opt/jdk/ sudo mv /opt/jdk/jdk-21.0.511 /opt/jdk/jdk-21 # 第三步查看解压后的目录结构确认安装正确 ls /opt/jdk/jdk-21/ # 应该能看到bin/ conf/ include/ jmods/ legal/ lib/ release解压完成后此时/opt/jdk/jdk-21/bin/java已经可以执行但直接调用需要输入完整路径不方便。下面的环境变量配置解决这个问题。2.3 配置 JAVA_HOME 和 PATH 环境变量这一步是新手最容易踩坑的地方核心问题是写在哪个配置文件里决定了这个变量对谁生效、在什么情况下生效。# 系统级环境变量对所有用户的所有 Shell 会话都生效推荐用于服务器环境 sudo tee /etc/profile.d/jdk.sh EOF export JAVA_HOME/opt/jdk/jdk-21 export PATH$JAVA_HOME/bin:$PATH export CLASSPATH.:$JAVA_HOME/lib EOF # 让配置立即在当前会话生效新开 SSH 连接后也会自动加载无需再次执行 source /etc/profile.d/jdk.sh # 验证 java -version echo $JAVA_HOME which java⚠️ 踩坑记录极其高频几乎人人都会踩source /etc/profile.d/jdk.sh让环境变量在当前 SSH 会话里立即生效但有三种情况下你会发现明明配好了 JAVA_HOME命令却找不到 java情况一打开了一个新的 SSH 连接但没有 source以为当前窗口自动生效了——其实新连接会在登录时自动加载/etc/profile.d/下的所有脚本所以新连接不需要手动 source但刚执行 source 的那个旧连接的 cd 状态和新连接是独立的这两件事不要搞混。情况二systemd Service 文件里的ExecStart用了java命令但 systemd 启动服务时不会加载/etc/profile.d/导致 systemd 找不到 java。解决办法是在.service文件的[Service]区块里显式配置EnvironmentJAVA_HOME/opt/jdk/jdk-21和EnvironmentPATH/opt/jdk/jdk-21/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin或者在ExecStart里直接用 java 的绝对路径/opt/jdk/jdk-21/bin/java。情况三crontab 里的脚本用到了 java但 cron 环境同样不加载/etc/profile.d/——这正是第14篇讲到的 cron 环境变量陷阱在脚本开头source /etc/profile或者用绝对路径解决。理解环境变量对谁生效这个问题的本质是 Linux 运维中非常基础但容易长期混淆的知识点花时间搞清楚一次后续类似问题能举一反三。三、SDKMAN多版本 JDK 管理的最佳工具当你的服务器上同时运行着 JDK 17 的旧项目和 JDK 21 的新项目或者需要在本地开发机上频繁在不同 JDK 版本间切换SDKMAN是管理这种复杂场景的利器。# 安装 SDKMAN会修改 ~/.bashrc 或 ~/.zshrc安装后需要重开终端或 source curl -s https://get.sdkman.io | bash source $HOME/.sdkman/bin/sdkman-init.sh # 查看可用的 JDK 发行版列表很长筛选 Temurin 版本 sdk list java | grep tem # 安装指定版本以 Temurin JDK 21 为例 sdk install java 21.0.5-tem # 安装多个版本 sdk install java 17.0.13-tem # 切换当前 Shell 会话使用的 JDK 版本临时切换只影响当前终端窗口 sdk use java 17.0.13-tem # 设置全局默认 JDK 版本影响所有新开的终端 sdk default java 21.0.5-tem # 查看当前使用的 JDK 版本 sdk current java # 卸载某个版本 sdk uninstall java 17.0.13-temSDKMAN 的工作原理是把所有 JDK 版本统一安装在~/.sdkman/candidates/java/目录下通过修改当前 Shell 的PATH变量指向不同版本的bin目录来实现版本切换。这比手动维护多个JAVA_HOME配置文件优雅很多切换操作是即时生效且可逆的。 生产提示SDKMAN 主要面向开发者的本地环境对于生产服务器建议用第二种方式手动解压到/opt/jdk/目录并配置/etc/profile.d/jdk.sh更显式地管理 JDK 版本——生产服务器的 JDK 版本不应该频繁切换明确的目录结构和配置文件更便于运维审计和问题排查不依赖 SDKMAN 这样的第三方工具也能减少一个潜在的故障点。四、生产环境 JVM 启动参数每一行都有讲究用 systemd 或脚本启动 Spring Boot 应用时java -jar app.jar前面可以附加大量 JVM 参数来调整运行行为这些参数对应用的稳定性和性能有直接影响。4.1 内存相关参数# 堆内存配置最重要的两个参数 -Xms2g # 初始堆大小启动时就分配这么多 -Xmx2g # 最大堆大小堆不会超过这个值 # 生产实践-Xms 和 -Xmx 设成相同的值避免堆在运行期动态扩缩导致的停顿 # 具体数值通常设为服务器物理内存的 50-70%为操作系统和其他进程留出余量 # 元空间Metaspace配置JDK 8存放类元数据 -XX:MetaspaceSize256m # 初始元空间大小 -XX:MaxMetaspaceSize512m # 最大元空间大小如果不设理论上无限增长这里要理解为什么-Xms和-Xmx建议设成相同值。如果两者不同比如-Xms512m -Xmx2gJVM 初始只分配 512MB随着对象增多再向 OS 申请内存动态扩展到 2GB每次堆扩展都会触发一次 Full GC垃圾回收产生额外的 GC 停顿。对于服务器应用启动时就直接分配好-Xmx指定的内存量-Xms-Xmx可以完全避免这种因堆扩展触发的 GC代价只是启动时多占一些内存对服务器来说这个代价完全可以接受。4.2 GC垃圾回收器选择# G1GCJDK 9 默认的 GC在吞吐量和停顿时间之间取得良好平衡推荐绝大多数场景使用 -XX:UseG1GC -XX:MaxGCPauseMillis200 # 目标最大 GC 停顿时间G1 会尽力控制在这个范围内 # ZGCJDK 15 进入生产可用极低延迟停顿通常1ms适合对响应时间极敏感的场景 # 代价吞吐量略低于 G1内存开销略高 -XX:UseZGC # Parallel GC吞吐量优先适合批处理类应用 -XX:UseParallelGC对于 Java SaaS Web 应用G1GC 是首选——它在控制停顿时间避免因 GC 导致的请求超时和保持较高吞吐量之间取得了很好的平衡。如果你的应用对延迟极度敏感比如实时通信、金融交易且运行在 JDK 17 上可以考虑迁移到 ZGC。4.3 GC 日志与 OOM 转储排查问题的必备配置# GC 日志分析 GC 行为、排查内存问题的重要数据来源 -Xlog:gc*:file/var/log/myapp/gc.log:time,uptime,level,tags:filecount5,filesize20m # OOM 时自动生成堆转储文件JVM 即将因 OOM 崩溃前先把堆内存快照保存下来供后续分析 -XX:HeapDumpOnOutOfMemoryError -XX:HeapDumpPath/var/log/myapp/heapdump.hprof # OOM 后自动重启配合前面第08篇的 systemd Restarton-failure 使用 -XX:OnOutOfMemoryErrorkill -9 %p⚠️ 踩坑记录-XX:HeapDumpOnOutOfMemoryError这个参数经常因为可能影响性能而被生产环境的工程师关掉这是一个错误的做法。这个参数在正常运行期间的性能开销为零只有在真正发生 OOM 时才会触发堆转储操作——而此时不管你有没有这个参数OOM 本身已经让应用无法正常工作了生成一个堆转储文件的额外时间在这种极端情况下完全可以接受。关掉这个参数的代价是OOM 发生后你没有任何堆快照只能靠猜测来分析是什么导致了内存溢出而有了 heapdump.hprof 文件用 Eclipse Memory AnalyzerMAT几分钟内就能定位到是哪种对象在泄漏。这个参数永远应该开着特别是在生产环境。4.4 完整的生产环境 JVM 启动参数示例把上面各类参数整合成一份完整的生产级配置放入 systemd Service 文件# /etc/systemd/system/myapp.service[Service] 区块的关键配置 [Service] Typesimple Usermyapp Groupmyapp WorkingDirectory/opt/myapp/current ExecStart/opt/jdk/jdk-21/bin/java \ -server \ -Xms2g -Xmx2g \ -XX:MetaspaceSize256m \ -XX:MaxMetaspaceSize512m \ -XX:UseG1GC \ -XX:MaxGCPauseMillis200 \ -XX:HeapDumpOnOutOfMemoryError \ -XX:HeapDumpPath/var/log/myapp/heapdump.hprof \ -XX:OnOutOfMemoryErrorkill -9 %p \ -Xlog:gc*:file/var/log/myapp/gc.log:time,uptime:filecount5,filesize20m \ -Djava.security.egdfile:/dev/./urandom \ -Dspring.profiles.activeproduction \ -Dspring.config.location/opt/myapp/config/application-prod.yml \ -jar /opt/myapp/current/app.jar-Djava.security.egdfile:/dev/./urandom这个参数解决了 Java 应用在 Linux 上一个经典的启动慢问题——Java 的SecureRandom默认读取/dev/random生成随机数而/dev/random在熵池不足时会阻塞等待导致应用启动时卡几秒甚至更长。改用/dev/urandom注意路径里的./是特意为了绕过 JVM 内部对/dev/urandom路径的特殊判断逻辑不会阻塞是生产环境的标准做法对安全性几乎没有实质影响。五、JVM 版本与 Spring Boot 兼容性矩阵选错了 JDK 版本和 Spring Boot 版本的组合会遇到各种奇怪的兼容性报错Spring Boot 版本最低 JDK 要求推荐 JDK备注3.xJDK 17JDK 21Spring Boot 3 完全拥抱 Java 17 特性2.7.xJDK 8JDK 17最后一个 2.x 版本已停止维护2023年11月2.6.x 及以下JDK 8JDK 11/17已停止维护不推荐继续使用# 检查当前运行的 Spring Boot 应用使用的 JDK 版本在应用已启动的情况下 jps -v | grep app.jar # 列出 Java 进程及其启动参数 # 检查 JAR 包编译时使用的 JDK 版本通过 class 文件版本号推断 javap -verbose -classpath app.jar org.springframework.boot.SpringApplication | grep major version # major version: 61 对应 JDK 17 # major version: 65 对应 JDK 21 # 实战场景生产服务器收到报错 Unsupported class file major version 65 # 这意味着编译时用了 JDK 21但生产服务器上安装的是 JDK 17 或更低版本无法运行这个字节码 生产提示在 CI/CD 流水线里明确锁定编译用的 JDK 版本是避免在开发机用新 JDK 编译、部署到装了旧 JDK 的生产服务器这类问题的最直接手段。Maven 项目在pom.xml里通过maven.compiler.source和maven.compiler.target指定字节码版本或者更现代的方式是用.sdkmanrc文件SDKMAN 支持或.java-version文件jenv 支持在项目根目录锁定 JDK 版本让团队所有成员和 CI/CD 环境都用相同的 JDK 版本从源头消除版本不一致的隐患。六、常见 JVM 问题快速排查# 查看 JVM 的运行时参数确认 -Xmx 等参数是否真的生效 jps # 列出所有 Java 进程的 PID jinfo -flags PID # 显示该进程的所有 JVM 参数 # 查看 GC 频率和停顿时间简要统计 jstat -gcutil PID 2000 10 # 每2秒输出一次共10次 # jstat 输出关键字段解读 # S0C/S1CSurvivor 0/1 区容量(KB) # ECEden 区容量(KB) # OCOld 区容量(KB) # YGCYoung GC 发生次数 # YGCTYoung GC 累计耗时(秒) # FGCFull GC 发生次数这个数值持续增长是内存问题的重要信号 # FGCTFull GC 累计耗时(秒) # 获取线程堆栈排查 CPU 高、死锁等问题——结合第12篇的性能排查思路 jstack PID /tmp/threaddump_$(date %Y%m%d_%H%M%S).txt # 获取堆内存对象统计排查内存泄漏 jmap -histo PID | head -30七、常见问题解答FAQ❓ Q1java -version显示的版本和 JAVA_HOME 指向的不一致是什么原因java -version执行的是PATH里第一个找到的java命令这可能是通过 apt 安装在/usr/bin/java一个指向 alternatives 的符号链接也可能是你JAVA_HOME/bin/java取决于PATH里哪个路径排在前面。which java能告诉你当前实际执行的是哪个路径的 javaecho $JAVA_HOME告诉你环境变量指向哪里。如果两者不一致说明PATH配置有问题$JAVA_HOME/bin没有排在其他 java 安装路径前面检查/etc/profile.d/jdk.sh里PATH的拼接顺序$JAVA_HOME/bin:$PATH要保证 JAVA_HOME 在前。❓ Q2服务器内存是 8GB-Xmx 应该设置多少没有放之四海皆准的公式但常用的经验原则是-Xmx设为可用内存的 50%-70%为操作系统、其他进程如果同一台机器上还有 Nginx、MySQL以及 JVM 的非堆内存Metaspace、直接内存等预留空间。8GB 内存的单应用服务器-Xmx4g到-Xmx6g是合理区间具体值需要结合实际的堆使用率监控数据来调整先上线收集 GC 日志观察堆的实际峰值使用量在峰值的 1.5-2 倍设置-Xmx是比较稳健的策略。❓ Q3Full GC 频繁发生怎么排查用jstat -gcutil PID 2000持续观察如果FGCFull GC 次数和FGCTFull GC 总时间持续增长说明 Full GC 确实频繁。常见根因老年代Old Gen内存被慢慢填满——用jmap -histo:live PID | head -20看哪些类的对象数量最多结合应用日志判断是业务逻辑导致对象无法被回收内存泄漏还是单纯的-Xmx设置太小、老年代空间不足两者的解决方案完全不同。❓ Q4Spring Boot 应用启动时报 Could not reserve enough space for object heap是什么原因-Xmx设置的值超过了当前系统实际可用的内存JVM 无法申请到足够的连续内存空间来创建堆。解决方法一是降低-Xmx值二是检查系统实际可用内存free -h看available列三是检查是否有其他进程已经占用了大量内存四是检查是否配置了 swap 分区增加 swap 能缓解这个问题但不能从根本解决。❓ Q5开发机是 macOS/Windows生产服务器是 Linux有没有可能因为平台差异导致 JVM 行为不同有但很少见。最常遇到的平台差异① 文件路径分隔符/和\Java 的File.separator能屏蔽这个差异② 换行符\nvs\r\n涉及文本文件读写时需要显式指定字符编码和行结束符③ 时区JVM 默认读取操作系统时区开发机是北京时间、服务器是 UTC 时区时日期计算结果会不一样生产服务器应该通过 JVM 参数-Duser.timezoneAsia/Shanghai显式指定时区而不依赖操作系统配置。本篇小结与系列导航 核心结论JDK 选型推荐 Eclipse TemurinAdoptium版本优先选 LTS 版本当前为 JDK 21。环境变量配置的核心问题是对谁生效——/etc/profile.d/对交互式 Shell 生效systemd Service 需要在[Service]里显式声明Environmentcron 需要在脚本内source /etc/profile。生产 JVM 参数的要点-Xms-Xmx避免堆扩展 GC、选对 GCG1GC 通用、ZGC 低延迟、永远开启-XX:HeapDumpOnOutOfMemoryError、-Djava.security.egd解决启动阻塞。SDKMAN 适合开发机多版本管理生产服务器推荐手动解压/etc/profile.d/配置的显式方式。 参考资料Eclipse Temurin JDK 下载页SDKMAN 官方文档JVM 参数完整参考 - OracleG1GC 官方调优指南如果本文对你有帮助请点赞 收藏 ⭐ 支持一下欢迎在评论区留言交流。系列标签LinuxJDK安装JAVA_HOMEJVM调优GC参数Spring BootSDKMANJava运维
![[C++]内存管理：串顺序存储的内存回收](http://pic.xiahunao.cn/yaotu/[C++]内存管理：串顺序存储的内存回收)
