换用OpenJ9可显著降低内存占用，其常驻内存约为HotSpot的1/3，且主动归还物理页；需显式设置-Xms、-Xmx和-XX:MaxMetaspaceSize，并选用Eclipse Adoptium或IBM Semeru的OpenJ9构建。
直接换 OpenJ9，比调参数见效快得多。HotSpot 在低内存场景下默认行为偏“重”，哪怕堆设得很小，元空间、线程栈、JIT 编译器缓存仍会悄悄吃掉几百 MB；OpenJ9 从设计上就面向资源受限环境，启动后常驻内存能压到 HotSpot 的 1/3 左右。
用 OpenJ9 替代 HotSpot 是最有效的第一步
不是所有 JDK 都适合小内存服务。标准 OpenJDK（HotSpot）在 512MB 以下内存的机器上容易因元空间膨胀或 GC 暂停失控而 OOM；OpenJ9 则把内存管理逻辑重构过，空闲时主动归还物理页给 OS，容器里尤其明显。
- 下载地址认准
Eclipse Adoptium或IBM Semeru Runtimes，选带openj9标签的构建（如jdk-11.0.22+10_openj9-0.43.0） - 启动命令无需大改，直接替换
java可执行文件路径即可，-Xms/-Xmx等通用参数照常生效 - 避免混用：不要把 OpenJ9 的
jre目录塞进 HotSpot 的JAVA_HOME，否则java -version仍报 HotSpot
堆参数必须显式限制，不能依赖默认值
小内存服务最常见错误是没设 -Xms 和 -Xmx，让 JVM 自己猜——HotSpot 默认初始堆可能达 1/4 物理内存，OpenJ9 虽好些，但不设也会飘。
-
-Xms128m -Xmx256m是 512MB 总内存设备的合理起点，留出足够空间给元空间和直接内存 - 加
-XX:MaxMetaspaceSize=64m，防止类加载过多撑爆元空间（Spring Boot 应用尤其要加） - 禁用压缩指针（
-XX:-UseCompressedOops）仅在 32 位系统或极小堆（
关掉非必要功能，尤其是 GUI 和 JIT 预热
小内存服务通常不渲染界面、不跑复杂计算，却默认加载 AWT/Swing 类和 JIT 编译器预热逻辑，白白占内存。
- 强制头less：
-Djava.awt.headless=true，跳过所有图形组件初始化 - 禁用 JIT 预热（对短生命周期服务有效）：
-XX:+TieredStopAtLevel=1，只用 C1 编译器，省掉 C2 占用的编译缓存 - 如果服务纯 HTTP + JSON，去掉 JMX：
-Dcom.sun.management.jmxremote=false，避免 MBeanServer 启动开销
注意 Direct Buffer 和虚拟线程的隐性开销
这两项在小内存服务里极易被忽略，但实际占用可能远超堆内对象。
-
ByteBuffer.allocateDirect()分配的是堆外内存，不受-Xmx控制，需用-XX:MaxDirectMemorySize=64m限死 - 虚拟线程（
Thread.ofVirtual()）虽轻量，但每个仍需约 16–32KB 栈空间（取决于调用深度），2000 个并发就吃掉 64MB，建议搭配-XX:MaxJavaStackTraceDepth=512压缩栈帧 - 检查第三方库是否暗中用了 Netty 或 Undertow——它们默认开启 direct buffer cache，得配
-Dio.netty.maxDirectMemory=0关闭
真正卡住小内存服务的，往往不是堆大小设得不够低，而是非堆内存失控、GUI 组件加载、或某个库偷偷分配了大量 direct buffer。OpenJ9 提供了更可控的基线，但具体到每个服务，还得看它实际加载了哪些类、打开了多少 channel、有没有滥用 finalize() 或 Cleaner —— 这些没法靠换 JVM 解决，得靠 jcmd <pid> VM.native_memory summary 实锤。
