0%

内存泄漏与内存溢出

发表于 更新于 分类于 阅读次数： Valine：
本文字数： 3.6k 阅读时长 ≈ 3 分钟

1. 内存泄漏

1.1 定义

内存泄漏是指一个不再被程序使用的对象或变量还在内存中占有存储空间。在C/C++语言中，内存的分配与释放是由开发人员来负责的，如果开发人员忘记释放已分配的内存就会造成内存泄漏。而在Java语言中引进了垃圾回收机制，由垃圾回收器负责回收不再使用的对象。既然有垃圾回收器来负责回收垃圾，那么是否还会存在内存泄漏的问题呢？

其实，在Java语言中，判断一个内存空间是否符合垃圾回收的标准有两个：第一，给对象赋了空值null，以后再也没有被使用过；第二，给对象赋予了新值，重新分配了内存空间。一般来讲，内存泄漏主要有两种情况：一是在堆中申请的空间没有被释放；二是对象已经不再被使用，但还仍然在内存中保留着。 垃圾回收机制的引入可以有效地解决第一种情况；而对于第二种情况，垃圾回收机制则无法保证不再使用的对象会被释放。因此，Java语言中的内存泄漏主要指的是第二种情况。

下面通过一个示例来介绍Java语言中的内存泄漏：

1
2
3
4
5
Vector v = new Vector(10);
for (int i = 1; i < 10; i++) {
    Object o = new Object();
    v.add(o);
}

在上述例子的循环中，不断创建新的对象并加到Vector集合中，当退出循环后，对象o的作用域将会结束，但是由于v在使用这些对象，因此垃圾回收器无法将其回收，此时就造成了内存泄漏。只有将这些对象从Vector中删除才能释放创建的这些对象。

内存泄漏的典型例子是一个没有重写 hashCode 和 equals 方法的 Key 类在 HashMap 中作为键保存的情况， 最后会生成很多重复的对象。 所有的内存泄露最后都会抛出OutOfMemoryError 异常 （ Exception in thread “main”java.lang.OutOfMemoryError: Java heap space） 。

1.2 内存泄露原因

在Java语言中，容易引起内存泄漏的原因有很多，主要有以下几个方面的内容：

  1. 静态集合类，例如HashMap和Vector。如果这些容器是静态的，由于他们的生命周期与程序一致，那么容器中的对象在程序结束之前将不能被释放，从而造成内存泄漏；

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

  3. 监听器。在Java语言中，往往会使用到监听器。通常一个应用中会用到多个监听器，但在释放对象的同时往往没有相应地删除监听器，这也可能导致内存泄漏。

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

    1
    2
    3
    4
    5
    6
    7
    8
    class Server {
        private String msg;
        
        public void recieveMsg() {
            readFromNet(); // 从网络接收数据保存到msg中
            saveDB(); // 把msg保存到数据库中
        }
    }

    在上述伪代码中，通过 readFromNet() 方法接收的消息保存在变量 msg 中，然后调用 saveDB() 方法把 msg 的内容保存到数据库中，此时 msg 已经没用了，但是由于 msg 的生命周期与对象的生命周期相同，此时 msg 还不能被回收，因此造成了内存泄漏。对于这个问题，有如下两种解决方法：第一种方法，由于 msg 的作用范围只在recieveMsg() 方法内，因此可以把 msg 定义为这个方法的局部变量，当方法结束后， msg 的生命周期就会结束，此时垃圾回收器就可以回收 msg 的内容了；第二种方法，在使用完 msg 后就把 msg 设置为 null，这样垃圾回收器就会自动回收 msg 内容所占的内存空间。

  5. 单例模式可能会造成内存泄漏。单例模式的实现方法有很多种，下例中所使用的单例模式就可能会造成内存泄漏：

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    class BigClass {
        // class body
    }
    class Singleton {
        private BigClass bc;
        private static Singleton instance =  new Singleton(new BigClass());
        private Singleton(BigClass bc) {
            this.bc = bc;
        }
        public Singleton getInstance() {
            return instance;
        }
    }

    在上述实现的单例模式中，Singleton 存在一个对对象 BigClass 的引用，由于单例对象以静态变量的方式存储，因此它在 JVM 的整个生命周期中都存在，同时由于它有一个对对象 BigClass 的引用，这样会导致 BigClass类的对象不能被回收。

1.3 内存泄露解决方案

  1. 避免在循环中创建对象。
  2. 尽早释放无用对象的引用。 （最基本的建议）
  3. 尽量少用静态变量， 因为静态变量存放在永久代（方法区） ， 永久代基本不参与垃圾回收。
  4. 使用字符串处理时， 避免使用 String， 应大量使用 StringBuffer，。因为每一个 String对象都得独立占用内存一块区域。

1.4 查找内存泄露

我们可以使用 JConsole 工具来查找是否存在内存泄漏现象。

没有内存泄露的：

造成内存泄露的： 如果内存的大小持续地增长， 则说明系统存在内存泄漏。

2. 内存溢出

内存溢出是指程序运行过程中无法申请到足够的内存而导致的一种错误。

内存溢出的几种情况（OOM 异常）：

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

  1. 虚拟机栈和本地方法栈溢出：如果线程请求的栈深度大于虚拟机所允许的最大深度，将抛出StackOverflowError 异常；如果虚拟机在扩展栈时无法申请到足够的内存空间 ， 则抛出OutOfMemoryError 异常。

  2. 堆溢出：一般的异常信息如 java.lang.OutOfMemoryError:Java heap spaces。出现这种异常， 一般手段是先通过内存映像分析工具(如 Eclipse MemoryAnalyzer)对 dump 出来的堆转存快照进行分析， 重点是确认内存中的对象是否是必要的， 先分清是因为内存泄漏(Memory Leak)还是内存溢出(MemoryOverflow)。

    如果是内存泄漏， 可进一步通过工具查看泄漏对象到 GC Roots 的引用链。于是就能找到泄漏对象是通过怎样的路径与 GC Roots 相关联并导致垃圾收集器无法自动回收。

    如果不存在泄漏， 那就应该检查虚拟机的参数(-Xmx 与-Xms)的设置是否适当。

  3. 方法区溢出：异常信息如 java.lang.OutOfMemoryError:PermGen space。

  4. 运行时常量池溢出：异常信息如 java.lang.OutOfMemoryError:PermGen space

2.1 内存溢出原因

  1. 内存中加载的数据量过于庞大， 如一次从数据库取出过多数据；
  2. 集合类中有对对象的引用， 使用完后未清空， 使得 JVM 不能回收；
  3. 代码中存在死循环或循环产生过多重复的对象实体；
  4. 启动参数内存值设定的过小。

2.2 内存溢出解决方案

第一步， 修改 JVM 启动参数， 直接增加内存。 (-Xms， -Xmx 参数一定不要忘记加。一般要将-Xms 和-Xmx 选项设置为相同， 以避免在每次 GC 后调整堆的大小； 建议堆的最大值设置为可用内存的最大值的 80%)。
第二步， 检查错误日志， 查看“OutOfMemory” 错误前是否有其它异常或错误。
第三步， 对代码进行走查和分析， 找出可能发生内存溢出的位置。
第四步， 使用内存查看工具动态查看内存使用情况（Jconsole）。

------ 本文结束------