内存泄漏

1. 什么是内存泄漏

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

1.1 内存泄漏的常见场景

1. 内存泄漏导致溢出的常见场景是大型的Java后端应用中，在处理用户的请求之后，没有及时将用户的数据删除。随着用户请求数量越来越多，内存泄漏的对象占满了堆内存最终导致内存溢出。
   这种产生的内存溢出会直接导致用户请求无法处理，影响用户的正常使用。重启可以恢复应用使用，但是在运行一段时间之后依然会出现内存溢出。
2. 第二种常见场景是分布式任务调度系统如Elastic-job、Quartz等进行任务调度时，被调度的Java应用在调度任务结束中出现了内存泄漏，最终导致多次调度之后内存溢出。
   这种产生的内存溢出会导致应用执行下次的调度任务执行。同样重启可以恢复应用使用，但是在调度执行一段时间之后依然会出现内存溢出。

1.2 解决内存溢出的思路

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

2. 发现问题的常用手段

2.1 发现问题–Top命令

top命令是linux下用来查看系统信息的一个命令，它提供给我们去实时地去查看系统的资源，比如执行时的进程、线程和系统参数等信息。进程使用的内存 = RES（常驻内存）- SHR（共享内存） 开启大写然后输入M,可以让Top进程列表按照内存倒序。
优点：操作简单、无额外的软件安装
缺点：只能查看最基础的进程信息，无法查看到每个部分的内存占用（堆、方法区、堆外）

2.2 发现问题–VisualVM

VisualVM是多功能合一的Java故障排除工具并且他是一款可视化工具，整合了命令行JDK工具和轻量级分析功能，功能非常强大。这款软件在Oracle JDK6~8中发布，但是在Oracle JDK9之后不在JDK安装目录下需要单独下载。下载地址：https://visualvm.github.io/
启动visualvm后，左边就会有可供选择的本地Java进程：
visualvm也支持远程连接，需要启动应用的时候开启支持远程连接：

java -jar -Djava.rmi.server.hostname=hadoop103 -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=9022 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false springboot-demo-1.0.jar

连接的时候不勾选使用SSL,然后保存后打开：
优点：功能丰富，实时监控CPU、内存、线程等详细信息 缺点：对大量集群化部署的Java进程需要手动进行管理

2.3 发现问题–Arthas

Arthas是一款线上监控诊断产品，通过全局视角实时查看应用load、内存、gc、线程的状态信息，并能在不修改应用代码的情况下，对业务问题进行诊断，包括查看方法调用的出入参、异常，监测方法执行耗时，类加载信息等，大大提升线上问题排查效率。
优点：功能强大，不止于监控基础的信息，还能监控单个方法的执行耗时等细节内容。支持应用的集群管理 缺点：部分高级功能使用门槛较高
下载tunnel-server的jar包，访问https://github.com/alibaba/arthas/releases ： 上传到服务器上面，推荐部署在非应用的节点机器：

[jack@hadoop103 software]$ ll
总用量 935028
-rw-r--r--.  1 jack jack  45278767 3月  28 04:53 arthas-tunnel-server-4.0.5-fatjar.jar

启动arthal-tunnel-server:

[jack@hadoop103 software]$ nohup java -jar -Dserver.port=8070 arthas-tunnel-server-4.0.5-fatjar.jar > arthas-tunnel-server.log  2>&1 &

使用阿里arthas tunnel管理所有的需要监控的程序，arthas3.7.2及以后的版本同时支持springboot2/3。在我们的程序中添加pom依赖：

<parent>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-parent</artifactId>
    <version>2.7.18</version>
    <relativePath />
</parent>

<properties>
    <maven.compiler.source>8</maven.compiler.source>
    <maven.compiler.target>8</maven.compiler.target>
    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
</properties>
<dependencies>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-web</artifactId>
    </dependency>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-actuator</artifactId>
    </dependency>
    <dependency>
        <groupId>com.taobao.arthas</groupId>
        <artifactId>arthas-spring-boot-starter</artifactId>
        <version>4.0.5</version>
    </dependency>
</dependencies>

<build>
    <plugins>
        <plugin>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-maven-plugin</artifactId>
        </plugin>
    </plugins>
</build>

在application.yml文件中添加tunnel服务端的地址，便于tunnel去监控所有的程序：

server.port=6002

spring.application.name=docker-demo

arthas.app-name=${spring.application.name}
arthas.tunnel-server=ws://192.168.101.103:7777/ws
arthas.http-port=8888
arthas.telnet-port=9999
arthas.agent-id=${spring.application.name}
## application.yml不支持通配符*,需要改成'*'
management.endpoints.web.exposure.include=*

打成jar包上传服务器，启动java程序

nohup java -jar docker-demo.jar > docker-demo.log 2>&1 &

打开tunnel的服务端页面，填写agetn-id为docker-demo，点击connect:

2.4 发现问题–Prometheus+Grafana

Prometheus+Grafana是企业中运维常用的监控方案，其中Prometheus用来采集系统或者应用的相关数据，同时具备告警功能。Grafana可以将Prometheus采集到的数据以可视化的方式进行展示 优点：支持系统级别和应用级别的监控，比如linux操作系统、Redis、MySQL、Java进程。支持告警并允许自定义告警指标，通过邮件、短信等方式尽早通知相关人员进行处理
缺点：环境搭建较为复杂，一般由运维人员完成
在我们的程序中添加pom依赖,支持暴露prometheus相关指标信息：

<dependency>
    <groupId>io.micrometer</groupId>
    <artifactId>micrometer-registry-prometheus</artifactId>
    <version>1.12.13</version>
</dependency>

配置application.properties:

management.endpoint.metrics.enabled=true
management.endpoint.prometheus.enabled=true
management.metrics.export.prometheus.enabled=true
management.metrics.tags.application=${spring.application.name}

然后配置prometheus。

3. 分析问题的常用方法

监控得到了JVM的信息后，还需要能够准确识别堆使用的图表信息才行。

3.1 堆内存状况的对比

观察要点就是查看FullGC之后内存是不是还在涨高：
其次点击Visual VM中的采样功能，可以帮助我们实时分析具体哪些占用的内存很高：
可以看到byte[]远高于其他对象的占用内存大小，紧跟其后附近的是HashMap.$Node对象，一般这两者必有关联，重点关注代码逻辑中使用HashMap的地方。

4. 内存溢出原因之代码

代码中的内存溢出导致生产环境出问题很少，因为开发测试的时候很容易被发现，使用简单的性能测试就会被暴露出来，在代码中尽量规避下面这些情况：

4.1 equals()和hashCode()

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

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){
            // 休眠是防止主线程一直死循环，导致visual vm连上处于假死状态
            if(count++ % 100 == 0){ 
                Thread.sleep(10);
            }
            // 没有重写equals()和hashCode()方法
            Student student = new Student();
            student.setId(1);
            student.setName("张三");
            // 一直往map里面放id为1的student
            // 期望的是student对象会覆盖之前的student, map中对象数量只有一个
            map.put(student,1L);
        }
    }
}

异常原因分析：
1、hashCode方法实现不正确，会导致相同id的学生对象计算出来的hash值不同，可能会被分到不同的槽中。
2、equals方法实现不正确，会导致key在比对时，即便学生对象的id是相同的，也被认为是不同的key。
3、长时间运行之后HashMap中会保存大量相同id的学生数据。
解决方案：
1、在定义新实体时，始终重写equals()和hashCode()方法。
2、重写时一定要确定使用了唯一标识去区分不同的对象，比如用户的id等。
3、hashmap使用时尽量使用编号id等数据作为key，不要将整个实体类对象作为key存放。

4.2 内部类引用外部类

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

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 {
        int count = 0;
        ArrayList<Inner> inners = new ArrayList<>();
        while (true){
            if(count++ % 100 == 0){
                Thread.sleep(10);
            }
            inners.add(new Outer().new Inner());
        }
    }
}

运行程序：
解决方案：这个案例中，使用内部类的原因是可以直接获取到外部类中的成员变量值，简化开发。如果不想持有外部类对象，应该使用静态内部类。

public class Outer2 {
    private byte[] bytes = new byte[1024 * 1024 * 10];
    public List<String> getData() {
        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);
            Outer2 o2 = new Outer2();
            objects.add(o2.getData());
        }
    }
}

JVM不会回收Outer2对象，因为getData()返回的匿名ArrayList对象会引用Outer2： 查看Outer2$1的字节码：
解决方案：使用静态方法，可以避免匿名内部类持有调用者对象。

4.3 ThreadLocal的使用

如果仅仅使用手动创建的线程，就算没有调用ThreadLocal的remove方法清理数据，也不会产生内存泄漏。因为当线程被回收时，ThreadLocal也同样被回收。但是如果使用线程池就不一定了。
解决方案：
线程方法执行完，一定要调用ThreadLocal中的remove方法清理对象。

4.4 String的intern方法

JDK6中字符串常量池位于堆内存中的Perm Gen永久代中，如果不同字符串的intern方法被大量调用，字符串常量池会不停的变大超过永久代内存上限之后就会产生内存溢出问题。

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()); //溢出
            }
        }
    }
}

解决方案：
1、注意代码中的逻辑，尽量不要将随机生成的字符串加入字符串常量池
2、增大永久代空间的大小，根据实际的测试/估算结果进行设置-XX:MaxPermSize=256M

4.5 通过静态字段保存对象

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

TestLazy.java

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

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

CaffineDemo.java

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

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

4.6 资源没有正常关闭

连接和流这些资源会占用内存，如果使用完之后没有关闭，这部分内存不一定会出现内存泄漏，但是会导致close方法不被执行。
解决方案： 1、为了防止出现这类的资源对象泄漏问题，必须在finally块中关闭不再使用的资源。 2、从Java 7开始，使用try-with-resources语法可以用于自动关闭资源。

5. 内存溢出原因之并发请求

并发请求问题指的是用户通过发送请求向Java应用获取数据，正常情况下Java应用将数据返回之后，这部分数据就可以在内存中被释放掉。但是由于用户的并发请求量有可能很大，同时处理数据的时间很长，导致大量的数据存在于内存中，最终超过了内存的上限，导致内存溢出。这类问题的处理思路和内存泄漏类似，首先要定位到对象产生的根源。

5.1 使用Jmeter进行并发测试，发现内存溢出问题

背景：小李的团队发现有一个微服务在晚上8点左右用户使用的高峰期会出现内存溢出的问题，于是他们希望在自己的开发环境能重现类似的问题。
步骤：

1. 安装Jmeter软件，添加线程组。
2. 在线程组中增加Http请求，添加随机参数。
3. 在线程组中添加监听器–聚合报告，用来展示最终结果。
4. 启动程序，运行线程组并观察程序是否出现内存溢出。
   编写接口代码：

// 大量数据 + 处理慢
@GetMapping("/test")
public void test1() throws InterruptedException {
    byte[] bytes = new byte[1024 * 1024 * 100];//100m
    Thread.sleep(10 * 1000L);
}
// 登录接口 传递名字和id,放入hashmap中
private static Map<Long,UserEntity> userCache = new HashMap<>();
@PostMapping("/login")
public void login(String name,Long id){
    userCache.put(id,new UserEntity(id,name));
}

启动jmeter后, 分别配置线程组和请求

5.2 诊断 – 内存快照

当堆内存溢出时，需要在堆内存溢出时将整个堆内存保存下来，生成内存快照(Heap Profile )文件。
生成内存快照的Java虚拟机参数：
-XX:+HeapDumpOnOutOfMemoryError：发生OutOfMemoryError错误时，自动生成hprof内存快照文件。
-XX:HeapDumpPath=<path>：指定hprof文件的输出路径。
使用MAT打开hprof文件，并选择内存泄漏检测功能，MAT会自行根据内存快照中保存的数据分析内存泄漏的根源。