简介从JDK11中提取并精简的JRE11运行时压缩包专为服务器部署、云主机和容器镜像等磁盘空间受限场景设计避免安装完整JDK所需约279MB的体积开销。解压后的JRE11约占158MB该zip资源包为56.27MB便于下载、传输与批量分发目录结构清晰适合作为基础运行环境直接集成到生产镜像。资源共350个文件以dll动态链接库、exe可执行组件、license/copyright授权文本、md说明文档、policy安全策略、properties配置及根证书库等为主涵盖Java运行所需的核心模块、安全认证、时区数据、加密策略、类加载配置和授权信息解压后即可作为完整运行时使用。已有4215人学习下载适合服务器资源敏感、需离线部署或制作精简JRE镜像的Java应用运维与后端开发人员可省去自行裁剪JDK的繁琐步骤直接获得一套稳定可用的运行环境。1. jre-11.0.10.zip 到底是什么先搞清你手上这个包一个名字叫 jre-11.0.10.zip 的压缩包多半不是从官网安装向导里拿到的更大可能来自内网镜像、同事分享或者某个离线部署包的一部分。它解决的问题很具体服务器不能联网或者你不想装完整 JDK但又必须把一个用 Java 11 编译的服务跑起来。JRE 只负责运行不负责编译zip 版意味着没有安装向导、不写注册表、不捆绑额外服务解压出来就能用。这篇文章把这条链路讲完整——怎么解压、怎么配环境变量、项目怎么认它、哪几个地方最容易踩坑适合部署运维和刚接手老项目的同学对照着手。2. 从解压到 java -version 跑通JRE 11 离线安装的完整路径2.1 先确认系统里有没有 Java命令与版本判断任何一次 JRE 部署之前我建议先花 10 秒确认目标机器上是不是已经有 Java。常见的情况是你以为没装其实系统里藏着一个旧 JDK或者你以为装的是 11但 PATH 里排前面的还是 1.8。这两种情况后面都会引出很难排查的问题早点确认能省一个下午。Windows 上打开 cmd执行java -version有输出且能看到版本号说明 PATH 里已经有 Java没有任何输出说明可以直接往下走。这里有个很多人不知道的细节java 的版本信息是打印到标准错误流的在脚本里做版本判断时要写成java -version 21否则用重定向抓输出会抓到空内容。Linux 上同样先执行再多加一步java -version 21 which -a java 2/dev/null第二个命令会列出 PATH 里所有能匹配到的 java 可执行文件。如果列出来多个路径说明机器上装过多套 JDK/JRE后面 3.2 会讲这为什么是隐患。注意这里要判断的不是「有没有 java 命令」而是「java 实际指向哪个版本」。有人装过 JDK 后又装 OpenJDKjava -version 显示的往往是 PATH 靠前的那一个并不代表系统里没有另外的版本。2.2 Windows 解压和配置三步完成避开 setx 的截断坑拿到 jre-11.0.10.zip 之后先建一个干净的目录别直接解压到 C 盘根目录也别放到带空格或中文的路径下。Windows 上我一般的做法是mkdir D:\tools cd D:\tools tar -xf D:\downloads\jre-11.0.10.zipWindows 10 及之后的系统自带 tar 命令可以解压 zip不需要额外装解压工具。解压后进目录看一眼结构dir D:\tools\jre-11.0.10正常情况下应该直接看到 bin、lib、conf、legal 这几个目录以及 release 文件。如果看到的是一个嵌套的 jre-11.0.10 目录说明压缩包里多包了一层JAVA_HOME 要指向真正有 bin 的那一层。接着设置环境变量。这里要提醒一个坑不要用 setx 去改 Path。setx 有个很老的问题——变量值超过 1024 个字符会被直接截断很多人在给 Path 追加 Java 路径时把整个系统 Path 覆盖掉导致一堆命令失效我早期就因为这个翻过车。推荐用 PowerShell 的方式写用户级变量[Environment]::SetEnvironmentVariable(JAVA_HOME, D:\tools\jre-11.0.10, User) [Environment]::SetEnvironmentVariable(Path, [Environment]::GetEnvironmentVariable(Path, User) ;D:\tools\jre-11.0.10\bin, User)第一句把 JAVA_HOME 写到当前用户的变量表第二句在用户 Path 末尾追加 bin 目录不碰系统级 Path。新开的 cmd 里执行java -version即可验证。注意 PowerShell 里设置的变量对已打开的终端不生效所有验证命令都要在新开的窗口里跑这是新手最容易忽略的一点。2.3 Linux 服务器部署目录规划与软链接习惯Linux 服务器上部署 JRE重点不是「怎么装」而是「目录放哪、以后怎么换版本」。很多人的做法是解压到 /opt 下然后直接改 /etc/profile但我不推荐直接改 /etc/profile因为一台机器将来可能部署多个 Java 相关组件写死在 profile 里后面切换版本非常痛苦。我一般按这个顺序操作mkdir -p /opt/jre unzip jre-11.0.10.zip -d /opt/jre ln -s /opt/jre/jre-11.0.10 /opt/java11先解压到 /opt/jre 下再做一个不带版本号的软链接 /opt/java11 指向当前要用的版本。以后升级版本时只需要解压新版然后把软链接换一个指向所有依赖 JAVA_HOME 的项目都不用改配置。这个软链接就是管理 Java 版本的主入口。环境变量放在独立的 profile 片段里排查和卸载都清晰cat /etc/profile.d/java11.sh EOF export JAVA_HOME/opt/java11 export PATH$JAVA_HOME/bin:$PATH EOF source /etc/profile.d/java11.sh上面这段用 here-doc 生成一个 java11.sh系统登录时自动加载。JAVA_HOME 指向软链接而不是真实目录是为了将来升级不用改这个文件。PATH 里把 $JAVA_HOME/bin 放在最前面确保 java 命令优先使用这个 JRE而不是系统自带的旧版本。如果你想先确认临时生效情况也可以只执行 export 那两行不写文件等确认没问题再固化。3. JAVA_HOME 与 PATH 配置项目真正认识这个 JRE 的关键3.1 JAVA_HOME 到底该指向哪一层bin 的上一级不是 bin 本身JAVA_HOME 是一个约定变量Tomcat、Gradle、Maven、Jenkins 的启动脚本都靠它定位 Java。它的值必须是一个「包含 bin 和 lib 的目录根」而不是 bin 目录本身。指向错误是这一类问题里最高频的把 JAVA_HOME 写成 D:\tools\jre-11.0.10\bin启动 Tomcat 时报错找不到 java或者报「通过 JAVA_HOME 定位失败」。为什么必须指到根目录因为很多框架不直接调用 java 命令而是基于 JAVA_HOME 自己拼路径比如 $JAVA_HOME/bin/java、%JAVA_HOME%\bin\java.exe。你把 JAVA_HOME 指到 bin它拼出来的路径就变成 bin/bin/java自然执行不了。验证 JAVA_HOME 是否指对最简单的方法是直接在这个目录下调用一次完整路径的 javaWindows%JAVA_HOME%\bin\java.exe -versionLinux$JAVA_HOME/bin/java -version如果命令能正常输出版本那 JAVA_HOME 的指向没问题。注意这里用双引号包住完整路径因为 Windows 路径可能包含 Program Files 这类带空格的目录。zip 版 JRE 一般装在自建目录下没有空格但如果你的解压路径确实带空格启动脚本里 99% 的场景都要给 JAVA_HOME 加引号。3.2 PATH 顺序决定真正执行的 javawhere java 与 which -aJAVA_HOME 配对了项目仍然可能跑错版本原因出在 PATH。java 这个命令是个「多版本切换器」它在 PATH 里从上往下找第一个可用的 java找到了就用后面的不会再检查。一台机器上同时装了 JDK 8 和这个 JRE 11如果 PATH 里 JDK 8 的 bin 排在前面你执行 java -version 看到的永远是 1.8即使 JAVA_HOME 写的是 11。很多部署脚本里写的是java -jar app.jar不是 $JAVA_HOME/bin/java -jar app.jar所以它走的是 PATH 而不是 JAVA_HOME这个黑匣子最容易骗人。排查方式Windowswhere javaLinuxwhich -a java两条命令都能列出所有存在 java 命令的路径按 PATH 顺序从上到下排列第一行就是实际执行的那一个。想彻底摆脱 PATH 带来的玄学问题我建议启动脚本里不要再用裸 java而是用 $JAVA_HOME/bin/java这样版本由脚本显式控制不依赖环境变量配置的当前状态。3.3 启动脚本显式指定 JRETomcat、Jenkins 与自定义服务部署层面最常见的场景是把 zip 版 JRE 放到生产服务器后让 Tomcat 或其他 Java 应用用这个版本启动。Tomcat 的启动脚本 catalina.sh / catalina.bat 会自动读取 JAVA_HOME所以只要 3.1 里验证过 $JAVA_HOME/bin/java 能跑Tomcat 基本不用改额外配置。对于自定义 Java 服务我一般在启动脚本开头写死 JRE 路径#!/usr/bin/env bash export JAVA_HOME/opt/java11 export PATH$JAVA_HOME/bin:$PATH exec $JAVA_HOME/bin/java -Xms512m -Xmx1g -jar /data/app/app.jarXms512m 表示堆内存初始值 512MBXmx1g 表示最大堆内存 1GB。这两个参数是生产环境 Java 服务最基本的设置不写的话 JVM 会按机器内存比例自动推算很多服务启动后被系统杀进程就是因为不限制最大值导致堆内存无上限增长。脚本里写死 JAVA_HOME 路径避免不同机器上目录名不一致的问题。Jenkins 这类以 war 包形式分发的应用同理启动前 export JAVA_HOME然后用完整路径java -jar jenkins.war比依赖系统 PATH 可靠得多。如果项目是用 systemd 管理的注意在 service 文件里用 Environment 指令设置 JAVA_HOME否则手动 export 的环境变量在 systemd 的隔离环境里是看不到的。4. jre-11.0.10 避坑指南解压版 JRE 的 5 个必踩坑4.1 坑一拿到 JRE 就找 javac编译和运行傻傻分不清现象有人把 JRE 11 装好兴冲冲地敲 javac结果提示不是内部或外部命令或者 command not found于是怀疑包坏了。原因JRE 全称是 Java Runtime Environment只负责运行不带编译器。javac、jar、javap 这些开发工具都只在 JDK 里才有。解决编译环境用 JDK运行环境用 JRE。如果这台机器既要编译又要运行直接装 JDK 别纠结 JRE——JDK 本身也能运行 Java 程序不会比 JRE 差。部署服务器上只放 JRE 是合理的但前提是你已经用别的地方编译好了 jar 或 class 文件。4.2 坑二zip 版不写注册表某些图形安装器识别不到 Java现象命令行 java -version 正常输出但一个基于 Java 的 Windows 桌面工具安装时提示系统未安装 Java或者装完无法启动。原因官方 exe 版 JRE 安装时会把安装路径写入注册表zip 免安装版跳过所有安装逻辑不写注册表。依赖注册表检测 Java 的旧软件自然找不到。解决命令行层面用 where java 确认可用对检测不到的工具要么在工具配置里手动指定 JRE 路径要么改用官方 exe 包装一次。不要指望 zip 版 JRE 能和正常系统级 Java 安装完全等价。4.3 坑三解压后 JAVA_HOME 指错层java -version 直接崩溃现象设置好 JAVA_HOME 后打开新终端执行%JAVA_HOME%\bin\java -version报错说找不到指定路径或提示 Error opening ZIP archive。原因有些打包源把 zip 做成双层目录比如解压后出现 D:\tools\jre-11.0.10\jre-11.0.10\bin你按单层路径配 JAVA_HOME自然指向了没有 bin 的目录另外有的包在压缩时丢了权限位Linux 上解压后 bin/java 没有执行权限也会报类似错误。解决解压后第一件事是 ls -l 看 bin 目录里 java 的权限位没有 x 权限就chmod x bin/java然后找到真正同时包含 bin、lib、conf 的目录再写进 JAVA_HOME。这个检查 10 秒钟能省掉后面一小时的排错。4.4 坑四路径带空格或中文引号缺失导致启动失败现象环境变量明明配了Tomcat 却报 Cannot find .\bin\catalina.bat或者找不到可执行文件。原因解压路径里带空格比如 D:\Program Files\jre-11.0.10而启动脚本调用 $JAVA_HOME/bin/java 时没有给变量加引号路径被拆成两段后指向了错误的位置。中文路径在 Windows 下还可能引发编码问题启动脚本里的日志输出乱码都算轻的。解决解压路径尽量用短路径、纯英文、无空格。如果已经放在带空格的目录把 JAVA_HOME 写成带引号的完整形式并在启动脚本里统一对变量加引号调用。这条在 Windows 上尤其容易踩因为 Program Files 是默认目录习惯但没有引号习惯的人一抓一把。4.5 坑五JRE 11 没有 rt.jar拿 JDK 8 的经验找包必然迷失现象有人把 JRE 8 时代的经验带过来在 jre-11.0.10\lib 目录下想找 rt.jar、tools.jar翻遍整个目录都找不到怀疑包不完整。原因Java 9 之后 JRE 完全模块化类库以模块镜像形式存在 lib 目录rt.jar、tools.jar 这些旧文件已经被移除。JRE 11 的 lib 目录下你会看到的是模块相关文件不是单个 jar。解决不要拿 JRE 8 的文件清单来核对 JRE 11。检查目录完整性时认 bin、lib、conf、legal、release 这些新结构。如果项目里硬编码引用了 rt.jar 路径说明项目本身的兼容性问题跟 JRE 版本没有关系这种情况换成 JDK 也没用。5. 多版本共存与替换技巧把 JRE 11 用得更稳多版本共存是生产机器的常态不会只装一个 Java。Linux 上我习惯用 update-alternatives 管理命令级版本update-alternatives --install /usr/bin/java java /opt/java11/bin/java 1100 update-alternatives --config java再配合第 2.3 节的软链接方案一个控制 java 命令的默认版本一个控制 JAVA_HOME 的默认路径两者各司其职切换时不用动任何项目的配置文件。验证一个 JRE 是不是真的没配错我强烈推荐这条命令java -XshowSettings:properties -version 21 | grep java.homejava.home 会直接打印当前 JVM 实际使用的安装根目录。它比 java -version 诚实得多——版本号可能被 PATH 里的其他命令干扰但 java.home 是 JVM 根据自身加载路径确定的值骗不了人。我有一次在生产服务器上花了一个下午排查「java -version 显示 11项目却跑在 8 上」的问题最后就是靠这一条命令发现启动脚本里 export 的路径被下一行脚本覆盖java.home 直接打脸定位到了旧 JDK。那之后我养成两个习惯一是启动脚本里所有 java 调用都写绝对路径二是每次切换完版本先跑一遍 java.home 验证确认实际生效的目录和预期一致再部署项目。JRE 版本换代同理拿到新包、解压、改软链接、跑 java.home 验证四步走完再上线环境层面基本不会出问题。希望帮到你。本文还有配套的精品资源点击获取
