OOM，全称是"Out Of Memory",翻译成中文就是"内存用完了"。在JVM中产生OOM的问题主要是方法区和堆区，也有可能出现栈区和本地方法栈区。
OOM分为虚拟内存OOM和物理内存OOM，两者是不一样的。虚拟内存OOM发生在用户空间，因为用户空间分配的就是虚拟内存，不能分配物理内存，程序在运行的时候触发缺页异常从而需要分配物理内存，内核自身在运行的时候也需要分配物理内存，如果此时物理内存不足了，就会发生物理内存OOM。用户空间虚拟内存OOM表现为malloc、mmap等内存分配接口返回失败，错误码为ENOMEM。大家也许会想，虚拟内存会OOM吗，虚拟内存那么大，对于32位进程来说就有3G，对于64位进程来说至少也得有上百G，应有尽有，而且很多教科书上都说的是虚拟内存可以随意分配，不受物理内存的限制，
oom就是我们常说的内存溢出，它是指需要的内存空间大于系统分配的内存空间，oom后果就是项目程序crash。
- 请求创建一个超大对象，通常是一个大数组。（所以尽量根据自己的实际需要去初始化数组大小）
- 超出预期的访问量/数据量，通常是上游系统请求流量飙升，常见于各类促销/秒杀活动，可以结合业务流量指标排查是否有尖状峰值。当流程突然很高是，由于提前没有对堆的内存空间做合理的准备，所以短时间内线程会创建大量的对象，这些对象可能会短时间内迅速的占满堆内存。
- 用终结器（Finalizer），该对象没有立即被 GC。
- 内存泄漏，大量的对象引用没有释放，GC没有办法对这些内存空间进行回收导致了内存泄漏的问题。
当Java进程花费 98%以上的时间执行 GC，但只恢复了不到2%的内存，且该动作连续重复了 5 次，就会抛出 java.lang.OutOfMemoryError:GC overhead limit exceeded 错误。简单地说，就是应用程序已经基本耗尽了所有可用内存， GC 也无法回收。 此类问题的原因与解决方案跟 Javaheap space非常类似。
1.2 Permgen space该错误表示永久代（Permanent Generation）已用满，通常是因为加载的 class 数目太多或体积太大。永久代存储对象主要包括以下几类：
- 加载/缓存到内存中的 class 定义，包括类的名称，字段，方法和字节码；
- 常量池；
- 对象数组/类型数组所关联的 class；
- JIT 编译器优化后的 class 信息。 PermGen 的使用量与加载到内存的 class 的数量/大小正相关。
根据 Permgen space 报错的时机，可以采用不同的解决方案，如下所示：
- 程序启动报错，修改 -XX:MaxPermSize 启动参数，调大永久代空间。
- 应用重新部署时报错，很可能是没有应用没有重启，导致加载了多份 class 信息，只需重启 JVM 即可解决。
- 运行时报错，应用程序可能会动态创建大量class，而这些 class 的生命周期很短暂，但是 JVM 默认不会卸载 class，可以设置 -XX:+CMSClassUnloadingEnabled 和-XX:+UseConcMarkSweepGC 这两个参数允许 JVM 卸载 class。 如果上述方法无法解决，可以通过 jmap 命令dump内存对象 jmap-dump:format=b,file=dump.hprof ，然后利用MAT功能逐一分析开销最大的classloader 和重复class。
JDK 1.8 使用 Metaspace 替换了永久代（Permanent Generation），该错误表示 Metaspace 已被用满，通常是因为加载的 class 数目太多或体积太大。 此类问题的原因与解决方法跟 Permgenspace 非常类似，可以参考上文。需要特别注意的是调整 Metaspace 空间大小的启动参数为 -XX:MaxMetaspaceSize。
1.4 Unable to create new native thread每个 Java 线程都需要占用一定的内存空间，当 JVM 向底层操作系统请求创建一个新的 native 线程时，如果没有足够的资源分配就会报此类错误。
JVM 向 OS 请求创建 native 线程失败，就会抛出 Unableto createnewnativethread，常见的原因包括以下几类：
- 线程数超过操作系统最大线程数 ulimit 限制；
- 线程数超过 kernel.pid_max（只能重启）；
- native 内存不足；
该问题发生的常见过程主要包括以下几步：
- JVM 内部的应用程序请求创建一个新的 Java 线程；
- JVM native 方法代理了该次请求，并向操作系统请求创建一个 native 线程；
- 操作系统尝试创建一个新的 native 线程，并为其分配内存；
- 如果操作系统的虚拟内存已耗尽，或是受到 32 位进程的地址空间限制，操作系统就会拒绝本次 native 内存分配；
- JVM 将抛出 java.lang.OutOfMemoryError:Unableto createnewnativethread错误。
解决方案
- 升级配置，为机器提供更多的内存；
- 降低 Java Heap Space 大小；
- 修复应用程序的线程泄漏问题；
- 限制线程池大小；
- 使用 -Xss 参数减少线程栈的大小；
- 调高 OS 层面的线程最大数：执行 ulimia-a 查看最大线程数限制，使用 ulimit-u xxx 调整最大线程数限制。
该错误表示所有可用的虚拟内存已被耗尽。虚拟内存（Virtual Memory）由物理内存（Physical Memory）和交换空间（Swap Space）两部分组成。 当运行时程序请求的虚拟内存溢出时就会报Outof swap space错误。
该错误出现的常见原因包括以下几类：
- 地址空间不足；
- 物理内存已耗光；
- 应用程序的本地内存泄漏（native leak），例如不断申请本地内存，却不释放。
- 执行 jmap-histo:live 命令，强制执行 Full GC；如果几次执行后内存明显下降，则基本确认为 Direct ByteBuffer 问题。
根据错误原因可以采取如下解决方案：
- 升级地址空间为 64 bit；
- 使用 Arthas 检查是否为 Inflater/Deflater 解压缩问题，如果是，则显式调用 end 方法。
- Direct ByteBuffer 问题可以通过启动参数 -XX:MaxDirectMemorySize 调低阈值。
- 升级服务器配置/隔离部署，避免争用。
- 不同于其他的 OOM 错误， Killprocessorsacrifice child 错误不是由 JVM 层面触发的，而是由操作系统层面触发的。
- 默认情况下，Linux 内核允许进程申请的内存总量大于系统可用内存，通过这种“错峰复用”的方式可以更有效的利用系统资源。 然而，这种方式也会无可避免地带来一定的“超卖”风险。例如某些进程持续占用系统内存，然后导致其他进程没有可用内存。此时，系统将自动激活 OOM Killer，寻找评分低的进程，并将其“杀死”，释放内存资源。
解决方案
- 升级服务器配置/隔离部署，避免争用。
- OOM Killer 调优。
JVM 限制了数组的最大长度，该错误表示程序请求创建的数组超过最大长度限制。 JVM 在为数组分配内存前，会检查要分配的数据结构在系统中是否可寻址，通常为Integer.MAX_VALUE-2。 此类问题比较罕见，通常需要检查代码，确认业务是否需要创建如此大的数组，是否可以拆分为多个块，分批执行。
1.8 Direct buffer memoryDirect ByteBuffer 的默认大小为 64 MB，一旦使用超出限制，就会抛出 Directbuffer memory 错误。
解决方案
- Java 只能通过 ByteBuffer.allocateDirect 方法使用 Direct ByteBuffer，因此，可以通过 Arthas 等在线诊断工具拦截该方法进行排查。
- 检查是否直接或间接使用了 NIO，如 netty，jetty 等。
- 通过启动参数 -XX:MaxDirectMemorySize 调整 Direct ByteBuffer 的上限值。
- 检查 JVM 参数是否有 -XX:+DisableExplicitGC 选项，如果有就去掉，因为该参数会使 System.gc() 失效。
- 检查堆外内存使用代码，确认是否存在内存泄漏；或者通过反射调用 sun.misc.Cleaner 的 clean() 方法来主动释放被 Direct ByteBuffer 持有的内存空间。
- 内存容量确实不足，升级配置。
[xjl@localhost ~]$ top
Tasks: 189 total, 1 running, 188 sleeping, 0 stopped, 0 zombie
%Cpu0 : 0.3 us, 0.3 sy, 0.0 ni, 99.3 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu1 : 0.0 us, 0.3 sy, 0.0 ni, 99.7 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu2 : 0.0 us, 0.0 sy, 0.0 ni,100.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu3 : 0.0 us, 0.0 sy, 0.0 ni,100.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem : 7906868 total, 159716 free, 2795504 used, 4951648 buff/cache
KiB Swap: 8388604 total, 8306172 free, 82432 used. 4685316 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
4913 avahi 20 0 62480 2144 1636 S 0.7 0.0 1944:50 avahi-daemon
15231 tomcat 20 0 162132 2400 1596 R 0.7 0.0 0:00.13 top
22529 tomcat 20 0 6325684 2.5g 9132 S 0.7 32.8 187:32.01 java[xjlt@localhost ~]$ top -Hp 22529
top - 15:10:21 up 146 days, 23:15, 1 user, load average: 0.00, 0.01, 0.05
Threads: 77 total, 0 running, 77 sleeping, 0 stopped, 0 zombie
%Cpu(s): 0.0 us, 0.0 sy, 0.0 ni,100.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem : 7906868 total, 158892 free, 2796352 used, 4951624 buff/cache
KiB Swap: 8388604 total, 8306172 free, 82432 used. 4684500 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
22529 tomcat 20 0 6325684 2.5g 9132 S 0.0 32.8 0:00.00 java
22530 tomcat 20 0 6325684 2.5g 9132 S 0.0 32.8 0:01.08 java
22531 tomcat 20 0 6325684 2.5g 9132 S 0.0 32.8 2:12.77 java
22542 tomcat 20 0 6325684 2.5g 9132 S 0.0 32.8 2:09.99 java[xjl@localhost ~]$ printf "%x\n" 22542
580e [xjl@localhost ~]$ jstack 22529 |grep 580e -A 20
"Service Thread" #8 daemon prio=9 os_prio=0 tid=0x00007f6d500c9000 nid=0x580e runnable [0x0000000000000000]
java.lang.Thread.State: RUNNABLE
"C1 CompilerThread2" #7 daemon prio=9 os_prio=0 tid=0x00007f6d500be000 nid=0x580d waiting on condition [0x0000000000000000]
java.lang.Thread.State: RUNNABLE
"Reference Handler" #2 daemon prio=10 os_prio=0 tid=0x00007f6d50082000 nid=0x5808 in Object.wait() [0x00007f6d40ffe000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
at java.lang.Object.wait(Object.java:502)
at java.lang.ref.Reference.tryHandlePending(Reference.java:191)
- locked (a java.lang.ref.Reference$Lock)
at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:153)
