果然吃内存,一个简单的 Java 程序就占用了 250M 内存
看到这个帖之后,尝试了一下把手上一个小项目做个 natvie image ,在等待了 17 分钟之后以失败告终,错误码 137(out of memory),比打传统 jar 包慢了几十倍。而同等规模的 Go 项目,构建一次比打 jar 包还快的多。
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 绝对性压制的局面,十年八年之内大概不会有任何改变了。
1
CodeCodeStudy 54 天前
历史包袱太重,新的小项目玩玩还可以
|
![]() |
2
karottc 53 天前
用 quarkus 可以好一些: https://www.v2ex.com/t/1057699
|
![]() |
3
sagaxu OP |
4
wssy001 53 天前
|
5
wssy001 53 天前
以 Hotspot 为例,生产环境的主流 GC 要么 G1 要么 ZGC 但一般都选 G1 ,G1 适用场景更多。目前只有大对象大缓存应用才用 ZGC, ZGC 针对大对象分配比其他 GC 都合理并减少了性能损耗
按照 spring 团队的说法,native image 下峰值性能能达到 JIT 的 9?%(有点忘了 90%还是 95%),可以借助 PGO 进一步提升性能 (顺带说一下,Oracle GraalVM 免费了) |