内存溢出和内存泄露

内存溢出（OOM）

• 内存溢出相对于内存泄漏来说，尽管更容易被理解，但是同样的，内存溢出也是引发程序崩溃的罪魁祸首之一。
• 由于GC一直在发展，所有一般情况下，除非应用程序占用的内存增长速度非常快，造成垃圾回收已经跟不上内存消耗的速度，否则不太容易出现OOM的情况。
• 大多数情况下，GC会进行各种年龄段的垃圾回收，实在不行了就放大招，来一次独占式的Full GC操作，这时候会回收大量的内存，供应用程序继续使用。
• javadoc中堆OutOfMemoryError的解释是，没有空闲的内存，并且垃圾收集器也无法提供更多内存。
• 这里面隐藏着一层意思是，在抛出OutOfMemoryError之前，通常垃圾收集器会被触发，尽其所能区清理出空间。
  1. 例如：在引用机制分析中，涉及JVM会去尝试回收软引用指向的对象等。
  2. 在java.nio.BIts.reserveMemory( ) 方法中，我们能清楚看到，System.gc( ) 会被被调用，以清理空间。
• 当然，也不是在任何情况下垃圾收集器都会被触发
  1. 比如，我们区分配一个超大对象，类似一个超大数组超过堆的最大值，JVM可以判断出垃圾收集并不能解决这个问题，所以直接抛出OutOfMemoryError。

当没有空闲内存的情况下，说明Java虚拟机的堆内存不够。

原因有2个：

① Java虚拟机的堆内存设置不够。

比如：可能存在内存泄露问题；也可能是堆的大小不合理，比如我们要处理比较可观的数据量，但是没有显式指定JVM堆大小或者指定数值偏小。我们可以通过参数-Xms , -Xmx 来调整。

② 代码中创建了大量大对象，并且长时间不能被垃圾收集器收集（存在被引用）

对于老版本的Oracle JDK，因为持久代的大小是有限的，并且JVM堆持久代垃圾回收（如，常量池回收、卸载不再需要的类型）非常不积极，所以我们不断添加新类型的时候，持久代会出现OutOfMemoryError也非常多见，尤其是在运行时存在大量动态类型生成的场合：类似intern子字符串缓存占用太多空间，也会导致OOM问题。对应的异常信息，会标记出来和持久代相关："java.lang.OutOfMemoryError: PremGen space"。

随着元数据区的引入，方法区内存已经不再那么窘迫，所以对应的OOM有所改观，出现OOM，异常信息则变成了："java.lang.OutOfMemoryError: Metaspace"。直接内存不足，也会导致OOM。

 

内存泄露

• 也称作"存储渗漏"。严格来说，只有对象不再被程序用到了，但是GC又不能回收它们的情况，才叫内存泄漏。
• 但实际情况很多时候一些不太好的实践（或疏忽）会导致对象的生命周期变得很长甚至OOM，也可以叫做宽泛意义上的"内存泄漏"。
• 尽管内存泄露并不会立刻引起程序崩溃，到那时一旦发生内存泄漏，程序中的可用内存就会逐步蚕食，直到耗尽所有内存，最终出现OutOfMemory异常，导致程序崩溃。
• 注意，这里的存储空间并不是指物理内存，而是指虚拟内存大小，这个虚拟内存大小取决于磁盘交换区设定的大小。

 

问几个问题：

1、举例子说明什么是宽泛意义上的"内存泄漏"？什么是不太好的实践？

当定义变量的时候，如果把大量的变量定义在类里面，也就是成员变量，这时候，这些变量的声明周期就会很长，它们会随着类的消亡而消亡，如果这种长周期的变量太多（不太好的实践），也会导致OOM，有些对象无法被回收也不能被引用，这是宽泛意义上的"内存泄漏"。

有些变量，没必要定义在成员变量里边，定义在方法里边就行了，这样的局部变量就随着方法的消亡而消亡，生命周期短。可以在一定长度上避免内存泄漏。

 

2、举内存泄漏的例子？

• 单例模式：单例的生命周期和应用程序是一样长的，所以在单例程序中，如果持有对外部对象的引用的话，那么这个外部对象是不能被回收的，则会导致内存泄漏的产生。
• 一些提供close的资源未关闭导致内存泄漏：数据库连接（dataSource.getConnection( ) ）, 网络链接（socket）和io连接必须手动close，否则是不能被回收的。

3、单例模式引起的内存泄漏问题？

参考文章https://blog.csdn.net/cao_dayong/article/details/64447191