这是一个创建于 571 天前的主题，其中的信息可能已经有所发展或是发生改变。
OP 从去年开始关注 GraalVM 的发展，前天开始想把我之前写的一些小应用转为可执行的二进制文件，原因当然是服务器的内存不够用。
实测在 MacOS 系统上普通 SpringBoot 程序大约占用内存 200MB ，转为可执行文件后内存占用大约 30MB 。
现在最大的问题是，GraalVM + image-native 这一套东西不支持跨端编译！也就是在 Mac 系统上编译出来的程序无法再 Linux 上直接运行。op 曾考虑过将代码转移到 Linux 服务器上进行编译，结果因为许多依赖问题，一直报错，前前后后折腾了两三天也没能想到好方法。🥲
实测在 MacOS 系统上普通 SpringBoot 程序大约占用内存 200MB ，转为可执行文件后内存占用大约 30MB 。
现在最大的问题是，GraalVM + image-native 这一套东西不支持跨端编译！也就是在 Mac 系统上编译出来的程序无法再 Linux 上直接运行。op 曾考虑过将代码转移到 Linux 服务器上进行编译，结果因为许多依赖问题，一直报错，前前后后折腾了两三天也没能想到好方法。🥲
34 条回复 • 2023-06-08 12:08:37 +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 牛逼点。
|
Select Language