【Jvm】性能调优（拓展）Jprofiler如何监控和解决死锁、内存泄露问题

2024-02-19 09:36
文章标签 java 问题 jvm 内存 性能 解决 拓展 死锁 监控 泄露 调优 jprofiler

本文主要是介绍【Jvm】性能调优（拓展）Jprofiler如何监控和解决死锁、内存泄露问题，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

文章目录

    • Jprofiler简介
    • 1.安装及IDEA集成Jprofiler
    • 2.如何监控并解决死锁
    • 3.如何监控及解决内存泄露(重点)
    • 4.总结
    • 5.后话

Jprofiler简介

  • Jprofilers是针对Java开发的性能分析工具(免费试用10天), 可以对Java程序的内存,CPU,线程,GC,锁等进行监控和分析,

1.安装及IDEA集成Jprofiler

本人IDEA版本是2020.2.2,选择的Jprofiler版本是12.0(早期的版本是纯英文的,12.0支持中文,安装主要考虑是否与IDEA插件兼容即可)

  1. 进入Jprofiler官网下载 -> Jprofiler 版本这边建议选择最新的或者次新的(前提是你的IEDA版本也比较新)

  2. 打开IDEA->File->settings->plugins->marketplace->搜索 Jprofiler
    在这里插入图片描述

  3. 插件安装后, 在IDEA工具栏找到如图所示的两个图标,点击箭头指的那个,进行路径配置,让插件能找到第1步中下载好的Jprofiler:
    在这里插入图片描述

    • 选中后然后同意安装协议, 一路next确认就好了,最后选试用10天激活,如果你有秘钥可以选永久激活,至此就安装好了,然后可以通过该按钮启动应用

      在这里插入图片描述

    1. 启动后就可以获取到启动应用的各种信息了, 也可以连接远程服务器上的java应用,或者通过dump出来的文件分析等:

      在这里插入图片描述

2.如何监控并解决死锁

public static void main(String[] args) {Object a = new Object();Object b = new Object();new Thread(()->{synchronized (a){try {System.out.println("已获取到a锁,尝试获取b锁===>");Thread.sleep(1000);} catch (InterruptedException e) {e.printStackTrace();}synchronized (b){System.out.println("尝试获取b锁...");}}}).start();new Thread(()->{synchronized (b){try {System.out.println("<===已获取到b锁,尝试获取a锁");Thread.sleep(1000);} catch (InterruptedException e) {e.printStackTrace();}synchronized (a){System.out.println("尝试获取a锁...");}}}).start();}

通过Jprofiler启动这段代码,然后可以在锁菜单界面直接看到当前锁的状态图:
在这里插入图片描述

然后可以在当前Monitor监视器设置一个观察阈值, 如果项目中的锁比较多, 可以把超过一定时间的锁给筛选出来, 进一步观察是否死锁, 因为有些长时间阻塞的锁`也可能是 饿锁
在这里插入图片描述

然后针对筛选出来的几个可能是死锁的进行深入分析, 首先可以看到这些锁的类型是处于阻塞的, 然后鼠标右键任意一个锁上面 选择在堆遍历器中显式所选内容:
在这里插入图片描述
然后在对堆遍历器中点击图表, 就可以看到这个锁所在的代码位置, 然后 看一看代码就知道到底有没有死锁,还是饿锁了
在这里插入图片描述

通常来说产生死锁的原因主要有:

  1. 没有设置锁的失效时间, 然后代码里可能因为异常没有处理, 锁没有在finaly代码块中释放导致其它线程无法获取锁而陷入等待

  2. 锁互相竞争（类似上图这种） ，线程1持有A锁尝试获取B锁, 线程2持有B锁尝试获取A锁, 谁也不让谁, 互相干等着。 这种情况要注意加锁的顺序, 让线程1是先获得了A锁,再去获取B锁, 然后线程2去尝试获取A锁,再获取B锁, 按这样的顺序就不会产生死锁.

  3. 由线程优先级产生的饿锁，即高优先级线程一直占着资源不放而导致其他线程得不到执行, 饿锁不算死锁，但也要引起重视,否则同样会造成资源浪费, 可以通过JUC提供的公平锁解决.

——>按照上面的思路,去排查对应的代码,基本上死锁都能被解决.

3.如何监控及解决内存泄露(重点)

内存泄漏相对于死锁和OOM会比较难定位,而且对整个应用的危害程度比较大, 一旦发生内存泄漏,可能会导致整个应用不可用.

  • 内存泄漏可以通过JDK自带的jconsole或者jvisovm都可以监控到,这里演示下通过Jprofiler如何监控内存泄漏.

  • 通常情况下,内存泄漏会拖垮整个应用,如果应用突然不可用了, 且网络正常. 可以服务器查看应用日志, 如果看到有OOM,可以初步怀疑有内存泄漏发生, 对于比较明显 或者 比较短的时间内产生的内存泄漏, 可以通过本地IDEA直连Jprofile启动应用的方式进行监控 ,对于在特定场景下才会发生的,可以加上VM参数: -XXHeapdump重启线上应用, 以便在下次内存泄漏OOM时,导出dump日志,然后导入Jprofile进行分析. 这里我以直连本地的方式进行演示(偷个懒)

public class Test {private final static ThreadLocal<List<String>> threadLocal = new ThreadLocal<>();private final static List<String> list = new ArrayList<>();public static void main(String[] args) throws InterruptedException {ExecutorService executorService = Executors.newSingleThreadExecutor();executorService.execute(()->{while (true){for (int i = 0; i < 1000000; i++) {list.add("oom");if (i%100==0){threadLocal.set(list);}}//让过程慢一点,留点时间去分析,否则OOM之后与Jprofiler的连接就断开了try {Thread.sleep(5000);} catch (InterruptedException e) {e.printStackTrace();}}});}
}

为了尽快的看到内存泄漏又能不中断与jprofiler的连接指定最大堆为1024M(-Xmx1024m ) , 以保证上面程序运行久一点, 不因为OOM中断影响分析
在这里插入图片描述
(上图是程序运行了很久之后)

  • 用IDEA的Jprofiler插件启动Jprofiler, 切换到遥测->内存界面, 内存使用量每增长一段时间后, 手动点击一次运行GC, 观察每次GC后已使用内存部分(下图中蓝色部分), 发现每次GC之后,已使用的内存变得越来越多, 如此积累下去, 直到已使用内存超过最大堆大小,应用就无法再创建对象, 然后疯狂触发GC, 但GC后又没有效果, 最终GC过载, CPU和内存资源被榨干,服务处于不可用状态.

    一句话: 观察前一次GC 和 当前GC后 剩余已用内存 是否处于 不断递增之中,如果是 ,则极有可能发生了内存泄漏.

在这里插入图片描述
在这里插入图片描述
通过线上服务不可用 和 监控到的数据, 几乎可以确认是发生了内存泄漏,下面开始排查,到底是哪里发生了内存泄漏?写了什么禽兽代码让内存泄漏了???

  1. 第一步：通过Jprofiler连接到本地或者远程JVM(考虑到安全问题,可以用远程dump的日志导入Jprofiler)

  2. 第二步：点击实时内存菜单下的所有对象, 然后点击标记当前对象, 然后持续观察实例 计数列,相差列,大小列变化

可以从以下几个线索去缩小范围:

  1. 可能发生内存泄漏的一般有 char[],String,Map,List,Object[] 等数据,可以重点去看看

  2. 占据大量内存空间 或是 实例计数超大的

    一般会导致内存泄漏且影响到服务正常吞吐的, 大小列的值都不会太小,毕竟一个应用的最大堆至少也会指定/默认在256Mb以上,像这种几百kb级别的,即便在持续增长,想要让系统不可用,也得积累很久很久

  3. 多次点击运行GC,观察每次GC后剩余的大小,如果大小列的值增长很快,但GC后仍剩余很大,可以怀疑此处可能有内存泄漏

    比如下图被我框了的地方, GC前有400多Mb, GC后仍有186MB剩余, 整个堆区在GC后剩余的总垃圾也不过189MB, 这玩意就独占鳌头186Mb,回收不掉, 隔一阵子再点GC,GC后这个值比186MB还大,再次印证该类很可能存在内存泄漏)

    在这里插入图片描述

    通过上面3种排查方式,逐步缩小排查范围,目前看下来就只有char[],String,Object[]三种类型的数据可能存在内存泄露

  • 第三步: 选中可疑项,点击鼠标右键,选择在堆遍历器中显式

在这里插入图片描述

在打开的新界面中,点击最大对象, 然后选中保留大小最大的(有的时候有好几个都挺大的,只能一一尝试,因为保留大小偏大的一般都可能导致内存泄漏),然后点击鼠标右键,使用选中对象

在这里插入图片描述
然后选择传入引用,点击确定
在这里插入图片描述
在下图中的界面,可以先展开树形结构的数据看一下,这个Oject[]底下是什么东西, 一般来说如果点开是大公司打头的包名,基本可以直接跳过不用看了,因为一般大公司的产品不大会出现内存泄漏,发布之前他们应该也有测过了.

  • 如果看了下包名,是自己应用的包名,就可以继续排查,点击在图表中显示
    在这里插入图片描述

在弹出的新页面中选中上一步中看到的ArrayList对象,点击显示到GC根的路径:

在这里插入图片描述
在这里插入图片描述
然后可以点开+号,瞅瞅, 基本上到这一步,就能确认到发生内存泄漏的代码所在的包名+类名了, 然后重点去排查这段代码即可
在这里插入图片描述
原因 :

  • 因为ThreadLocal持有List<String>,然后ThreadLocal并没有remove(),导致List<String>被强引用,无法被GC,致使内存泄漏.

4.总结

  1. 如果没有Jprofiler这类工具, 在生产环境发生内存泄漏, 去一行一行review所有代码是不现实的, 通过此工具我们可以在较短的时间内定位到导致内存泄漏出现的代码位置, 然后review该位置的代码即可.

  2. 内存泄漏的难的主要是定位, 解决起来一般比较简单, 重启生产环境应用,让服务恢复正常, 然后在把导致内存泄漏的代码优化(该释放的释放,强引用显示置为为null...),改好之后测试并重新发布即可解决.

5.后话

当这些问题出现在生产环境时,一般都会带来严重的损失,而且排查和分析起来难度非常大, 在养成良好编码习惯, 尽量去规避死锁,内存溢出,及内存泄漏, 防患于未然是最好的。

  • 多学点监控和解决方式, 或许有一天还真能派上用场.像这类低频使用的知识, 最好能总结一遍,留下文档,下次再碰到时,可以快速回忆,

这篇关于【Jvm】性能调优（拓展）Jprofiler如何监控和解决死锁、内存泄露问题的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！


http://www.chinasem.cn/article/724268。

相关文章

Vue3 的 shallowRef 和 shallowReactive：优化性能

Vue3 的 shallowRef 和 shallowReactive：优化性能

大家对 Vue3 的 ref 和 reactive 都很熟悉，那么对 shallowRef 和 shallowReactive 是否了解呢？ 在编程和数据结构中，“shallow”（浅层）通常指对数据结构的最外层进行操作，而不递归地处理其内部或嵌套的数据。这种处理方式关注的是数据结构的第一层属性或元素，而忽略更深层次的嵌套内容。 1. 浅层与深层的对比 1.1 浅层（Shallow） 定义
阅读更多...
JVM 的类初始化机制

JVM 的类初始化机制

前言 当你在 Java 程序中new对象时，有没有考虑过 JVM 是如何把静态的字节码（byte code）转化为运行时对象的呢，这个问题看似简单，但清楚的同学相信也不会太多，这篇文章首先介绍 JVM 类初始化的机制，然后给出几个易出错的实例来分析，帮助大家更好理解这个知识点。 JVM 将字节码转化为运行时对象分为三个阶段，分别是：loading 、Linking、initialization
阅读更多...
Spring Security 基于表达式的权限控制

Spring Security 基于表达式的权限控制

前言 spring security 3.0已经可以使用spring el表达式来控制授权，允许在表达式中使用复杂的布尔逻辑来控制访问的权限。 常见的表达式 Spring Security可用表达式对象的基类是SecurityExpressionRoot。 表达式描述hasRole([role])用户拥有制定的角色时返回true （Spring security默认会带有ROLE_前缀）,去
阅读更多...
浅析Spring Security认证过程

浅析Spring Security认证过程

类图 为了方便理解Spring Security认证流程，特意画了如下的类图，包含相关的核心认证类 概述 核心验证器 AuthenticationManager 该对象提供了认证方法的入口，接收一个Authentiaton对象作为参数; public interface AuthenticationManager {Authentication authenticate(Authenti
阅读更多...
Spring Security--Architecture Overview

Spring Security--Architecture Overview

1 核心组件 这一节主要介绍一些在Spring Security中常见且核心的Java类，它们之间的依赖，构建起了整个框架。想要理解整个架构，最起码得对这些类眼熟。 1.1 SecurityContextHolder SecurityContextHolder用于存储安全上下文（security context）的信息。当前操作的用户是谁，该用户是否已经被认证，他拥有哪些角色权限…这些都被保
阅读更多...
Spring Security基于数据库验证流程详解

Spring Security基于数据库验证流程详解

Spring Security 校验流程图 相关解释说明（认真看哦） AbstractAuthenticationProcessingFilter 抽象类 /*** 调用 #requiresAuthentication(HttpServletRequest, HttpServletResponse) 决定是否需要进行验证操作。* 如果需要验证，则会调用 #attemptAuthentica
阅读更多...
Spring Security 从入门到进阶系列教程

Spring Security 从入门到进阶系列教程

Spring Security 入门系列 《保护 Web 应用的安全》 《Spring-Security-入门（一）：登录与退出》 《Spring-Security-入门（二）：基于数据库验证》 《Spring-Security-入门（三）：密码加密》 《Spring-Security-入门（四）：自定义-Filter》 《Spring-Security-入门（五）：在 Sprin
阅读更多...
Java架构师知识体认识

Java架构师知识体认识

源码分析 常用设计模式 Proxy代理模式Factory工厂模式Singleton单例模式Delegate委派模式Strategy策略模式Prototype原型模式Template模板模式 Spring5 beans 接口实例化代理Bean操作 Context Ioc容器设计原理及高级特性Aop设计原理Factorybean与Beanfactory Transaction 声明式事物
阅读更多...
流媒体平台/视频监控/安防视频汇聚EasyCVR播放暂停后视频画面黑屏是什么原因？

流媒体平台/视频监控/安防视频汇聚EasyCVR播放暂停后视频画面黑屏是什么原因？

视频智能分析/视频监控/安防监控综合管理系统EasyCVR视频汇聚融合平台，是TSINGSEE青犀视频垂直深耕音视频流媒体技术、AI智能技术领域的杰出成果。该平台以其强大的视频处理、汇聚与融合能力，在构建全栈视频监控系统中展现出了独特的优势。视频监控管理系统EasyCVR平台内置了强大的视频解码、转码、压缩等技术，能够处理多种视频流格式，并以多种格式（RTMP、RTSP、HTTP-FLV、WebS
阅读更多...
性能测试介绍

性能测试介绍

性能测试是一种测试方法，旨在评估系统、应用程序或组件在现实场景中的性能表现和可靠性。它通常用于衡量系统在不同负载条件下的响应时间、吞吐量、资源利用率、稳定性和可扩展性等关键指标。 为什么要进行性能测试 通过性能测试，可以确定系统是否能够满足预期的性能要求，找出性能瓶颈和潜在的问题，并进行优化和调整。 发现性能瓶颈：性能测试可以帮助发现系统的性能瓶颈，即系统在高负载或高并发情况下可能出现的问题
阅读更多...

Copyright China编程 23002807@qq.com

沪ICP备2023033072号-2