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