果然吃内存,一个简单的 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 绝对性压制的局面,十年八年之内大概不会有任何改变了。