简介面向需要在Linux下快速搭建Java运行环境的开发者与运维入门者这份PDF文档以VMware Workstation 17为虚拟化平台选用免费开源的CentOS 7.9系统逐步演示从虚拟机创建、ISO镜像安装、root与普通用户设置到系统基础优化的完整过程。内容围绕主流的JDK 1.8、Tomcat 8.5与MySQL 8.0组合详细讲解JDK解压与环境变量配置JAVA_HOME、PATH、CLASSPATH、Tomcat部署与CATALINA_HOME设置、MySQL 8.0编译安装及my.cnf参数调优同时覆盖Xshell、Xftp、ZenTermLite等远程连接工具的使用技巧并针对外网服务器密码强度、日常账号权限给出安全建议帮助读者从零完成Java Web运行环境的落地。资源为单个PDF文件大小26.44MB共1个文档适合边看边操作或作为课后复习手册。目前已有384人学习下载文档结构清晰包含虚拟机创建、系统安装、软件配置及性能优化等完整流程可显著降低初学者在Linux下搭建环境的踩坑成本。1. Linux 上装 Java 运行环境难点不在「装」而在「选」多数人第一次在 Linux 上装 Java以为跑一条apt install default-jdk就收工。实际到了线上才发现安装命令三分钟真正花掉一下午的是三件事确定装哪个 JDK 分发版、用哪种方式装、如何让环境变量和 JVM 参数经得起生产流量考验。这个标题里值得展开的恰恰是「安装」后半段被忽略的「优化」二字。本文面向两类人刚接手 Linux 服务器部署的运维以及准备在开发机上搭建多 JDK 并行环境的 Java 工程师。按「版本选型 → 安装落地 → 环境变量 → JVM 参数 → 验证排错」的顺序把一套可复现的完整路径讲清楚。2. JDK 选型与三种安装方式对比包管理器 / tar.gz / 多版本共存2.1 先确认 CPU 架构和发行版再决定下载哪个 JDK 包安装前第一件事不是复制命令而是确认目标机器的架构。JDK 的二进制包按x86_64、aarch64ARM64区分下载错了直接报Exec format error。用下面两条命令确认uname -m cat /etc/os-releaseuname -m输出x86_64就选 x64 版本输出aarch64就选 ARM64 版本。/etc/os-release里的ID字段能看出是基于 Debianapt还是 RHELyum/dnf的发行版。国产桌面系统里常见的麒麟、统信 UOS 虽然名字不同但多数基于 Debian 系或 RHEL 系封装下面命令基本能用只是仓库名称略有差异。2.2 版本选型优先盯 LTS而非最新版Java 的版本策略已经变成「每半年一个小版本每两年一个 LTS」。生产环境选型时LTS 仍是唯一稳妥的选择。当前主流梯队是 Java 8、11、17、21。Java 8 占存量老系统17 是近年新项目的主力21 适合新起盘且团队愿意跟随虚拟线程特性的场景。除此之外还要选 JDK 分发版。常见选择是 OpenJDK 官方构建、Eclipse Temurin原 AdoptOpenJDK、Liberica JDK 和 Amazon Corretto。它们都基于 OpenJDK 源码差异主要在授权、更新节奏和内置组件如 JavaFX上。多数服务器场景下Temurin 或发行版自带的 OpenJDK 足够用不必追求某一个「最权威」的商标。# Debian/Ubuntu 系 sudo apt update apt-cache search openjdk-17 | grep -E jdk|jreapt-cache search的用途是在安装前先看仓库里有哪些包可供选择避免装出一个没带javac的 JRE。搜索结果的包名如果以-jre结尾只有运行环境以-jdk结尾才带编译器。对应到 RHEL/CentOS 系命令换成yum list available java-17*。2.3 包管理器安装适合对版本没执念的场景包管理器安装的最大优势是自动处理依赖、提供 systemd 级别的集成。Debian/Ubuntu 上安装 JDK 17 的无头版本命令如下sudo apt install -y openjdk-17-jdk-headless-headless后缀表示不包含图形相关组件服务器场景完全够用还少一堆依赖本地要跑 Swing/JavaFX 图形程序则用openjdk-17-jdk。安装完后java -version验证但要注意包管理器装的 JDK 不一定会设置JAVA_HOME环境变量这一步需要单独补齐。另外default-jdk这个包是指向发行版默认版本的软链包不同发行版的「默认」五花八门有时是 11有时是 17在脚本里直接用default-jdk会让部署环境在不同的 Linux 版本上行为不一致。这也是我在生产环境更倾向手动安装的原因。2.4 手动 tar.gz 安装版本由你说了算手动安装其实不复杂核心是三步下载、解压、放置到固定路径。以 Temurin 17 为例把下载到的 tar.gz 包放入/opt下解压sudo mkdir -p /opt/jdk sudo tar -xzf temurin-17-jdk_x64_linux_hotspot.tar.gz -C /opt/jdk sudo mv /opt/jdk/jdk-17.0.127 /opt/jdk/jdk-17解压后文件夹名通常带完整版本号和构建号建议改成一个干净且固定的软链名jdk-17后续升级时只需替换指向。放置路径选/opt/jdk是为了和/usr/lib/jvm区分开后者是发行版包管理器默认扫描路径手动解压的包放进去容易被update-alternatives误认。最终目录里确认有bin/java和lib两个关键存在即可。2.5 多版本共存用软链接管理默认 JDK一台机器上装多个 JDK 是常态老服务卡在 Java 8新服务用 Java 17两边互不影响。/opt/jdk下的结构可以是这样/opt/jdk/jdk-8 /opt/jdk/jdk-17 /opt/jdk/default-jdk - jdk-17切换全局默认版本时只需要重指软链接sudo ln -sfn /opt/jdk/jdk-8 /opt/jdk/default-jdkln -sfn三个参数的含义很明确-s建立软链接-f若目标已存在则强制覆盖-n避免在目录里嵌套创建同名软链接。这个方案对老部署脚本最友好因为很多脚本里写死了/opt/jdk/default-jdk/bin/java这类固定路径改变量不如换软链接来得无痛。安装方式依赖处理版本可控性升级成本适用场景包管理器自动一般取决于发行版仓库低个人开发机、对版本无强要求的环境tar.gz 手动安装无高中换链接即可生产服务器、需要锁版本的环境容器镜像内无高随镜像重建CI/CD 和 K8s 场景表格之外还有一条实践结论容器场景不要手动进容器装 JDK直接选官方镜像或独立 JDK 基础镜像更可靠。标题既然说的是「Linux 下」重点范围放在物理机/虚拟机层面容器里的路径按镜像思维走不混在一起讲。3. 配置 JAVA_HOME 与 PATH让系统认准你要的那个 JDK3.1 为什么不能只改~/.bashrc装完 JDK 后最容易出现的状态是直接改~/.bashrc尾部塞两行 export 就完事。这在个人开发机上勉强能用但放到生产环境有几个隐患非交互式 shell 不读~/.bashrccron 任务和 systemd 服务拿不到环境变量多人共用的机器上每个账号都要各自配一遍后续有人手动改了系统路径排查时谁都不知道当前实际生效的是哪个文件。常见做法是在/etc/profile.d/下单独建一个 JDK 环境变量脚本sudo vim /etc/profile.d/java.sh写入以下内容export JAVA_HOME/opt/jdk/default-jdk export PATH$JAVA_HOME/bin:$PATH/etc/profile.d/下的.sh文件在用户登录时会被/etc/profile自动 source所有用户统一生效。把JAVA_HOME/bin放在PATH最前面是为了覆盖可能已被包管理器写入/usr/bin/java的旧版命令确保你敲java时优先命中刚配置的 JDK。保存后执行source /etc/profile再验证echo $JAVA_HOME which java java -version如果which java仍指向/usr/bin/java说明系统里原有 JDK 的优先级更高需要继续看下面的update-alternatives。3.2 用update-alternatives管理系统级java命令Debian 系发行版自带update-alternatives机制专门处理这类「多个程序提供同名命令」的冲突。安装手动 JDK 后把新 JDK 注册到系统备选列表里sudo update-alternatives --install /usr/bin/java java /opt/jdk/jdk-17/bin/java 200 sudo update-alternatives --install /usr/bin/javac javac /opt/jdk/jdk-17/bin/javac 200最后一个数字200是优先级数字越大优先级越高。注册完可以随时切换sudo update-alternatives --config java这条命令会列出所有已注册的 JDK 路径输入编号即可切换。查看当前生效项用update-alternatives --list java或--display java。需要说明的是这个机制只管理/usr/bin/下的命令链接并不改写JAVA_HOME环境变量所以在java -version正确之后还要确认JAVA_HOME指向的路径与update-alternatives里的当前项一致避免出现「命令是新的环境变量指向旧的」这种割裂状态。3.3 多项目环境变量相互干扰的两个坑实际部署中环境变量出问题往往不在配置那一刻而在后续叠加配置时。第一个坑是 Python 或其它工具链的安装脚本把自己目录插入PATH时没有做前缀判断把原有路径挤到后面java命令静默失效。第二个坑是有人为了图省事在/etc/environment里也写了一份JAVA_HOME和/etc/profile.d/java.sh里的值冲突导致通过 SSH 登录与通过图形界面登录拿到两套不同环境。排查时用env | grep -E JAVA|PATH看最终结果再用bash -x -c source /etc/profile; java -version跟踪到底哪一步改了变量。验证软链接实际指向的命令值得单独记下来readlink -f $(which java)readlink -f会把软链接逐层解析到真实文件的绝对路径配合ls -l /opt/jdk/default-jdk能看到当前默认版本是谁。4. 面向生产环境的 JVM 参数优化堆、GC、日志与容器适配4.1 先记住一个原则没有万能参数只有压测校验过的参数标题里的「优化」两个字最容易被理解成「找一组网上流传的配置抄上去」。这种思路的危害在于JVM 参数是个高度耦合的系统-Xmx调大可能让 GC 暂停时间恶化调小又引发频繁 Full GC每个参数都在和其他参数做博弈。正确起点是明确你的服务特性并发高不高、请求峰值是不是瞬时、有没有大对象、对响应时间敏感还是对吞吐量敏感。下面给的是通用基线落地必须配合压测微调。4.2 生产环境 JVM 参数基线与逐项解释先给一组可直接用于 Spring Boot 服务启动的参数java -Xms4g -Xmx4g \ -XX:MaxMetaspaceSize512m \ -XX:UseG1GC \ -XX:MaxGCPauseMillis200 \ -Xlog:gc*:file/var/log/app/gc.log:time,uptime,level,tags:filecount5,filesize20m \ -jar app.jar逐个拆解-Xms4g -Xmx4g堆初始大小和堆最大值相等。相等的好处是避免 JVM 在运行期动态扩缩堆带来的停顿生产上建议保持相等。数值本身由服务负载决定4g 艺是一个中间值不是通用答案。-XX:MaxMetaspaceSize512m限制元空间上限防止框架大量生成动态类时元空间失控。默认情况下 Metaspace 只受本机内存限制不设上限就等于埋雷。-XX:UseG1GCJDK 11 之后的默认收集器就是 G1显式写出是为了在启动脚本里表明意图。G1 适合多核大堆场景能把 GC 停顿控制在可配置范围内。-XX:MaxGCPauseMillis200G1 的目标停顿时间注意是「目标」而非「保证」JVM 会尽力向这个值靠拢但遇到内存吃紧时保吞吐优先。-XlogJDK 11 的 GC 日志统一语法。gc*表示记录所有 GC 级别日志filecount5,filesize20m做 5 个文件轮转避免日志无限增长把磁盘写满。如果还是 JDK 8GC 日志参数要换成两段式-XX:PrintGCDetails -XX:PrintGCDateStamps -Xloggc:/var/log/app/gc.log -XX:UseGCLogFileRotation -XX:NumberOfGCLogFiles5 -XX:GCLogFileSize20mJDK 8 的Xloggc和 JDK 11 的Xlog语法不兼容升级 JDK 时修改启动脚本是一个高频问题提前注意可以少踩一次坑。4.3 内存只有 1G 的机器怎么调小内存机器1G 或 2G跑 Java 服务参数思路完全不同java -Xmx512m -Xms512m \ -XX:MaxMetaspaceSize128m \ -XX:UseSerialGC \ -jar app.jar-XX:UseSerialGC是单线程 GC吞吐不如 G1但它的优点是内存占用极小、暂停时间反而可预测。堆只有 512m 时G1 的多线程并行机制反而是一种负担SerialGC 更合适。此场景下更要管住依赖限流框架、指标采集组件这类库也会堆叠内存占用JVM 参数调得再好也抵不过依赖把堆塞满。4.4 容器场景内存参数不能照搬物理机容器跑 Java 有个经典坑JDK 8u191 以前的版本不识别 cgroup 的内存限制Runtime.getRuntime().maxMemory()拿到的是宿主机内存-Xmx设大了直接导致容器被 OOM Killer 杀掉。JDK 8u191 和 JDK 10 默认开启UseContainerSupport能识别 cgroup 限制。在容器里更推荐用相对值而非固定-Xmxjava -XX:MaxRAMPercentage75.0 -XX:InitialRAMPercentage75.0 -jar app.jarMaxRAMPercentage75.0表示 JVM 最大堆为容器可用内存的 75%要给堆外内存、线程栈、Metaspace 预留空间。物理机上直接用百分比不如绝对值精确但在弹性伸缩的 K8s 场景里这组参数能保证一次镜像在不同规格的 Pod 上都能正确适配内存。固定-Xmx一旦 Pod 配额调整就得重新改镜像极端不灵活。4.5 面向响应时间敏感的调参表参数作用适用场景-XX:UseG1GC分代回收暂停可控多核、堆 4G、低延迟要求-XX:UseShenandoahGC并发回收暂停极短大堆、要求极低停顿JDK 15-XX:UseZGC可扩展低延迟收集器TB 级堆、微服务网关JDK 15-XX:UseStringDeduplication堆内重复字符串去重大堆里字符串对象占比高-XX:MaxGCPauseMillisG1 目标暂停时间对 P99 延迟敏感的服务-XX:AlwaysPreTouch启动时物理内存预占防止运行期缺页中断影响响应AlwaysPreTouch值得多说一句开启后 JVM 启动阶段就把堆内存全部锁定为物理内存启动会变慢但运行期不会因为内存页未分配产生额外的缺页暂停。对启动时间敏感的服务要慎用对运行期极致稳定有要求的可以打开。参数调完之后不要马上下线保留一套带-Xlog的启动参数跑至少一天的完整业务周期次日用 GC 日志里的实际停顿和堆占用反推参数是否合理而不是凭感觉修改。5. 安装后的验证清单与常见排错技巧5.1 五分钟完成安装结果核验部署脚本跑完后不要只看java -version就拍板。用下面这段命令做一次系统级核验java -version javac -version # 只要 JDK 不要 JRE echo $JAVA_HOME which java readlink -f $(which java)如果echo $JAVA_HOME输出为空但java -version正常说明系统里还有一份通过包管理器安装的 JDK 在兜底当前 shell 根本没加载/etc/profile.d/java.sh。检查是否登录时会话没加载手动执行source /etc/profile后再看。readlink -f的输出若指向/opt/jdk/default-jdk/bin/java说明环境变量和软链接策略生效整个切换链路是通顺的。5.2 开发机上需要但老是被漏掉的一步纯运行线上的服务器不需要javac但开发机上如果装了 JREjps、jstack、jcmd这些 JDK 自带诊断工具都不存在。手动安装 JDK 后确认/opt/jdk/jdk-17/bin下能看到jcmd和jmap两个文件。这两个工具是排查生产问题必备缺失时检查是否下载的是 JRE-only 包。5.3 三个高频启动失败场景场景一启动时报Could not reserve enough space for 2097152KB object heap。堆内存设置大于可用物理内存或者容器里-Xmx设得比 cgroup 限制还大。用free -h看物理内存容器里先看/sys/fs/cgroup/memory.max再向下调整-Xmx。场景二UnsupportedClassVersionError。编译时 JDK 版本高于运行版本典型现象是本地用 JDK 21 编译服务器上是 JDK 11。这个报错说明升级服务器 JDK 跑的是新包也可以为旧 JDK 单独保留编译产物两者选其一。场景三环境变量配了但 Java 进程实际跑了另一个版本。systemd 服务不会读/etc/profile.d/下的脚本所以 systemd 启动的 Java 服务必须在 service 文件里显式写EnvironmentJAVA_HOME/opt/jdk/jdk-17。排查时用cat /proc/pid/environ | tr \0 \n | grep JAVA_HOME看进程实际拿到的值不要只看登录 shell 里的结果。5.4 一个更精细的验证技巧用 jcmd 确认 JVM 实际参数java -version显示的是启动器版本不等于运行的 JVM 真的吃到了你设置的参数。找一个正在运行的 Java 进程执行jcmd pid VM.version jcmd pid VM.command_lineVM.command_line输出的是 JVM 实际生效的完整启动参数包括你没有显式设置但由 JVM 默认补充的参数。若发现-Xmx和你配置的不一致多半是启动脚本里存在两处 java 命令入口一处改了另一处没改。用这个命令做最后一层兜底核验比肉眼读启动脚本可靠得多。最后记住安装只是手段让 Java 服务在目标 Linux 上稳定跑满一个完整业务周期才是这套流程的终点。本文还有配套的精品资源点击获取