这篇文章主要是对java程序运行在JVM上可能产生内存溢出（OOM）的情况进行整理...
在这里引言书中作者一句话
“希望读者在工作中遇到实际的内存溢出异常时，能根据异常的信息快速判断是哪个区域的内存溢出，知道什么样的代码可能会导致这些区域内存溢出，以及出现这些异常后该如何 处理”
所以，了解这部分知识是非常必要的，那么下面开始整理...
1. java 堆溢出
java堆用于存储对象实例，只要不断地创建对象，并且这些对象不会被回收（什么情况对象不会被回收呢？如：由于GC Root到对象之间有可达路径，所以垃圾回收机制不会清除这些对象），那么，当对象的数量达到一定的数量，从而达到了最大堆容量（-Xmx）限制了，这个时候会产生内存溢出异常。
java堆内存溢出异常的堆栈信息“java.lang.OutOfMemoryError：java heap space”
那么如何解决呢？
首先要确认内存中的对象是否是必要的，也就是要区分出现的是内存泄露（Memory Leak）还是内存溢出（Memory Overflow）
如果是内存泄露，要使用工具查看泄露对象到GC Roots的引用链，找到泄露对象是通过怎样的路径与GC Roots相关联并导致垃圾收集器无法自动回收它们。
如果不是内存泄露，那么就要检查JVM参数（-Xmx与-Xms），根据机器物理内存情况看看是否能把参数调大一些，另一方面，从代码层面考虑，看看是否存在某些对象生命周期过长、持有状态时间过长的情况，优化代码，从而尝试减少程序在运行期的内存消耗。
2. java栈溢出
JVM中有虚拟机栈和本地方法栈，栈容量由-Xss参数来设置
在java虚拟机规范中描述两种异常：
1）如果线程请求的栈深度大于虚拟机所允许的最大深度，将抛出StackOverflowError异常
2）如果虚拟机在扩展栈时无法申请足够的内存空间，则抛出OutOfMemoryError异常
那么什么时候可能会抛出上面两种异常呢？
a. 一般来说， 在单线程下，无论是由于栈帧太大还是虚拟机栈容量太小，当内存无法分配的时候，虚拟机抛出的都是StackOverflowError异常。
b. 程序在不断的创建线程，这可能会产生OutOfMemoryError异常，但是此种情况与栈空间是否足够大并没有任何关系
下面来分析一下情况b
b这种情况，为每个线程的栈分配的内存越大，反而越容易产生内存溢出异常
为什么呢？
原因：操作系统分配给每个进程的内存是有限的（32位Windows限制为2GB），虚拟机提供参数来设置java堆和方法区这两部分内存的最大值，
剩余内存 = 2GB - Xmx（最大堆容量） - MaxPermSize（最大方法区容量）
（程序计数器消耗的内存忽略，因为很小）
那么，可以创建线程的数量可以表示为：
可以创建线程的数量 = 剩余内存 / 线程的容量
所有，若每个线程分配的栈容量（-Xss）越大，可以创建的线程数量就越小
那么，不断的创建线程，把剩余内存逐渐耗尽，当剩余内存不足时，就会抛出OutOfMemoryError异常。
“java.lang.OutOfMemoryError：unable to create new native thread”
如何解决呢？
对于情况a，一般来说是不会出现的，（虚拟机默认参数，栈深度一般情况下可以达到1000-2000没有问题，正常的方法调用，这个深度足够了）
对于情况b，解决办法一个是减少线程数量，若不能减少线程数量，那么考虑“减少内存”的手段来解决，即通过减少最大堆和减少栈容量来换取更多的线程
3. 方法区和运行时常量池溢出
首先，了解一下，在JDK1.6及之前的版本中，常量池分配在永久带内，可以通过-XX:PermSize和-XX:MaxPermSize限制方法区的大小，从而间接来限制常量池的大小，
“java.lang.OutOfMemoryError:PermGen space”
JDK1.7开始逐步“去永久代”...，常量池移到了堆中
4. 直接内存溢出
DirectMemory容量默认值与java堆最大值（-Xmx）一样大，也可以通过-XX:MaxDirectMemorySize指定
由DirectMemory导致的内存溢出，可以考虑一下是不是由于程序中使用了NIO导致的，进行排查
总结，主要对堆内存、栈内存、方法区及运行时常量池、直接内存这几部分区域可能会产生内存溢出的情况进行整理...