目录

一.内存泄漏

1.1内存泄漏的常见场景

1.2解决内存溢出的思路

二.发现问题

2.1监控工具

VisualVM

Arthas

Prometheus + Grafana

2.2堆内存状况的对比

三.内存溢出的产生原因

①代码中的内存泄漏

equals()和hashCode()未重写导致的内存泄漏

内部类引用外部类

ThreadLocal的使用

通过静态字段保存对象

资源没有正常关闭

②并发请求问题

四.诊断原因

4.1离线诊断:生成内存快照并分析

4.1.1内存快照

4.1.2内存分析工具(MAT)

4.1.3MAT内存泄漏检测的原理

支配树

深堆和浅堆

4.1.4分析超大堆的内存快照

4.2在线定位问题

五.案例分析

案例1 – 分页查询接口的内存溢出

案例2 – Mybatis在使用foreach进行sql拼接时导致的内存溢出

案例3 – 导出大文件内存溢出

案例4 – ThreadLocal使用时占用大量内存

案例5 – 异步业务处理

Java虚拟机进行生产环境线上问题解决以及性能问题的优化。

一.内存泄漏

内存泄漏(memory leak):在Java中如果不再使用一个对象,但是该对象依然在GC ROOT的引用链上,这个对象就不会被垃圾回收器回收,这种情况就称之为内存泄漏。少量的内存泄漏可以容忍,但是如果发生持续的内存泄漏,就像滚雪球雪球越滚越大,不管有多大的内存迟早会被消耗完,最终导致的结果就是内存溢出。但是产生内存溢出并不是只有内存泄漏这一种原因。内存泄漏绝大多数情况都是由堆内存泄漏引起的,没有特别说明则讨论的都是堆内存泄漏。

1.1内存泄漏的常见场景

内存泄漏导致溢出的常见场景是大型的Java后端应用中,在处理用户的请求之后,没有及时将用户的数据删除。随着用户请求数量越来越多,内存泄漏的对象占满了堆内存最终导致内存溢出。这种产生的内存溢出会直接导致用户请求无法处理,影响用户的正常使用。重启可以恢复应用使用,但是在运行一段时间之后依然会出现内存溢出。

第二种常见场景是分布式任务调度系统如Elastic-job、Quartz等进行任务调度时,被调度的Java应用在调度任务结束中出现了内存泄漏,最终导致多次调度之后内存溢出。这种产生的内存溢出会导致应用执行下次的调度任务执行。同样重启可以恢复应用使用,但是在调度执行一段时间之后依然会出现内存溢出。

1.2解决内存溢出的思路

解决内存溢出的步骤总共分为四个步骤,其中前两个步骤是最核心的:

二.发现问题

2.1监控工具

VisualVM

VisualVM是多功能合一的Java故障排除工具并且他是一款可视化工具,整合了 命令行 JDK 工具和轻量级分析功能,功能非常强大。这款软件在Oracle JDK 6~8 中发布,但是在 Oracle JDK 9 之后不在JDK安装目录下需要单独下载。下载地址:VisualVM: Home

优点:功能丰富,实时监控CPU、 内存、线程等详细信息 缺点:

适用于开发、测试环境,不适用于生产环境,VisualVM部分功能会停止所有的线程,这会影响到用户的使用对大量集群化部署的Java进程需要手动进行管理

Arthas

Arthas 是一款线上监控诊断产品,通过全局视角实时查看应用 load、内存、gc、线程的状态信息,并能在不修改应用代码的情况下,对业务问题进行诊断, 包括查看方法调用的出入参、异常,监测方法执行耗时,类加载信息等,大大提升线上问题排查效率。arthas (aliyun.com)

优点:

功能强大,不止于监控基础的信息,还能监控单个方法的执行耗时等细节内容。支持应用的集群管理,使用阿里arthas tunnel可以管理所有的需要监控的程序开发人员可以在线解决生产问题。无需 JVM 重启,无需代码更改。 Arthas 作为观察者永远不会暂停正在运行的线程。

Prometheus + Grafana

Prometheus+Grafana是企业中运维常用的监控方案,其中Prometheus用来采集系统或者应用的相关数据,同时具备告警功能。Grafana可以将Prometheus采集到的数据以可视化的方式进行展示。

优点:

支持系统级别和应用级别的监控,比如linux操作系统、Redis、MySQL、Java进程支持告警并允许自定义告警指标,通过邮件、短信等方式尽早通知相关人员进行处理

2.2堆内存状况的对比

三.内存溢出的产生原因

①代码中的内存泄漏

实际上,代码中的内存泄漏大部分能在测试环境上被排除。在测试环境上采用压力测试,发送大量的请求到服务端测试。

equals()和hashCode()未重写导致的内存泄漏

问题:在定义新类时没有重写正确的equals()和hashCode()方法。在使用HashMap的场景下,如果使用这个类对象作为key,HashMap在判断key是否已经存在时会使用这些方法,如果重写方式不正确,会导致相同的数据被保存多份。

内部类引用外部类

问题:

非静态的内部类默认会持有外部类,尽管代码上不再使用外部类,所以如果有地方引用了这个非静态内部类,会导致外部类也被引用,垃圾回收时无法回收这个外部类。匿名内部类对象如果在非静态方法中被创建,会持有调用者对象,垃圾回收时无法回收调用者。

解决方案:

如果不想持有外部类对象,应该使用静态内部类。 使用静态方法,可以避免匿名内部类持有调用者对象。

ThreadLocal的使用

问题:如果仅仅使用手动创建的线程,就算没有调用ThreadLocal的remove方法清理数据,也不会产生内存泄漏。因为当线程被回收时,ThreadLocal也同样被回收。但是如果使用线程池就不一定了。

解决方案:线程方法执行完,一定要调用ThreadLocal中的remove方法清理对象。

通过静态字段保存对象

问题:如果大量的数据在静态变量中被长期引用,数据就不会被释放,如果这些数据不再使用,就成为了内存泄漏。

解决方案:

尽量减少将对象长时间的保存在静态变量中,如果不再使用,必须将对象删除(比如在集合中)或 者将静态变量设置为null。 使用单例模式时,尽量使用懒加载,而不是立即加载。Spring的Bean中不要长期存放大对象,如果是缓存用于提升性能,尽量设置过期时间定期失效。

资源没有正常关闭

问题:连接和流这些资源会占用内存,如果使用完之后没有关闭,这部分内存不一定会出现内存泄漏

解决方案:从 Java 7 开始,使用try-with-resources语法可以用于自动关闭资源。

②并发请求问题

并发请求问题指的是用户通过发送请求向Java应用获取数据,正常情况下Java应用将数据返回之后,这部分数据就可以在内存中被释放掉。但是由于用户的并发请求量有可能很大,同时处理数据的时间很长,导致大量的数据存在于内存中,最终超过了内存的上限,导致内存溢出。

四.诊断原因

4.1离线诊断:生成内存快照并分析

4.1.1内存快照

当堆内存溢出时,需要在堆内存溢出时将整个堆内存保存下来,生成内存快照(Heap Profile )文件。生成内存快照的Java虚拟机参数:-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=

-XX:+HeapDumpOnOutOfMemoryError 发生OutOfMemoryError错误时,自动生成hprof内存快照文件。 XX:HeapDumpPath= 指定hprof文件的输出路径。使用内存分析工具MAT(Memory Analyzer Tool)打开hprof文件,并选择内存泄漏检测功能,MAT会自行根据内存快照中保存的数据分析内存泄漏的根源。

如果并未产生内存溢出,也可以导出运行中系统的内存快照,比较简单的方式有两种,注意只需要导出标记为存活的对象:

通过JDK自带的jmap命令导出,格式为: jmap -dump:live,format=b,file=文件路径和文件名 进程ID 通过arthas的heapdump命令导出,格式为: heapdump --live 文件路径和文件名

加上 live 后会自动做一次Full GC,只保留存活的对象,生成快照

4.1.2内存分析工具(MAT)

我们用下面的程序来模拟内存溢出的场景:

/**

* 内存溢出的参数

* -Xms20m -Xmx20m -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=D:\Develop_Tools\Java\hprof

* 分析内存溢出:

* 1.占用内存过大的对象有哪些(Histogram)

* 2.被谁引用的(dominator_tree)

* 3.定位到具体的代码(thread_overview)

*/

public class OOMTest {

public static void main(String[] args) {

List memoryLeakArray=new ArrayList<>();

for(int i=0;i<100;i++){

byte[] temp=new byte[1024*1024];//添加 1m 的数据到list中

memoryLeakArray.add(temp);

}

}

}

这里我使用的内存分析工具是 Eclipse Memory Analyzer,分析内存溢出主要分3个步骤:

占用内存过大的对象有哪些(Histogram)  被谁引用的(dominator_tree)  定位到具体的代码(thread_overview)

Histogram(直方图):查看内存占用

dominator_tree(支配树):关系引用图

thread_overview:查看线程的概览信息

定位到了具体的26行代码

4.1.3MAT内存泄漏检测的原理

支配树

MAT提供了称为支配树(Dominator Tree)的对象图。支配树展示的是对象实例间的支配关系(非引用关系)。在对象引用图中,所有指向对象B的路径都经过对象A,则认为对象A支配对象B。MAT就是根据支配树,从叶子节点向根节点遍历,如果发现深堆的大小超过整个堆内存的一定比例阈值,就会将其标记成内存泄漏的“嫌疑对象”。

深堆和浅堆

支配树中对象本身占用的空间称之为浅堆(Shallow Heap)。支配树中对象的子树就是所有被该对象支配的内容,这些内容组成了对象的深堆(Retained Heap),也称之为保留集( Retained Set ) 。深堆的大小表示该对象如果可以被回收,能释放多大的内存空间。

4.1.4分析超大堆的内存快照

在程序员开发用的机器内存范围之内的快照文件,直接使用MAT打开分析即可。但是经常会遇到服务器上的程序占用的内存达到10G以上,开发机无法正常打开此类内存快照,我们可以找一台内存足够的服务器,在服务器上使用MAT。

此时需要下载服务器操作系统对应的MAT。下载地址:Eclipse Memory Analyzer Open Source Project | The Eclipse Foundation

然后通过MAT中的脚本生成分析报告(体积很小,包括了一些静态页面),下载到开发机上

./ParseHeapDump.sh 快照文件路径 org.eclipse.mat.api:suspects

org.eclipse.mat.api:overview org.eclipse.mat.api:top_components

suspects:内存泄漏检测报告overview:总览图top_components:组件图

注意:默认MAT分析时只使用了1G的堆内存,如果快照文件超过1G,需要修改MAT目录下的 MemoryAnalyzer.ini配置文件调整最大堆内存。

还可以使用 HeapHero 智能分析堆内存快照,官方网站:Brilliant Graphs, metrics and java heap dump analysis anti-patterns reported (heaphero.io)

4.2在线定位问题

五.案例分析

解决思路:

服务出现OOM内存溢出时,生成内存快照。 使用MAT分析内存快照,找到内存溢出的对象。 尝试在开发环境中重现问题,分析代码中问题产生的原因。 修改代码。 测试并验证结果。

案例1 – 分页查询接口的内存溢出

我们通过观察支配树,将深堆从大到小的排序,发现Tomcat的工作线程对象居于前列

我们查看Tomcat的工作线程对象的支配树,可以看到HandlerMethod,即Controller中的方法接口,查看它的outgoing references。

outgoing references:该对象引用了哪些对象incoming references:该对象被哪些对象所引用

根据description可以找到当前线程正在执行哪个接口方法

案例2 – Mybatis在使用foreach进行sql拼接时导致的内存溢出

问题根源:

Mybatis在使用foreach进行sql拼接时,会在内存中创建对象,如果foreach处理的数组或者集合元素个数过多,会占用大量的内存空间。

解决思路:

限制集合元素个数将id缓存到redis或者内存缓存中,通过缓存进行校验

案例3 – 导出大文件内存溢出

问题根源:

Excel文件导出如果使用POI的XSSFWorkbook,在大数据量(几十万)的情况下会占用大量 的内存。

解决思路:

使用poi的SXSSFWorkbookhutool提供的BigExcelWriter减少内存开销使用easy excel,对内存进行了大量的优化,但由于是分片写,导出时间较长

案例4 – ThreadLocal使用时占用大量内存

ThreadLocal有个经典的应用场景:当一个用户请求到服务时,拦截器会根据请求头信息组装一个用户信息的对象放到ThreadLocal中,这样方便我们后面在Controller层、Service层等地方使用,但是在拦截器的afterCompletion方法中,必须要将ThreadLocal 中的数据清理掉。

案例5 – 异步业务处理

存在问题:

线程池参数设置不当,会导致大量线程的创建或者队列中保存大量的数据。 任务没有持久化,一旦走线程池的拒绝策略或者服务宕机、服务器掉电等情况很有可能会丢失任务。

存在问题:

队列参数设置不正确,会保存大量的数据。 需要自行实现持久化的机制,否则数据会丢失。

参考阅读

评论可见,请评论后查看内容,谢谢!!!
 您阅读本篇文章共花了: