Red Hat OpenJDK JRE 14在Windows x86_64上的安装配置指南-开发者社区

简介：Java 14 的 OpenJDK JRE 14.0.1.7-1 版本 Windows Red Hat x86_64 运行时环境资源包，面向需要在 Windows 平台安装或离线部署 Java 14 运行环境的开发与运维人员。包体按 Red Hat 构建规范整理，包含 JRE 运行所需的核心动态链接库、可执行文件、策略文件、安全证书以及模块描述等，压缩包共 358 个文件，大小约 59.57MB，可满足无网络环境下的快速安装与多实例配置需求。包内还包含 63 份 additional_license_info 和 63 份 assembly_exception 许可文件，对于关注开源许可证合规的团队尤为实用。资源内附带 license、additional_license_info、assembly_exception 等许可与合规说明，便于企业用户核对使用条款；另有 md 文档与 properties、cfg 等配置文件，辅助了解构建信息与运行时参数。目前已有 620 人学习/下载，适合需要获取相应版本 JRE 用于测试、生产环境搭建或学习 Java 模块化运行时结构的读者。解压后目录层级清楚，可直接集成到现有应用或容器镜像中，作为本地构建与运行的基础环境。看到java-14-openjdk-jre-14.0.1.7-1.windows.redhat.x86_64.zip这个文件名，很多刚接触 Java 生态的同学可能一脸懵：这到底是给 Linux 用的还是给 Windows 用的？RedHat 的包怎么跑到 Windows 上了？实际上，这是 Red Hat 在 Windows x86_64 平台发布的 OpenJDK 运行时环境，里面封装了 JRE 14.0.1.7，专门给那些"只需要运行 Java 程序、不打算写代码"的环境准备。我自己在折腾服务器和本地环境时经常遇到这种命名复杂的安装包，踩过不少坑，这篇文章就把拆包、安装、配置、验证的完整过程讲清楚，顺便把热搜里那些高频问题（JRE 和 JVM 啥关系、环境变量怎么配、内存不足怎么办）一并解决掉。

1. 项目概述与环境理解

先把这个包的名头捋顺，再做任何安装动作之前，都得知道手里拿的是什么。

1.1 这个 JRE 安装包到底是什么

文件名拆开看是这样的：

java-14：Java 主版本号 14。
openjdk：来自 OpenJDK 社区构建，不是 Oracle 官方商业版。
jre：Java Runtime Environment，也就是 Java 运行时环境，只负责运行.class和.jar，不包含编译器javac。
14.0.1.7：特性版本 14.0.1，安全补丁级别 7。
windows.redhat.x86_64：平台是 Windows，架构是 x86_64（即 64 位），由 Red Hat 出品。

这个包的本质是：Red Hat 团队用 OpenJDK 源码，在 Windows x86_64 环境下构建出来的 JRE 运行时压缩包。解压之后就能直接用java命令，不需要安装器，也不需要管理员权限，特别适合内网部署和绿色化集成。

1.2 为什么需要单独装 JRE 而不是直接装 JDK

很多人上来就问：我直接装个 JDK 不就行了？JDK 里自带 JRE 啊。这句话放在几年前没错，但从 Java 9 开始，官方不再提供独立的 JRE 安装包，JDK 内部结构也改了，不再是一个 JDK 目录下嵌套一个 JRE 目录。但 OpenJDK 社区和 Red Hat 这类发行商会单独维护 JRE 构建产物，专门给生产环境用。

生产服务器的原则是最小化安装。你想想，如果一台只跑 Spring Boot 应用的服务器装了完整 JDK，等于多出了javac、javap、jdb、jmap这些开发调试工具，占磁盘不说，还扩大了攻击面。JRE 只保留类库、虚拟机、启动器这些运行必需的部分，体积更小、更安全。普通用户运行桌面 Java 程序，也只需要 JRE，装 JDK 反而多余。

所以这个包面向的场景很明确：Windows 服务器或桌面环境，只需要运行 Java 应用，不搞开发编译，那就用 JRE。

2. 核心概念拆解：JRE、JDK、JVM 的关系

在动手部署之前，把这三个概念彻底搞明白，后面排查问题会轻松一半。

2.1 三者的层级关系

用大白话说：

JVM（Java Virtual Machine）：Java 虚拟机，负责把字节码翻译成当前操作系统能识别的机器指令。它是 Java 跨平台的根本。
JRE（Java Runtime Environment）：JVM + Java 核心类库（rt.jar、java.lang、java.util等）+ 启动命令（java.exe）。它提供"运行 Java 程序"所需的一切。
JDK（Java Development Kit）：JRE + 开发工具（javac.exe、jar.exe、jdb.exe等）+ 各类调试诊断工具。它提供"开发 Java 程序"所需的一切。

关系就是套娃：JDK 包含 JRE，JRE 包含 JVM。热搜里那个"jre和jvm之间的关系"看这个就通了。

有个常被忽略的细节：JVM 本身不是一个独立安装的软件，它藏在 JRE 或 JDK 目录里。Windows 上 JRE 目录下会有bin\server\jvm.dll，这才是虚拟机的实体文件。java.exe启动时会去加载这个 DLL，如果没有它，程序根本跑不起来。

2.2 OpenJDK 与 Oracle JDK 的差异

Java 11 之后，Oracle JDK 和 OpenJDK 在功能上几乎没有差别，区别主要在发行方、许可证和支持策略：

对比项	Oracle JDK	OpenJDK
源码	基于 OpenJDK，含少量闭源组件	完全开源
许可证	Oracle 商业许可（付费）	GPL+CE，可免费商用
更新频率	长期支持版本提供长期更新	由社区和发行商维护
典型发行方	Oracle	Red Hat、Adoptium、Microsoft、Azul 等
最适合场景	企业合规采购	一般生产环境、云原生、容器

这个包是 Red Hat 构建的 OpenJDK JRE，意味着你可以免费下载、免费部署、自由分发。很多云厂商的 Java 镜像底层跑的就是这一类发行版。

2.3 版本号背后的含义

14.0.1.7这几个数字很多人搞不清。Java 14 是特性版本，2020 年 3 月发布，属于非 LTS（长期支持）版本。14.0.1是更新版本，修了不少 bug，7是构建编号。

这里给个实操建议：如果是新项目，建议直接上 LTS 版本（Java 8、11、17、21），不要选 14 这种短期特性版。但如果你手头有老系统、老应用锁定了 Java 14，或者课程资料、旧项目正好用这个版本，那这个包也能用，只是要知道它的生命周期早就结束了，别指望官方补丁。

3. Windows x86_64 落地部署流程

这部分是重头戏，照着做，十分钟内能跑起第一个 Java 程序。

3.1 环境准备与前提检查

开始之前，先确认三件事：

确认操作系统位数。这个包是 x86_64 即 64 位，如果你的 Windows 是 32 位系统，装了也启动不了。查看方式：设置 -> 系统 -> 关于，看"系统类型"一栏。
确认是否已有其他 Java 版本。在 CMD 里输入java -version，如果已经有 Java，要注意版本冲突，建议先卸载旧的或调整 PATH 顺序。
确认磁盘空间。JRE 解压后大约 180~230MB，预留 500MB 以上磁盘空间比较稳妥。

注意：下载 zip 包时要注意校验文件哈希。Red Hat 官方提供的包带有 SHA256 校验值，下载后用certutil -hashfile java-14-openjdk-jre-14.0.1.7-1.windows.redhat.x86_64.zip SHA256核对一下，防止下载损坏或被篡改。

3.2 解压安装与路径规划

这个 zip 包不需要运行安装向导，解压即用。但路径规划一定要做对。

推荐把 Java 运行时放统一目录，比如C:\Java\jre-14.0.1.7。解压的时候注意：

不要只解压 zip 里的子文件夹，要确保bin、lib、conf这些目录直接位于C:\Java\jre-14.0.1.7下。
解压后检查目录结构，如果看到C:\Java\jre-14.0.1.7\bin\java.exe存在，就说明结构对了。

为什么强调目录结构？因为后面配 JAVA_HOME 时，系统会认为$JAVA_HOME/bin/java.exe就是启动入口，一旦层级多了一层，所有命令都找不到。

解压完还能顺手压缩一份副本放到其他盘，以后重装系统直接解压又能用，这就是绿色软件的好处。

3.3 环境变量配置详解

在 Windows 上配 Java 环境变量，核心是三个变量：

JAVA_HOME

JAVA_HOME=C:\Java\jre-14.0.1.7

注意：这个变量值就是 JRE 根目录，不要写成C:\Java\jre-14.0.1.7\bin。很多新手在这里翻车。

PATH

在Path变量里新增一行：

%JAVA_HOME%\bin

放在所有已有 Java 相关路径之前，这样可以保证命令行执行java时优先使用当前版本。

CLASSPATH

JRE 单独运行时，一般不需要手动设置 CLASSPATH。Java 9 之后默认类路径是当前目录，再手动配CLASSPATH反而容易出怪问题。除非跑的是特别老的程序，否则保持留空。

配置完成后，重新打开 CMD 窗口，让环境变量生效。

3.4 验证安装是否成功

打开新的 CMD，依次执行：

java -version

正常输出：

openjdk version "14.0.1" 2020-04-14 OpenJDK Runtime Environment (build 14.0.1+7) OpenJDK 64-Bit Server VM (build 14.0.1+7, mixed mode, sharing)

看到这三行，说明虚拟机加载成功、版本正确、架构是 64 位。

再执行：

javac -version

此时应该提示找不到命令。这是正常的，因为 JRE 里没有编译器。如果你连javac都不需要，说明环境装对了；如果还需要开发编译，请换成 JDK。

最后跑一个最小测试程序验证运行能力。新建一个Test.java文件，内容：

public class Test { public static void main(String[] args) { System.out.println("JRE works on Windows x86_64!"); } }

不过这里有个关键点：你没有任何编译器，怎么把Test.java转成Test.class？

这是 JRE 和 JDK 分工的天然边界。你可以在开发机（装有 JDK）上编译好Test.class，然后把.class文件或打包好的.jar拷到这台只装了 JRE 的机器上，用java Test运行。这才是 JRE 的正确用法：只运行，不编译。

4. 常见问题与排查技巧实录

部署过程中最烦的不是安装本身，而是各种报错。我把高频问题整理成速查表，这里挑几个典型展开讲。

4.1 “cannot find a valid baseurl for repo: base/7/x86_64”

这个报错虽然经常出现在 Linux 的yum命令里，但它的本质是软件源不可达。如果你是在 Windows 上做 Java 开发，旁边一台 Linux 服务器配 Java 环境时遇到了这个错，多半是仓库地址失效或网络不通。

排查思路：

检查 DNS：ping mirror.centos.org通不通。
检查仓库配置：vi /etc/yum.repos.d/CentOS-Base.repo，把 baseurl 里的地址换成国内可访问的镜像源。
清理缓存重试：yum clean all && yum makecache。

跟 JRE 本体的关系：如果你是通过yum install java-14-openjdk来装 Java，源挂了会导致装不上。此时有两个选择，要么修好 yum 源，要么直接用我们这篇文章讲的 zip 包手动部署。后者不依赖任何系统包管理器，兼容性最好。

4.2 JRE 安装出现脚本错误

如果你用的是官方 exe 安装器或某些第三方安装脚本，Windows 上偶尔会弹"脚本错误"对话框。这个多半是安装程序在调用 WSH（Windows Script Host）或 PowerShell 执行自定义动作时被系统安全策略拦截了。

处理方法依次试：

右键安装包，选"以管理员身份运行"。
临时关闭杀毒软件或 Windows Defender 实时保护（装完再开）。
如果是 IE 安全级别拦截 ActiveX 导致的历史问题，升级到新版本 Java 基本不会出现，因为 Java 早就弃用了浏览器 Applet 插件。

热搜里那个 "applet 插件" 也顺带说一下：Java 在浏览器里的 Applet 插件已经被彻底淘汰，Java 9 以后的 JRE 不再支持浏览器插件。现在看到任何引导你装 Java 浏览器插件的页面，直接忽略，那是老古董。

另外，下载 exe 安装包时如果看到的是jre-8u202-windows-i586.exe这种老版本，要特别注意：i586 是 32 位版本，64 位系统虽然能装，但性能和内存上限都受限。能用 x86_64 构建就别用 i586。

4.3 java: OutOfMemoryError: insufficient memory

运行 Java 程序时如果报：

java.lang.OutOfMemoryError: insufficient memory

说明 JVM 启动时申请不到足够内存，要么系统剩余物理内存不够，要么 32 位 JVM 进程地址空间有限（约 1.5~2GB 上限）。

我们这个是 64 位 JRE，所以主要查物理内存和 JVM 参数：

打开任务管理器，看物理内存是否充足。
如果机器内存不大，可以调小堆内存：java -Xms256m -Xmx512m -jar app.jar。
检查是不是同时运行了太多 Java 进程，用tasklist | findstr java查看所有 Java 进程，把多余的杀掉。

注意：JRE 模式下，-Xmx参数依然有效，因为堆内存管理是 JVM 的事情，和有没有编译器无关。所以生产环境调优 Java 应用时，JRE 照样能接收所有 JVM 启动参数。

还有个典型的坑：Windows 下如果 PATH 里同时存在多个 Java，可能一个 64 位 JRE 和一个 32 位 JRE 交替使用，启动参数一模一样但内存上限差异巨大。用where java查看当前到底调用的哪个java.exe，把 32 位的从 PATH 里干掉。

4.4 Lombok 不工作：You aren't using a compiler supported by Lombok

热搜里那条 "you aren't using a compiler supported by lombok" 也值得聊聊。这虽然针对开发环境，但反映了一个常见现象：Java 版本和第三方库的兼容性问题。

Lombok 通过注解处理器操作编译器内部 API 来生成代码，新版本 JDK 一旦改了内部接口，老版本 Lombok 就罢工。如果你在 JDK 14 上开发，至少要用 Lombok 1.18.12 以上版本。如果只是运行用 JRE，那段报错一般不会出现，因为 JRE 不跑编译流程。

给个通用建议：开发环境用 JDK，生产环境运行用 JRE（或专用 runtime 镜像），两边版本必须一致或兼容。不要开发机装 Java 17、生产机装 Java 14，很多诡异 bug 就是这么来的。

4.5 常见问题速查表

现象	大概率原因	解决方案
`java`不是内部或外部命令	PATH 未配置	重新配置`%JAVA_HOME%\bin`
运行报版本 8 而不是 14	系统里存在旧版本	`where java`定位，调整 PATH 顺序
`javac`找不到	装的是 JRE	需要开发编译请换 JDK
中文乱码	控制台编码不一致	`java -Dfile.encoding=utf-8 -jar app.jar`
双击 jar 无反应	未关联 jar 文件	右键 -> 打开方式 -> 选择 java.exe
Windows 更新后 Java 不能跑	环境变量丢失	重新检查 JAVA_HOME 和 PATH

5. 实际操作中的避坑建议

最后压轴部分是我个人反复折腾 Java 环境积累下来的一些判断，不一定写在任何官方文档里，但很实用。

5.1 依赖系统包管理器不如"自带运行时"

如果你的 Windows 应用是要分发给很多用户的，最稳的做法不是让用户自己装 JRE（他们会装错、装不上、版本不对），而是把 JRE 目录整个塞进你的应用安装包，启动脚本里优先使用应用目录下的java.exe。

比如你的应用目录结构：

MyApp/ ├── app/ │ └── myapp.jar ├── runtime/ │ ├── bin/ │ │ └── java.exe │ └── ... └── start.bat

start.bat里写：

@echo off set JAVA_HOME=%~dp0runtime "%JAVA_HOME%\bin\java" -Xms256m -Xmx1024m -jar "%~dp0app\myapp.jar"

这样用户机器上有没有装 Java 都无所谓，应用自己带着运行时跑。我们这篇的 zip 包解压后完全符合"便携运行时"的要求。

5.2 不要为了"省事"修改系统目录

有些人喜欢把 JRE 解压到C:\Windows\System32或者C:\Program Files下的深层目录，以为这样系统能找到。这其实是给自己埋雷：

路径带空格会导致脚本解析问题。
系统目录会被杀毒软件重点监控，降低性能。
升级替换时容易改到系统文件权限。

最好的习惯是专门建一层干净的目录，比如C:\Java\，里面按版本分文件夹，jre-14、jdk-17、jre-21排列整齐。要切换版本时，改一下JAVA_HOME就完事了。

5.3 定期清理无用的 Java 版本

Java 家谱里版本非常多，很多人机器上装了 8、11、14、17 好多个 JDK/JRE，PATH 里各种路径交错，最终导致运行某个应用时版本不对，疯狂踩坑。

清理原则：

保留项目实际要求的版本，其余卸载。
生产环境只保留一个 JRE。
开发机可以保留 JDK 和 JRE 各一个，但 PATH 里同一时刻只留一个生效版本。

where java

这个命令会列出所有能看到的 java.exe 位置，结合起来逐个检查，把无效的路径从 PATH 里删干净。

5.4 关于小版本更新的执念

很多人盯着 14.0.1.7 这种小版本号不放，非要找到最新补丁不可。实际上对于非 LTS 版本，补丁多几个少几个对普通应用影响没那么大。真正重要的是：

大版本（比如 8 升级到 17）会带来 API 破坏，慎升。
同大版本内的小版本升级，风险极低，放心升。
安全敏感环境（金融、政务）必须跟紧安全公告，及时更新。

如果你是在内网离线环境部署，记得提前下载好 zip 包，放到本地文件服务器上，这样不管哪台机器都能快速复制部署，不用每次重新下载。

6. 写在最后的操作心得

说实话，我在实际使用中发现，真正困住大家的往往不是 Java 本身，而是版本命名和发行方选择。java-14-openjdk-jre-14.0.1.7-1.windows.redhat.x86_64.zip这个包看起来又长又绕，但只要你掌握了拆解方法——主版本、发行方、组件类型、平台架构——一眼就能判断它适不适合自己的场景。

部署过程本身没什么黑魔法，解压、配环境变量、验证，三步就能搞定。剩下那些所谓的"Java 环境问题"，十有八九是 PATH 顺序错了、版本混了、内存参数没调好。排查的时候别慌，按照where java->java -version->echo %JAVA_HOME%这条路子走，问题总能定位。

最后再分享一个小技巧：每次配完 Java 环境，顺手写一个check-java.bat放到桌面，内容就四行：

@echo off echo JAVA_HOME=%JAVA_HOME% where java java -version pause

以后遇到任何环境问题，先双击这个文件，三秒钟就知道当前环境到底用的哪个 Java，省去大量盲猜的时间。这招我用到现在，专治各种"我这没毛病啊"的玄学环境问题。

本文还有配套的精品资源，点击获取

Red Hat OpenJDK JRE 14在Windows x86_64上的安装配置指南