这是一个创建于 897 天前的主题，其中的信息可能已经有所发展或是发生改变。
OP 从去年开始关注 GraalVM 的发展，前天开始想把我之前写的一些小应用转为可执行的二进制文件，原因当然是服务器的内存不够用。
实测在 MacOS 系统上普通 SpringBoot 程序大约占用内存 200MB ，转为可执行文件后内存占用大约 30MB 。
现在最大的问题是，GraalVM + image-native 这一套东西不支持跨端编译！也就是在 Mac 系统上编译出来的程序无法 Linux 上直接运行。op 曾考虑过将代码转移到 Linux 服务器上进行编译，结果因为许多依赖问题，一直报错，前前后后折腾了两三天也没能想到好方法。
实测在 MacOS 系统上普通 SpringBoot 程序大约占用内存 200MB ，转为可执行文件后内存占用大约 30MB 。
现在最大的问题是，GraalVM + image-native 这一套东西不支持跨端编译！也就是在 Mac 系统上编译出来的程序无法 Linux 上直接运行。op 曾考虑过将代码转移到 Linux 服务器上进行编译，结果因为许多依赖问题，一直报错，前前后后折腾了两三天也没能想到好方法。
35 条回复 2025-09-04 11:53:27 +08:00
 | 1 Akitora 2023-04-30 10:17:46 +08:00 via Android |
 | 2 oldshensheep 2023-04-30 10:24:28 +08:00 用 GitHub Action 编译。我这个简单的 Web 程序就是用 GitHub action 编译的，可以参考一下。编译了三端 Linux ，Mac ，Windows ，https://github.com/oldshensheep/place 或者把报错贴出来，我也不知道你说的依赖问题是什么。 |
 | 3 ljhrot 2023-04-30 10:24:51 +08:00 via Android graalvm 编译占用太多内存这个问题一直存在，加上不支持交叉编译，所以我在多余的硬盘上装了 Linux 用来编译，相当于得配一套跟部署环境一致的机器专门来编译 Linux 安装 graalvm 应该还好吧，你直接把报错信息发出来让大伙瞧瞧 我之前是想在一个新项目尝尝鲜，结果第三方依赖的静态资源太多，搞不动就放弃了，感觉生态还有很长的路要走 |
 | 4 gakaki 2023-04-30 10:33:11 +08:00 https://github.com/gakaki/spring_template 我写了一个也是 github action 的 |
| 5 gakaki 2023-04-30 10:35:29 +08:00 基于 docker 编译 注意编译一次要 3 到 5 分钟要 github action 自己本机还算了吧 这题最麻烦的还是 se 运维， 遇到麻烦的 se 可能给你打回不让你用， 还必须用 jdk17 以上 |
 | 6 ThinkStu OP |
 | 7 julyclyde 2023-04-30 11:18:33 +08:00 那个 /root/.jdks/graalvm-ce-17/bin/java 文件存在吗？能运行吗？ |
| 8 oldshensheep 2023-04-30 11:39:01 +08:00 maven 添加个-X 参数，看看 full debug logging |
| 9 ThinkStu OP |
| 11 ThinkStu OP 源码其实就是一个很小的测试案例，已经上传至 GitHub： https://github.com/Bistutu/hello_graalvm |
 | 12 swhhaa 2023-04-30 14:36:56 +08:00 GraalVM 自己玩还行，不知道有没有用于生产环境的... |
 | 13 lff0305 2023-04-30 15:23:41 +08:00 via Android 试试在 graal home 的 bin 里运行 ./gu list 看看有没有装好了 native image |
| 15 oldshensheep 2023-04-30 16:18:32 +08:00  1 你的代码我用 Linux 编译了可以正常编译运行（ ARM ，Ubuntu ） Failed to spawn exec helper 有没有试过下面的方法，Google 的 chmod +x $JAVA_HOME/lib/jspawnhelper |
| 16 ljhrot 2023-04-30 16:53:39 +08:00 |
| 17 ThinkStu OP @oldshensheep #15 我切换到 arm 架构的虚拟机，也能正常编译了，不过为什么 Intel 还是没有成功，暂时不知道原因 |
| 20 ThinkStu OP 感谢大家的帮助！此贴终结。经过测试，原因已经找到：可能是因为利用 orbStack 创建出来的 Intel 虚拟机存在问题，导致一直无法正常编译（因为我是 MacOS 系统，M1 pro 芯片 ）。 |
| 21 ThinkStu OP 我刚才使用了 3 种不同情境的虚拟机，编译结果如下（本机 MacOS 系统，M1 pro 芯片）： 1 、orbStack 模拟 arm 虚拟机：编译通过，正常生成可执行文件。 2 、orbStack 模拟 Intel 虚拟机：编译失败，未知报错。 3 、阿里云 Intel 服务器：编译通过，正常生成可执行文件。 |
| 22 gakaki 2023-04-30 19:36:17 +08:00 实际上最后还是要用 ci 系统来编译的 也就是 docker 编译 而本地用 arm 自己的即可 |
 | 23 awolf 2023-04-30 22:41:21 +08:00 springboot 也能减少内存？奇迹 |
 | 24 wdwwtzy 2023-04-30 23:15:27 +08:00 1 |
| 25 ThinkStu OP @awolf 原本编译 jar 包，现在编译成可执行文件，也不需要 JVM 的参与了，内存使用率自然下降（不过编译出来的程序性能也会下降一点） |
 | 27 flyqie 2023-05-01 00:58:42 +08:00 via Android |
 | 28 cheng6563 2023-05-01 09:09:17 +08:00 1 用 openj9 jvm 啊 |
 | 29 yazinnnn 2023-05-01 10:37:06 +08:00 aot 也需要 jvm |
 | 30 Huelse 2023-05-01 13:33:17 +08:00 至今没成功编译 static image ，有些解决方案藏在他们的 issue 里很难找。 |
| 31 ThinkStu OP 2 @Huelse 写了一篇博客《 GraalVM 编译 SpringBoot 程序》，希望对你有所帮助~： https://blog.csdn.net/qq_35760825/article/details/130459747?spm=1001.2014.3001.5501 |
| 32 ThinkStu OP @cheng6563 谢了老哥，我也试了下，openj9 平均降低了运行内存 20%~50%~ 对于个人开发者来说，的确是个不错的方案 |
 | 33 coderstory 2023-05-30 12:53:49 +08:00 openj9 对于某项项目 会导致启动很慢 我已经弃用了 |
 | 34 byte10 2023-06-08 12:08:37 +08:00 我的那个 alist-encrypt 用的是 nodejs ，先用 ncc 整合编译单个文件，然后用 pgk 进行打包可执行文件。后来又研究了一下 wasm ，挺不错的东西，但是也有很多局限，也不能很好的打包编译。看来还是 go 牛逼点。 |
 | 35 CodeCodeStudy 39 天前 @yazinnnn #29 aot 不用 jvm ，需要 jvm 那是因为原生编译不成功，fallback 了的 |
Select Language