Java GC问题排查的一些个人总结和问题复盘

news/2024/6/20 16:32:42/文章来源:https://blog.csdn.net/iwts_24/article/details/139279346

个人博客

Java GC问题排查的一些个人总结和问题复盘 | iwts’s blog

是否存在GC问题判断指标

有的比较明显,比如发布上线后内存直接就起飞了,这种也是比较好排查的,也是最多的。如果单纯从优化角度,看当前应用是否需要优化,有一些指标判断:

  1. 延迟(Latency):也可以理解为最大停顿时间,即STW最长时间。
  2. 吞吐量(Throughput):例如系统运行了 100 min,GC 耗时 1 min,则系统吞吐量为 99%。

两者是结合的,延迟越低越好,而吞吐量一般有各个业务指标,例如TP999,即99.9%的吞吐量,TP9999则是99.99%。

一般来说尤其是技术还不错的大厂,除了发布是很难碰到相关问题的。。尤其是阿里这种比较卷比的,早就优化甚至为了ppt而优化给整完了,确实没啥优化空间。

包括JVM在内,这种东西能不碰就不碰,真的性价比不高。不过日常代码还是要注意,比如内存泄露这种代码就别写出来了。

这里主要还是聊聊如果真碰到了问题,或者性能不是很行,想要分析是否是GC的话,有一些我个人工作的经验总结以及之前看到的解决方案的分析。

通用排查流程

GC日志分析

有一些网站,dump下来GC日志后上传上去,各种可视化信息。例如:Universal JVM GC analyzer - Java Garbage collection log analysis made easy

分析JVM内存配置

jmap -heap {pid}

先看看JVM启动参数&各代内存分配情况:

先看看分代参数不合理是否会影响本次GC问题。

堆内存对象大小分析

查看存活对象中的实例数量&具体占用内存大小:

jmap -histo 7276 | head -n20

后面的可以忽略,只看前面一部分就ok。

或者直接>重定向写到log中,慢慢看。

主要看是否有哪个对象占用量非常的大,远超过其他对象,如果有,那说明该对象的生成可能是不合理的。

堆文件dump分析

确定有比较异常的对象,才考虑dump下来看。

JProfile之类的比较高端,能直接远程监控VM,但是需要线上配置。自己负责的业务能线上直接操作,或者基建比较nb已经有相关内部工具,那么可以代替dump。

dump命令:

jmap -dump:format=b,file={文件名} {pid}

然后利用可视化工具装载,例如JProfile、JVisualVM。JProfile要破解,JDK自带JVisualVM。

可以具体分析对象到底是哪些实例。

JVisualVM

JDK自带可视化分析工具。

路径JAVA_HOME/bin/jvisualvm.exe

Idea可以下载插件:VisualVM,配置后可以直接拉起比较方便。

本质上是监控,但是一般公司基建都不错,不在乎这种。主要还是快,直接打开exe文件,省的再去JDK下找。

类加载情况

JVM启动参数,增加内容:

-verbose:class # 查看类加载情况
-verbose:gc # 查看虚拟机中内存回收情况
-verbose:jni # 查看本地方法调用的情况

一般是class,启动后java -verbose:class,可以看到当前程序的加载情况。

代码分析

总归是要回归代码的。尤其是上线后导致的问题,更容易排查出问题的到底是在哪,必然是因为上线后更新的代码导致的。

不管怎么调优,最终还是要回归代码的。

频繁Full GC

内存空间角度

  1. 先看JVM内存配置,是不是老年代太小,实在没啥空间,频繁触发阈值开启Full GC。
  2. 是否有内存泄漏,老年代增长速度非常快,回收后跟没回收一样,可能是内存泄漏。

大对象

例如单SQL未分页,同时刻大对象装载进入内存,此时由于超过了Eden区大小,会直接装载进老年代,从而导致Full GC频繁。

这样在观察heap的时候就能看出来,是否会出现某些对象实例少,占用空间大。

内存泄漏

比较经典了,每次Full GC只能回收一点,机器重启后解决问题。标准的内存泄漏。主要看看IO之类的是不是哪里没有close。

Minor GC角度

会不会是Minor GC频率太高导致的。高频次的Minor GC会导致大量的对象年龄增加以进入老年代。

晋升代数设置不合理-调整代数设置

如果Minor GC的频率确实这么高,那么考虑是不是晋升代数设置的太低导致的。例如对象A生命周期60秒,Minor GC 10s一次,而晋升代数设置的是3。

那么A对象30s就会晋升一次,导致大量A对象进入老年代。

如果设置成晋升代数为7,那么在60s后,A对象生命周期结束,年龄为6,Minor GC直接清除,不再丢入老年代。

OOM

一般伴随着Full GC的问题。场景不多,给一些比较常见的。

内存泄漏

同上,一般先是大量Full GC,老年代迟早要被完全填满的,填满后就是OOM。

ThreadLocal内存泄漏

比较经典,可以参考:详解Java ThreadLocal

new大量新类

比较少见,仍然是先高频率Full GC,最终填满导致OOM

内存空间不合理

可能有很多,哪个空间都有可能OOM,此时异常一般也说明了是哪个区OOM了,一般很少见,真碰见一般就是非常低的情况。比如之前CRM不知道谁给设置的,Heap 100MB还是多少,Full GC的🐎都不认识,但是最后只有少量OOM。(大对象还是少)

堆外内存泄漏

感觉还是相当少了,之前吃交易P0的瓜,好像是这个问题。

首先回顾以下堆外内存,JVM分为堆和非堆,堆之外的,包括本地内存、栈等。一般JVM控制的内存大小是固定的,反映在监控上,在内存占用这里基本就是一条直线。

蘑菇街这边基本就是75%这样。

出现时的表现:

  1. 内存使用率不断上升,甚至开始使用 SWAP 内存。
  2. GC 时间飙升。
  3. 线程被 Block。
  4. 通过 top 命令发现 Java 进程的 RES 甚至超过了 -Xmx 的大小。

例如:

结合上次交易的P0事故。一般发生堆外内存泄漏,都跟我们自己的代码关系不太大。因为大量调用栈这种情况一般不出现,出现也是OOM,不会产生对机器内存大量读写的场景。那么有那种情况下会对内存大量读写?native方法。

那么有个最重要的点:IO通信框架一般是会大量操作本地内存的。

大家都是RPC,内部可能是Netty或者NIO框架,所以RPC框架是很有可能导致堆外内存泄漏的,通信过程中大量使用JNI方法调用本地线程,这样指向了一个非常常见的问题:瞬时大量长时间请求。

比如接口日常请求100QPS,并发量也就10这样,如果跑任务之类的,瞬间QPS达到5000,直接堆外内存就打满了。

交易上次P0基本确定是这个问题。缓存击穿之后大量请求读写接口,Tesla接口QPS达到了万级,瞬间OOM机器开始挂。后续多次没起来也是,机器刚启动,Tesla线程拉起后直接OOM,继续挂。

给个云总的blog:netty oom

这里也有个小知识点:堆外内存是不由JVM管理的,所以大量占用的时候,GC不会被触发,同时JVM基本上也不限制本地内存大小。所以这块很难防止。

Metaspace OOM

具体分析可以看一下这个 深入JVM元空间以及弹性伸缩机制

已经聊了一些Metaspace OOM问题了。本质上就是一般设定都是固定大小不扩容,然后大量新class被load进去,导致OOM。

所以除了RPC框架,也有可能是跟IO相关的其他框架导致的,例如fastjson就有可能会在序列化中利用ASM技术执行字节码增强,产生大量的class对象。

这种情况本质上是类的内部方法建立的对象,存储在Metaspace的klass空间中。那么此时大量请求时就会不断创建,由于没有GC导致OOM。

此时两种方案:

  1. 设置Metaspace大小。默认情况下一般是非常大的,所以没有上限,设置一个大小触发卸载,可能会缓解这个问题。
  2. 本质上还是要看代码。一般这种情况还是代码有问题,能频繁不在堆上创建对象,说明该方法一般可以通过static固定到运行时常量池中,全部类只存一份。

Minor GC时间长

晋升代数不合理

和上面的Full GC恰好相反,有可能是晋升代数设置的太高了。那么此时的表现可能是:From区和To区Minor GC一次只能GC掉很少的数据,导致剩余空间小,每次Minor GC后,From/To区进行复制,这个时间花费太长了。

存在大量长生命周期对象

这个跟晋升代数类似,都是高龄对象堆满From/To区,但是不同点在于:此时晋升代数的设置是比较合理的。

那么这种情况就是高龄对象太多,导致的。还是要从heap 文件中找思路。很有可能是某个集合里面对象太多。比如一个list里面存几十万的对象。

那么主要就是先去找大对象,找到大对象后分析大对象的属性,看为什么能这么大。

频繁Minor GC

Eden扩容

一般来说可以对Eden区进行扩容来减少Minor GC次数,也就是说,增加了Minor GC的时间间隔,一次GC可以回收更多的对象。这里需要聊下新生代的GC算法:

  1. 新生代扫描。
  2. 复制Eden存活对象到Survivor。

这两步都存在时间消耗,但是复制要比扫描需要的时间多很多。

所以,对于Eden分区的扩容需要根据实际对象生命周期来计算,有这样的场景:

  1. 对象生命周期<扩容后Minor GC时间间隔。

    a. 此时对象只会被扫描,扫描后标记清除,不进行复制。

  2. 对象生命周期>=扩容后Minor GC时间间隔。

    a. 此时对象跟扩容前一样,先扫描后复制。

再结合上面扫描和复制的性能损耗:如果能保证扩容后Minor GC能将原来不能回收的对象给回收掉,那么收益是很大的。

反之,如果对象生命周期长,那么由于Eden区的扩大,会导致扫描时间变长,所以Minor GC时间也会增加。所以,有可能实际工作时间会降低。

所以Eden扩容并不是完美解决方案,依然要先分析对象存活时间之类的参数,然后再考虑扩容。

简而言之:如果对象平均代数低,那么扩容是有效的。

高峰期CMS Full GC时间突刺

CMS Full GC只有在Remark阶段会进行长时间STW,初始标记只是遍历GC Roots,STW很快。例如下面,Remark阶段STW时间为1.39s:

这里可能是Full GC慢的一个很重要的问题:跨代引用。具体可以看下:JVM CMS 在Full GC时针对跨代引用的优化

那么在高峰期可以看,在Full GC发生Remark的时候,新生代对象数量是否有很多,所以会出现这种突刺类型的问题:

  1. 如果Full GC前已经Minor GC一次。

    a. 那么跨代引用扫描很少数据,Full GC快。

  2. 如果Full GC时恰好新生代很满,例如75%。

    a. 那么跨代引用扫描大量数据,Full GC慢。

为了解决这个问题,CMS本身就有一些优化,上面link的文章已经聊到了。

那么同样是上图,发现CMS-concurrent-abortable-preclean阶段执行时间5.35s,超过了默认5s的等待,所以可以认为Remark时是没有进行Minor GC的。

这种情况下可以调高CMSMaxAbortablePrecleanTime(不推荐),或者设置CMSMaxAbortablePrecleanTime(推荐),在Remark前强制执行一次Minor GC。

启动时大量GC后趋于正常(空间震荡)

表现还是比较经典的:

  1. 启动后频繁GC。
  2. 每次GC时占用内存空间都很小,但是每次GC后都会增加。

JVM配置中,各个空间一般都是配置两个:一个正常,一个最大。而在JVM初始化的时候,是按正常的分配的。

所以说这种问题就是初始空间配置小了,很快就需要执行GC,调大即可。

显式调用

When you have eliminated the impossibles, whatever remains, however improbable, must be the truth.

如果确实排查不出来问题,全局搜一下

System.gc()

说不定确实有那个sb上传了测试代码,真的在调用。。。

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.ldbm.cn/p/430180.html

如若内容造成侵权/违法违规/事实不符,请联系编程新知网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

微服务架构-分支微服务设计模式

微服务架构-分支微服务设计模式 这种模式是聚合器模式的扩展&#xff0c;允许同时调用两个微服务链 分支微服务设计模式是一种用于构建大型系统的微服务架构模式&#xff0c;其核心思想是 将复杂的业务逻辑拆解为多个小的、相互独立的子系统&#xff0c;每个子系统由一个或多…

医疗科技:UWB模块为智能医疗设备带来的变革

随着医疗科技的不断发展和人们健康意识的提高&#xff0c;智能医疗设备的应用越来越广泛。超宽带&#xff08;UWB&#xff09;技术作为一种新兴的定位技术&#xff0c;正在引领着智能医疗设备的变革。UWB模块作为UWB技术的核心组成部分&#xff0c;在智能医疗设备中发挥着越来越…

Unity3D输入事件

文章目录 前言一、全局事件二、射线三、点选3D模型四、点击地面控制人物移动总结 前言 Unity输入事件分为两类&#xff0c;全局触发和监听式触发。全局触发通常是运行在update在每帧进行检测&#xff0c;而监听式触发是被动的输入事件。 一、全局事件 在最新的unity中有新和旧…

索引问题引起的执行计划偏移(EBS Cost Management performance issue )

之前遇到的一个EBS性能问题&#xff0c;更新至CSDN Create Accounting - Cost Management_performance issue SYMPTOMS 元旦过后&#xff0c;create accounting cost management执行时间过长&#xff0c;还时常报错&#xff0c;影响正常作业&#xff1b; 1.对比2018/12和20…

中国上市企业行业异质性数据分析

数据简介&#xff1a;企业行业异质性数据是指不同行业的企业在运营、管理、财务等方面的差异性数据。这些数据可以反映不同行业企业的特点、优势和劣势&#xff0c;以及行业间的异质性对企业经营和投资的影响。通过对企业行业异质性数据的分析&#xff0c;投资者可以更好地了解…

盲人无障碍设施建设:科技之光照亮前行之路

在这个快速发展的时代&#xff0c;科技的每一次进步都在悄然改变着我们的生活&#xff0c;尤其在提升特殊群体生活质量方面&#xff0c;展现出前所未有的力量。今天&#xff0c;让我们聚焦于盲人无障碍设施建设这一重要话题&#xff0c;通过一款名为“蝙蝠避障”的辅助软件&…

【区块链】外部应用程序与区块链进行交互

一&#xff0c;外部应用程序与区块链进行交互案例目标与流程 1.1案例目标 掌握FISCO BCOS应用环境的搭建 与使用&#xff08;FISCO BCOSWeBASE&#xff09;掌握基于Java SpringBoot的应 用程序后端项目搭建与开发。掌握应用程序后端与FISCO BCOS 链的交互。掌握应用程序前端…

算法打卡 Day13(栈与队列)-滑动窗口最大值 + 前 K 个高频元素 + 总结

文章目录 Leetcode 239-滑动窗口最大值题目描述解题思路 Leetcode 347-前 K 个高频元素题目描述解题思路 栈与队列总结 Leetcode 239-滑动窗口最大值 题目描述 https://leetcode.cn/problems/sliding-window-maximum/description/ 解题思路 在本题中我们使用自定义的单调队列…

【Linux】Linux的权限_2 + Linux环境基础开发工具_1

文章目录 三、权限3. Linux权限管理修改文件的拥有者和所属组 4. 文件的类型5. 权限掩码 四、Linux环境基础开发工具1. yumyum 工具的使用 未完待续 三、权限 3. Linux权限管理 修改文件的拥有者和所属组 在上一节我们讲到如何更改文件的访问权限&#xff0c;那我们需要更改…

ubuntu strace命令

strace 是 Linux 系统中的一个调试工具&#xff0c;用于跟踪并记录系统调用&#xff08;system calls&#xff09;和信号&#xff08;signals&#xff09;。在 Ubuntu 中&#xff0c;strace 命令可以帮助开发者和系统管理员了解一个程序在运行时如何与操作系统内核进行交互&…

【教程】利用API接口添加本站同款【每日新闻早早报】-每天自动更新,不占用文章数量

本次分享的是给网站添加一个每日早报的文章&#xff0c;可以看到本站置顶上面还有一个日更的日报&#xff0c;这是利用ALAPI的接口完成的&#xff01;利用接口有利也有弊&#xff0c;因为每次用户访问网站的时候就会增加一次API接口请求&#xff0c;导致文章的请求会因为请求量…

Pytorch 笔记

执行下面这段代码后&#xff0c;为什么返回的是 2 &#xff1f; vector torch.tensor([7, 7]) vector.shape为什么返回的是 torch.Size([2])&#xff1f; 当你创建一个PyTorch张量时&#xff0c;它会记住张量中元素的数量和每个维度的大小。在你的代码中&#xff0c;torch.t…

智慧城市运维可视化:透视未来城市高效管理的新视窗

行业痛点 现代城市运维是一个复杂而庞大的系统&#xff0c;涉及到诸多方面&#xff0c;包括交通、环境、能源等等。然而&#xff0c;在城市运维中&#xff0c;存在着一些现实的痛点&#xff0c;给城市管理者带来了不小的压力和困扰&#xff1a; 1、交通拥堵 随着城市化进程的…

【算法】位运算算法——只出现一次的数字Ⅱ

题解&#xff1a;只出现一次的数字Ⅱ(位运算算法) 目录 1.题目2.题解&#xff1a;3.代码示例4.总结 1.题目 题目链接&#xff1a;LINK 要求&#xff1a;时间复杂度&#xff1a;O(N)&#xff0c;空间复杂度&#xff1a;O(1) 2.题解&#xff1a; 3.代码示例 class Solution {…

微信小程序毕业设计-校车购票系统项目开发实战(附源码+论文)

大家好&#xff01;我是程序猿老A&#xff0c;感谢您阅读本文&#xff0c;欢迎一键三连哦。 &#x1f49e;当前专栏&#xff1a;微信小程序毕业设计 精彩专栏推荐&#x1f447;&#x1f3fb;&#x1f447;&#x1f3fb;&#x1f447;&#x1f3fb; &#x1f380; Python毕业设计…

操作系统 - 输入/输出(I/O)管理

输入/输出(I/O)管理 考纲内容 I/O管理基础 设备&#xff1a;设备的基本概念&#xff0c;设备的分类&#xff0c;I/O接口 I/O控制方式&#xff1a;轮询方式&#xff0c;中断方式&#xff0c;DMA方式 I/O软件层次结构&#xff1a;中断处理程序&#xff0c;驱动程序&#xff0c;…

go语言初识别(五)

本博客内容涉及到&#xff1a;切片 切片 1. 切片的概念 首先先对数组进行一下回顾&#xff1a; 数组定义完&#xff0c;长度是固定的&#xff0c;例如&#xff1a; var num [5]int [5]int{1,2,3,4,5}定义的num数组长度是5&#xff0c;表示只能存储5个整形数字&#xff0c…

七个很酷的GenAI LLM技术性面试问题

不同于互联网上随处可见的传统问题库&#xff0c;这些问题需要跳出常规思维。 大语言模型(LLM)在数据科学、生成式人工智能(GenAI)和人工智能领域越来越重要。这些复杂的算法提升了人类的技能&#xff0c;并在诸多行业中推动了效率和创新性的提升&#xff0c;成为企业保持竞争…

java8以上版本

java9及其以上版本 一、JDK17 LTS 常用新特性1、switch语句的增强2、字符串拼接3、判断类型instanceof自动类型转换4、密封类 关键字 sealed permits5、record类6、优化空指针异常7、ZGC垃圾收集器 一、JDK17 LTS 常用新特性 1、switch语句的增强 在 Java 17中&#xff0c;sw…

外卖系统源码开发全攻略:外卖小程序与后台管理系统的设计与实现

今天&#xff0c;小编将详细介绍外卖系统源码的开发全攻略&#xff0c;从需求分析到设计与实现&#xff0c;为开发者提供全面指导。 一、需求分析 1.用户需求 用户是外卖系统的核心&#xff0c;需满足以下基本需求&#xff1a; -浏览菜单并下单 -实时追踪订单 -多种支付方…