当前位置: 首页 > article >正文

jvm排查问题-实践追踪问题 与思路--堆内堆外内存泄漏排查方针

概述

排查问题的一般思路是:现象 ——> 直接原因 ——>根本原因。
从问题现象出发,可以分为 应用逻辑问题、资源使用问题、虚拟机异常:

  1. 应用逻辑可能导致报错增加、死锁、程序退出等;
  2. 资源问题主要集中在CPU上升和内存上升(OOM Kill);
  3. 虚拟机问题通常包括GC问题、进程crash;

当然,不同的问题可能导向同一现象(比如crash和spring启动失败都会导致程序退出),从现象出发排查需要逐步验证、做排除法,最终定位根因。请添加图片描述

1.0. 虚拟机行为排查

Java应用逻辑经由JVM虚拟机得以运行,JVM负责解释/编译 Java代码,并且管理运行时应用所需要的各种资源,维护应用状态。JVM的管理行为大多通过异步执行+Barrier的方式完成,不会对业务造成明显影响。但GC、Crash以及个别情况下的编译问题可能会对业务产生性能上的体感变化。

1.1. GC问题排查

1.1.1 GC算法

GC主要任务就是,自动回收掉应用不在需要的内存,保证应用程序运行过程中,使用内存可以控制在预设的Size范围内。由于Java进程的运行会持续伴随着内存分配,但Java用户几乎不需要主动归还内存,于是,归还内存的任务就交给了JVM,这个过程就叫做垃圾清理(Garbage Collect),且需要保证清理效率不低于应用使用内存的需求,否则就会出现积压,造成OOME的风险。

因此以时间维度来看,可以将Java运行分为3个阶段:

分配内存阶段 ——> 识别垃圾阶段 ——> 清理垃圾阶段;

如此一来,一个最简单的GC算法就出现了。我们进一步会考虑到,识别垃圾的同时能不能分配内存?清理垃圾的同时能不能也分配内存?如果我随时可以分配内存,那么GC不就影响不到应用运行了吗?JDK的发展就伴随着诸如此般优化,产生了不同的GC算法。

目前业界使用比较广泛的GC算法有:ParallelGC、G1GC、PauselessGC(Shenandoah && ZGC),小红书还有极个别场景使用Serial GC。这些GC算法的发展可以概述为几个方向:

  1. 【并发化(异步化)】:让更多GC的工作可以和应用同时并发进行,减少对应用运行的阻塞;例如G1的Concurrent Mark、ZGC的并发回收、异步GC log等;不管是哪种GC算法,都无法做到完全并发,这些无法与应用并发完成的工作会在STW(stop the world)中进行,STW的时长会导致应用的卡顿。
  2. 【并行化】:从 SerialGC 到 ParallelGC,JVM会开启多个GC线程同时完成GC任务。另外G1也是JDK9之后逐渐支持FullGC并行处理。并行处理GC可以降低JVM处在STW阶段的时长,降低对应用的影响。
  3. 【分代】:所有GC算法都基于分代假说成立而设立,对年轻代和老年代采取不同的策略可以大大减小GC的开销;新一代的ZGC和Shenandoah通常不分代,这是由于分代GC更难实现。JDK21已经Release分代Gen-ZGC,JDK25有机会Release分代Shenandoah;
  4. 【预测】:根据GC收集到的历史信息,预判未来应用行为,提前作出规划以满足更好的性能和卡顿要求。例如G1的动态预测、ZGC的Alloc Pacing等;
    在这里插入图片描述

1.1.2 观察 GC 行为

监控

监控可以比较得看到GC变化趋势,快速定位问题时间点,从监控中通常可以获得几个GC指标:

GC频率
在这里插入图片描述
GC Pause时间(stw)
在这里插入图片描述

GC原因
在这里插入图片描述

各分区用量

在这里插入图片描述

对于RPC服务,GC频率、Pause、分区用量可以在 Xray 面板或调用链监控(Grafana)中找到,GC原因仅后者支持。
结合GC算法可以初步定位一些问题,例如:

  1. G1GC发生Old GC(也就是FGC)是异常行为,可以根据GC原因初步判断。
  • GCCause::System.GC()则往往代表DirectMemory满了;
  • GCCause::Metaspace Threshold代表metaspace不足需要扩充;
  • GCCause::Evacuation Pause 代表对象分配过快,回收效率不匹配;
  1. 遇到Old GC问题,连续发生多次且Old区使用量不降低,基本可以确定为内存泄漏或内存size过大。接下来可以通过heapdump(1.1.3介绍)分析
  2. 如果使用Parallel GC,则发生Old GC为正常行为;仅需要关注GC次数/时间的变化曲线。

打开 GC Log

查看GC Log可以细致得知道历史时刻中GC的变化,根据GC变化反推产生变化的原因,从而定位具体问题。
使用JDK参数模版,默认会打开gc*,safepoint的info等级log,通过info log可以基本确定问题直接原因,有时继续定位根因需要进一步打开更多log,方式为:

//排查GC卡顿时间:打开gc+phases=debug
-Xlog:gc*=info,safepoint=info,gc+phases=debug:gc.log:time,tags,tid:filesize=20M

http://www.kler.cn/a/454298.html

相关文章:

  • HarmonyOS NEXT 实战之元服务:静态案例效果---咖啡制作实况窗
  • css
  • 随时随地编码,高效算法学习工具—E时代IDE
  • PDF书籍《手写调用链监控APM系统-Java版》第10章 插件与链路的结合:SpringBoot环境插件获取应用名
  • Uniapp 微信小程序检测新版本并更新
  • 数据分析的常见问题及解决方案
  • 安全合规遇 AI 强援:深度驱动行业发展新引擎 | 倍孜网络CEO聂子尧出席ICT深度观察报告会!
  • C++-----------映射
  • Java Spring Boot 项目中嵌入前端静态资源:完整教程与实战案例
  • 模板方法、观察者模式、策略模式
  • Security知识点分享之高级安全安装虚拟机
  • 电商数据的安全与隐私保护:API接口的角色
  • 开源代码寻找平台总结
  • 【数据结构】【线性表】栈在算术表达式中的应用
  • McDonald‘s Event-Driven Architecture 麦当劳事件驱动架构
  • 分布式 IO 模块助力冲压机械臂产线实现智能控制
  • 基于python+django的旅游信息网站-旅游景点门票管理系统
  • 树莓集团:数字化产业园建设运营推动数字经济
  • 极狐GitLab 17.7正式发布,可从 GitLab 丝滑迁移至极狐GitLab【二】
  • “鼎和财险一体化数据安全管控实践”入选信通院金融领域优秀案例