Java生产环境内存泄漏监控需提前捕捉异常增长信号，核心是监控老年代使用率、Full GC行为、对象增长速率三项指标，结合告警规则、自动堆转储与可观测性增强实现闭环。
Java 生产环境内存泄漏的自动化监控报警，核心不是等 OOM 才响应，而是提前捕捉“内存持续异常增长”的信号，并自动触发告警与现场留存。关键在于指标选得准、规则配得细、动作链得紧。
盯住三个高敏感度指标
老年代使用率、Full GC 行为、对象增长速率这三项组合，比单看“堆内存使用率”或“GC 次数”更能反映真实泄漏趋势：
- 老年代使用率 >85% 且 Full GC 后回落 ：说明晋升对象无法被有效回收，是强泄漏信号
- 连续 3 次 Full GC 间隔 ：GC 已疲于奔命但收效甚微
- java.util.HashMap$Node、byte[] 或核心业务类实例每小时增长超 10%：指向具体泄漏载体，便于后续归因
用 Prometheus + Grafana 配复合告警规则
避免简单阈值告警（如“Old Gen >90%”），改用带时间窗口和变化率的 PromQL 表达式：
- jvm_memory_used_bytes{area="old"} / jvm_memory_max_bytes{area="old"} > 0.85 and delta(jvm_memory_used_bytes{area="old"}[30m]) > 100_000_000：既超阈值又在半小时内猛增 100MB+
- rate(jvm_gc_collection_seconds_count{gc=~"G1.*Old|ConcurrentMarkSweep"}[10m]) > 0.1 and avg_over_time(jvm_gc_collection_seconds_sum{gc=~"G1.*Old|ConcurrentMarkSweep"}[10m]) > 2：10 分钟内 Old GC 频次 ≥6 次，且平均停顿超 2 秒
- 告警规则需标注 severity（warning/critical）、summary 和 description，方便 Alertmanager 分级推送至钉钉/企业微信
自动触发堆转储并保留上下文
告警触发后，不能只发消息，必须同步捕获现场：
- 用 shell 脚本监听 GC 日志（如 tail -f /logs/gc.log），检测到连续 2 次 Full GC 回收率低于 15%，立即执行：
jmap -dump:live,format=b,file=/dump/auto_$(date +%s).hprof $PID - 转储后自动：
• chown app:app /dump/auto_*.hprof
• gzip /dump/auto_*.hprof
• 上传至 MinIO/S3，并记录元数据（JVM 参数、QPS、线程数、告警时间戳） - 底线保障仍要配置：-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/dump/oom/
配套采集与可观测增强
让指标更可信、分析更高效：
- JVM 启动参数中加入：-Xloggc:/logs/gc.log -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=5 -XX:GCLogFileSize=10M，确保 GC 日志可回溯不丢失
- 用 Arthas dashboard 或自研脚本每 30 秒采集 jstat -gc $PID，上报关键字段（S0C、EC、OC、YGC、FGC、GCT）到指标系统
- 通过 Micrometer + Spring Boot Actuator 暴露 /actuator/prometheus，统一纳管 JVM、HTTP、线程池等维度指标
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
