17、JVM实战:内存溢出与内存泄漏


157

内存溢出

  • 内存溢出相对于内存泄漏来说,尽管更容易被理解,但是同样的,内存溢出也是引发程序崩溃的罪魁祸首之一。
  • 由于GC一直在发展,所有一般情况下,除非应用程序占用的内存增长速度非常快,造成垃圾回收已经跟不上内存消耗的速度,否则不太容易出现OOM的情况。
  • 大多数情况下,GC会进行各种年龄段的垃圾回收,实在不行了就放大招,来一次独占式的Full GC操作,这时候会回收大量的内存,供应用程序继续使用。
  • javadoc中对OutOfMemoryError的解释是,没有空闲内存,并且垃圾收集器也无法提供更多内存(意思是即使GC之后,也无法提供空闲的内存)。
  • 首先说没有空闲内存的情况:说明Java虚拟机的堆内存不够。原因有二:

1、 Java虚拟机的堆内存设置不够;
比如:可能存在内存泄漏问题;也很有可能就是堆的大小不合理,比如我们要处理比较可观的数据量,但是没有显式指定JVM堆大小或者指定数值偏小。我们可以通过参数一Xms、一Xmx来调整。
2、 代码中创建了大量大对象,并且长时间不能被垃圾收集器收集(存在被引用)对于老版本的OracleJDK,因为永久代的大小是有限的,并且JVM对永久代垃圾回收(如,常量池回收、卸载不再需要的类型)非常不积极,所以当我们不断添加新类型的时候,永久代出现OutOfMemoryError也非常多见,尤其是在运行时存在大量动态类型生成的场合;类似intern字符串缓存占用太多空间,也会导致0OM问题对应的异常信息,会标记出来和永久代相关:“java.lang.OutOfMemoryError:PermGenspace”;
随着元数据区的引入,方法区内存已经不再那么窘迫,所以相应的00M有所改观,出现00M,异常信息则变成了:“java. lang. OutOfMemoryError: Metaspace"。 直接内存不足,也会导致0OM。

  • 这里面隐含着一层意思是,在抛出0utOfMemoryError之 前,通常垃圾收集器会被触发,尽其所能去清理出空间。

1、 *例如:在引用机制分析中,涉及到JVM会去尝试回收软引用指向的对象等;
2、 *在java.nio.BIts.reserveMemory()方法中,我们能清楚的看到,System.gc()会被调用,以清理空间;
当然,也不是在任何情况下垃圾收集器都会被触发的
3、 *比如,我们去分配一个超大对象,类似一个超大数组超过堆的最大值,JVM可以判断出垃圾收集并不能解决这个问题,所以直接拋出OutOfMemoryError;


158

内存泄漏(Memory Leak)

  • 也称作“存储渗漏”。严格来说,只有对象不会再被程序用到了,但是GC又不能回收他们的情况,才叫内存泄漏。
  • 但实际情况很多时候一些不太好的实践(或疏忽)会导致对象的生命周期变得很长甚至导致OOM,也可以叫做宽泛意义上的“内存泄漏。
  • 尽管内存泄漏并不会立刻引起程序崩溃,但是一旦发生内存泄漏,程序中的可用内存就会被逐步蚕食,直至耗尽所有内存,最终出现OutOfMemory异常,导致程序崩溃。

注意,这里的存储空间并不是指物理内存,而是指Java层面JVM虚拟内存大小,这个虚拟内存大小取决于磁盘交换区设定的大小。

*
Forgotten Reference:由于某种原因没有/忘记断开的引用,导致内存泄漏。

Java中的内存泄漏举例:

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