如果Java程序中显示oom，该怎么解决？ oom会在什么场景出现？ 1.javaheapspace2. gcoverheadlimitexceeded3. permgenspace4. meta space5. unabletocreatenewnativethread6. out of swap space7space
1.Java头部空间
如果堆内存(Heap Space )中没有足够的空间来存储新创建的对象，则可以抛出内存错误Java.lang.out of : javaheapspace错误，并在发现后立即进行处理
产生Javaheap space错误的常见原因可分为以下类别：
1、要求制作巨大的实物。 通常是大排列。
2、超出预期的访问量/数据量，通常上游系统要求流量激增，常见于各种促销/秒杀活动，可结合业务流量指标查看是否存在尖峰。
3、终结器(Finalizer )使用过度，其对象没有立即被GC。
4、内存泄漏，大量对象引用未释放，JVM无法自动回收。 经常出现没有使用File等资源回收的情况。原因分析
大多数情况下，只需使用-Xmx参数来增加JVM堆内存空间。 如果仍然无法解决，请参考以下情况进一步处理。
1、超大型对象时，可以在不限制结果数的情况下检查是否一次性查询了数据库的所有结果等合理性。
2、如果是工作高峰期的压力，可以考虑追加机械资源或进行限流降级。
3、内存泄漏时，需要修改代码设计，如找到对方，关闭未释放的连接等。
2.GCoverheadlimitexceededJava进程花费98%以上的时间运行GC，但只恢复了不到2%的内存，如果连续五次重复此操作， 抛出内存错误3360 gcoverheadlimit的Java.lang.out简单来说，就是APP应用程序几乎耗尽了可用的内存，GC也无法回收。
出现此类问题的原因与http://www.Sina.com/javaheapspace非常相似，请参考以上内容。
3. Permgen space此错误表示性能生成已满。 通常是因为加载的class数量太多或体积太大。解决方案
持久存储对象主要有以下几类：
1、加载/缓存在内存中的class定义，包括类的名称、字段、方法和字节码；
2、定数池；
3、与对象数组/类型数组相关的class
4、JIT编译器优化的class信息。
PermGen的使用情况与加载到内存中的类的数量/大小正相关。解决方案
根据Permgen space何时报告错误，可以使用不同的解决方案，如下所示：
1、报告程序启动错误，修改-XX:MaxPermSize启动参数，增大永久世代空间。
2、重新部署APP应用程序时出现错误的情况下，很可能APP应用程序没有重新启动，因为加载了多个class信息，所以只要重新启动JVM就可以解决。
3、运行时错误，APP应用程序可能会动态创建大量的class，这些class的生命周期较短，但缺省情况下JVM不卸载class，- xx : cmsclassunloadingenance
如果无法通过上述方法解决问题，请使用jmap命令指定dump内存对象jmap-dump:format=b，file=dump.hprof，然后选择eclipse mat 3359 www.eclipse.org /
4. Metaspace JDK 1.8使用Metaspace代替永久世代。 此错误指示Metaspace已满。 这通常是因为加载的class数量太多或太大。
这些问题的原因和解决方法与Permgenspace非常相似，请参考以上内容。 需要特别注意的是，调整Metaspace空间大小的启动参数为-XX:MaxMetaspaceSize。
5 .每个unabletocreatenewnativethreadjava线程必须占用一定的内存空间。 当请求基于JVM的操作系统创建新的本地线程时，如果没有足够的资源分配，则会报告这样的错误。原因分析
ng>JVM 向 OS 请求创建 native 线程失败，就会抛出 Unableto createnewnativethread，常见的原因包括以下几类：
1、线程数超过操作系统最大线程数 ulimit 限制；
2、线程数超过 kernel.pid_max（只能重启）；
3、native 内存不足；
该问题发生的常见过程主要包括以下几步：
1、JVM 内部的应用程序请求创建一个新的 Java 线程；
2、JVM native 方法代理了该次请求，并向操作系统请求创建一个 native 线程；
3、操作系统尝试创建一个新的 native 线程，并为其分配内存；
4、如果操作系统的虚拟内存已耗尽，或是受到 32 位进程的地址空间限制，操作系统就会拒绝本次 native 内存分配；
5、JVM 将抛出 java.lang.OutOfMemoryError:Unableto createnewnativethread 错误。
解决方案
1、升级配置，为机器提供更多的内存；
2、降低 Java Heap Space 大小；
3、修复应用程序的线程泄漏问题；
4、限制线程池大小；
5、使用 -Xss 参数减少线程栈的大小；
6、调高 OS 层面的线程最大数：执行 ulimia -a 查看最大线程数限制，使用 ulimit -u xxx 调整最大线程数限制。
参见:https://blog.csdn.net/qq_29974229/article/details/121669507 6. 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、升级服务器配置/隔离部署，避免争用。
有一种内核作业（Kernel Job）名为 Out of Memory Killer，它会在可用内存极低的情况下“杀死”（kill）某些进程。OOM Killer 会对所有进程进行打分，然后将评分较低的进程“杀死”，具体的评分规则可以参考 Surviving the Linux OOM Killer。
不同于其他的 OOM 错误， Killprocessorsacrifice child 错误不是由 JVM 层面触发的，而是由操作系统层面触发的。
原因分析
默认情况下，Linux 内核允许进程申请的内存总量大于系统可用内存，通过这种“错峰复用”的方式可以更有效的利用系统资源。
然而，这种方式也会无可避免地带来一定的“超卖”风险。例如某些进程持续占用系统内存，然后导致其他进程没有可用内存。此时，系统将自动激活 OOM Killer，寻找评分低的进程，并将其“杀死”，释放内存资源。
解决方案
1、升级服务器配置/隔离部署，避免争用。
2、OOM Killer 调优。
JVM 限制了数组的最大长度，该错误表示程序请求创建的数组超过最大长度限制。
JVM 在为数组分配内存前，会检查要分配的数据结构在系统中是否可寻址，通常为 Integer.MAX_VALUE-2。
此类问题比较罕见，通常需要检查代码，确认业务是否需要创建如此大的数组，是否可以拆分为多个块，分批执行。
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、内存容量确实不足，升级配置。