Loading...
墨滴

阿东lazy

2021/08/02  阅读:26  主题:蔷薇紫

深入理解JVM - 案例实战

深入理解JVM - 案例实战

前言:

​ 这一篇文章还是讲实战,但是内容并不是很多,下一篇会出一个阶段总结对于之前的内容进行回顾。

前文回顾

​ 上一节深入扩展了JVM工具jstat是如何使用了,但是从实际场景可以看出,更多情况是代码的问题,或者因为好奇害死猫乱设置参数导致线上各种报错或者频繁的卡死,这里还是再次强调一句不要使用System.gc()这个臭名昭著的方法,最好是JVM禁止此方法的运行。

本文概述

  1. 排查Full Gc的套路是什么,这里用一个电商案例来进行说明。
  2. spilt()方法是如何造成内存泄露的?如何通过可视化图形分析出问题。以及如何从源代码层面发现根本问题

思维导图:

幕布:https://www.mubucm.com/doc/IgrEXbw6vB

电商案例-排查Full GC套路

主要业务:

​ 在日常场景进行发邮箱,短信以及APP 的推送消息一些特别活动。

​ 这种业务的特点是短时间之内会有大量的用户进入APP进行参与,这时候系统的压力会突然增加。

问题:

​ 在业务流量高峰的时候,CPU的使用率十分十分高,并且直接导致系统卡死,无法进行任何请求的处理,在系统重启之后会好一段时间,但是后面又会马上卡死。

初步排查:

  • 首先我们需要排查是否为 线程创建过多:线程过多并且并发执行差,所以CPU的上下文切换十分频繁,压力很大
  • 频繁的FULL GC导致系统卡顿

​ 通过这种思路排查,结果果然发现FULL GC的频率十分高,居然一分钟一次FULL GC,频率实在是太高了。

初步排查FULL GC的套路有哪些:(重点)

  1. 内存分配不合理,对象频繁进入老年代,引发频繁FULL GC
  2. 内存泄露问题,内存驻留大量的老年代对象,一有对象就会触发FULL GC,比如之前提到的全表查询引发海量对象
  3. 永久代的类太多,触发 FULL GC

继续排查:

​ 继续排查发现使用jstat发现并不存在内存不合理的情况,并且对象也是正常进入老年代,同时永久代的内存居然也是正常的。

​ 这时候又会考虑一个问题,一分钟一次FULL GC,证明老年代空间是不够的,虽然新生代进入老年代是正常的,但是如果老年代 本身对象就非常多,会不会也会出现问题呢?按照这个思路继续排查,果然发现老年代GC之后 居然还有那么多对象存活

​ 真相大白,原因就是老年代被大量对象占满了,很容易触发FULL GC,我们可以使用Jmap的工具排查这里面的内容,当然,也可以使用mat(memory anaylyze tool)进行排查,但是本文不涉及工具的使用介绍,大致介绍一下mat的处理流程:

MAT的排查进程:

jmap -dump:format=b,file=文件名[服务进程ID]

1. 首先内存快照,可以看到当前内存情况
2. 其次发现内存泄露
3. 创建的对象占比量过大
4. 发现原因是jvm缓存没有及时进行清理,导致内存越来越大
5. 排查结果是本地内存没有进行限制,同时没有定期淘汰算法
6. 解决办法使用一些EHCACASH的缓存即可

解决方式:

  1. 使用JSTAT和JMAP找到让对象大量创建的原因
  2. 使用MAT 软件进行分析
    1. jmap -dump:format=b,file=文件名[服务进程ID]
    2. 使用jhat等可视化图形工具进行分析。
  3. 解决代码层面短时间大量创建对象的问题。

总结:

​ 其实按照排查思路进行一步步排查,要找到问题其实并不是很难。

String.split是如何造成内存泄露的

主要业务:

​ 业务就直接跳过,这里重点关注问题分析和解决流程。

问题分析:

  1. 发现也是CPU突然爆高,但是可以看到新生代和老年代居然同时有10G的内存大小
  2. 发现每两分钟就会有一次FULL GC同时伴随着系统的资源高度占用
  3. 不是简单的改一下JVM参数就可以解决的事情,排查发现代码出了问题。

​ 不用说,标题已经暴露了一切,但是究竟是如何分析出来的?这里也不兜圈子,直接给一张图,:

Problem Suspect 1

​ 从这里看到java.lang.Thread的主线程main 线程,局部变量居然占用了**24.97%**的内存的对象。这里告诉你问题出现在java.lang.Object[]数组,这个数组占用大量的内存。

​ 在1的下面有一行蓝色的 Details,进入之后可以看到下面的内容:

Problem Supspect 3里面也可以看到这里面占用了大量的String对象。

​ 从这里可以看到在main线程里面,有一个arrayList集合占用了几乎所有的内存,这个List显然也是Object[]的数组,并且在内容里面存在Demo1$Data的对象实例。

​ 从这个分析我们知道了如何分析出内存占用的问题,其实大胆猜测加上实用工具测试可以基本都可以验证出问题。

trance链路追踪:

​ 知道了占用是因为Object[]数组的问题,接着来看下链路追踪的情况:

​ 如上图所示,我们点击statictrace进入到具体的代码界面:

​ 答案在最下面的图:

​ 我们可以明显的看到是String的问题,通过代码搜索发现有一个String.split可能是产生问题的原因。

为什么String.split()会造成内存泄露

​ 这里就涉及一个JDK源代码的问题了:

​ 在JDK6的版本,一个字符串的底层是基于下面的形式进行存储的,比如"yes yes yes yes"使用空格切分是如下的形式:

["yes","yes","yes","yes"]

​ 但是到了Jdk7,他给每个切分出来的字符串都创建了一个新的数组,意思就是说每次切分都切分出一个新的数组,这里可能没法理解,所以我们给出代码:

if (xxxxx)// 一大堆判断,不用管,总之大部分情况你都会进这个If判断
{    
    return list.subList(0, resultSize).toArray(result);
}
return Pattern.compile(regex).split(this, limit);

​ 这个sublist毫无疑问就是罪魁祸首了,导致JDK版本升级了之后内存占用爆高也是这个代码,这个代码干了啥呢?

public List<E> subList(int fromIndex, int toIndex) {
    subListRangeCheck(fromIndex, toIndex, size);
    return new SubList(this0, fromIndex, toIndex);
}

​ 这个也是典型的面试题,可用看到返回了当前List的视图,同时这个视图会随着数组的改变而改变,关于这个对象细节百度一大堆,这里不讨论,这里需要关注的是这个new

​ 到这里相信读者也清楚为什么split()方法会导致大量的Object[]数组被构建出来,SubList底层依然是一个数组!

解决方式:

​ 说白了还是代码的质量问题,不用想可以知道需要从代码层面修复问题,解决fot循环里面的split()方法。

​ 所以字符串的操作尤其需要谨慎,因为字符串天生的不可变的特性,使用频率非常高的同时也很容易出现问题。

总结:

​ 这篇文章内容不多,主要为下面两个点:

  1. 通过可视化工具以及代码排查,可以从分析图表里面看到根本的代码问题点
  2. 关于FULL GC的常见排查讨论

写在最后

​ 感谢各位的观看,下一篇文章为阶段总结。

阿东lazy

2021/08/02  阅读:26  主题:蔷薇紫

作者介绍

阿东lazy