Java应用防止内存溢出的关键是让JVM各内存区域有界、可监控、可回收：堆内存需-Xms=-Xmx且不超过物理内存70%～80%，元空间和直接内存必须显式设限，搭配G1/ZGC及OOM自动转储与GC日志，辅以代码层资源释放与监控。
Java 应用防止内存溢出，关键不是盲目加大内存，而是让 JVM 各内存区域有界、可监控、可回收。核心思路是：堆内存合理分配、非堆内存显式限制、GC 策略匹配业务、异常时留痕定位。
堆内存设置要稳且均衡
堆是对象主要存放区，也是 OOM 最常发生的区域。必须避免动态伸缩带来的抖动和不可预测性：
-
-Xms 和 -Xmx 设为相同值，例如
-Xms4g -Xmx4g，防止运行中扩容/缩容引发 GC 压力或暂停 - 堆大小不超过物理内存的 70%～80%，为系统、元空间、直接内存等留出余量
- 避免设置过大（如单机堆超 8G），可能延长 GC 暂停时间；过小则频繁 GC，吞吐下降
非堆内存必须显式设限
很多 OOM 并非来自堆，而是元空间或直接内存——它们默认无上限，极易失控：
-
元空间（Metaspace）：用
-XX:MetaspaceSize=256m -XX:MaxMetaspaceSize=512m固定上限，防止类加载过多导致溢出 -
直接内存（Direct Memory）：NIO、Netty、数据库驱动等常隐式使用，务必加
-XX:MaxDirectMemorySize=1g（建议为堆内存的 20%～50%） - 注意总内存（堆 + 元空间 + 直接内存 + 线程栈）不能超过机器可用内存，否则触发系统级 OOM Killer
选对垃圾回收器并开启诊断
GC 策略直接影响内存回收效率和稳定性：
立即学习“Java免费学习笔记（深入）”；
- JDK 8 推荐
-XX:+UseG1GC；JDK 11+ 可评估-XX:+UseZGC（低延迟场景）或继续用 G1 - 配合调优参数，如
-XX:MaxGCPauseMillis=200控制停顿目标 - 必开诊断：
-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/dump，OOM 时自动生成堆快照 - 加上
-Xloggc:gc.log -XX:+PrintGCDetails记录 GC 行为，便于回溯分析
代码与运行时协同防御
JVM 参数只是防线之一，还需从应用层加固：
- 显式释放 DirectByteBuffer：使用
buffer.cleaner().clean()或更推荐的池化方案（如 Netty 的ByteBufAllocator+release()） - 避免静态持有大对象或缓存未设上限，尤其注意 Map、Cache、线程局部变量（ThreadLocal）的生命周期
- 压测阶段用
jcmd <pid> VM.native_memory summary查看堆外内存分布，验证直接内存是否稳定 - 上线后接入监控（如 Prometheus + JVM Exporter），重点关注 heap_used、metaspace_used、direct_buffer_count 等指标
