在Java虚拟机的规范中，除了程序计数器，其它几块内存区域都可能出现OutOfMemoryError异常（简称OOM）。以HotSpot虚拟机为例，将分析OOM的出现及处理思路。

一、Java堆溢出

Java堆用于存储对象实例，只要不断创建对象，并且保证GC Roots到对象之间有可达路径来避免垃圾回收机制清楚这些对象，那么对象数量到达最大堆的容量限制后就会产生内存溢出异常。

-XX:+HeapDumpOnOutOfMemoryError 可以让虚拟机出现内存溢出异常时Dump出当前的内存堆转储快照以便事后进行分析。

• 异常
  java.lang.OutOfMemoryError:java heap space

• 解决异常思路
  先通过内存映射分析工具（如Eclipse Memory Analyzer)对Dump出来的堆转储快照进行分析，重点是确认内存中的对象是否是必要的，也就是要分清到底是出现了内存泄漏（Memory Leak）还是内存溢出（Memory Overflow）

  1. 内存泄漏
     可进一步通过工具查看泄漏对象到GC Roots的引用链。通过找到泄漏对象是通过怎样的路径与GC Roots相关联并导致垃圾收集器无法自动回收，可比较准确地定位出泄漏代码的位置。
  2. 内存溢出
     也就是说内存中的对象都必须活着。那就应当检查虚拟机的堆参数（-Xmx与-Xms）,与机器物理内存相比，是否可以调大。从代码上检查是否存在某些对象生命周期过长，持有状态时间过长的情况，尝试减少程序运行期的内存消耗。

二、虚拟机栈和本地方法栈溢出

HotSpot不区别虚拟机栈和本地方法栈，因此对于HotSpot来说，虽然-Xoss参数（设置本地方法栈大小）存在，但实际上是无效的，栈容量只由-Xss参数设定。Java规范描述了两种异常。

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

把异常分成两种情况，看似更严谨，却存在相互重叠的地方：当栈空间无法继续分配时，到底是内存太小，还是已使用的栈空间太大，本质上只是对同一件事物的两种描述。

1. 在单线程范围内的实验中：
   • 使用-Xss参数减少栈内存容量。结果：抛出StackOverflowError异常，异常出现时输出的堆栈深度相应缩小。
   • 定义了大量的本地变量，增大此方法帧中本地变量表的长度。结果：抛出StackOverflowError异常时输出的堆栈深度相应缩小。

实验表明：单线程下，无论是由于帧栈太大还是虚拟机栈容量太小，当内存无法分配的时候，虚拟机抛出的都是StackOverflowError异常。

2. 多线程范围实验下，通过不断的建立线程的方式倒可以产生内存溢出异常，但这样的内存溢出异常与栈空间是否足够大并不存在任何联系。也就是说，在这种情况下，为每个线程的栈分配的内存越大，反而越容易产生内存溢出异常。
   • 原因
     操作系统分配给每个进程的内存是有限制的（如32位的Windows限制为2GB）。
     虚拟机提供了参数来控制Java堆和方法区的这两部分内存的最大值，剩余的内存为2GB（操作系统限制）减去Xmx（最大堆容量），再减去MaxPermSize（最大方法区容量），程序计数器所消耗内存很小，可忽略。若虚拟机本身耗费的内存不计算在内，剩下的内存就由虚拟机栈和本地方法栈“瓜分”。
     每个线程分配到的栈容量越大，可建立的线程数量就越少，建立线程时就越容易把剩下的内存耗尽。

• 解决异常思路
  出现StackOverflowError异常时有错误堆栈可阅读，相对而言容易找到问题的所在。而且，如果使用虚拟机默认参数，栈深度在大多数情况下（因为每个方法压入栈的帧大小并不一样，所以是大多数情况下）达到1000-2000完全没有问题，对于正常的方法调用（含递归），这个深度够用了。
  若如果是建立过多线程导致的内存溢出，在不能减少线程数或者更换64虚拟机的情况下，就只能通过减少最大堆和减少栈容量来换取更多的线程。

三、方法区和运行时常量池溢出

运行时常量池时方法区的一部分。

String.intern()是Native方法,它的作用：如果字符串常量池中已包含一个等于此String对象的字符串，则返回代表池中这个字符串的String对象；否则，将此String对象包含的字符串添加到常量池中，并返回此String对象的引用。
JDK1.6中，intern()把首次遇到的字符串实例复制到永久代中，返回永久代中这个字符串实例的引用。
JDK1.7及以后，intern()不再复制实例

• 异常
  java.lang.OutOfMemoryError:permGen space

• 产生原因
  当前的很多主流框架，如Spring、Hibernate，在对类进行增强时，都会使用到CGLib这类字节码技术。增强的类越多，就需要越大的方法区来保证动态生成的Class可以载入内存。另外，JVM上的动态语言（如Groovy等）通常都会持续创建类来实现语言的动态性，随着这类语言的流行，也越容易产生此类异常。

• 解决异常思路
  方法区溢出也是常见的内存溢出异常，一个类要被垃圾收集器回收掉，判定条件是比较苛刻的。在经常动态生成大量Class的应用中，需特别注意类的回收状况。这类场景除了CGLib字节码增强和动态语言之外，常见的还有：大量JSP或动态产生JSP文件的应用（JSP第一次运行时徐编译为Java类）、基于OSGI的应用（即使是同一个类文件，被不同的加载器加载也会视为不同的类）等。

四、本机直接内存溢出

DirectMemory容量可通过-XX：MaxDirectMemorySize指定，如果不指定，则默认与Java堆最大值（-Xmx指定）一样。
由DirectMemory导致的内存溢出，一个明显的特征是在Heap Dump文件中不会看见明显的异常，如果发现OOM之后Dump文件很小，而程序中又直接或间接使用了NIO，就可考虑检查一下是否是这方法的原因。