java堆溢出
java堆用于存储对象实例，只要不断地创建对象，并且保证gc roots到对象之间有可达路径来避免垃圾回收机制来清楚这些对象，那么在 对象到达最大堆的容量限制后就会产生内存溢出溢出。
异常：java.lang.OutOfMemoryError: java heap space
要解决这个区域的异常，首先要区分是出现了内存泄露（Memory Leak）还是内存溢出（Memory OverFlow）。 解决方式：如果是内存泄露，通过工具（eclipse memory analyzer）查看泄露对象到gc roots的引用链。于是就能找到泄露对象是通过怎样的路径与gc roots相关联 并导致垃圾回收器无法自动回收它们的。掌握了泄露对象的类型信息及gc roots引用链的信息，就可以准确的找出泄露代码的位置。 如果不存在泄露，换句话说，就是内存中的对象确实都还必须存活着，那就应当检查虚拟机的堆参数（-Xmx与-Xms）与机器物理内存是否还可以调大，从代码上检查 是否存在某些对象生命周期过长，持有状态时间过长的情况，尝试减少程序运行期的内存消耗。
虚拟机栈和本地方法栈溢出
-Xoss参数设置本地方法栈大小 -Xss 参数设置栈容量
-Xoss参数是否有效，取决于jvm采用了哪种虚拟机，譬如如果采用HotSpot虚拟机，-Xoss参数（无效），这样虚拟机栈和本地方法栈通过栈容量控制。
关于虚拟机栈和本地方法栈，在java虚拟机规范中描述了两种异常： 如果线程请求的栈深度大于虚拟机所允许的最大深度，将抛出*Error异常。 如果虚拟机在扩展栈时无法申请到足够的内存空间，则抛出OutOfMemoryError异常。
在单个线程下，无论是由于栈帧太大还是虚拟机容量太小，当内存无法分配的时候，虚拟机抛出的都是*Error异常。 如果不限于单线程，在这种情况下，为每个线程的栈分配的内存越大，反而越容易产生内存溢出异常。
如果建立过多线程导致内存溢出，在不能减少线程数或者更换64位虚拟机的情况下，就只能通过减少最大堆和减少栈容量来换取更多的线程。
方法区和运行时常量池溢出
运行时常量池是方法区的一部分。 从JDK1.7开始逐步“去永久代”，我们这里讨论1.6版本，在1.6版本中，由于常量池分配在永久代内，我们可以 通过-XX:PermSeize和-XX:MaxPermSeize限制方法区大小，从而间接限制其中常量池的容量。
异常：java.lang.OutOfMemoryError: PermGen space
方法区用于存放Class的相关信息，如类名，访问修饰符，常量池，字段描述，方法描述等。 方法区异常是一种常见的内存溢出异常，一个类要被垃圾收集器回收掉，判定条件是比较苛刻的。在经常动态生成大量Class的应用中，需要特别注意类的回收情况。
本机直接内存溢出
异常：java.lang.OutOfMemoryError
DirectMemory容量可通过-XX：MaxDirectMemorySize,如果不指定，默认与java堆最大值（-Xmx指定）一样。 由DirectMemory导致的内存溢出，一个明显的特征是在Heap Dump文件中不会看见明显的异常，如果发现OOM之后Dump文件很小，而程序中又直接或间接使用了NIO，那就可以 考虑检查一下是不是这方面的原因。