内存溢出是长期压力积累所致，需在oom前通过堆内存与gc行为监控（如jstat）、gc日志分析（含promotion failed等关键词）、定期堆快照（jmap+mat）及业务指标关联来主动识别风险。
内存溢出不是突发事故，而是长期压力积累的结果。真正有效的应对方式，是在 OOM 发生前就识别出内存使用趋势异常——关键在于建立可量化的监控指标、设置合理的阈值，并配合轻量级工具持续采集数据。
盯住核心指标：堆内存增长与 GC 行为
堆内存使用率和垃圾回收频率是最直接的预警信号。重点关注老年代（Old Gen）使用率是否持续上升、Full GC 是否频繁发生且回收效果差（比如每次只释放少量内存）。
- 用 jstat -gcutil
2000 - 若 OU（Old Used）在多次采样中稳步上升，且 FGC 次数同步增加，说明对象正在堆积，可能已存在泄漏或缓存未限流
- YGC 频率突然升高但 EU（Eden Used）回落快，通常是短期高创建压力；若 EU 居高不下、YGC 效果变差，则新生代可能过小或对象存活时间过长
配置自动日志：让 GC 自己“说话”
GC 日志是回溯问题的原始证据，必须开启并保留足够时长。
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
- 启动参数加入：-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，可按需主动抓取堆快照做横向对比。
- 用 jmap -histo:live
查看当前活跃对象数量和大小，重点关注自定义类、集合类（如 HashMap、ArrayList）、字符串或 byte[] 实例是否异常偏多 - 对疑似问题时段执行 jmap -dump:format=b,file=heap_$(date +%s).hprof
，后续用 MAT 分析支配树（Dominator Tree）和 GC Roots 引用链 - 若某类对象实例数随请求量线性增长却无对应减少，极可能是缓存未清理或监听器未注销
结合业务维度做关联判断
脱离业务场景的内存监控容易误判。把 JVM 指标和业务指标联动，才能定位真实瓶颈。
- 例如：订单服务的老年代使用率在每小时整点上升 5%，同时监控发现定时任务拉取全量用户数据并缓存——这就是明确的优化入口
- 在流量高峰期间，若线程数激增且堆内存同步上涨，需检查是否线程池未设界、或每个请求创建了大对象（如未复用的 ByteBuffer、未关闭的 InputStream）
- 元空间（Metaspace）持续增长，伴随类加载数上升，大概率是框架动态代理、JSON 序列化库反复生成类，或热部署未清理旧类加载器
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
