线上java内存监控核心是盯住堆内存趋势、gc异常和非堆压力，而非仅堆满报警；需结合老年代水位、晋升速率、gc耗时占比、metaspace与直接内存使用率等组合指标提前发现泄漏、配置问题或流量冲击。
线上 Java 应用内存监控，核心是盯住 堆内存使用趋势 + GC 行为异常 + 非堆关键区域压力，而不是堆满才报警。重点不是“看哪些指标”，而是“哪些指标组合能提前暴露泄漏、配置不合理或突发流量冲击”。
堆内存：重点关注已用率、晋升速率和老年代水位
只看“堆使用率 80%”意义不大，要结合时间维度和代际分布：
- 老年代使用率持续缓慢上涨（如每小时涨 1%）：大概率存在内存泄漏或对象生命周期过长，比年轻代波动更值得警惕
- 每次 Full GC 后老年代回收量极小（：说明对象堆积且无法释放，配合 OOM 前日志可定位泄漏点
- 年轻代 Eden 区每分钟晋升到老年代的字节数（Promotion Rate）突增：可能因大对象创建、缓存未设上限、或 Survivor 区太小导致过早晋升
GC 行为：不只看频率，更要看停顿和效率
GC 日志是黄金数据源，监控需提取结构化指标：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 单次 Young GC 平均耗时 > 50ms 或 Full GC > 200ms：说明堆过大、GC 算法不匹配（如 G1 未调优）或存在大对象拷贝
- 单位时间 GC 总耗时占比 > 10%（例如 1 分钟内 GC 占 8 秒）：应用有效计算时间严重缩水，性能已受损
- 连续多次 Young GC 后老年代增长快于回收：预示即将触发 Full GC，可作为前置预警信号
非堆内存：元空间和直接内存常被忽略但易引发崩溃
这两块不走 GC 流程，靠显式释放或 JVM 自动扩容，失控后直接 OOM：
- Metaspace 使用率 > 85% 且持续上升：常见于频繁动态生成类（Groovy/SpEL 脚本、大量代理类、热部署未清理）
- Direct Buffer 已分配容量接近 -XX:MaxDirectMemorySize：Netty、NIO 文件读写、数据库驱动（如 PostgreSQL 的 pgjdbc）容易踩坑
- Compressed Class Space 使用量异常增长：JDK 8u20+ 后与 Metaspace 分离，需单独监控
辅助定位：线程与对象分布提供上下文
内存问题最终要落到“谁在占”和“谁在创建”：
- 活跃线程数突增且堆栈含大量 WAITING/TIMED_WAITING：可能线程池堆积、连接未释放，间接拖垮内存（如线程局部缓存膨胀）
- 堆中某类实例数 TOP 3 占比超 60%（如 HashMap$Node、String、ByteBuf）：结合业务逻辑判断是否合理，比如缓存未淘汰、日志字符串拼接泛滥
- 对象创建速率（/秒）突增：Arthas `vmtool --action getInstances` 或 JFR 可辅助采样，定位高频 new 点
实际落地建议用 Prometheus + Grafana 抓取 JVM Exporter 指标，重点做三类告警：老年代周环比上涨超 30%、Full GC 频次 5 分钟内 ≥ 3 次、Metaspace 使用率 > 90% 持续 2 分钟。不复杂但容易忽略。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
