【开发篇】一、内存泄漏的分析工具

文章目录

1、内存泄漏
2、解决内存泄漏
3、工具一：Top
4、工具二：VisualVM
5、工具三：阿尔萨斯Arthas
6、工具四：Promethus + Grafana
7、图像分析

1、内存泄漏

一个对象不再使用后，（因其从GC Root仍有引用链可达）却未被JVM回收，白白占着内存，即内存泄漏，这个效果累积，最后就会OOM。

在这里插入图片描述

2、解决内存泄漏

发现：设置监控告警，内存占用超过阈值就发送警告邮件
诊断：借助分析工具
修复：修复代码或做设计方案调整
验证

3、工具一：Top

Linux下：

top

在这里插入图片描述

4、工具二：VisualVM

可视化分析工具，Oracle JDK 6~8 中自带，双击运行：

在这里插入图片描述

Oracle JDK 9之后需要单独安装，下载地址：https://visualvm.github.io/

在这里插入图片描述

本地启动Visual VM：

解压即可使用，双击启动：

在这里插入图片描述

这里展示了当前本地启动的Java进程：

在这里插入图片描述

切换到Monitor监控tab页，这里有CPU、堆、元空间、类、线程，可勾选要展示和监控的内容：

在这里插入图片描述

看下整体信息，正常展示了我在IDEA加的启动JVM参数：

在这里插入图片描述

查看堆和元空间的走向：这里有size向max扩容的知识点，别看到高的线就认为空间不足

在这里插入图片描述

IDEA的插件版的Visual VM：

在这里插入图片描述

安装完成后，再次setting-> Other Setting，选择exe的目录：

在这里插入图片描述

此时的这两个按钮，就等于普通的debug / run 再加一个启动Visual VM：

在这里插入图片描述

点击启动程序，直接打开Visual VM，并定位到这个进程。

Visual VM远程监控线上服务：

以上为本地的监控，如果是远程线上服务的监控，需要添加JVM参数：

java -jar
-Djava.rmi.server.hostname=10.4.134.198  //hostname为远程主机地址
-Dcom.sun.management.jmxremote //开启jmx远程访问的功能
-Dcom.sun.management.jmxremote.port=80  //设置jmx远程访问的端口号，比如9122
-Dcom.sun.management.jmxremote.rmi.port=80
-Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false //关掉ssl以及认证这两个安全与权限的认证
demo-0.0.1.jar

打开jmx，选远程，右键Add Remote Host：

在这里插入图片描述

右键Add JMX Connection:

在这里插入图片描述
加上前面的端口：

在这里插入图片描述

监控成功：

在这里插入图片描述

但不建议给生产环境用，因为要保证生产环境的稳定，而Full GC和Heap Dump生成内存快照的这两个功能会停止用户线程。还有，如果是集群化部署，不是上面的java -jar一个jar包，远程就很不方便。

在这里插入图片描述

//连接远程踩坑帖子
https://blog.csdn.net/qq_27641935/article/details/102919542

5、工具三：阿尔萨斯Arthas

微服务架构下，在每个pod里去启动Arthas很繁琐（当然临时排查一下某单个服务的话这样也挺好），可以使用Arthas的tunnel管理所有的需要监控的服务。实现步骤：

微服务pom中添加arthas的起步依赖（有公共的common模块的话，扔common也行）

在这里插入图片描述

写arthas的配置

在这里插入图片描述

在某服务器上启动tunnel服务端程序，各个微服务间http端口号和telnet远程连接端口号不要重复

//tunnel服务端jar是是一个Spring Boot插件打的jar，可直接启动
//-Darthas.enable-detail-pages=true参数，让tunnel提供一个页面供我们去看注册上来的应用，默认8080端口访问
nohup java -jar -Darthas.enable-detail-pages=true arthas-tunnel-server-3.7.1-fatjar.jar &

重启微服务
访问tunnel页面，查看所有进程并进行arthas的操作

在这里插入图片描述

Arthas的tunnel（隧道），适用于生产、测试环境下，管理微服务的集群。

//见鬼，为什么-Dserver.port=8081会端口占用，--server.port=8081就没事
-Dserver.port=8081
--server.port=8081

6、工具四：Promethus + Grafana

Promethus收集应用的数据，Grafann以可视化方式展示。首先需要微服务中引入actuator，以http的方式将服务对应的指标向外暴露，以便Promethus收集

在这里插入图片描述
配置：

再引入另一依赖：micrometer，将JVM、数据库连接池的信息、磁盘信息等收集上来，组装成Prometheus能识别的格式

在这里插入图片描述

调接口看下暴露出来的promethues相关的端点信息

在这里插入图片描述

再往后就是Promethues的部署、连接了。略了。

7、图像分析

正常的堆内存变化图：

在这里插入图片描述

特点：

上下起伏，创建对象频繁时会升高，Young GC后会下降
Full GC后骤降，且降完后的值和之前接近（这就说明这段时间内没有产生不可被回收的对象，即没有内存泄漏）
长时间看，整条线在一个区间内上下波动，而不是逐渐上升

有内存泄漏的堆内存变化图：

在这里插入图片描述

特点：

持续增长，YounGC也不会降太多
两次Full GC的内存量有落差
长远看，整体占用量一直在上升

最后，可以使用Visual VM的采样tab页，查看当前堆里的对象信息。点Perform GC来Full GC，发现这块空间一直不能降，大概率问题就在这儿。

在这里插入图片描述

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

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