简介GraalVM JDK 17 Windows x64 二进制发行包面向需要在 Windows 平台上进行 Java 高性能运行与多语言开发的开发者尤其适合关注 Native Image 提前编译、希望缩短启动时间与降低内存占用的中高级 Java 工程师。资源共 586 个文件压缩包约 305.58MB整体为解压即用的绿色目录dll、lib、exe 构成运行时与 native-image 工具链的二进制核心jmod、jar 承载 JDK 17 标准模块与类库properties、cmd、cfg 等提供组件管理与启动配置copyright、license、md 则收录各模块许可与说明文档结构层次与官方发行版一致便于按需定位。目前已有 506 人学习下载可作为验证密封类、记录类、开关表达式、instanceof 模式匹配与文本块等 JDK 17 新特性的本地实验环境也能用于对照 gu 工具安装多语言运行时、构建本地可执行程序时的目录与参数整理适合想系统上手 GraalVM 技术栈的读者留存备用。1. 第一次在 Windows 上装 GraalVM JDK 17压缩包解压完不等于装好了上周帮一位开发者看机器他把 graalvm-jdk-17-windows-x64-bin 解压到 D 盘环境变量也改了敲java -version出来的却还是机器上那个老 1.8。翻来覆去折腾到下午才发现 PATH 里另一条 java 路径排在了前面——新装的这套压根没被调用过。类似的 java windows 环境问题我见得太多了GraalVM JDK 17 的 bin 包是免安装的压缩包没有安装向导、不写注册表、不弹完成提示装没装好全靠三样东西撑着——解压路径、JAVA_HOME、PATH。它适合两类人一类是想把 Java 代码直接打成单个 exe、摆脱目标机器装 JRE 的另一类是本机要同时放好几个 JDK、需要随时切版本又不想重装的。这套东西配错的时候往往一声不响界面不崩、命令不报错只在你要跑 native-image 的那天突然摊手。所以第一步不是急着解压而是先把这台机器的 java windows 环境算清楚。2. 下载与解压windows-x64-bin 这个包该落在哪个目录拿到文件先别双击。名字里的windows-x64-bin已经把关键信息写全了Windows 平台、x64 架构、bin 形式的压缩包不是 installer。这三个词任何一项理解错后面都会白忙。2.1 三种发布形态先分清别下错包同一版本的 GraalVM JDK 17 在分发时通常有几种形态落到实际使用上差别不小包形态特征适合的场景需要注意windows-x64-binzip解压即用不写注册表多版本并存、整目录拷贝迁移、不想动系统环境变量要手工配exe / msi 安装包有向导可选写 PATH单版本、只求省事升级时容易和旧目录互相纠缠容器镜像 / 压缩包带运行时自带运行环境服务端统一交付体积大开发机上手不灵活我一般优先选 bin 包理由很实在卸载就是删目录不会留下“明明删了但 where java 还指着一个不存在的路径”这种烂摊子换机器时把整个目录打包拷过去改两行变量就能跑团队里几个人机器配置不一致时bin 包最容易对齐。代价就是环境变量得自己动手而这恰恰是最容易翻车的一段。还有一个版本差异必须提前说清楚早期 22.3 及更早的发行版里native-image要用gu install native-image单独装bin目录下还能看到gu.cmd到 JDK 17 这批新版本23.1 之后gu已经被移除native-image直接随包提供。所以你在网上翻到“先 gu install 再 native-image”的老教程时别照抄先看自己包里有没有native-image.cmd有就不用装。2.2 解压路径四个不能出现的字符路径这件事听起来像玄学实际是有硬原因的。native-image 编译过程中会调用 C 编译器去拉一长串命令行参数路径里带空格、中文、括号、感叹号时引号转义和编码转换极易出岔子报错还往往指向别处。我的固定规则不含空格C:\Program Files这类目录直接排除不含中文和全角字符桌面、下载、文档这些中文名的系统目录一律不用层级别太深D:\dev\graalvm-jdk-17这种就刚好避免撞上 Windows 的长路径限制不要把bin直接铺到D:\dev底下——解压时确认压缩包里的顶层目录一起解出来。解压完成后先别动环境变量用绝对路径先把包本身验一遍# 直接调用绝对路径绕开 PATH 干扰先确认这份包是完好的 Get-ChildItem -Path D:\dev\graalvm-jdk-17 -Name D:\dev\graalvm-jdk-17\bin\java.exe -version第一行列出根目录内容正常应该能看到bin、conf、include、jmods、legal、lib、release这几项。第二行输出的版本串里只要带上了 GraalVM 字样说明包没问题接下来所有问题都只可能出在环境变量上——这一步把排查范围从“整台机器”缩到了“两个变量”值不值得做一次装过的人都知道。2.3 目录结构的三处自查bin目录下有java.exe、javac.exe、native-image.cmd三个关键文件缺任何一个都要停下来。特别注意native-image在 Windows 上是.cmd批处理而不是.exe用where native-image找不到.exe是正常的别以为装漏了。根目录下还有个release文本文件用记事本打开能看到JAVA_VERSION17.0.x和GRAALVM_VERSION一类的键值。团队协作时我习惯把这两个值记下来因为同一个项目里两个人装了小版本不同的 JDK 17编出来的 native 包一个能跑一个崩这种事真发生过。3. 环境变量配置JAVA_HOME 与 PATH 的三处写法解压只是把文件放好了真正让系统认这套 Java 的是两个变量。这一段写细一点因为九成的“装了没生效”都出在这里。3.1 JAVA_HOME 到底指到哪一层答案只有一个指到包含 bin 的那一层根目录也就是D:\dev\graalvm-jdk-17。三种常见错法指到...\graalvm-jdk-17\bin—— 于是 PATH 里拼出来变成...\bin\bin\java.exe命令直接找不到指到...\graalvm-jdk-17\jmods—— 看着像 JDK 的内部目录其实只是模块包值里带了引号或尾部反斜杠 —— 部分工具拼接路径时会出现D:\dev\\bin这种双斜杠个别编译器不认。另外提一句旧文档里的GRAALVM_HOME。在基于 JDK 8 的老版本里跑 native-image 前必须额外设GRAALVM_HOME到 JDK 17 这批版本JAVA_HOME一个就够了GRAALVM_HOME属于历史遗留。照着老教程两个都设也不是不行但要保证两个值指向同一个根目录不然以后切换版本时只改了一个又是半天排查。设变量有两条路我倾向 PowerShell 命令好处是可复制、可写进脚本、不会点错层级# 只写用户级变量不动系统级避免影响同一台机器上的其他账号 [Environment]::SetEnvironmentVariable(JAVA_HOME, D:\dev\graalvm-jdk-17, User) # 先读旧 PATH 再拼绝不直接覆盖 $oldPath [Environment]::GetEnvironmentVariable(Path, User) if ($oldPath -notlike *%JAVA_HOME%\bin*) { [Environment]::SetEnvironmentVariable(Path, %JAVA_HOME%\bin;$oldPath, User) }逻辑上分三步写JAVA_HOME用绝对路径、不加引号、不加尾部斜杠读旧Path是为了在原值基础上追加直接set一个新值会把编辑器、包管理器写进去的路径全冲掉写入前做一次包含判断重复执行脚本也不会把同一条路径堆上十几遍。参数上唯一要斟酌的是作用域User写当前用户Machine写系统级。系统级需要管理员权限且会影响这台机器上所有账号开发机自己用用户级足够出问题也好回退。3.2 PATH 顺序与多 JDK 共存时怎么切Windows 查找可执行文件是从 PATH 前往后扫第一个命中的赢。所以“我明明设了新 JAVA_HOME”和“java -version 还是老的”可以同时成立——因为 PATH 里另一条老的 java 路径排在前面。这就是开篇那一幕的真正原因。多版本共存时我通常这么排PATH 最前面留一条指向“当前默认版本”的%JAVA_HOME%\bin其余版本的路径一概不写进 PATH。想临时切到另一个版本只在当前窗口里改关掉就恢复:: 只在当前命令行窗口内生效不影响系统和别的窗口 set JAVA_HOMED:\dev\graalvm-jdk-17 set PATH%JAVA_HOME%\bin;%PATH% java -version这三行的作用是给当前会话打一个临时补丁%PATH%放在后面表示原有路径全部保留。做构建验证、复现别人报的 bug 时非常好用尤其是机器上同时装了 8、11、17 三个版本的情况比反复去改环境变量安全得多。需要长期固定的场景就把默认版本那条放在 PATH 最前。别贪方便把四五个 JDK 的 bin 全塞进 PATH那种配置当下能跑三个月后自己都说不清是哪条生效。3.3 一条命令确认变量真的生效改完变量必须新开一个窗口。已经开着的 PowerShell、cmd、IDE 都持有旧的环境副本不会自己刷新——这一条每年都要重复解释很多次。# 新窗口执行三行分别确认变量值、命中顺序、实际版本 echo $env:JAVA_HOME where.exe java java -versionwhere.exe是关键的一行注意要带.exe后缀否则在 PowerShell 里会撞上Where-Object别名。它会按 PATH 顺序列出所有命中的 java第一条就是你实际在用的。如果第一条不是D:\dev\graalvm-jdk-17\bin\java.exe说明顺序没排对回去调 PATH而不是怀疑包坏了。java -version的输出里第二行通常带运行环境名称和 build 号。想进一步确认 java.home 究竟落在哪用java -XshowSettings:properties -version 21 | Select-String java.home-XshowSettings:properties会打印全部系统属性配合Select-String过滤只留java.home一行21是因为这些信息走的是标准错误流不重定向会漏掉。4. native-image 编译链路从 cmd 到第一个 exe环境变量通了java和javac能跑只说明 JDK 部分装好了。GraalVM 真正区别于普通 JDK 的地方是 native-image它需要一条完整的 C 编译链路。4.1 先确认 native-image 在不在包里:: 在普通的 cmd 窗口里跑确认命令能被解析到 native-image --version正常输出会是一行版本信息包含native-image字样、JDK 版本号和 build 号。如果提示“不是内部或外部命令”先dir D:\dev\graalvm-jdk-17\bin\native-image.*看一眼文件在不在。文件在但命令找不到是 PATH 问题文件本身不在说明下的是普通 JDK不是 GraalVM 发行版——这种情况重下比修更省时间。还有一种情况命令能跑但报Please specify the location of the JDK一类的话多半是JAVA_HOME又被别的安装程序改回去了。看一眼echo %JAVA_HOME%很多时候是装了别的开发工具顺手动过。4.2 装 C 生成工具与 Windows SDKnative-image 在 Windows 上最终是把中间产物交给 C 编译器链接成 exe所以机器上必须有 C 生成工具和 Windows SDK。安装时勾选“使用 C 的桌面开发”这一个工作负载右边详情里确认 C 生成工具和 Windows 10/11 SDK 都被选上其余可以不要整个装下来也要几个 G磁盘留够。版本上有个门槛需要留意JDK 17 这条线的 native-image 对编译器版本有要求太老的编译器会被直接拒绝报错文本里会明确写出它期望的版本区间。看到这类报错不要硬扛按提示把生成工具升上去就行。装完先验证编译器可见性:: 必须在 x64 Native Tools 命令行里执行普通 cmd 找不到 cl where cl where link4.3 用 x64 Native Tools 命令行跑通第一次编译这是最容易漏的一步native-image 需要cl.exe、link.exe以及INCLUDE、LIB这几个环境变量而这些只有“x64 Native Tools 命令提示符”启动时才会自动配好。在普通 cmd 里直接跑 native-image就会得到“找不到编译器”的报错。不想每次去找快捷方式可以在普通窗口里手动调一次初始化脚本:: 路径按本机实际安装位置调整作用是注入编译器和 SDK 的环境变量 call C:\BuildTools\VC\Auxiliary\Build\vcvars64.bat where cl准备一个最小用例// HelloNative.java刻意不依赖任何三方库先把链路跑通再谈业务 public class HelloNative { public static void main(String[] args) { System.out.println(native image ok, java.version System.getProperty(java.version)); } }javac HelloNative.java native-image -cp . HelloNative --no-fallback -o hello-native -J-Xmx4g hello-native.exe参数逐个说清楚-cp .把当前目录作为类路径编译出的 class 在这里HelloNative是要编译的主类名不带.class后缀--no-fallback让编译失败时直接报错退出而不是悄悄退回“需要 JVM 才能跑”的降级镜像——这个开关在调试阶段几乎必加否则你会在目标机器上才发现它根本没编成原生程序-o hello-native指定输出名Windows 下会自动补.exe-J-Xmx4g是传给执行编译的那个 JVM 的堆参数-J前缀表示“这一项是给 JVM 的不是给 native-image 的”。第一次编译慢是正常的几十秒到几分钟都可能中途 CPU 和内存占用会拉满。编译成功的标志是输出目录下出现一个几 MB 到几十 MB 的 exe双击或命令行运行能直接打印结果且这台机器上没有装 JRE 也能跑——这才是验收标准。5. 避坑与排查装 GraalVM JDK 17 最常翻车的几个点以下都是我自己或者旁边人真实撞过的按“现象 → 原因 → 解决”记遇到时可以直接对号入座。5.1 环境变量类改了没生效、被悄悄截断现象一改完变量java -version还是老版本。原因当前窗口持有旧环境副本或者 PATH 里旧 java 排在前面。解决新开窗口重试用where.exe java看命中顺序把%JAVA_HOME%\bin提到最前。现象二用setx PATH %PATH%;...之后原本能用的命令集体失灵。原因setx会对值做长度截断老机器上 PATH 一长就会把尾部条目砍掉。解决别用setx改 PATH改用第 3 章里那种“先读旧值再追加”的写法已经截断的去图形界面的环境变量编辑框里对照备份修回来。现象三JAVA_HOME看着是对的native-image 却报目录无效。原因值里带了引号、尾部反斜杠或者指向了bin层。解决重设为纯根目录路径用echo %JAVA_HOME%肉眼确认没有多余字符。5.2 编译类找不到编译器、内存不够、路径带中文现象四native-image报找不到 C 编译器提示需要生成工具。原因没装 C 工作负载或者在普通 cmd 里跑而不是 Native Tools 命令行。解决补装工作负载每次编译前call vcvars64.bat或直接用专用命令行窗口。现象五编译到一半报内存不足或者整机卡死。原因native-image 的编译阶段内存消耗远高于普通 javac机器同时开着 IDE 和浏览器就撑不住。解决加-J-Xmx6g之类的堆上限按物理内存给别超过一半编译时关掉不必要的大内存程序机械硬盘上编译会更慢尽量放 SSD。现象六报“找不到路径”但路径明明存在。原因路径里带中文、空格或特殊符号编译命令行在转义时出了错。解决把整个 GraalVM 目录挪到纯英文短路径下重新设JAVA_HOME重建工程。5.3 运行类exe 起来了但行为不对现象七编出来的 exe 双击一闪就退或者读不到配置文件。原因native image 在编译期就把类路径扫描完了运行时才去读的资源文件默认不会被打进去。解决用-H:IncludeResources.*\.(properties|xml|json)$显式声明要打包的资源或者生成资源配置文件后随构建一起带上。这类问题在日志里往往只留一句空指针属于典型的排错黑匣子建议一开始就把资源清单写进构建脚本。现象八编译特别慢或者 exe 被杀毒软件直接删掉。原因编译阶段频繁调用链接器、大量生成临时文件实时扫描会全程拦。解决给 GraalVM 目录和工程输出目录加实时扫描排除项编译完再恢复。6. 装完怎么验证三条命令和一张对照表装完不要只看“能敲出 java -version”就收工那只能证明 JDK 部分通了。我习惯一次跑完三条命令把三层都验一遍# 第一层确认实际调用的是哪一份而不是系统里残留的老版本 where.exe java java -version # 第二层确认 native-image 可用且版本与 JDK 主版本对得上 native-image --version # 第三层一个最小可运行产物验证编译器链路真的闭环 javac HelloNative.java native-image -cp . HelloNative --no-fallback -o hello-native .\hello-native.exe对照着看结果判断标准比想象中具体检查项期望结果不符合时的第一排查点where.exe java第一条指向...\graalvm-jdk-17\bin\java.exePATH 顺序java -version17.x且带 GraalVM 标识包是否下错、JAVA_HOME 层级native-image --version版本号与 JDK 主版本一致bin 目录下是否有 native-image.cmd编译过程全程无“找不到编译器”报错是否在 Native Tools 命令行exe 运行输出正常不依赖本机 JRE--no-fallback是否加上补一个我很推荐的小习惯把这几条写成check-graalvm.ps1放在工程根目录换机器、升级、别人接手时先跑一遍。脚本里就三件事——读JAVA_HOME、比对java -version里的主版本号、试着调一次native-image --version任何一项不符就打印提示退出。看起来是多此一举但它能在五分钟内把“到底是包的问题还是变量的问题”分清楚比在群里来回问强得多。还有个容易忽略的收尾动作机器上如果原本装着别的 JDK别急着卸载。先用这套 GraalVM JDK 17 把手上项目完整构建一遍包括单元测试和一次 native 打包确认没有因为 JDK 内部模块差异踩到反射、动态代理这类在原生镜像里受限的写法再决定要不要清掉旧版本。曾经有台机器就是为了省事直接卸了旧 JDK结果一个依赖老版本内部 API 的构建脚本当场罢工回滚比装回去还费时间。从那以后我每次装完新 JDK都会留一周的并行期期间两个版本都留着构建脚本里显式写死用哪个等 CI 和本地都稳定了再动手清理。这套流程麻烦是麻烦了点但省下的是那种“线上才发现编出来的包行为不一样”的后悔药。希望帮到你。本文还有配套的精品资源点击获取
