Java内存泄漏概念、造成原因及检测方式（全）

前言

本身java有垃圾回收器GC，可以内存管理，但为什么还会造成内存泄漏（内存泄漏不等于内存溢出），内存泄漏在项目实战或者企业项目是不被允许，甚至在企业面试中也是常考的题型

1. 概念

了解什么是内存泄漏，需要知道具体的定义、检测以及解决方式

内存泄漏：对系统申请内存使用，将其内存分配给对象使用，但内存空间使用完毕后未释放，一直占用内存空间。（长期的堆积，内存迟早被耗尽，所以今早的解决内存泄漏无疑是好事）

本身内存泄漏就是缺点，没有所谓的优点
缺点如下：

• 造成OOM
• 性能整体下降导致一系列错误
  （系统分配额外内存影响整体系统的运行情况）
• 程序运行延迟卡顿或者直接奔溃
  （可用内存少，频繁GC，频率高了，用户会感受到卡顿）

2. 原因

以下的方式会造成内存泄漏的风险，所以谨慎使用

2.1 大量使用static静态变量

回顾下static的知识点:java零基础从入门到精通（全）

• 实例变量是对象级别的，每个对象的实例变量值可能不同，所以实例变量必须先创建对象，通过“引用”去访问，而静态变量访问时不需要创建对象，直接通过“类名”访问。实例变量存储在堆内存当中，静态变量存储在方法区当中。实例变量在构造方法执行过程中初始化，静态变量在类加载时初始化
• 当一个类的所有对象的某个“属性值”不会随着对象的改变而变化的时候，建议将该属性定义为静态属性（或者说把这个变量定义为静态变量），静态变量在类加载的时候初始化，存储在方法区当中，不需要创建对象，直接通过“类名”来访问

类似的伪代码如下：

public class test{
    // 静态变量
    public void method() {
        // 该函数中使用了静态变量
    }
    public static void main(String[] args) {
    	// 业务逻辑代码
		
		// 此处调用了method来操作静态变量
        
        // 业务逻辑代码
    }
}

如上就会造成一时的内存泄漏，直到程序运行完毕才会释放
这是因为静态变量的生命周期和主函数保持一致，所以尽量减少使用静态变量

2.2 finalize方法

（补充一下常考的面试题）
这个方法常和final、finally与finalize作比较

• final是一个关键字。表示最终的。不变的
• finally也是一个关键字，和try联合使用，使用在异常处理机制中
• finalize()是Object类中的一个方法。作为方法名出现，finalize是标识符。这个方法是由垃圾回收器GC负责调用的

以下是finalize的整体流程：

之所以会造成内存泄漏，是因为在垃圾回收的时候，如果重写了finalize方法而且该对象的finalize方法没有被执行过，但是进入队列之后一直没被调用就会一直占用内存空间

2.3 对象引用有误

业务逻辑代码模块中，稍微不注意就可能引发内存泄漏，一句代码也可能引发致命错误

具体如下：（以下代码不会内存泄露）

int[] a = new int[5];
int[] b = new int[5];
b = a;

在Java中，将一个数组变量赋值给另一个数组变量，如 b = a; 不会导致内存泄漏。

实际上，这只是将数组引用 b 指向与数组引用 a 指向相同的数组对象。这意味着 a 和 b 都指向相同的内存位置，它们引用的是同一个数组对象。这并不会导致内存泄漏。

内存泄漏通常指的是无法访问或释放不再需要的内存，通常是因为没有引用指向这些内存，但它们仍然被占用。a 和 b 仍然引用相同的数组对象，因此内存不会泄漏。

但请注意，如果后续将 b 赋值为其他数组或 null，而没有其他引用指向原始的数组对象，那么原始数组对象将变得无法访问，从而导致内存泄漏。

2.4 资源未被关闭

在使用到jdbc、数据库连接、io连接等，都会进行一个jvm的分配内存
最后代码模块都会进行一个资源的关闭，如果资源未被正常关闭，内存就一直在运行，直到主函数关闭（但是并不是时时刻刻都在连接查询资源）

补充：对应的知识可看我之前的文章：

1. javaSE从入门到精通的二十万字总结（二）
2. jdbc从入门到精通（全）
3. Mysql底层原理详细剖析+常见面试题（全）

2.5 Threadlocal对象赋值null

补充以下ThreadLocal的底层原理以及知识点：
每个线程都有自个独立的ThreadLocalMap对象（Entry对象）
如果当前线程对应的ThreadLocalMap对象为空，则为其创建key以及value（key为ThreadLocal对象，value为缓存变量值）

Threadlocal<String> stringThreadlocal=new Threadlocal<>();
stringThreadlocal.set("码农研究僧"); 

ThreadLocalMap可以存放多个ThreadLocal对象
每个ThreadLocal对象只能缓存一个变量值

通过ThreadLocal.get()可以获取相对应的key值
ThreadLocalMap 的entry对象为，key为ThreadLocal，value为缓存变量值

---

主线程调用了ThreadLocal，给予其变量为null（引用断开了，而不是单纯没有引用）。但是当前线程的ThreadLocalMap还是会引用其堆的变量，如果是强引用，gc是不会回收的。
代码如下所示：（该变量不会被gc回收）

ThreadLocal<String>ss =new ThreadLocal<>();
ss.set("码农研究僧");
ss=null

如果修改其变量引用指向，才会被gc回收

ThreadLocalMap删除Entry的对象，才会解决其引用断开，所以才会被gc清理掉
代码如下所示：

ThreadLocal<String>ss =new ThreadLocal<>();
ss.set("码农研究僧");
//ThreadLocalMap与堆内存中的ThreadLocal断开引用
ss.remove();
//ss与堆内存中的ThreadLocal断开引用
ss=null

GCroot引用链就会发现ThreadLocal没有被任何人引用就会被清理掉该对象，避免内存泄漏问题

关于避免ThreadLocal内存泄漏问题
可以通过：

1. 通过调用remove方法将不要的数据移除避免内存泄漏问题
2. 每次set设置的时候（内部方法都会判断之前的key是否为null），如果设置了null，则可以避免内存泄漏

2.6 其他

如果在实际应用场景中遇到一些内存泄漏的问题
可在底下评论区留言

3. 检测

3.1 JVM命令

如果不使用工具来检测的话，可通过JVM自带的一些命令参数：

• jps：当前运行的所有java进程
• jstat：单个java进程GC情况
• jmap: 单个java进程中堆内存使用情况
• jvisualvm：可视化查看堆内存与metaspace占用情况
• jstack：查看具体某个java进行的线程堆栈情况

也可通过IDEA配置-verbose:gc

3.2 工具

JVM的检测巩固可通过java的VisualVM、YourKit、Netbeans Profiler等

• JProbe：分析java内存泄漏
• Jprofiler：主要用于分析J2SE和J2EE的一些应用程序
• JRockit：诊断java内存泄漏找出根本原因
  通过分析内存、对象以及CPU的各个情况
  查看堆的最大最小以及使用情况

通过查看堆内存，打印堆的各个使用情况
或者将其Dump文件分析

对应的检测工具跟命令大同小异，都是分析其对应内存是否有泄漏情况