内存溢出是长期压力积累所致，需在OOM前通过堆内存与GC行为监控（如jstat）、GC日志分析（含promotion failed等关键词）、定期堆快照（jmap+MAT）及业务指标关联来主动识别风险。
内存溢出不是突发事故，而是长期压力积累的结果。真正有效的应对方式，是在 OOM 发生前就识别出内存使用趋势异常——关键在于建立可量化的监控指标、设置合理的阈值，并配合轻量级工具持续采集数据。
盯住核心指标：堆内存增长与 GC 行为
堆内存使用率和垃圾回收频率是最直接的预警信号。重点关注老年代（Old Gen）使用率是否持续上升、Full GC 是否频繁发生且回收效果差（比如每次只释放少量内存）。
- 用 jstat -gcutil <pid> 2000
- 若 OU（Old Used）在多次采样中稳步上升，且 FGC 次数同步增加，说明对象正在堆积，可能已存在泄漏或缓存未限流
- YGC 频率突然升高但 EU（Eden Used）回落快，通常是短期高创建压力；若 EU 居高不下、YGC 效果变差，则新生代可能过小或对象存活时间过长
配置自动日志：让 GC 自己“说话”
GC 日志是回溯问题的原始证据，必须开启并保留足够时长。
- 启动参数加入：-XX:+PrintGCDetails -XX:+PrintGCTimeStamps -Xloggc:/path/gc.log -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=5 -XX:GCLogFileSize=10M
- 关注日志中的 promotion failed（晋升失败）、concurrent mode failure（CMS 失败）等关键词，它们常是 OOM 的前兆
- 用工具如 GCViewer 或 GCEasy 分析日志，能直观看到各代内存占用趋势、GC 耗时变化、停顿时间增长曲线
定期快照 + 对象分布分析
光看总量不够，得知道“谁占得多”。不必等 OOM 才 dump，可按需主动抓取堆快照做横向对比。
立即学习“Java免费学习笔记（深入）”；
- 用 jmap -histo:live <pid> 查看当前活跃对象数量和大小，重点关注自定义类、集合类（如 HashMap、ArrayList）、字符串或 byte[] 实例是否异常偏多
- 对疑似问题时段执行 jmap -dump:format=b,file=heap_$(date +%s).hprof <pid>，后续用 MAT 分析支配树（Dominator Tree）和 GC Roots 引用链
- 若某类对象实例数随请求量线性增长却无对应减少，极可能是缓存未清理或监听器未注销
结合业务维度做关联判断
脱离业务场景的内存监控容易误判。把 JVM 指标和业务指标联动，才能定位真实瓶颈。
- 例如：订单服务的老年代使用率在每小时整点上升 5%，同时监控发现定时任务拉取全量用户数据并缓存——这就是明确的优化入口
- 在流量高峰期间，若线程数激增且堆内存同步上涨，需检查是否线程池未设界、或每个请求创建了大对象（如未复用的 ByteBuffer、未关闭的 InputStream）
- 元空间（Metaspace）持续增长，伴随类加载数上升，大概率是框架动态代理、JSON 序列化库反复生成类，或热部署未清理旧类加载器
