核心指标是老年代使用率、Full GC频次与停顿时间；需结构化采集GC日志并结合实时告警与每日离线趋势分析，提前识别内存泄漏与雪崩风险。

监控和报警 JVM GC 日志的核心指标，关键不是堆满才告警，而是从趋势和节奏中识别异常信号。重点盯住老年代使用率、Full GC 频次、GC 停顿时间这三项，配合日志采集与自动化分析，才能在 OOM 发生前介入。

老年代使用率持续攀升（核心预警信号）

老年代（Old Gen）是内存泄漏最典型的“蓄水池”。只要它持续上升且不回落，就是强风险信号。

• 监控目标：jvm_memory_used_bytes{area="heap"} 与 jvm_memory_max_bytes{area="heap"} 的比值，但必须拆出老年代部分（如用 JMX 的 java.lang:type=MemoryPool,name=PS Old Gen）
• 报警阈值建议：连续5分钟 >80% 触发 P2 级告警；连续1分钟 >95% 升为 P1，立即通知值班人
• 注意区分：单次冲高后快速回落（如大报表导出），和缓慢但不可逆的爬升（如静态 Map 不断 put）——后者才是真问题

Full GC 频次与耗时双控（防雪崩）

Full GC 是系统“窒息”的直接表现，频繁发生会拖垮吞吐量和响应延迟。

Java注释规范Skills

当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。

下载

• 从 GC 日志中提取：每分钟 FGC 次数（FGC 字段）、每次 FGCT 耗时（毫秒级）
• 报警逻辑：每小时 ≥3 次 Full GC 或 单次 >1.5 秒，即触发告警；若同时满足，自动升级为紧急事件
• 补充判断：结合 GC Cause 字段，如出现 “Ergonomics”、“Metadata GC Threshold” 属于可预期场景；但 “Allocation Failure” 在老年代触发，则高度可疑

GC 日志必须结构化采集并留存

没有日志，所有指标都是空中楼阁。光靠 Prometheus 抓 JMX 数值不够，必须落地原始 GC 日志用于回溯分析。

• JVM 启动参数务必包含：-Xlog:gc*:file=/var/log/java/gc.log:time,uptime,level,tags:filecount=5,filesize=100M（JDK 11+）
• 日志需实时采集进 ELK 或 Loki，建立索引字段如：timestamp、gc_type（Young/Full）、used_before、used_after、duration_ms
• 用 Logstash 或自定义脚本做简单解析，对每条 Full GC 记录打标 “is_urgent:true”，便于告警规则快速匹配

用 GCViewer + 定时任务做离线趋势扫描

除了实时告警，每天凌晨跑一次 GC 日志分析，能发现肉眼难察的缓慢恶化趋势。

• 用 crontab 每天 3:00 执行：java -jar gcviewer.jar /var/log/java/gc.log.0 -dumpcsv /tmp/gc_daily.csv
• 检查 CSV 中 “Max Heap Usage %” 和 “Full GC Count” 7 日环比，若老年代峰值上升 >15% 或 Full GC 总数翻倍，自动发日报提醒
• 这个动作不替代实时告警，但能暴露“温水煮青蛙”型泄漏，比如某 SDK 缓存未清理、线程局部变量累积等