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

wssy001

2024-07-16 15:24:27 +08:00

以 Hotspot 为例，生产环境的主流 GC 要么 G1 要么 ZGC 但一般都选 G1 ，G1 适用场景更多。目前只有大对象大缓存应用才用 ZGC, ZGC 针对大对象分配比其他 GC 都合理并减少了性能损耗
按照 spring 团队的说法，native image 下峰值性能能达到 JIT 的 9?%（有点忘了 90%还是 95%），可以借助 PGO 进一步提升性能
（顺带说一下，Oracle GraalVM 免费了）