内存泄漏和、内存溢出 （史上最全）

文章很长，建议收藏起来，慢慢读! 疯狂创客圈为小伙伴奉上以下珍贵的学习资源：

• 疯狂创客圈 经典图书 ： 《Netty Zookeeper Redis 高并发实战》 面试必备 + 大厂必备 + 涨薪必备
• 疯狂创客圈 经典图书 ： 《SpringCloud、Nginx高并发核心编程》 面试必备 + 大厂必备 + 涨薪必备
• 资源宝库： Java程序员必备 网盘资源大集合 价值>1000元 随便取 GO->【博客园总入口 】
• 独孤九剑：Netty灵魂实验 ： 本地 100W连接 高并发实验，瞬间提升Java内力

---

推荐2：史上最全 Java 面试题 21 个专题

史上最全 Java 面试题 21 个专题	阿里、京东、美团、头条… 随意挑、横着走！！！
1： JVM面试题（史上最强、持续更新、吐血推荐）	https://www.cnblogs.com/crazymakercircle/p/14365820.html
2：Java基础面试题（史上最全、持续更新、吐血推荐）	https://www.cnblogs.com/crazymakercircle/p/14366081.html
3：死锁面试题（史上最强、持续更新）	https://www.cnblogs.com/crazymakercircle/p/14323919.html
4：设计模式面试题 （史上最全、持续更新、吐血推荐）	https://www.cnblogs.com/crazymakercircle/p/14367101.html
5：架构设计面试题 （史上最全、持续更新、吐血推荐）	https://www.cnblogs.com/crazymakercircle/p/14367907.html
还有 10 + 篇必刷、必刷 的面试题	更多 …， 请参见【 疯狂创客圈 高并发 总目录 】

推荐3： 疯狂创客圈 高质量 博文

springCloud 高质量 博文
nacos 实战（史上最全）	sentinel （史上最全+入门教程）
springcloud + webflux 高并发实战	Webflux（史上最全）
SpringCloud gateway （史上最全）	spring security （史上最全）
还有 10 + 篇 必刷、必刷 的高质量 博文	更多 …， 请参见【 疯狂创客圈 高并发 总目录 】

---

内存泄漏和内存溢出

内存溢出和内存泄露的区别与联系

内存溢出：（out of memory）通俗理解就是内存不够，指程序要求的内存超出了系统所能分配的范围，通常在运行大型软件或游戏时，软件或游戏所需要的内存远远超出了你主机内安装的内存所承受大小，就叫内存溢出。比如申请一个int类型，但给了它一个int才能存放的数，就会出现内存溢出，或者是创建一个大的对象，而堆内存放不下这个对象，这也是内存溢出。

内存泄漏：（Memory Leak）是指程序中己动态分配的堆内存由于某种原因程序未释放或无法释放，造成系统内存的浪费，导致程序运行速度减慢甚至系统崩溃等严重后果。一次内存泄露危害可以忽略，但内存泄露堆积后果很严重，无论多少内存,迟早会被占光。

因此，我们从上面也可以推断出内存泄露可能会导致内存溢出。

二者的关系：

内存溢出会抛出异常，内存泄露不会抛出异常，大多数时候程序看起来是正常运行的。

JVM内存模型

根据 JVM8 规范，JVM 运行时内存共分为虚拟机栈、堆、元空间、程序计数器、本地方法栈五个部分。还有一部分内存叫直接内存，属于操作系统的本地内存，也是可以直接操作的。

1. 元空间(Metaspace）

元空间的本质和永久代类似，都是对JVM规范中方法区的实现。不过元空间与永久代之间最大的区别在于：元空间并不在虚拟机中，而是使用本地内存。

2.虚拟机栈(JVM Stacks）

每个线程有一个私有的栈，随着线程的创建而创建。栈里面存着的是一种叫“栈帧”的东西，每个方法会创建一个栈帧，栈帧中存放了局部变量表（基本数据类型和对象引用）、操作数栈、方法出口等信息。栈的大小可以固定也可以动态扩展。

3. 本地方法栈(Native Method Stack)

与虚拟机栈类似，区别是虚拟机栈执行java方法，本地方法站执行native方法。在虚拟机规范中对本地方法栈中方法使用的语言、使用方法与数据结构没有强制规定，因此虚拟机可以自由实现它。

4. 程序计数器(Program Counter Register)

程序计数器可以看成是当前线程所执行的字节码的行号指示器。在任何一个确定的时刻，一个处理器（对于多内核来说是一个内核）都只会执行一条线程中的指令。因此，为了线程切换后能恢复到正确的执行位置，每条线程都需要一个独立的程序计数器，我们称这类内存区域为“线程私有”内存。

5.堆内存(Heap)

堆内存是 JVM 所有线程共享的部分，在虚拟机启动的时候就已经创建。所有的对象和数组都在堆上进行分配。这部分空间可通过 GC 进行回收。当申请不到空间时会抛出 OutOfMemoryError。堆是JVM内存占用最大，管理最复杂的一个区域。其唯一的用途就是存放对象实例：所有的对象实例及数组都在对上进行分配。jdk1.8后，字符串常量池从永久代中剥离出来，存放在队中。

6.直接内存(Direct Memory)

直接内存并不是虚拟机运行时数据区的一部分，也不是Java 虚拟机规范中农定义的内存区域。在JDK1.4 中新加入了NIO(New Input/Output)类，引入了一种基于通道(Channel)与缓冲区（Buffer）的I/O 方式，它可以使用native 函数库直接分配堆外内存，然后通脱一个存储在Java堆中的DirectByteBuffer 对象作为这块内存的引用进行操作。这样能在一些场景中显著提高性能，因为避免了在Java堆和Native堆中来回复制数据。

内存泄露8种情况

由于java的JVM引入了垃圾回收机制，垃圾回收器会自动回收不再使用的对象，了解JVM回收机制的都知道JVM是使用引用计数法和可达性分析算法来判断对象是否是不再使用的对象，本质都是判断一个对象是否还被引用。那么对于这种情况下，由于代码的实现不同就会出现很多种内存泄漏问题（让JVM误以为此对象还在引用中，无法回收，造成内存泄漏）。

1、静态集合类

如HashMap、LinkedList等等。如果这些容器为静态的，那么它们的生命周期与程序一致，则容器中的对象在程序结束之前将不能被释放，从而造成内存泄漏。简单而言，长生命周期的对象持有短生命周期对象的引用，尽管短生命周期的对象不再使用，但是因为长生命周期对象持有它的引用而导致不能被回收。

2、各种连接，如数据库连接、网络连接和IO连接等。

在对数据库进行操作的过程中，首先需要建立与数据库的连接，当不再使用时，需要调用close方法来释放与数据库的连接。只有连接被关闭后，垃圾回收器才会回收对应的对象。否则，如果在访问数据库的过程中，对Connection、Statement或ResultSet不显性地关闭，将会造成大量的对象无法被回收，从而引起内存泄漏。

3、变量不合理的作用域。

一般而言，一个变量的定义的作用范围大于其使用范围，很有可能会造成内存泄漏。另一方面，如果没有及时地把对象设置为null，很有可能导致内存泄漏的发生。

public class UsingRandom {

		private String msg;

		public void receiveMsg(){
		
		readFromNet();// 从网络中接受数据保存到msg中
		
		saveDB();// 把msg保存到数据库中

}

}
123456789101112131415

如上面这个伪代码，通过readFromNet方法把接受的消息保存在变量msg中，然后调用saveDB方法把msg的内容保存到数据库中，此时msg已经就没用了，由于msg的生命周期与对象的生命周期相同，此时msg还不能回收，因此造成了内存泄漏。

实际上这个msg变量可以放在receiveMsg方法内部，当方法使用完，那么msg的生命周期也就结束，此时就可以回收了。还有一种方法，在使用完msg后，把msg设置为null，这样垃圾回收器也会回收msg的内存空间。

4、内部类持有外部类

如果一个外部类的实例对象的方法返回了一个内部类的实例对象，这个内部类对象被长期引用了，即使那个外部类实例对象不再被使用，但由于内部类持有外部类的实例对象，这个外部类对象将不会被垃圾回收，这也会造成内存泄露。

5、改变哈希值

当一个对象被存储进HashSet集合中以后，就不能修改这个对象中的那些参与计算哈希值的字段了，否则，对象修改后的哈希值与最初存储进HashSet集合中时的哈希值就不同了，在这种情况下，即使在contains方法使用该对象的当前引用作为的参数去HashSet集合中检索对象，也将返回找不到对象的结果，这也会导致无法从HashSet集合中单独删除当前对象，造成内存泄露

6、过期引用

内存泄漏的第一个常见来源是存在过期引用。

举个例子-看你能否找出内存泄漏

import java.util.Arrays;

public class Stack {
    private Object[] elements;
    private int size = 0;
    private static final int DEFAULT_INITIAL_CAPACITY = 16;

    public Stack() {
        elements = new Object[DEFAULT_INITIAL_CAPACITY];
    }

    public void push(Object e) {
        ensureCapacity();
        elements[size++] = e;
    }

    public Object pop() {
        if (size == 0)
            throw new EmptyStackException();
        return elements[--size];
    }

    private void ensureCapacity() {
        if (elements.length == size)
            elements = Arrays.copyOf(elements, 2 * size + 1);
    }
}

1234567891011121314151617181920212223242526272829

如果一个栈先是增长，然后再收缩，从栈中弹出来的对象不会被当作垃圾回收，即使使用栈的程序不再引用这些对象，它们也不会被回收。因为栈内部维护着对这些对象的过期引用（obsolete reference）。过期引用指永远也不会再被解除的引用。在本例中，在elements数组的“活动部分（active portion）”之外的任何引用都是过期的。活动部分指elements中下标小于size的那些元素。

如果一个对象引用被无意识地保留了，垃圾回收机制不仅不会回收这个对象，而且不会回收被这个对象所引用的所有其他对象。解决方法：一旦对象引用已经过期，只需清空这些引用即可。在本例中，只要一个元素被弹出栈，指向它的引用就过期了。

6.1原因分析

上述程序并没有明显的错误，但是这段程序有一个内存泄漏，随着GC活动的增加，或者内存占用的不断增加，程序性能的降低就会表现出来，严重时可导致内存泄漏，但是这种失败情况相对较少。
代码的主要问题在pop函数，下面通过这张图示展现
假设这个栈一直增长，增长后如下图所示

当进行大量的pop操作时，由于引用未进行置空，gc是不会释放的，如下图所示

从上图中看以看出，如果栈先增长，在收缩，那么从栈中弹出的对象将不会被当作垃圾回收，即使程序不再使用栈中的这些队象，他们也不会回收，因为栈中仍然保存这对象的引用，俗称过期引用，这个内存泄露很隐蔽。

6.2解决方法

public Object pop() {
    if (size == 0)
    throw new EmptyStackException();
    Object result = elements[--size];
    elements[size] = null;
    return result;
}
1234567

一旦引用过期，清空这些引用，将引用置空。

7.缓存泄漏

内存泄漏的另一个常见来源是缓存，一旦你把对象引用放入到缓存中，他就很容易遗忘，对于这个问题，可以使用WeakHashMap代表缓存，此种Map的特点是，当除了自身有对key的引用外，此key没有其他引用那么此map会自动丢弃此值

7.1代码示例

package com.ratel.test;

/**
 * @业务描述：
 * @package_name： com.ratel.test
 * @project_name： ssm
 * @author： [email protected]
 * @create_time： 2019-04-18 20:20
 * @copyright (c) ratelfu 版权所有
 */
import java.util.HashMap;
import java.util.Map;
import java.util.WeakHashMap;
import java.util.concurrent.TimeUnit;

public class MapTest {
    static Map wMap = new WeakHashMap();
    static Map map = new HashMap();
    public static void main(String[] args) {
        init();
        testWeakHashMap();
        testHashMap();
    }



    public static void init(){
        String ref1= new String("obejct1");
        String ref2 = new String("obejct2");
        String ref3 = new String ("obejct3");
        String ref4 = new String ("obejct4");
        wMap.put(ref1, "chaheObject1");
        wMap.put(ref2, "chaheObject2");
        map.put(ref3, "chaheObject3");
        map.put(ref4, "chaheObject4");
        System.out.println("String引用ref1，ref2，ref3，ref4 消失");

    }
    public static void testWeakHashMap(){

        System.out.println("WeakHashMap GC之前");
        for (Object o : wMap.entrySet()) {
            System.out.println(o);
        }
        try {
            System.gc();
            TimeUnit.SECONDS.sleep(20);
        } catch (InterruptedException e) {
            // TODO Auto-generated catch block
            e.printStackTrace();
        }
        System.out.println("WeakHashMap GC之后");
        for (Object o : wMap.entrySet()) {
            System.out.println(o);
        }
    }
    public static void testHashMap(){
        System.out.println("HashMap GC之前");
        for (Object o : map.entrySet()) {
            System.out.println(o);
        }
        try {
            System.gc();
            TimeUnit.SECONDS.sleep(20);
        } catch (InterruptedException e) {
            // TODO Auto-generated catch block
            e.printStackTrace();
        }
        System.out.println("HashMap GC之后");
        for (Object o : map.entrySet()) {
            System.out.println(o);
        }
    }

}
/** 结果
 String引用ref1，ref2，ref3，ref4 消失
 WeakHashMap GC之前
 obejct2=chaheObject2
 obejct1=chaheObject1
 WeakHashMap GC之后
 HashMap GC之前
 obejct4=chaheObject4
 obejct3=chaheObject3
 Disconnected from the target VM, address: '127.0.0.1:51628', transport: 'socket'
 HashMap GC之后
 obejct4=chaheObject4
 obejct3=chaheObject3
 **/

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990

上面代码和图示主演演示WeakHashMap如何自动释放缓存对象，当init函数执行完成后，局部变量字符串引用weakd1,weakd2,d1,d2都会消失，此时只有静态map中保存中对字符串对象的引用，可以看到，调用gc之后，hashmap的没有被回收，而WeakHashmap里面的缓存被回收了。

8.监听器和回调

内存泄漏第三个常见来源是监听器和其他回调，如果客户端在你实现的API中注册回调，却没有显示的取消，那么就会积聚。需要确保回调立即被当作垃圾回收的最佳方法是只保存他的若引用，例如将他们保存成为WeakHashMap中的键。

内存溢出的十个场景

JVM运行时首先需要类加载器（classLoader）加载所需类的字节码文件。加载完毕交由执行引擎执行，在执行过程中需要一段空间来存储数据（类比CPU与主存）。这段内存空间的分配和释放过程正是我们需要关心的运行时数据区。内存溢出的情况就是从类加载器加载的时候开始出现的，内存溢出分为两大类：OutOfMemoryError和StackOverflowError。以下举出10个内存溢出的情况，并通过实例代码的方式讲解了是如何出现内存溢出的。

1.java堆内存溢出

当出现java.lang.OutOfMemoryError:Java heap space异常时，就是堆内存溢出了。

1.问题描述

1.设置的jvm内存太小，对象所需内存太大，创建对象时分配空间，就会抛出这个异常。

2.流量/数据峰值，应用程序自身的处理存在一定的限额，比如一定数量的用户或一定数量的数据。而当用户数量或数据量突然激增并超过预期的阈值时，那么就会峰值停止前正常运行的操作将停止并触发java . lang.OutOfMemoryError:Java堆空间错误

2.示例代码

编译以下代码，执行时jvm参数设置为-Xms20m -Xmx20m

以上这个示例，如果一次请求只分配一次5m的内存的话，请求量很少垃圾回收正常就不会出错，但是一旦并发上来就会超出最大内存值，就会抛出内存溢出。

3.解决方法

首先，如果代码没有什么问题的情况下，可以适当调整-Xms和-Xmx两个jvm参数，使用压力测试来调整这两个参数达到最优值。

其次，尽量避免大的对象的申请，像文件上传，大批量从数据库中获取，这是需要避免的，尽量分块或者分批处理，有助于系统的正常稳定的执行。

最后，尽量提高一次请求的执行速度，垃圾回收越早越好，否则，大量的并发来了的时候，再来新的请求就无法分配内存了，就容易造成系统的雪崩。

2.java堆内存泄漏

1.问题描述

Java中的内存泄漏是一些对象不再被应用程序使用但垃圾收集无法识别的情况。因此，这些未使用的对象仍然在Java堆空间中无限期地存在。不停的堆积最终会触发java . lang.OutOfMemoryError。

2.示例代码

当执行上面的代码时，可能会期望它永远运行，不会出现任何问题，假设单纯的缓存解决方案只将底层映射扩展到10,000个元素，而不是所有键都已经在HashMap中。然而事实上元素将继续被添加，因为key类并没有重写它的equals()方法。

随着时间的推移，随着不断使用的泄漏代码，“缓存”的结果最终会消耗大量Java堆空间。当泄漏内存填充堆区域中的所有可用内存时，垃圾收集无法清理它，java . lang.OutOfMemoryError。

3.解决办法

相对来说对应的解决方案比较简单：重写equals方法即可：

3.垃圾回收超时内存溢出

1、问题描述
当应用程序耗尽所有可用内存时，GC开销限制超过了错误，而GC多次未能清除它，这时便会引发java.lang.OutOfMemoryError。当JVM花费大量的时间执行GC，而收效甚微，而一旦整个GC的过程超过限制便会触发错误(默认的jvm配置GC的时间超过98%，回收堆内存低于2%)。

2.示例代码

3.解决方法

要减少对象生命周期，尽量能快速的进行垃圾回收。

4.Metaspace内存溢出

1.问题描述

元空间的溢出，系统会抛出java.lang.OutOfMemoryError: Metaspace。出现这个异常的问题的原因是系统的代码非常多或引用的第三方包非常多或者通过动态代码生成类加载等方法，导致元空间的内存占用很大。

2.示例代码

以下是用循环动态生成class的方式来模拟元空间的内存溢出的。

3.解决办法

默认情况下，元空间的大小仅受本地内存限制。但是为了整机的性能，尽量还是要对该项进行设置，以免造成整机的服务停机。

1）优化参数配置，避免影响其他JVM进程

-XX:MetaspaceSize，初始空间大小，达到该值就会触发垃圾收集进行类型卸载，同时GC会对该值进行调整：如果释放了大量的空间，就适当降低该值；如果释放了很少的空间，那么在不超过MaxMetaspaceSize时，适当提高该值。

-XX:MaxMetaspaceSize，最大空间，默认是没有限制的。

除了上面两个指定大小的选项以外，还有两个与 GC 相关的属性：
-XX:MinMetaspaceFreeRatio，在GC之后，最小的Metaspace剩余空间容量的百分比，减少为分配空间所导致的垃圾收集 。
-XX:MaxMetaspaceFreeRatio，在GC之后，最大的Metaspace剩余空间容量的百分比，减少为释放空间所导致的垃圾收集。

2）慎重引用第三方包

对第三方包，一定要慎重选择，不需要的包就去掉。这样既有助于提高编译打包的速度，也有助于提高远程部署的速度。

3）关注动态生成类的框架

对于使用大量动态生成类的框架，要做好压力测试，验证动态生成的类是否超出内存的需求会抛出异常。

5.直接内存内存溢出

1.问题描述

在使用ByteBuffer中的allocateDirect()的时候会用到，很多javaNIO(像netty)的框架中被封装为其他的方法，出现该问题时会抛出java.lang.OutOfMemoryError: Direct buffer memory异常。

如果你在直接或间接使用了ByteBuffer中的allocateDirect方法的时候，而不做clear的时候就会出现类似的问题。

2.示例代码

3.解决办法

如果经常有类似的操作，可以考虑设置参数：-XX:MaxDirectMemorySize，并及时clear内存。

6.栈内存溢出

1.问题描述

当一个线程执行一个Java方法时，JVM将创建一个新的栈帧并且把它push到栈顶。此时新的栈帧就变成了当前栈帧，方法执行时，使用栈帧来存储参数、局部变量、中间指令以及其他数据。

当一个方法递归调用自己时，新的方法所产生的数据(也可以理解为新的栈帧)将会被push到栈顶，方法每次调用自己时，会拷贝一份当前方法的数据并push到栈中。因此，递归的每层调用都需要创建一个新的栈帧。这样的结果是，栈中越来越多的内存将随着递归调用而被消耗，如果递归调用自己一百万次，那么将会产生一百万个栈帧。这样就会造成栈的内存溢出。

2.示例代码

3.解决办法

如果程序中确实有递归调用，出现栈溢出时，可以调高-Xss大小，就可以解决栈内存溢出的问题了。递归调用防止形成死循环，否则就会出现栈内存溢出。

7.创建本地线程内存溢出

1.问题描述

线程基本只占用heap以外的内存区域，也就是这个错误说明除了heap以外的区域，无法为线程分配一块内存区域了，这个要么是内存本身就不够，要么heap的空间设置得太大了，导致了剩余的内存已经不多了，而由于线程本身要占用内存，所以就不够用了。
2.示例代码

3.解决方法

首先检查操作系统是否有线程数的限制，使用shell也无法创建线程，如果是这个问题就需要调整系统的最大可支持的文件数。

日常开发中尽量保证线程最大数的可控制的，不要随意使用线程池。不能无限制的增长下去。

8.超出交换区内存溢出

1.问题描述

在Java应用程序启动过程中，可以通过-Xmx和其他类似的启动参数限制指定的所需的内存。而当JVM所请求的总内存大于可用物理内存的情况下，操作系统开始将内容从内存转换为硬盘。

一般来说JVM会抛出Out of swap space错误，代表应用程序向JVM native heap请求分配内存失败并且native heap也即将耗尽时，错误消息中包含分配失败的大小（以字节为单位）和请求失败的原因。

2.解决办法

增加系统交换区的大小，我个人认为，如果使用了交换区，性能会大大降低，不建议采用这种方式，生产环境尽量避免最大内存超过系统的物理内存。其次，去掉系统交换区，只使用系统的内存，保证应用的性能。

9.数组超限内存溢出

1.问题描述
有的时候会碰到这种内存溢出的描述Requested array size exceeds VM limit，一般来说java对应用程序所能分配数组最大大小是有限制的，只不过不同的平台限制有所不同，但通常在1到21亿个元素之间。当Requested array size exceeds VM limit错误出现时，意味着应用程序试图分配大于Java虚拟机可以支持的数组。JVM在为数组分配内存之前，会执行特定平台的检查：分配的数据结构是否在此平台是可寻址的。
2.示例代码

以下就是代码就是数组超出了最大限制。

3.解决方法

因此数组长度要在平台允许的长度范围之内。不过这个错误一般少见的，主要是由于Java数组的索引是int类型。 Java中的最大正整数为2 ^ 31 - 1 = 2,147,483,647。 并且平台特定的限制可以非常接近这个数字，例如：我的环境上(64位macOS，运行Jdk1.8)可以初始化数组的长度高达2,147,483,645（Integer.MAX_VALUE-2）。若是在将数组的长度再增加1达到nteger.MAX_VALUE-1会出现的OutOfMemoryError。

10.系统杀死进程内存溢出

1.问题概述
在描述该问题之前，先熟悉一点操作系统的知识：操作系统是建立在进程的概念之上，这些进程在内核中作业，其中有一个非常特殊的进程，称为“内存杀手（Out of memory killer）”。当内核检测到系统内存不足时，OOM killer被激活，检查当前谁占用内存最多然后将该进程杀掉。

一般Out of memory:Kill process or sacrifice child错会在当可用虚拟虚拟内存(包括交换空间)消耗到让整个操作系统面临风险时，会被触发。在这种情况下，OOM Killer会选择“流氓进程”并杀死它。

2.示例代码

3.解决方法

虽然增加交换空间的方式可以缓解Java heap space异常，还是建议最好的方案就是升级系统内存，让java应用有足够的内存可用，就不会出现这种问题。

内存溢出或泄露原因分析

分析堆内存溢出的原因可能如下：

使用了大量的递归或无限递归（递归中用到了大量的新建的对象）

使用了大量循环或死循环（循环中用到了大量的新建的对象）

类中和引用变量过多使用了Static修饰 如 public staitc Student s；在类中的属性中使用 static修饰的最好只用基本类型或字符串。如public static int i = 0; //public static String str;

数组，List，Map中存放的是对象的引用而不是对象，因为这些引用会让对应的对象不能被释放，会大量存储在内存中。

分析栈内存溢出的原因可能如下：

使用了大量的递归或无限递归

使用了大量循环或死循环（如循环中不停调用方法）

list，map，数组等长度过大等。

出现内存溢出或内存泄露的解决方案

1.修改JVM启动参数(-Xms，-Xmx)，直接增加虚拟机内存。

2.检查错误日志。

3.使用内存查看工具查看内存使用情况(如jconsole)

4.对代码进行仔细分析，找出可能发生内存溢出的位置。

详细排查方案如下:

检查在数据库中取的数据量是否超过内存

检查是否有过大的集合或对象

检查是死循环或递归是否会导致溢出

检查是否有大量对象的创建是否会出现内存问题

检查是否有大量的连接对象或监听器等未关闭

…

在开发中应如何避免出现内存泄露

1.尽量少使用枚举

2.尽量使用静态内部类而不是内部类

3.尽量使用轻量级的数据结构

4.养成关闭连接和注销监听器的习惯

5.谨慎使用static关键字

6.谨慎使用单例模式

…