堆内存增大不等于性能提升，因gc停顿时间随堆增长而上升，大堆掩盖内存泄漏、易致oom killed，且可能降低年轻代比例导致对象过早晋升；仅当监控显示频繁gc且存活率高、metaspace逼近上限或eden空闲低而老年代使用率低时，才应扩容。
不是。堆内存越大，性能反而可能越差，尤其在容器环境或低配机器上。
为什么堆内存增大不等于性能提升
JVM 垃圾回收（GC）的停顿时间与堆大小强相关——G1、ZGC 等现代收集器虽有改进，但扫描、标记、转移对象的开销仍随堆增长而上升。比如 8GB 堆在 Full GC 时可能暂停 1.2 秒，而 2GB 堆仅 200ms；更关键的是，大堆会掩盖内存泄漏：对象缓慢堆积数小时才触发 GC，问题定位变难。
另外，堆外内存（如 ByteBuffer.allocateDirect()、元空间、线程栈）不受 -Xmx 控制，若堆占满 90% 容器内存，剩余空间很可能不够分配这些区域，直接触发 OOM Killed。
- 堆越大，GC 暂停时间越长（尤其 G1 的 Mixed GC 阶段）
- 堆过大时，JVM 可能减少年轻代比例，导致短生命周期对象过早晋升到老年代
- 容器中未预留非堆内存空间，
-Xmx10g配在 12Gi 内存 Pod 里极易被 kill
什么情况下该调大堆内存
只有当监控明确指向“堆频繁 GC 且每次回收后存活对象占比高”时，才考虑扩容。典型信号包括：G1EvacuationPause 日志中 survivor 区长期 >80% 占用、Metaspace 持续增长接近上限、或 jstat -gc 显示 EC（Eden）几乎无空闲但 OC（Old）使用率稳定在 40% 以下。
- 对象平均生命周期长（如缓存服务），且老年代实际使用率长期
- 已启用
-XX:+UseG1GC或-XX:+UseZGC，并调优了-XX:MaxGCPauseMillis或-XX:ZCollectionInterval - 确认堆外内存可控：
-XX:MaxDirectMemorySize=256m、-XX:MaxMetaspaceSize=512m、-Xss256k已显式设置
容器环境下堆大小的合理取值
别再用 -Xmx 硬编码。OpenJDK 8u191+ / 11+ 默认启用容器感知，应优先用 -XX:MaxRAMPercentage。例如容器限制 2Gi 内存，设为 -XX:MaxRAMPercentage=75.0，JVM 自动计算约 1.5Gi 堆，留出 512Mi 给元空间、直接内存、JNI 等。
- 1Gi 容器 →
-XX:MaxRAMPercentage=60.0（约 614Mi 堆） - 4Gi 容器 →
-XX:MaxRAMPercentage=75.0（约 3Gi 堆） - 禁用
-Xms/-Xmx，避免与MaxRAMPercentage冲突（JVM 会忽略后者） - 若必须用
-Xmx，务必 ≤ 容器 memory limit × 0.8，且同步设置-XX:MaxMetaspaceSize
真正影响性能的是 GC 行为是否平稳，而不是堆数字有多大。很多线上事故，根源是盲目堆大 + 忽略元空间膨胀，最后 java.lang.OutOfMemoryError: Compressed class space 报错却还在查堆内存。
