针对以Java主导的企业级应用开发，Java虚拟机是整个项目架构的灵魂所在。只有弄清楚其内存分配及垃圾回收机制才能够在项目建设活动过程中游刃而余，无论是基于当前流行的微服务体系（以Spring家族的 Spring Cloud或以Ali家族的Dubbo）or 即将（已经）流行的服务网格体系。
废话不多说，先来张Java虚拟机内存体系结构图：
注：本文主要基于Oracle JDK体系进行阐述
此体系结构图主要基于Java Lang Out Of Memory Error异常进行适当微调，毕竟，核心的问题及要素可通过上述图进行展示。本文主要基于OOM异常进行解析，如果想进一步了解Java虚拟机的相关知识，可参考官网所述。
当我们的应用程序因Java虚拟机内存分配异常时，就会抛出 java.lang.OutOfMemoryError 错误。本文结合实际的项目经验总结了常见的 OOM 原因及其解决方法，如有遗漏或错误，欢迎补充指正。
1、Java Heap Space
此场景表明当堆内存（Heap Space）没有足够的空间存放新创建的对象时，就会抛出 java.lang.OutOfMemoryError:Java heap space错误。
原因分析
Java heap space 错误产生的常见原因主要包含以下几类：
1、请求创建一个超大对象，通常是一个大数组
2、超出预期的访问量/数据量，通常是上游系统请求流量飙升
3、过度使用终结器（Finalizer），该对象没有立即被 GC
4、内存泄漏（Memory Leak），大量对象引用没有释放，JVM 无法对其自动回收，常见于使用了 File 等资源没有回收
解决方案
针对大部分情况，通常只需要通过 -Xmx 参数调高 JVM 堆内存空间即可。如果仍然没有解决，可以参考以下情况做进一步处理：
1、如果是超大对象，可以检查其合理性，比如是否一次性查询了数据库全部结果，而没有做结果数限制。
2、如果是业务峰值压力，可以考虑添加机器资源，或者做限流降级。
3、如果是内存泄漏，需要找到持有的对象，优化代码设计。
2、GC overhead limit exceeded
此场景为jdk1.6新增的错误类型。如果没有这个异常，会出现什么情况呢？经过垃圾回收释放的2%可用内存空间会快速的被填满，迫使GC再次执行，出现频繁的执行GC操作， 服务器会因为频繁的执行GC垃圾回收操作而达到100%的时使用率，服务器运行变慢，应用系统会出现卡死现象，平常只需几毫秒就可以执行的操作，现在需要更长时间，甚至是好几分钟才可以完成。
原因分析
1、垃圾回收可用空间较小
2、频繁执行GC操作，使得资源使用率较高
解决方案
1、增加heap堆内存
2、增加对内存后错误依旧，获取heap内存快照，使用Eclipse MAT工具，找出内存泄露
发生的原因并进行修复
3、优化代码以使用更少的内存或重用对象，而不是创建新的对象，从而减少垃圾收集器
运行的次数。如果代码中创建了许多临时对象(例如在循环中)，应该尝试重用它们
4、升级JDK到1.8，最起码也是1.7，并使用G1 GC垃圾回收算法
5、优化代码
3、Unable to create new native thread
每个 Java 线程都需要占用一定的内存空间，当 JVM 向底层操作系统请求创建一个新的 native 线程时，如果没有足够的资源分配就会报此类错误。
原因分析
JVM 向 OS 请求创建 native 线程失败，就会抛出 Unableto createnewnativethread，常见的原因包括以下几类：
1、线程数超过操作系统最大线程数 ulimit 限制
2、线程数超过 kernel.pid_max（只能重启）
3、native 内存不足
解决方案
1、升级配置，为机器提供更多的内存
2、降低 Java Heap Space 大小
3、修复应用程序的线程泄漏问题
4、限制线程池大小
5、使用 -Xss 参数减少线程栈的大小
6、调高 OS 层面的线程最大数：执行 ulimia-a 查看最大线程数限制，使用 ulimit-u xxx 调整最大线程数限制
4、Out of swap space？
该错误表示所有可用的虚拟内存已被耗尽。虚拟内存（Virtual Memory）由物理内存（Physical Memory）和交换空间（Swap Space）两部分组成。当运行时程序请求的虚拟内存溢出时就会报 Outof swap space? 错误。
原因分析
该错误出现的常见原因包括以下几类：
1、地址空间不足
2、物理内存已耗光
3、应用程序的本地内存泄漏（native leak），例如不断申请本地内存，却不释放
4、执行 jmap-histo:live 命令，强制执行 Full GC；如果几次执行后内存明显下降，则基本确认为 Direct ByteBuffer 问题
解决方案
根据错误原因可以采取如下解决方案：
1、升级地址空间为 64 bit
2、使用 Arthas 检查是否为 Inflater/Deflater 解压缩问题，如果是，则显式调用 end 方法
3、Direct ByteBuffer 问题可以通过启动参数 -XX:MaxDirectMemorySize 调低阈值
4、升级服务器配置/隔离部署，避免争用
5、 Kill process or sacrifice child
有一种内核作业（Kernel Job）名为 Out of Memory Killer，它会在可用内存极低的情况下“杀死”（kill）某些进程。OOM Killer 会对所有进程进行打分，然后将评分较低的进程“杀死”，具体的评分规则可以参考 Surviving the Linux OOM Killer。 不同于其他的 OOM 错误， Killprocessorsacrifice child 错误不是由 JVM 层面触发的，而是由操作系统层面触发的。
原因分析
1、默认情况下，Linux 内核允许进程申请的内存总量大于系统可用内存，通过这种“错峰复用”的方式可以更有效的利用系统资源
2、然而，这种方式也会无可避免地带来一定的“超卖”风险。例如某些进程持续占用系统内存，然后导致其他进程没有可用内存。此时，系统将自动激活 OOM Killer，寻找评分低的进程，并将其“杀死”，释放内存资源
解决方案
1、升级服务器配置/隔离部署，避免争用
2、OOM Killer 调优
6、Requested array size exceeds VM limit
JVM 限制了数组的最大长度，该错误表示程序请求创建的数组超过最大长度限制。
JVM 在为数组分配内存前，会检查要分配的数据结构在系统中是否可寻址，通常为 Integer.MAX_VALUE-2。
此类问题比较罕见，通常需要检查代码，确认业务是否需要创建如此大的数组，是否可以拆分为多个块，分批执行。
7、Direct buffer memory
Java 允许应用程序通过 Direct ByteBuffer 直接访问堆外内存，许多高性能程序通过 Direct ByteBuffer 结合内存映射文件（Memory Mapped File）实现高速 IO。
原因分析
Direct ByteBuffer 的默认大小为 64 MB，一旦使用超出限制，就会抛出 Directbuffer memory 错误。
解决方案
1、Java 只能通过 ByteBuffer.allocateDirect 方法使用 Direct ByteBuffer，因此，可以通过 Arthas 等在线诊断工具拦截该方法进行排查
2、检查是否直接或间接使用了 NIO，如 netty，jetty 等
3、通过启动参数 -XX:MaxDirectMemorySize 调整 Direct ByteBuffer 的上限值
4、检查 JVM 参数是否有 -XX:+DisableExplicitGC 选项，如果有就去掉，因为该参数会使 System.gc() 失效
5、检查堆外内存使用代码，确认是否存在内存泄漏；或者通过反射调用 sun.misc.Cleaner 的 clean() 方法来主动释放被 Direct ByteBuffer 持有的内存空间
6、内存容量确实不足，升级配置
8、Permgen space
该错误表示永久代（Permanent Generation）已用满，通常是因为加载的 class 数目太多或体积太大。
原因分析
永久代存储对象主要包括以下几类：
1、加载/缓存到内存中的 class 定义，包括类的名称，字段，方法和字节码
2、常量池
3、对象数组/类型数组所关联的 class
4、JIT 编译器优化后的 class 信息[PermGen 的使用量与加载到内存的 class 的数量/大小正相关]
解决方案
根据 Permgen space 报错的时机，可以采用不同的解决方案，如下所示：
1、程序启动报错，修改 -XX:MaxPermSize 启动参数，调大永久代空间
2、应用重新部署时报错，很可能是没有应用没有重启，导致加载了多份 class 信息，只需重启 JVM 即可解决
3、运行时报错，应用程序可能会动态创建大量 class，而这些 class 的生命周期很短暂，但是 JVM 默认不会卸载 class，可以设置 -XX:+CMSClassUnloadingEnabled 和 -XX:+UseConcMarkSweepGC这两个参数允许 JVM 卸载 class
9、Metaspace
原因分析
JDK 1.8 使用 Metaspace 替换了永久代（Permanent Generation），该错误表示 Metaspace 已被用满，通常是因为加载的 class 数目太多或体积太大。
解决方案
此类问题的原因与解决方法跟 Permgenspace 非常类似，可以参考上文。需要特别注意的是调整 Metaspace 空间大小的启动参数为 -XX:MaxMetaspaceSize。
