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 绝对性压制的局面，十年八年之内大概不会有任何改变了。