关于JAVA程序内存安全内存泄漏问题，你应该了解的几点！

Posted 2022-12-04 ArthurKingYs

Java在内存管理方面是要比C/C++更方便的，不需要为每一个对象编写释放内存的代码，JVM虚拟机将为我们选择合适的时间释放内存空间，使得程序不容易出现内存泄漏和溢出的问题

不过，也正是因为Java把内存控制的权利交给了Java虚拟机，一旦出现内存泄漏和溢出方面的问题，如果不了解虚拟机是怎么使用内存的，那排查错误将会成为一项异常艰难的工作

下面先看看JVM如何管理内存的

内存管理

根据Java虚拟机规范(第3版) 的规定，Java虚拟机所管理的内存将会包括以下几个运行内存数据区域：

• 线程隔离数据区：
  • 程序计数器： 当前线程所执行字节码的行号指示器
  • 虚拟机栈： 里面的元素叫栈帧，存储局部变量表、操作栈、动态链接、方法出口等，方法被调用到执行完成的过程对应一个栈帧在虚拟机栈中入栈到出栈的过程。
  • 本地方法栈： 和虚拟机栈的区别在于虚拟机栈为虚拟机执行Java方法，本地方法栈为虚拟机使用到的本地Native方法服务。
• 线程共享数据区：
  • 方法区： 可以描述为堆的一个逻辑部分，或者说使用永久代来实现方法区。存储已被虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码等数据。
  • 堆： 唯一目的就是存放对象的实例，是垃圾回收管理器的主要区域，分为Eden、From/To Survivor空间。

Java各版本内存管理改进

下图中永久代理解为堆的逻辑区域，移除永久代的工作从JDK7就已经开始了，部分永久代中的数据(常量池)在JDK7中就已经转移到了堆中，JDK8中直接去除了永久代，方法区中的数据大部分被移到堆里面，还剩下一些元数据被保存在元空间里

内存溢出

• 内存泄露Memory Leak： 申请的内存空间没有及时释放，导致后续程序里这块内容永远被占用。
• 内存溢出Out Of Memory： 要求的内存超过了系统所能提供的

运行时数据区域的常见异常

在JVM中，除了程序计数器外，虚拟机内存的其他几个运行时数据区域都有发生OOM异常的可能。

堆内存溢出

不断的创建对象，并且保证GC Roots到对象之间有可达路径来避免垃圾回收机制清除这些对象。

1. public class HeapOOM  
2.     static class ObjectInHeap 
3.      
4.     public static void main(String[] args)  
5.         List<ObjectInHeap> list = new ArrayList(); 
6.         while (true)  
7.             list.add(new ObjectInHeap()); 
8.          
9.      
10.  

栈溢出

单个线程下不断扩大栈的深度引起栈溢出。

1. public class StackSOF  
2.     private int stackLength = 1; 
3.     public void stackLeak()  
4.         stackLength++; 
5.         stackLeak(); 
6.      
7.     public static void main(String[] args)  
8.         StackSOF sof = new StackSOF(); 
9.         try  
10.             sof.stackLeak(); 
11.          catch (Throwable e)  
12.             System.out.println("Stack Length: " + sof.stackLength); 
13.             throw e; 
14.          
15.      
16.  

循环的创建线程，达到最大栈容量。

1. public class StackOOM  
2.     private void dontStop()  
3.         while (true)  
4.          
5.      
6.     public void stackLeadByThread()  
7.         while (true)  
8.             Thread thread = new Thread(new Runnable()  
9.                 @Override 
10.                 public void run()  
11.                     dontStop(); 
12.                  
13.             ); 
14.             thread.start(); 
15.          
16.      
17.     public static void main(String[] args)  
18.         StackOOM stackOOM = new StackOOM(); 
19.         stackOOM.stackLeadByThread(); 
20.      
21.  

运行时常量池溢出

不断的在常量池中新建String，并且保持引用不释放。

1. public class RuntimeConstantPoolOOM  
2.     public static void main(String[] args)  
3.         // 使用List保持着常量池的引用，避免Full GC回收常量池 
4.         List<String> list = new ArrayList<String>(); 
5.         int i = 0; 
6.         while (true)  
7.             // intern()方法使String放入常量池 
8.             list.add(String.valueOf(i++).intern()); 
9.          
10.      
11.  

方法区溢出

借助CGLib直接操作字节码运行时产生大量的动态类，最终撑爆内存导致方法区溢出。

1. public class MethodAreaOOM  
2.     static class ObjectInMethod  
3.      
4.     public static void main(final String[] args)  
5.         // 借助CGLib实现 
6.         while (true)  
7.             Enhancer enhancer = new Enhancer(); 
8.             enhancer.setSuperclass(ObjectInMethod.class); 
9.             enhancer.setUseCache(false); 
10.             enhancer.setCallback(new MethodInterceptor()  
11.                 @Override 
12.                 public Object intercept(Object o, Method method, Object[] objects, MethodProxy methodProxy) throws Throwable  
13.                     return methodProxy.invokeSuper(o, objects); 
14.                  
15.             ); 
16.             enhancer.create(); 
17.          
18.      
19.  

元空间溢出

助CG Lib运行时产生大量动态类，唯一的区别在于运行环境修改为Java 1.8，设置-XX:MaxMetaspaceSize参数，便可以收获java.lang.OutOfMemoryError: Metaspace这一报错

本机直接内存溢出

直接申请分配内存(实际上并没有真正向操作系统申请分配内存，而是通过计算得知内存无法分配，于是抛出异常)

1. public class DirectMemoryOOM  
2.     private static final int _1MB = 1024 * 1024; 
3.     public static void main(String[] args) throws IllegalAccessException  
4.         Field unsafeField = Unsafe.class.getDeclaredFields()[0]; 
5.         unsafeField.setAccessible(true); 
6.         Unsafe unsafe = (Unsafe) unsafeField.get(null); 
7.         while (true)  
8.             unsafe.allocateMemory(_1MB); 
9.          
10.      
11.  

常见案例

在工作中一般会遇到有以下几种情况导致内存问题

传输数据量过大

因为传输数量过大、或一些极端情况导致代码中间结果对象数据量过大，过大的数据量撑爆内存

查询出大量对象

这个多为SQL语句设置问题，SQL未设置分页，用户一次查询数据量过大、频繁查询SQL导致内存堆积、或是未作判空处理导致WHERE条件为空查询出超大数据量等

接口性能问题导致

这类为外部接口性能较慢，占用内存较大，并且短时间内高QPS导致的，导致服务内存不足，线程堆积或挂起进而出现FullGC

元空间问题

使用了大量的反射代码，Java字节码存取器生成的类不断生成

问题排查

使用jmap分析内存泄漏

1.生成dump文件

1. jmap -dump:format=b,file=/xx/xx/xx.hprof pid 

2.dump文件下载到本地

3.dump文件分析

可以使用MAT，MAT可作为Eclipse插件或一个独立软件使用，MAT是一个高性能、具备丰富功能的Java堆内存分析工具，主要用来排查内存泄漏和内存浪费的问题。

使用MAT打开上一部后缀名.hprof的dump文件

• Histogram：直方图，各个类的实例，包括个数和大小，可以查看类引用和被引用的路径。
• Dominator Tree：支配图，列出所有线程和线程下面的那些对象占用的空间。
• Top Consumers：通过图形列出消耗内存多的实例。
• Leak Suspects：MAT自动分析的内存泄漏报表

可以用这个工具分析出什么对象什么线程占用内存空间较大，对象是被什么引用的，线程内有哪些资源占用很高

以运行时常量池溢出为例

打开Histogram类实例表

Objects是类的对象的数量;Shallow是对象本身占用内存大小、不包含其他引用;

Retained是对象自己的Shallow加上直接或间接访问到对象的Shallow之和，也可以说是GC之后可以回收的内存总和

从图中可以看出运行时常量池溢出的情况，产生了大量的String和char[]实例

在char[]上右键可以得到上图所有char[]对象的被引用路径，可以看出这些char数组都是以String的形式存在ArrayList中，并且是由main这个线程运行的

可以看出是main线程中新建了一个数组，其中存了32w+个长度为6的char数组组成的String造成的内存溢出

https://www.tuicool.com/articles/amAziqM

Java通过垃圾回收机制，可以自动的管理内存，这对开发人员来说是多么美好的事啊。但垃圾回收器并不是万能的，它能够处理大部分场景下的内存清理、内存泄露以及内存优化。但它也并不是万能的。

不然，我们在实践的过程中也不会出现那么多因内存泄露导致的生产事件了。但很多内存泄露时间也是因为开发人员使用不当导致的。

本篇文章我们就来聊聊内存泄露的原因是什么，如何识别内存泄露，以及如果在应用程序中进行处理。

什么是内存泄露

什么是内存泄露，通俗的来说就是堆中的一些对象已经不会再被使用了，但垃圾收集器却无法将它们从内存中清除。

内存泄漏很严重的问题，因为它会阻塞内存资源并随着时间的推移降低系统性能。如果不进行有效的处理，最终的结果将会使应用程序耗尽内存资源，无法正常服务，导致程序崩溃，抛出java.lang.OutOfMemoryError异常。

堆内存中通常有两种类型的对象：被引用的对象和未被引用的对象。被引用的对象是应用程序中仍然具有活跃的引用，而未被引用的对象则没有任何活跃的引用。

垃圾收集器会回收那些未被引用的对象，但不会回收那些还在被引用的对象。这也是内存泄露发生的源头。

内存泄露往往有以下表象：

• 当应用程序长时间连续运行时，性能严重下降;
• 抛出OutOfMemoryError异常;
• 程序莫名其妙的自动崩溃;
• 应用程序耗尽链接对象;

当然，如果打印GC日志，有些场景下还会看到频繁执行full GC等状况。下面就具体分析一下这些场景和处理方案。

Java中内存泄露分类

在任何一个应用程序中，发生内存泄露往往由很多原因构成。下面我们就聊聊最常见的一些内存泄露场景。

静态属性导致内存泄露

会导致内存泄露的一种情况就是大量使用static静态变量。在Java中，静态属性的生命周期通常伴随着应用整个生命周期(除非ClassLoader符合垃圾回收的条件)。

下面来看一个具体的会导致内存泄露的实例：

public class StaticTest  
    public static List<Double> list = new ArrayList<>(); 
 
    public void populateList()  
        for (int i = 0; i < 10000000; i++)  
            list.add(Math.random()); 
         
        Log.info("Debug Point 2"); 
     
 
    public static void main(String[] args)  
        Log.info("Debug Point 1"); 
        new StaticTest().populateList(); 
        Log.info("Debug Point 3"); 
     
 

如果监控内存堆内存的变化，会发现在打印Point1和Point2之间，堆内存会有一个明显的增长趋势图。

但当执行完populateList方法之后，对堆内存并没有被垃圾回收器进行回收。

上图为VisualVM监控显示的信息，关于VisualVM的使用这里就不再赘述了，可参考文章《没有监控过JVM内存的职场生涯，是不完美的》。

但针对上述程序，如果将定义list的变量前的static关键字去掉，再次执行程序，会发现内存发生了具体的变化。VisualVM监控信息如下图：

对比两个图可以看出，程序执行的前半部分内存使用情况都一样，但当执行完populateList方法之后，后者不再有引用指向对应的数据，垃圾回收器便进行了回收操作。

因此，我们要十分留意static的变量，如果集合或大量的对象定义为static的，它们会停留在整个应用程序的生命周期当中。而它们所占用的内存空间，本可以用于其他地方。

那么如何优化呢?第一，进来减少静态变量;第二，如果使用单例，尽量采用懒加载。

未关闭的资源

无论什么时候当我们创建一个连接或打开一个流，JVM都会分配内存给这些资源。比如，数据库链接、输入流和session对象。

忘记关闭这些资源，会阻塞内存，从而导致GC无法进行清理。特别是当程序发生异常时，没有在finally中进行资源关闭的情况。

这些未正常关闭的连接，如果不进行处理，轻则影响程序性能，重则导致OutOfMemoryError异常发生。

如果进行处理呢?第一，始终记得在finally中进行资源的关闭;第二，关闭连接的自身代码不能发生异常;第三，Java7以上版本可使用try-with-resources代码方式进行资源关闭。

不当的equals方法和hashCode方法实现

当我们定义个新的类时，往往需要重写equals方法和hashCode方法。在HashSet和HashMap中的很多操作都用到了这两个方法。如果重写不得当，会造成内存泄露的问题。

下面来看一个具体的实例：

public class Person  
    public String name; 
     
    public Person(String name)  
        this.name = name; 
     
 

现在将重复的Person对象插入到Map当中。我们知道Map的key是不能重复的。

@Test 
public void givenMap_whenEqualsAndHashCodeNotOverridden_thenMemoryLeak()  
    Map<Person, Integer> map = new HashMap<>(); 
    for(int i=0; i<100; i++)  
        map.put(new Person("jon"), 1); 
     
    Assert.assertFalse(map.size() == 1); 
 

上述代码中将Person对象作为key，存入Map当中。理论上当重复的key存入Map时，会进行对象的覆盖，不会导致内存的增长。

但由于上述代码的Person类并没有重写equals方法，因此在执行put操作时，Map会认为每次创建的对象都是新的对象，从而导致内存不断的增长。

VisualVM中显示信息如下图：

当重写equals方法和hashCode方法之后，Map当中便只会存储一个对象了。方法的实现如下：

public class Person  
    public String name; 
     
    public Person(String name)  
        this.name = name; 
     
     
    @Override 
    public boolean equals(Object o)  
        if (o == this) return true; 
        if (!(o instanceof Person))  
            return false; 
         
        Person person = (Person) o; 
        return person.name.equals(name); 
     
     
    @Override 
    public int hashCode()  
        int result = 17; 
        result = 31 * result + name.hashCode(); 
        return result; 
     
 

经过上述修改之后，Assert中判断Map的size便会返回true。

@Test 
public void givenMap_whenEqualsAndHashCodeNotOverridden_thenMemoryLeak()  
    Map<Person, Integer> map = new HashMap<>(); 
    for(int i=0; i<2; i++)  
        map.put(new Person("jon"), 1); 
     
    Assert.assertTrue(map.size() == 1); 
 

重写equals方法和hashCode方法之后，堆内存的变化如下图：

另外的例子就是当使用ORM框架，如Hibernate时，会使用equals方法和hashCode方法进行对象的的分析和缓存操作。

如果不重写这些方法，则发生内存泄漏的可能性非常高，因为Hibernate将无法比较对象(每次都是新对象)，然后不停的更新缓存。

如何进行处理?第一，如果创建一个实体类，总是重写equals方法和hashCode方法;第二，不仅要覆盖默认的方法实现，而且还要考虑最优的实现方式;

外部类引用内部类

这种情况发生在非静态内部类(匿名类)中，在类初始化时，内部类总是需要外部类的一个实例。

每个非静态内部类默认都持有外部类的隐式引用。如果在应用程序中使用该内部类的对象，即使外部类使用完毕，也不会对其进行垃圾回收。

假设一个类，其中包含大量笨重对象的引用，并且具有一个非静态内部类。当我们创建内部类的对象时，内存模型如下所示：

如果将内部类声明为static的，那么内存曲线则像从写equals和hashCode方法之后的图一样，是一条平稳的直线。

此种情况，之所以发生内存泄露，是因为内部类对象隐含的持有外部类的引用，从而导致外部类成为垃圾对象时却无法被正常回收。使用匿名类的时候也会发生类似的情况。

如何避免此种情况?如果内部类不需要访问外部类的成员信息，可以考虑将其转换为静态内部类。

finalize()方法

使用finalize()方法会存在潜在的内存泄露问题，每当一个类的finalize()方法被重写时，该类的对象就不会被GC立即回收。GC会将它们放入队列进行最终确定，在以后的某个时间点进行回收。

如果finalize()方法重写的不合理或finalizer队列无法跟上Java垃圾回收器的速度，那么迟早，应用程序会出现OutOfMemoryError异常。

假设某个类重写了finalize()方法，并且重写的方法在执行时需要一些时间。如果存在大量该对象，垃圾回收时，在VisualVM中的曲线如下：

如果去掉重写的finalize()方法，同样的程序，展示的曲线如下：

如果避免此种情况发生呢?始终避免使用finalizer。

String的intern方法

字符串常量池在Java7中从PermGen移动到了堆空间。在Java6及以前版本，我们使用字符串时要多加小心。

如果读取了一个大字符串对象，并且调用其intern方法，intern()会将String放在JVM的内存池中(PermGen)，而JVM的内存池是不会被GC的。同样会造成程序性能降低和内存溢出问题。

JDK1.6中PermGen中存储大对象示例：

如何避免此种情况发生?第一，最简单的方式是更新JDK版到7及以上;第二，如果无法避免，则可调整PermGen大小，避免OutOfMemoryErrors溢出。

PermGen相关配置：

-XX:MaxPermSize=512m 

使用ThreadLocal

ThreadLocal提供了线程本地变量，它可以保证访问到的变量属于当前线程，每个线程都保存有一个变量副本，每个线程的变量都不同。ThreadLocal相当于提供了一种线程隔离，将变量与线程相绑定，从而实现线程安全的特性。

ThreadLocal的实现中，每个Thread维护一个ThreadLocalMap映射表，key是ThreadLocal实例本身，value是真正需要存储的Object。

ThreadLocalMap使用ThreadLocal的弱引用作为key，如果一个ThreadLocal没有外部强引用来引用它，那么系统GC时，这个ThreadLocal势必会被回收，这样一来，ThreadLocalMap中就会出现key为null的Entry，就没有办法访问这些key为null的Entry的value。

如果当前线程迟迟不结束的话，这些key为null的Entry的value就会一直存在一条强引用链：Thread Ref -> Thread -> ThreaLocalMap -> Entry -> value永远无法回收，造成内存泄漏。

如何解决此问题?

第一，使用ThreadLocal提供的remove方法，可对当前线程中的value值进行移除;

第二，不要使用ThreadLocal.set(null) 的方式清除value，它实际上并没有清除值，而是查找与当前线程关联的Map并将键值对分别设置为当前线程和null。

第三，最好将ThreadLocal视为需要在finally块中关闭的资源，以确保即使在发生异常的情况下也始终关闭该资源。

try  
    threadLocal.set(System.nanoTime()); 
    //... further processing 
 finally  
    threadLocal.remove(); 
 

处理内存泄漏的其他策略

尽管在处理内存泄漏时没有万能的解决方案，但是有一些方法可以使内存泄漏最小化。

启用分析

我们可通过一些工具，用来对应用应用程序的内存使用情况等进行监控和诊断，从而找到最佳的利用系统资源的方案。

类似的工具有前面我们提到的VisualVM，还有Mission Control，JProfiler，YourKit，Java VisualVM和Netbeans Profiler等。

显示垃圾回收详情

通过启用垃圾收集详情日志，可以对GC的详细进行跟踪。通过以下命令进行启动：

-verbose:gc 

通过添加此参数，我们可以看到GC内部发生的情况的详细信息：

使用引用对象避免内存泄漏

在Java中，我们还可以使用java.lang.ref包内置引用对象来处理内存泄漏。使用java.lang.ref包，而不是直接引用对象，我们对对象使用特殊的引用，从而确保它们可以轻松地被垃圾回收。

IDE警告

无论是Eclipse还是IDEA，如果安装对应的插件(比如阿里巴巴开发手册插件等)，当写代码中出现内存泄露风险代码时，IDE会进行警告提醒，从而从源头上避免内存泄露的代码出现在生产环境。

基准测试

通过执行基准测试来衡量和分析Java代码的性能，从而选择更合理的解决方案。

Code Review

这也是最古老，最有效的方式之一，通过经验丰富的开发人员对代码的Review或多人进行Review，从而达到查漏补缺的效果，排除一些常见的内存泄露问题。

小结

本文介绍了内存泄露的原因以及常见的7种内存泄露场景，针对每种内存泄露的场景都提供了解决方案。另外，还为大家提供了6种额外的通用性解决策略。

但针对内存泄露来说，这还是九牛一毛，不同的代码，不同的场景都会出现一些未知的内存泄露问题，同时也没有万能的解决方案。这就需要我们了解内存泄露的根本原因，同时掌握一些基本的分析方法和策略，以便灵活应对。