[JVM] JVM内存调优

🌸个人主页:https://blog.csdn.net/2301_80050796?spm=1000.2115.3001.5343
🏵️热门专栏:
🧊 Java基本语法(97平均质量分)https://blog.csdn.net/2301_80050796/category_12615970.html?spm=1001.2014.3001.5482
🍕 Collection与数据结构 (93平均质量分)https://blog.csdn.net/2301_80050796/category_12621348.html?spm=1001.2014.3001.5482
🧀线程与网络(97平均质量分) https://blog.csdn.net/2301_80050796/category_12643370.html?spm=1001.2014.3001.5482
🍭MySql数据库(95平均质量分)https://blog.csdn.net/2301_80050796/category_12629890.html?spm=1001.2014.3001.5482
🍬算法(97平均质量分)https://blog.csdn.net/2301_80050796/category_12676091.html?spm=1001.2014.3001.5482
🍃 Spring(97平均质量分)https://blog.csdn.net/2301_80050796/category_12724152.html?spm=1001.2014.3001.5482
🎃Redis(97平均质量分)https://blog.csdn.net/2301_80050796/category_12777129.html?spm=1001.2014.3001.5482
🐰RabbitMQ(97平均质量分) https://blog.csdn.net/2301_80050796/category_12792900.html?spm=1001.2014.3001.5482
感谢点赞与关注~~~

在这里插入图片描述

1. 内存溢出和内存泄漏
- 1.1 基本概念
- 1.2 内存泄漏的常见场景
- 1.3 常见的虚拟机参数
2. 解决内存溢出的办法
- 2.1 常用的监控工具
- - 2.1.1 Top命令:
  - 2.2.2 VisualVM
  - 2.2.3 Arthas
  - 2.2.4 使用阿里arthas tunnel管理所有的需要监控的程序
  - 2.2.5 Prometheus+Grafana
- 2.2 堆内存情况的对比
- 2.3 产生内存溢出的原因一: 代码中的内存泄漏
- - 2.3.1 equals和hashCode导致的内存泄漏
  - 2.3.2 内部类引用外部类
  - 2.3.3 ThreadLocal的使用
  - 2.3.4 String的intern方法
  - 2.3.5 通过静态字段保存对象
  - 2.3.6 资源没有正常关闭
- 2.4 产生内存溢出的原因二: 并发请求问题
- 2.5 诊断
- - 2.5.1 内存快照
  - 2.5.2 MAT内存泄漏检测原理
  - 2.5.3 服务器上的内存快照导出和分析
  - - 背景:
    - 思路:

1. 内存溢出和内存泄漏

1.1 基本概念

内存泄漏: 在java中如果不再使用一个对象,但是该对象依然在GC Root的引用链上,这个对象就不会被垃圾回收器回收,这种情况就称之为内存泄漏.
内存泄漏绝大多数都是由对内存泄漏引起的,所以后续没有特别说明则讨论的都是堆内存泄漏.
比如图中,如果学生对象1不再使用
在这里插入图片描述
可以选择将ArrayList到学生对象1的引用删除:

或者将对象A堆ArrayList的引用删除,这样所有的学生包括ArrayList都可以回收:

但是如果不移除这两个引用中的任何一个,学生对象1就属于内存泄漏了.
少量的内存泄漏可以容忍,但是如果发生持续的内存泄漏,就像滚雪球一样越滚越大,不管由多大的内存迟早会被消耗完,最终导致内存溢出,但是产生的内存溢出并不只有内存泄漏这一种原因.
在这里插入图片描述
这些学生对象如果都不再使用,越积越多,就会导致超过堆内存的上限出现内存溢出.
正常情况的内存结构图如下:

内存溢出出现时如下:

内存泄漏的对象依然在GC Root引用链上需要使用的对象加起来沾满了内存空间,无法为新的对象分配内存.

1.2 内存泄漏的常见场景

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

在这里插入图片描述
代码:

package com.itheima.jvmoptimize.controller;

import com.itheima.jvmoptimize.entity.UserEntity;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.PostMapping;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;

import java.util.ArrayList;
import java.util.HashMap;
import java.util.List;
import java.util.Map;

@RestController
@RequestMapping("/leak2")
public class LeakController2 {
    private static Map<Long,Object> userCache = new HashMap<>();

    /**
     * 登录接口 放入hashmap中
     */
    @PostMapping("/login")
    public void login(String name,Long id){
        userCache.put(id,new byte[1024 * 1024 * 300]);
    }


    /**
     * 登出接口，删除缓存的用户信息
     */

    @GetMapping("/logout")
    public void logout(Long id){
        userCache.remove(id);
    }

}

设置虚拟机参数,将最大堆内存设置为1g:
在这里插入图片描述
PostMan连续调用login传递不同的id,但是不调用logout.

调用几次之后就会出现内存溢出:
2. 第二种常见的是分布式任务调度系统如Elastic-job、Quartz等进行任务调度时,被调度的java应用在调度任务结束中出现了内存泄漏,最终导致多次调度之后内存溢出.
这种产生的内存溢出会导致应用执行下次的调度任务执行,同样重启可以恢复应用使用,但是在调度执行一段时间之后依然会出现内存溢出.
在这里插入图片描述
开启定时任务:
定时任务代码:

package com.itheima.jvmoptimize.task;

import com.itheima.jvmoptimize.leakdemo.demo4.Outer;
import org.springframework.scheduling.annotation.Scheduled;
import org.springframework.stereotype.Component;

import java.util.ArrayList;
import java.util.List;

@Component
public class LeakTask {

    private int count = 0;
    private List<Object> list = new ArrayList<>();

    @Scheduled(fixedRate = 100L)
    public void test(){
        System.out.println("定时任务调用" + ++count);
        list.add(new Outer().newList());
    }
}

启动程序之后很快就出现了内存溢出:
在这里插入图片描述

1.3 常见的虚拟机参数

在这里插入图片描述

2. 解决内存溢出的办法

在这里插入图片描述
首先要熟悉一些常用的监控工具:

2.1 常用的监控工具

2.1.1 Top命令:

top命令是Linux下用来查看系统信息的一个命令,它提供我们去实地地去查看系统的资源,比如执行时的进程,线程和系统参数等信息,进程使用的内存为res(常驻内存)-shr(共享内存)
在这里插入图片描述

优点:

操作简单
无额外的软件安装

缺点:

只能查看最基础的进程信息,无法查看到每个部分的内存占用(堆,方法区,堆外).

2.2.2 VisualVM

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

优点:

功能丰富,实时监控CPU,内存,线程等详细信息.
支持idea插件,开发过程中也可以使用.

缺点:

对大量集群化部署的java进程需要手动进行管理.

如果需要进行远程监控,可以通过jmx方式进行连接,在启动java程序时为配置文件添加如下参数:

-Djava.rmi.server.hostname=服务器ip地址
-Dcom.sun.management.jmxremote
-Dcom.sun.management.jmxremote.port=9122
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.authenticate=false

右键点击remote:

在这里插入图片描述
填写服务器的IP地址:

在这里插入图片描述
右键点击JMX连接:

填写IP地址和端口号,勾选不需要SSL安全验证:

双击成功连接:

在这里插入图片描述

2.2.3 Arthas

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

在这里插入图片描述
优点:

功能强大,不止于监控基础信息,还可以监控单个方法的执行耗时等细节内容.
支持应用的集群管理

缺点:
部分高级功能使用门槛较高

2.2.4 使用阿里arthas tunnel管理所有的需要监控的程序

背景:
小李的团队已经普及了arthas的使用,但是由于使用了微服务框架,生产环境上的应用数量非常多,使用arthas还得登录到每一台服务器上再去操作非常不方便,他看到官方文档上可以使用tunnel来管理所有需要监控的程序.
在这里插入图片描述
步骤:

在SpringBoot程序中添加了Arthas的依赖(支持SpringBoot2),在配置文件中添加了tunnel服务端的地址,便于tunnel去监控所有的程序.
将tunnel服务端程序部署在某台服务器上并启动.
启动java程序
打开tunnel的服务端页面,查看所有的进程列表,并选择进程进行arthas的操作.

pom.xml添加依赖:

<dependency>
    <groupId>com.taobao.arthas</groupId>
    <artifactId>arthas-spring-boot-starter</artifactId>
    <version>3.7.1</version>
</dependency>

application.yml中添加配置:

arthas:
  #tunnel地址，目前是部署在同一台服务器，正式环境需要拆分
  tunnel-server: ws://localhost:7777/ws
  #tunnel显示的应用名称，直接使用应用名
  app-name: ${spring.application.name}
  #arthas http访问的端口和远程连接的端口
  http-port: 8888
  telnet-port: 9999

我们需要提前准备好arthas-tunnel-server.3.7.1-fatjar.jar上传到服务器,并使用nohup java -jar -Darthas.enable-detail-pages=true arthas-tunnel-server.3.7.1-fatjar.jar &命令启动该程序. -Darthas.enable-detail-pages=true参数作用是可以有一个页面展示内容.通过服务器ip地址:8080/apps.html打开页面,目前没有注册上来任何应用.
在这里插入图片描述
启动SpringBoot应用,如果在一台服务器上,注意区分端口.

-Dserver.port=tomcat端口号
-Darthas.http-port=arthas的http端口号
-Darthas.telnet-port=arthas的telnet端口号端口号

在这里插入图片描述
最终就能看到两个应用:

单击应用就可以进入操作arthas了.

2.2.5 Prometheus+Grafana

Prometheus+Grafana是企业中运维常用的监控方案,其中Prometheus用来采集系统或者应用的相关数据,同时具备告警功能,Grafana可以将Prometheus采集到的数据以可视化的方式进行展示.
在这里插入图片描述
优点:

支持系统级别和应用级别的监控,比如Linux操作系统,Redi,MySQL,java进程.
支持告警运行定义告警指标,通过邮件,短信等方式尽早通知相关人员进行处理.

缺点:
环境搭建较为复杂,一般有运维人员完成

2.2 堆内存情况的对比

正常情况
- 处理业务时会出现上下起伏,业务对象频繁创建内存会升高,触发MinorGC之后会降下来.
- 手动执行FULLGC之后,内存大小会骤降,而且每次降完之后的大小是接近的.
- 长时间观察内存曲线应该是在一个范围内.
- 出现内存泄漏
  - 处于持续增长的情况,即使MinorGC也不能把大部分对象回收
  - 手动FullGC之后的内存量每一次都在增长
  - 长时间观察内存曲线持续增长

2.3 产生内存溢出的原因一: 代码中的内存泄漏

总结了6种产生的内存泄漏的原因,均来自java代码的处理不当:

equals()和hashCode(),不正确的equals()和hashCode()实现导致内存泄漏
ThreadLocal的使用,由于线程池中的线程不被回收导致的ThreadLocal内存泄漏
内部类引用外部类,非静态的内部类和匿名内部类的错误使用导致内存泄漏.
String的Intern方法,由于JDK6中的字符串常量池位于永久代,intern被大量的调用并保存产生的内存泄漏
通过静态字段保存的对象,大量的数据在静态变量中被引用,但是不再使用,成为了内存泄漏.
资源没有正常关闭,由于资源没有调用close方法正常关闭,导致的内存溢出.

2.3.1 equals和hashCode导致的内存泄漏

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

以JDK8为例,首先调用hash方法计算key的哈希值,hash方法中会使用到key的hashCode方法,根据hash方法的结果决定存放的数组中的位置.
如果没有元素,直接放入,如果有元素,先判断key是否相等,会用到equals方法,如果key相等,直接替换value,key不相等,走链表或者是红黑树查找逻辑,其中也会使用equals对比是否相等.

异常情况:
hashCode方法实现不正确,会导致相同id的学生对象计算出来的hash值不同,可能会被分到不同的槽中.
equals方法实现不正确,会导致key在对比时,即便学生对象的id是相同的,也被认为是不同的key.
5. 长时间运行之后HashMap中会保存大量相同的id的学生的数据.

在这里插入图片描述
比如下面的代码,就会发生内存泄漏,我们在student中不重写hashCode和equals方法,我们直接

public class Student {
    private String name;
    private Integer id;
    private byte[] bytes = new byte[1024 * 1024];

    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }

    public Integer getId() {
        return id;
    }

    public void setId(Integer id) {
        this.id = id;
    }
}

package com.itheima.jvmoptimize.leakdemo.demo2;

import java.util.HashMap;
import java.util.Map;

public class Demo2 {
    public static long count = 0;
    public static Map<Student,Long> map = new HashMap<>();
    public static void main(String[] args) throws InterruptedException {
        while (true){
            if(count++ % 100 == 0){
                Thread.sleep(10);
            }
            Student student = new Student();
            student.setId(1);
            student.setName("张三");
            map.put(student,1L);
        }
    }
}

运行之后观察VisualVM,出现了内存泄漏的现象.
在这里插入图片描述
解决方案:

在定义实体时,始终重写equals()和hashCode()方法.
重写时一定要确定使用了唯一标识去区分不同的对象,比如用户的id等.
HashMap使用时尽量使用使用编号id等数据作为key,不要将整个实体类对象作为key存放.

2.3.2 内部类引用外部类

问题:

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

package com.itheima.jvmoptimize.leakdemo.demo3;

import java.io.IOException;
import java.util.ArrayList;

public class Outer{
    private byte[] bytes = new byte[1024 * 1024]; //外部类持有数据
    private static String name  = "测试";
    class Inner{
        private String name;
        public Inner() {
            this.name = Outer.name;
        }
    }

    public static void main(String[] args) throws IOException, InterruptedException {
//        System.in.read();
        int count = 0;
        ArrayList<Inner> inners = new ArrayList<>();
        while (true){
            if(count++ % 100 == 0){
                Thread.sleep(10);
            }
            inners.add(new Outer().new Inner());
        }
    }
}

package com.itheima.jvmoptimize.leakdemo.demo4;

import java.io.IOException;
import java.util.ArrayList;
import java.util.List;

public class Outer {
    private byte[] bytes = new byte[1024 * 1024 * 10];
    public List<String> newList() {
        List<String> list = new ArrayList<String>() {{
            add("1");
            add("2");
        }};
        return list;
    }

    public static void main(String[] args) throws IOException {
        System.in.read();
        int count = 0;
        ArrayList<Object> objects = new ArrayList<>();
        while (true){
            System.out.println(++count);
            objects.add(new Outer().newList());
        }
    }
}

解决方案:

这个案例中,使用内部类的原因是可以直接获取到外部类中的成员变量值,简化开发,如果不想持有外部类的对象,应该使用静态内部类.
使用静态方法,可以避免匿名内部类持有调用者对象.

2.3.3 ThreadLocal的使用

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

package com.itheima.jvmoptimize.leakdemo.demo5;

import java.util.concurrent.*;

public class Demo5 {
    public static ThreadLocal<Object> threadLocal = new ThreadLocal<>();

    public static void main(String[] args) throws InterruptedException {
        ThreadPoolExecutor threadPoolExecutor = new ThreadPoolExecutor(Integer.MAX_VALUE, Integer.MAX_VALUE,
                0, TimeUnit.DAYS, new SynchronousQueue<>());
        int count = 0;
        while (true) {
            System.out.println(++count);
            threadPoolExecutor.execute(() -> {
                threadLocal.set(new byte[1024 * 1024]);
            });
            Thread.sleep(10);
        }
    }
}

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

package com.itheima.jvmoptimize.leakdemo.demo5;

import java.util.concurrent.*;

public class Demo5 {
    public static ThreadLocal<Object> threadLocal = new ThreadLocal<>();

    public static void main(String[] args) throws InterruptedException {
        ThreadPoolExecutor threadPoolExecutor = new ThreadPoolExecutor(Integer.MAX_VALUE, Integer.MAX_VALUE,
                0, TimeUnit.DAYS, new SynchronousQueue<>());
        int count = 0;
        while (true) {
            System.out.println(++count);
            threadPoolExecutor.execute(() -> {
                threadLocal.set(new byte[1024 * 1024]);
                threadLocal.remove();
            });
            Thread.sleep(10);
        }
    }
}

2.3.4 String的intern方法

问题:
JDK6中字符串常量池位于堆内存中的perm gen永久代中==,如果不同字符串的intern方法被大量调用(表示将该字符串加入常量池中),字符串常量池会不停的变大超过永久代内存上限之后就会产生内存溢出问题==.

package com.itheima.jvmoptimize.leakdemo.demo6;

import org.apache.commons.lang3.RandomStringUtils;

import java.util.ArrayList;
import java.util.List;

public class Demo6 {
    public static void main(String[] args) {
        while (true){
            List<String> list = new ArrayList<String>();
            int i = 0;
            while (true) {
                //String.valueOf(i++).intern(); //JDK1.6 perm gen 不会溢出
                list.add(String.valueOf(i++).intern()); //溢出
            }
        }
    }
}

2.3.5 通过静态字段保存对象

问题:
如果大量的数据在静态变量中被长期引用,而静态字段的生命周期与类本身不同相同,数据就不会被释放,如果这些数据不再使用,就会成为内存泄漏.

public class Cache {
    private static Map<String, Object> cache = new HashMap<>();
    
    public static void addToCache(String key, Object value) {
        cache.put(key, value);
    }
    
    public static Object getFromCache(String key) {
        return cache.get(key);
    }
}

解决方案:

尽量减少将对象长时间保存在静态变量中,如果不再使用,必须将对象删除(比如在集合中)或者将静态变量摄者为null.
使用单例模式时,尽量使用懒加载,而不是立即加载.

package com.itheima.jvmoptimize.leakdemo.demo7;

import org.springframework.context.annotation.Lazy;
import org.springframework.stereotype.Component;

@Lazy //懒加载
@Component
public class TestLazy {
    private byte[] bytes = new byte[1024 * 1024 * 1024];
}

Spring的Bean中不要长期存放大量对象,如果是缓存用于提升性能,尽量设置过期时间定期失效.

package com.itheima.jvmoptimize.leakdemo.demo7;

import com.github.benmanes.caffeine.cache.Cache;
import com.github.benmanes.caffeine.cache.Caffeine;

import java.time.Duration;

public class CaffineDemo {
    public static void main(String[] args) throws InterruptedException {
        Cache<Object, Object> build = Caffeine.newBuilder()
        //设置100ms之后就过期
                 .expireAfterWrite(Duration.ofMillis(100))
                .build();
        int count = 0;
        while (true){
            build.put(count++,new byte[1024 * 1024 * 10]);
            Thread.sleep(100L);
        }
    }
}

2.3.6 资源没有正常关闭

问题:
连接和流这些资源会占用内存,如果使用完之后没有关闭,这部分内存不一定会出现内存泄漏,但是会导致close方法不被执行.
解决方案:

为了防止出现这类的资源对象泄漏问题,必须在finally块中关闭不再使用的资源.
从java7开始,使用try-with-resource语法可以用户自动关闭资源.

2.4 产生内存溢出的原因二: 并发请求问题

通过发送请求向java应用中获取数据,正常情况下java应用将数据返回之后,这部分数据就可以在内存中被释放掉.
接收到请求是创建对象:
在这里插入图片描述
响应返回之后,对象就可以被回收掉:

在这里插入图片描述
并发请求问题指的是由于用户的并发请求量可能很大,同时处理数据的时间很长,导致大量的数据存在于内存中,最终超过了内存的上限,导致内存溢出,这类问题的处理思路和内存泄漏类似,首先要定位到对象产生的根源.
在这里插入图片描述
接下来我们就来模拟一下这种情况:
接口代码如下:

/**
 * 大量数据 + 处理慢
 */
@GetMapping("/test")
public void test1() throws InterruptedException {
    byte[] bytes = new byte[1024 * 1024 * 100];//100m
    Thread.sleep(10 * 1000L);
}

接下来我们使用Jmeter进行并发测试,把线程参数设置为100.
添加虚拟机参数
点击运行进行压测,很快就出现了内存溢出:

比如我们再来看一个案例:
代码如下:

/**
 * 登录接口 传递名字和id,放入hashmap中
 */
@PostMapping("/login")
public void login(String name,Long id){
    userCache.put(id,new UserEntity(id,name));
}

在压测工具中添加name字段,id字段设置为指定区间的随机数
点击测试,一段时间之后同样出现了内存溢出:

2.5 诊断

2.5.1 内存快照

当堆内存溢出时,需要在堆内存溢出时将整个堆内存保存下来,生成快照文件.
使用MAT打开hprof文件,并选择内存泄漏检测功能,MAT会自动根据内存快照中保存的数据分析内存泄漏的根源.
在这里插入图片描述
生成内存快照的java虚拟机参数:
-XX:+HeapDumpOnOutOfMemoryError: 发生OutOfMemoryError错误时,自动生成hprof内存快照文件.
-XX:HeapDumpPath=<path>: 指定hprof文件的输出路径.
使用MAT打开hprof文件,并选择内存泄漏检测功能,MAT会自动根据内存快照中保存的数据分析内存泄漏的根源.
在程序中添加jvm参数:

-Xmx256m -Xms256m -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=D:\jvm\dump\test1.hprof

运行程序之后:
在这里插入图片描述
使用MAT打开hprof文件,首页就显示了MAT检测出来的内存泄漏问题的原因.

点击Detail查看详情,这个线程持有了大量的字节数组:

2.5.2 MAT内存泄漏检测原理

MAT提供了称为支配树的对象图.支配树展示的是对象实例间支配关系,在对象引用中,所有指向对象的B路径都经过A,则认为对象A支配对象B.
如下图,A引用BC,BC引用D,C引用ED,E引用F,转成支配树之后,由于E只有C引用,所以E挂在C上,接下来BCDF都由其他至少1个对象引用,所以追溯上去,只有A满足支配它们的条件.

在这里插入图片描述
支配树中对象本身占用的空间称之为浅堆,支配树种对象的子树就是所有被该对象支配的内容,这些内容组成了对象的深堆,也称之为保留集==,深堆的大小表示该对象如果可以被回收,能释放多大的内存空间==.
如下图: C自身包含一个浅堆,而C地下挂了E,所以C+E占用的空间大小代表C的深堆.
在这里插入图片描述
在MAT中,也有查看MAT支配树的功能:

输入main进行搜索,可以看到支配树的整体结构: