实验 1 、直接原生 java -jar 跑
我 win10 占内存 36m ，同事的 mac(arm 架构)只有 19m ，win10 简单加几个参数能压到 20 多 m
java -Xmx5m -Xms1m -XX:MaxMetaspaceSize=1m -XX:+UseSerialGC -XX:CompressedClassSpaceSize=1m -Xss512k -Xint -jar nativedemo-1.0-SNAPSHOT.jar
然后拉一下内存使用情况：
Memory used total max usage GC
heap 22M 252M 3986M 0.57% gc.g1_young_generation.count 2
g1_eden_space 4M 62M -1 6.45% gc.g1_young_generation.time(ms) 14
g1_old_gen 12M 184M 3986M 0.32% gc.g1_concurrent_gc.count 0
g1_survivor_space 6M 6M -1 100.00% gc.g1_concurrent_gc.time(ms) 0
nonheap 28M 31M -1 90.20% gc.g1_old_generation.count 0
codeheap_'non-nmethods' 1M 2M 5M 26.09% gc.g1_old_generation.time(ms) 0
metaspace 19M 20M -1 98.64%
codeheap_'profiled_nmethods' 3M 3M 117M 3.27%
compressed_class_space 2M 2M 1024M 0.22%
codeheap_'non-profiled_nmethods' 838K 2496K 120028K 0.70%
mapped 0K 0K - 0.00%
direct 4M 4M - 100.00%
mapped - 'non-volatile memory' 0K 0K - 0.00%

我拿 arthas 拉的，arthas 注入进来后内存有膨胀了一些，你看占用大头都在 metaspace 、codeheap 以及 old_gen 上，这 hello world 又没 new 啥对象，old_gen 肯定是一些 static 的对象了，这就说明了这些内存是基本消耗，不会随着你的应用增长。

实验 2 、native 打包
<build>
<plugins>
<plugin>
<groupId>org.graalvm.buildtools</groupId>
<artifactId>native-maven-plugin</artifactId>
<version>${native.maven.plugin.version}</version>
<executions>
<execution>
<goals>
<goal>native-image</goal>
</goals>
</execution>
</executions>
<configuration>
<mainClass>${mainClass}</mainClass>
</configuration>
</plugin>
</plugins>
</build>

这个打完在 x64 的 kali 下运行只占 8m ，在 arm 架构下还会更低。


在复杂场景下，实验 1 以及诸多大厂的生产环境都证明了 java 的稳定可靠，实验 2 则说明如果确实需要在物联网终端等内存极其苛刻的场景下使用，native 也能胜任。所以 Java 内存没救了？你要救什么？