Java进程内存占用远超-Xmx设定值，是因为-Xmx仅限制堆内存，而RSS包含元空间、直接内存、线程栈、JNI本地分配等全部进程内存；例如-Xmx8g进程占12G，正是因元空间无上限、直接内存未限制、线程栈累积等共同导致。
Java进程内存占用远超-Xmx设定值？不是配置错了，是只调堆内存根本不管用。
为什么-Xmx8g的Java进程实际占了12G内存？
Linux上top或ps aux看到的RES值，包含JVM堆、元空间、直接内存、线程栈、JNI本地分配等全部进程内存。只设-Xmx等于只管了其中一部分。
-
-Xmx只限制堆内存（Eden+Survivor+老年代），不控制元空间、直接内存、线程栈等 - 默认
-XX:MaxMetaspaceSize无上限，类加载多的应用（如Spring Boot、热部署）极易撑爆元空间 -
-XX:MaxDirectMemorySize未显式设置时，默认等于-Xmx，但Netty、NIO框架常绕过该限制超额分配 -
-Xss默认1M/线程，500个线程就吃掉500MB栈空间，且无法被GC回收
-Xms和-Xmx必须设成一样吗？
必须。动态扩容堆会触发Full GC，且在K8s等受限环境中可能因cgroup内存边界触发OOMKiller杀进程。
- 单机场景：设为物理内存的1/4～1/2，例如16G机器设
-Xms8g -Xmx8g - K8s容器场景：必须≤容器limit，且建议留20%余量给非堆内存，比如容器limit=10Gi，堆最多配8g
- 若
-Xms＜-Xmx，JVM启动后需多次扩容，每次扩容都伴随GC暂停，压测时易出现毛刺
元空间和直接内存怎么防溢出？
这两个区域不走常规GC路径，溢出即OutOfMemoryError: Metaspace或OutOfMemoryError: Direct buffer memory，必须显式限流。
- 元空间：
-XX:MetaspaceSize=256m -XX:MaxMetaspaceSize=512m，避免初始GC过早触发；Spring Boot应用建议≥384m - 直接内存：
-XX:MaxDirectMemorySize=1g，尤其使用Netty、RocketMQ客户端时必加，否则ByteBuffer.allocateDirect()可无限分配 - 验证是否生效：启动后执行
jstat -gc <pid></pid>，看MU（元空间已用）和CCMU（压缩类空间）是否稳定在上限内
不同GC策略对内存参数的影响
G1、ZGC、Shenandoah对内存分区逻辑完全不同，硬套同一套参数反而引发问题。
- G1 GC（JDK9+默认）：
-XX:+UseG1GC -XX:MaxGCPauseMillis=200，需配合-Xms/-Xmx设为相同值，G1HeapRegionSize一般不用调 - ZGC（JDK11+）：
-XX:+UseZGC必须搭配-XX:ZHeapSize=8g（不是-Xmx），ZGC完全接管堆管理，-Xmx会被忽略 - Shenandoah：
-XX:+UseShenandoahGC，同样不依赖-Xmx，但需确保-XX:InitialHeapSize与-XX:MaxHeapSize一致
最容易被忽略的是：ZGC和Shenandoah在JDK21中已转正，但很多线上脚本还在沿用G1的旧参数模板，导致ZGC无法启用或退化为Serial GC。
