2024 年， graalvm native image 仍较为勉强

果然吃内存，一个简单的 Java 程序就占用了 250M 内存

看到这个帖之后，尝试了一下把手上一个小项目做个 natvie image ，在等待了 17 分钟之后以失败告终，错误码 137(out of memory)，比打传统 jar 包慢了几十倍。而同等规模的 Go 项目构建一次比打 jar 包还快的多。

• 编译资源消耗大，耗时非常久
• 额外的配置工作，涉及 jar 包内资源或者反射都要注意
• natvie image 可选 GC 少，并且降低了吞吐性能
• 距离生产环境成熟，缺乏足够数量的成功案例

Build resources: - 8.31GB of memory (54.2% of 15.33GB system memory, determined at start) - 4 thread(s) (100.0% of 4 available processor(s), determined at start) SLF4J(W): No SLF4J providers were found. SLF4J(W): Defaulting to no-operation (NOP) logger implementation SLF4J(W): See https://www.slf4j.org/codes.html#noProviders for further details. Found pending operations, continuing analysis. [2/8] Performing analysis... [******] (188.0s @ 4.52GB) 48,632 reachable types (92.1% of 52,814 total) 78,016 reachable fields (64.2% of 121,484 total) 258,776 reachable methods (60.6% of 427,364 total) 14,060 types, 916 fields, and 13,355 methods registered for reflection 67 types, 67 fields, and 59 methods registered for JNI access 4 native libraries: dl, pthread, rt, z [3/8] Building universe... (31.3s @ 5.15GB) [4/8] Parsing methods... [*******] (57.7s @ 4.01GB) [5/8] Inlining methods... [****] (8.6s @ 3.48GB) [6/8] Compiling methods... [*************************] (662.1s @ 5.38GB) 

JVM 生态在云原生领域被 Go 绝对性压制的局面，十年八年之内大概不会有任何改变了。