Java中关于OOM的场景及解决方法

Java中关于OOM的场景及解决方法
1、OOM for Heap=>例如：java.lang.OutOfMemoryError: Java heap space
【分析】
此OOM是由于JVM中heap的最大值不满足需要，将设置heap的最大值调高即可，参数样例为：-Xmx2G
【解决方法】
调高heap的最大值，即-Xmx的值调大。
2、OOM for Perm=>例如：java.lang.OutOfMemoryError: Java perm space
【分析】
此OOM是由于JVM中perm的最大值不满足需要，将设置perm的最大值调高即可，参数样例为：-XX:MaxPermSize=512M
【解决方法】
调高heap的最大值，即-XX:MaxPermSize的值调大。
另外，注意一点，Perm一般是在JVM启动时加载类进来，如果是JVM运行较长一段时间而不是刚启动后溢出的话，
很有可能是由于运行时有类被动态加载进来，此时建议用CMS策略中的类卸载配置。
如：-XX:+UseConcMarkSweepGC -XX:+CMSClassUnloadingEnabled
3、OOM for GC=>例如：java.lang.OutOfMemoryError: GC overhead limit exceeded
【分析】
此OOM是由于JVM在GC时，对象过多，导致内存溢出，建议调整GC的策略，在一定比例下开始GC而不要使用默认的策略，或者将新代和老代设置合适的大小，
需要进行微调存活率。
【解决方法】
改变GC策略，在老代80%时就是开始GC，并且将-XX:SurvivorRatio（-XX:SurvivorRatio=8）和-XX:NewRatio（-XX:NewRatio=4）设置的更合理。
4、OOM for native thread created=>例如：java.lang.OutOfMemoryError: unable to create new native thread
【分析】
参考如下：
(MaxProcessMemory - JVMMemory - ReservedOsMemory) / (ThreadStackSize) = Number of threads
MaxProcessMemory   指的是一个进程的最大内存
JVMMemory         JVM内存
ReservedOsMemory   保留的操作系统内存
ThreadStackSize      线程栈的大小
如果JVM内存调的过大或者可利用率小于20%，可以建议将heap及perm的最大值下调，并将线程栈调小，即-Xss调小，如：-Xss128k
【解决方法】
在JVM内存不能调小的前提下，将-Xss设置较小，如：-Xss:128k

5、OOM for allocate huge array=>例如：Exception in thread "main": java.lang.OutOfMemoryError: Requested array size exceeds VM limit
【分析】
此类信息表明应用程序（或者被应用程序调用的APIs）试图分配一个大于堆大小的数组。例如，如果应用程序new一个数组对象，大小为512M，但是最大堆大小为256M，因此OutOfMemoryError会抛出，因为数组的大小超过虚拟机的限制。
【解决方法】
（1）、首先检查heap的-Xmx是不是设置的过小
（2）、如果heap的-Xmx已经足够大，那么请检查应用程序是不是存在bug，例如：应用程序可能在计算数组的大小时，存在算法错误，导致数组的size很大，从而导致巨大的数组被分配。
6、OOM for small swap=>例如：Exception in thread "main": java.lang.OutOfMemoryError: request <size> bytes for <reason>. Out of swap space?
【分析】
抛出这类错误，是由于从native堆中分配内存失败，并且堆内存可能接近耗尽。这类错误可能跟应用程序没有关系，例如下面两种原因也会导致错误的发生：
（1）操作系统配置了较小的交换区
（2）系统的另外一个进程正在消耗所有的内存
【解决方法】
（1）、检查os的swap是不是没有设置或者设置的过小
（2）、检查是否有其他进程在消耗大量的内存，从而导致当前的JVM内存不够分配。
注意：虽然有时<reason>部分显示导致OOM的原因，但大多数情况下，<reason>显示的是提示分配失败的源模块的名称，所以有必要查看日志文件，如crash时的hs文件。

7、OOM for exhausted native memory=>例如：java.lang.OutOfMemoryErr java.io.FileInputStream.readBytes(Native Method)
【分析】
从错误日志来看，在OOM后面没有提示引起OOM的原因，进一步查看stack trace发现，导致OOM的原因是由Native Method的调用引起的，另外检查Java heap，发现heap的使用正常，因而需要考虑问题的发生是由于Native memory被耗尽导致的。
【解决方法】
从根本上来说，解决此问题的方法应该通过检测发生问题时的环境下，native memory为什么被占用或者说为什么native memory越来越小，从而去解决引起Native memory减小的问题。但是如果此问题不容易分析时，可以通过以下方法或者结合起来处理。
（1）、cpu和os保证是64位的，并且jdk也换为64位的。
（2）、将java heap的-Xmx尽量调小，但是保证在不影响应用使用的前提下。
（3）、限制对native memory的消耗，比如：将thread的-Xss调小，并且限制产生大量的线程；限制文件的io操作次数和数量；限制网络的使用等等。

（4）、jvm crash时的signature信息小结

****************************

1.SIGSEGV:Signature Segment Value =>非法访问内存
2.SIGBUS:Signature Bus=>非法访问内存
3.SIGFPE:Signature Float Pointer Exception =>浮点数异常，错误的算术操作 =>erroneous arithmetic operation
4.SIGPIPE:Signature Pipe =>试图写管道时错误
5.SIGXFSZ:Signature Maximum File Size =>文件增长超过允许的最大值
6.SIGILL:Signature Illegal Instrucation =>不合法的指令
7.SIGUSR1:Signature User 1 =>识别用户定义的条件
8.SIGUSR2:Signature User 2 =>识别用户定义的条件
9.SIGHUP:Signature Hang Up =>挂起=>控制终端关闭时
10.SIGINT:Signature Interrupt =>用户希望中断进程时
11.SIGTERM:Signature Termination =>请求终端
12.SIGQUIT:Signature Quit =>用户请求执行core dump

****************************

（5）、关于stack size for jvm =>java stack and native method stack

-Xss256k =>maximum size of native code stack for each thread =>default 500K

-Xoss256k =>maximum size of java code stack for each thread=>default 400K

待续………………