内存溢出（OOM）
内存溢出相对于内存泄漏来说，尽管更容易被理解，但是同样的，内存溢出也是引发程序崩溃的罪魁祸首之一。
由于GC一直在发展，所有一般情况下，除非应用程序占用的内存增长速度非常快，造成垃圾回收已经跟不上内存消耗的速度，否则不太容易出现OOM的情况。
大多数情况下，GC会进行各种年龄段的垃圾回收，实在不行了就放大招，来一次独占式的Full GC操作，这时候会回收大量的内存，供应用程序继续使用。
javadoc中对outOfMemoryError的解释是，没有空闲内存，并且垃圾收集器也无法提供更多内存。
造成空闲内存不够的情况有以下原因：
1.java虚拟机堆内存设置不够
比如：可能存在内存泄漏问题；也可能是堆的大小不合理，在需要处理较大的数据量时，没有显式指定JVM堆大小或者指定数值偏小。可以通过-Xms,-Xmx来调整
2.代码中创建了大量的对象，并且长时间不能被垃圾收集器搜集（存在被引用）
对于老版本ORACLE JDK，因为永久代的大小是有限的，并且JVM对永久代垃圾回收（如常量池回收，卸载不再需要的类型）非常不积极，所以我们在不断添加新类型的时候，永久代出现OOM异常很常见，尤其在运行时存在存在大量动态类型生成的场合，类似intern字符串缓存占用太多空间，也会导致OOM问题。对应的异常信息会标记出来和永久代相关：“java.lang.OutOfMemoryError: PermGen space”
随着元数据区的引入，方法区内存已经不再那么窘迫，所以相对应的OOM有所改观，出现OOM，异常信息变成“java.lang.OutOfMemoryError: Metaspace”，直接内存不足也会导致OOM。
在抛出OOM异常之前，通常垃圾收集器会被触发，尽其所能去清理出空间。在引用机制分析中，涉及到JVM会去尝试回收软引用指向的对象等；在java.nio.BIts.reserveMemory()方法中，我们能清楚地看到，System.gc()会被调用，以清理空间。当然，也不是任何情况下垃圾收集器都会被触发的，比如，我们去分配一个超大对象，当这个超大对象超过堆的最大值，JVM可以判断出垃圾收集并不能解决这个问题，所以直接抛出OOM异常。
内存泄漏（Memory Leak）
严格来说,只有对象不在被程序用到，但是GC又不能回收他们的情况下才叫内存泄漏；
但实际情况很多时候一些不合理的操作导致对象的生命周期变的很长甚至OOM，也可以叫做宽泛意义上的“内存泄漏”；
尽管内存泄漏不会立刻引起程序崩溃，但是一旦发生内存泄漏，程序中的可用内存就会被逐步蚕食，直至耗尽所有的内存，最终出现OOM异常，导致程序崩溃；
java所使用了可达性分析算法，从GC Roots出发，遍历所有引用链所触及的对象，属于存活对象，不会被虚拟机回收；而GC Roots不可达的对象将会被回收；
图2中，有些对象的引用链已经断开，表示这些对象不再被使用，但是有一个指针忘记断开了，而GC Roots通过引用链，可以找到这些不再使用的对象，导致这些对象无法被回收
内存泄漏举例：
1. 单例模式
单例的生命周期和应用程序是一样长的，所以单例程序中，如果持有对外部对象引用的话，那么这个外部对象是不能被回收的，则会导致内存泄漏的产生。
2. 一些提供close的资源未关闭导致内存泄漏
数据库连接（dataSource.getConnection()）,网络连接（socket）和io连接必须手动close，否则是不能被回收的；