Java内存溢出（OOM）是长期资源管理失当的集中爆发，需通过实时监控GC行为、合理配置JVM参数（如-Xms/-Xmx相等、HeapDumpOnOutOfMemoryError）、防御代码泄漏（静态集合清理、ThreadLocal remove、try-with-resources）及轻量巡检（jmap比对、线程数阈值告警）实现早发现、准定位、稳干预。
Java内存溢出（OOM）不是突发故障，而是长期资源管理失当的集中爆发。监控和预防的关键在于“早发现、准定位、稳干预”——不依赖等报错才行动，而是在内存使用趋势异常时就介入。
实时监控堆内存使用与GC行为
仅看是否OOM远远不够。真正有效的监控要捕捉内存增长节奏和GC效率变化：
- 启用详细GC日志：Java 9+ 推荐 -Xlog:gc*,gc+heap=debug,gc+metaspace=debug:file=gc.log:time,tags,uptime；旧版本用 -XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:gc.log
- 关注核心指标：每次Full GC后老年代剩余空间是否持续升高？Minor GC频率是否在数分钟内陡增？GC耗时占比是否连续多次超10%？这些是泄漏早期信号
- 配合jstat定期采样：例如 jstat -gc -h10 <pid> 5s 每5秒输出一行，观察 OU（老年代已用） 和 OGC（老年代GC次数） 的协同变化趋势
配置合理JVM参数并启用自动诊断
参数不是越大越好，而是要匹配应用特征并留出诊断窗口：
- 堆内存：初始堆（-Xms）与最大堆（-Xmx）设为相同值，避免运行中扩容抖动；大小参考压测峰值的1.2–1.5倍，而非盲目堆到8G+
- 关键开关必加：-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/data/dump/，确保OOM瞬间生成可用的hprof文件
- 元空间防护：-XX:MetaspaceSize=256m -XX:MaxMetaspaceSize=512m，防止动态类加载失控；对Spring Boot等反射密集型应用可适度上调
- 直接内存控制：-XX:MaxDirectMemorySize=512m，尤其使用Netty、NIO ByteBuffer时必须显式限制
代码层主动防御常见泄漏点
很多OOM源于开发阶段未约束的引用习惯，需在编码时建立防御意识：
立即学习“Java免费学习笔记（深入）”；
- 静态集合务必配清理机制：如 static Map<String, byte[]> cache = new ConcurrentHashMap<>()，配合LRU策略或定时清理线程，禁用无界static ArrayList
- 监听器/回调注册后必须配套注销：GUI组件、事件总线、Spring ApplicationListener等场景，确保onDestroy或finally中调用removeListener
- ThreadLocal使用后及时remove：try-finally块中执行 tl.remove()，避免线程池复用时残留上一个请求的数据
- 资源操作强制使用try-with-resources：InputStream、Connection、Statement等所有AutoCloseable对象，杜绝因异常跳过close
生产环境轻量级巡检机制
无需侵入业务，靠标准化脚本实现常态化风险筛查：
- 每日凌晨执行一次内存快照比对：用 jmap -histo:live <pid> 输出存活对象统计，对比前一日TOP20类实例数波动，突增即告警
- 线程数监控阈值化：用 jstack <pid> | grep 'java.lang.Thread' | wc -l 定期采集，超过预设值（如500）触发预警，防“unable to create new native thread”
- 结合Prometheus + JMX Exporter暴露JVM指标，将Old Gen Usage、Loaded Class Count、Direct Memory Used等纳入SRE告警规则
