JVM虚拟机-OOM

1.java堆：
java堆大小配置：
最大值：-Xmx
最小值：-Xms
当两个参数设置为一样时可以避免自动扩展
java堆内存中的OOM异常是实际应用中常见的内存溢出异常情况，当java堆出现内存溢出时，异常堆栈信息”java.lang.OutOfMemoryError”会跟着进一步提示”java heap space”.
解决办法：
<1>通过内存映像分析工具（Eclipse Memory Analyzer）对Dump出来的堆转储快照进行分析，重点是确认出存中的对象是否是必要的，先分清楚是出现了内存泄露(Memory Leak)还是内存溢出(Memory Overflow)
<2>如果是Memory Leak则进一步通过工具查看泄露对到GC Roots的引用链.找到泄露对象是通过怎样的路径与GC Roots相关联并导致垃圾收集器无法自动回收它们的.
<3>如果不存泄露，就说明内存的对象确实都必须活着，就应当检查jvm的堆参数(-Xmx与-Xms),与机器物理内存对比看是否可以调整，从代码检查是否存在某些对象生命周期过长，持有时间过长的情况，尝试减少运行期内存消耗。
2.虚拟机栈和本地方法栈溢出
1)配置：通过-Xss参数设定
2)异常：
a.StackOverflowError:线程请求的栈深度大于虚拟机允许的最大深度；
b.OutOfMemoryError:虚拟机在扩展栈时无法申请到足够的内存空间
3)解决方法:
a.开发多线程应用时出现StackOverflowError异常可以通过阅读错误堆栈，定位出现问题代码
b.如果使用jvm默认参数，栈深度在大多数情况下达到1000~2000完全没有问题，对于正常的方法调用，这个深度完全够用。如果建立过多线程导致的内存溢出，在不能减少线程数或者更换64位虚拟机的情况下，只能通过减少最大堆和减少栈容量来换取更多的线程。
3.方法区和运行时常量池溢出
配置：通过-XX:PermSize和-XX:MaxPermSize限制方法区大小，从而间接限制其中常量池的容量(jdk1.6及之前的版本,常量池分配在永久代中)当运行时常量池溢出，在OutOfMemoryError后面跟随的提示信息”PermGen space”,说明运行时常量池属于方法区(HotSpot虚拟机中的永久代)一部分
解决方法：
方法区用于存入Class的相关信息，如类名，访问修饰符，常量池，字段描述，方法描述等。在经常动态生成大量Class的应用中，需要特别注意类的回收状况。常见的生成大量Class的情景有如下几种：
a.使用CGLib字节码增强和动态语言
b.大量JSP或动态产生JSP文件的应用
c.基于OSGI的应用(同一个类文件，被不同的加载器加载也会视为不同的类)
4.本机直接内存溢出
配置：
-XX:MaxDirectMemorySize(如果不指定，则默认与Java堆最大值(-Xmx指定)一样)
解决方法：
分析OOM之后Dump文件，如果文件很小，而程序 中又直接或间接使用了NIO，则可以跟踪NIO中的内存分配