OOM异常的4种可能分析及常见的OOM异常演示

OOM异常的4种可能分析及常见的OOM异常演示

OOM异常： OutOfMemoryError

1.JAVA堆溢出
JAVA堆用于存储对象实例，只要不断的创建对象，并且保证GC Roots到这些对象之间有路径可以来避免垃圾回收机制清除这些对象，那么在对象数量达到最大堆的容量限制之后就会产生OOM异常

解决方案：先分析到底是出现了内存泄漏（无法释放已申请的内存空间）还是内存溢出（没有足够的内存空间使用）
内存泄漏：通过工具查看泄漏对象到GC Roots的引用链，于是就能够找到内存泄漏对象是通过怎样的路径与GC Roots相关联并导致垃圾收集器无法回收，这样就可以准确的定位到内存泄漏的代码
内存溢出：检查JVM的堆参数，与机器物理内存相比看看是否可以调大，并且从代码上检查是否存在某些对象生命周期太长，持有状态时间太长等情况，减少程序运行期间内存的消耗

2.虚拟机栈和本地方法栈溢出
多线程环境下，当为每个线程分配的栈内存越大，就越容易产生内存溢出异常，因为操作系统分配给每个进程的内存是有限的，每个线程分配到的栈容量越大，可以建立的线程数量自然越少，建立线程就越容易把剩下的内存耗尽

解决方案：减少最大堆和减少栈容量来换取更多的线程

3.方法区和运行常量池溢出
运行常量池是方法区的一部分，方法区存放的是Class的相关信息，当运行时产生了大量的类了填满方法区时，再产生类就会导致OOM
比如大量的JSP或动态产生JSP文件的应用（JSP第一次运行需要编译为JAVA类），基于OSGI的应用（即同一个文件，被不同的类加载器加载也会视为不同的类）

解决方案：减少不必要的类的产生

4.本机直接内存溢出
物理机器内存不足，满足不了JVM需求了

idea运行java设置VM参数-测试内存溢出方法。

Demo代码示例：

package com.example.core.mydemo.java;

public class OomTest {
}

package com.example.core.mydemo.java;

import org.springframework.cglib.proxy.Enhancer;
import org.springframework.cglib.proxy.MethodInterceptor;
import org.springframework.cglib.proxy.MethodProxy;

import java.lang.reflect.Method;
import java.nio.ByteBuffer;
import java.util.ArrayList;
import java.util.concurrent.TimeUnit;

public class OutOfMemoryErrorTest {
    public static void main(String[] args) {
        /**
         * 在创建大对象的时候特别注意堆内存的使用，避免产生堆的内存溢出
         * 1.堆内存溢出，这是工作中最常见的OOM故障
         *  在JVM启动参数的时候将堆内存设置成10M  -Xmx10m -Xms10m
         *  报错：java.lang.OutOfMemoryError: Java heap space
         */
        //创建一个20M的对象
//        Byte[] b = new Byte[20*1024*1024];

        /**
         * 2.OMM 之 java.lang. StackOverflowError 栈空间溢出，栈管运行，每个方法就是一个栈帧，循环调用方法，会出现这种问题
         * 报错： java.OutOfMemoryErrorTest.stackoverflowError(OutOfMemoryErrorTest.java:20)
         */
//        stackoverflowError();

        /**
         * 3.GC overhead limit exceeded GC时间太长引发的异常
         * GC回收时间过长时会抛出outOfMemroyError，过长的定义是：超过98%的时间用来做GC并且回收不到2%的堆内存。
         * 连续多次GC都只回收了不到2%的极端情况下会抛出。假如不抛出GC overhead limit 错误会发生什么信况呢?
         * 那就是GC清理的这么点内存很快会再次填满，迫使GC 再次执行。这样就形成恶性循环,
         * CPU使用率一直是100%， 两GC 却没有任何效果
         *
         *  GC overhead limit exceeded
         *  * JVM参数设置：8U
         *  * -Xms10m -Xmx10m -XX:+PrintGCDetails -XX:MaxDirectMemorySize=5m
         *  报错：java.lang.OutOfMemoryError: GC overhead limit exceeded
         */
//        int i =0;
//        final ArrayList list = new ArrayList();
//
//        while (true){
//            //String.intern() 方法是 Java 中的一个方法，它用于在字符串常量池（String Pool）中维护字符串对象的引用，以便可以有效地重用字符串，从而节省内存。
//            list.add(String.valueOf(++i).intern());
//        }

        /**
         * 4.Directbuffer memory buffer 内存溢出
         * 导致原因：
         * 写NIO程序经常使ByteBuffer读取或者写入数据，这是一种基于通道(Channel)与缓冲区(Buffer)的I/0方式，
         * 它可以使用Native函数库直接分配堆外内存，然后通过一个存储在Java堆里面的DirectByteBuffer对象作为这块内存的引用进行操作。
         * 这样能在一些场景中显著提高性能， 因为避免了在Java堆和Native堆中来回复制数据。
         * ByteBuffer. allocate(capability) 第一种方式是分配JVM堆内存， 属于GC 营结范围，由于需要拷贝所以速度相对较慢
         * ByteBuffer. allocteDirect(capability)第2种方式是分配操作系统本地内存，不属于GC 管辖范围，由于不需要内存拷贝所以速度相对较快。
         * 但如果不断分配本地内存，堆内存很少使用，那么JVM就不需要执行CG, DirectByteBuffer对象们就不会被回收，
         * 这时候堆内存充足，但本地内存可能已经使用光了，再次尝试分配本地内存就会出OutOfMemoryError,程序就直接崩溃。
         *
         * java.lang.OutOfMemoryError: Direct buffer memory 演示
         * JVM参数配置：-Xms10m -Xmx10m -XX:+PrintGCDetails  -XX:MaxDirectMemorySize=5m
         * 报错：java.lang.OutOfMemoryError: Direct buffer memory
         */
//        System.out.println("配置的maxDirectMemory: " + (sun.misc.VM.maxDirectMemory() / (double) 1024 / 1024) + "MB");
//        //最大5M 申请6M
//        ByteBuffer bb = ByteBuffer. allocateDirect(6* 1024*1024);

        /**
         * 5.unable to create new native thread 无法创建线程
         * 高并发请求服务器时,经常出现如下异常:java.Lang.OutOfMemoryError: unable to create new native thread准确的讲native thread 异常与对应的平台有关
         * 导致原因:
         * 你的应用创建了太多线程了,一个应用进程创建多个线程,超过系统承裁极限。
         * 你的服务器并不允许你的应用程序创建这么多线程linux系统默认允许单个进程可以创建的线程数是1024个,你的应用创建超过这个数量，就会报java. lang. OutOfMemoryError: unable to create new native thread
         * 解决办法:
         * 1.想办法降低你应用程序创建线程的数量，分析应用是否真的需要创建这么多线程如果不是,改代码将线程数量降到最低
         * 2.对于有的应用,确实需要创建很多线程,远超过Linux系统的默认1024个线程的限制,可以通过修改Linux服务器配置,扩大linux默认限制
         * 模拟：这个类拷贝到linux下执行。本机未报错。
         */
//        int MAX_VALUE = 1;
//        for (int i = 1;; i++) {
//            System.out.println("i = " + i);
//            new Thread(()->{
//                try {
//                    TimeUnit.SECONDS.sleep(MAX_VALUE);
//                } catch (InterruptedException e) {
//                    e.printStackTrace();
//                }
//            },""+i).start();
//        }

        /**
         * 6.java.lang.OutOfMemoryError: Metaspace 元空间溢出
         * Java 8及之后的版本使用Metaspace来替代永久化。Metaspace.是方法区在Hotspot中的实现，它与持久代最大的区别在于: Metaspace 不在虚拟机内存中而是使用本地内存
         * 也即在java8中classe metadata(the virtual machines internal presentation of Java class), 被存储在叫做Metaspace的native memory
         *
         * 永久代(java8后被原空间Metaspace取代了)存放了以下信息:
         * 虚拟机加载的类信息
         * 常量池
         * 静态变量
         * 即时编译后的代码
         *
         * 模拟Metaspace空间溢出，我们不断生成类往元空间灌，类占据的空间总是会超过Metaspace指定的空间大小的
         * 异常演示： java.lang.OutOfMemoryError: Metaspace
         * -XX:MetaspaceSize=8m -XX:MaxMetaspaceSize=8m
         * 报错： java.lang.OutOfMemoryError-->Metaspace
         */
        int i = 0;
        try {
            while (true){
                i++;
                final Enhancer enhancer = new Enhancer();
                enhancer.setSuperclass(OomTest.class);
                enhancer.setUseCache(false);
                enhancer.setCallback(new MethodInterceptor() {
                    @Override
                    public Object intercept(Object o, Method method, Object[] objects, MethodProxy methodProxy) throws Throwable {
                        return methodProxy.invoke(o,args);
                    }
                });

                enhancer.create();
            }
        }catch (Exception e){
            System.out.println("*****多少次发生异常 " + i);
            e.printStackTrace();
        }

    }

    //不能使用内部类
//    class OomTest{}

    private static void stackoverflowError() {
        stackoverflowError();
    }

}

[PSYoungGen: 1022K->490K(1536K)]: [收集器类型: GC前该内存区域已经使用容量->GC后该内存区域已使用容量(该内存区域总容量)],执行时间 secs
[Times: user=0.00 sys=0.00, real=0.00 secs]: user=用户线程使用时间 sys=系统执行使用时间, real=真正回收时间

[Full GC (Ergonomics) [PSYoungGen: 2048K->2048K(2560K)] [ParOldGen: 7048K->7048K(7168K)] 9096K->9096K(9728K), [Metaspace: 3479K->3479K(1056768K)], 0.0192901 secs] [Times: user=0.09 sys=0.00, real=0.02 secs]
[Full GC (Ergonomics) [PSYoungGen: 2048K->0K(2560K)] [ParOldGen: 7060K->974K(7168K)] 9108K->974K(9728K), [Metaspace: 3492K->3492K(1056768K)], 0.0043629 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
Heap
 PSYoungGen      total 2560K, used 109K [0x00000000ffd00000, 0x0000000100000000, 0x0000000100000000)
  eden space 2048K, 5% used [0x00000000ffd00000,0x00000000ffd1b700,0x00000000fff00000)
  from space 512K, 0% used [0x00000000fff80000,0x00000000fff80000,0x0000000100000000)
  to   space 512K, 0% used [0x00000000fff00000,0x00000000fff00000,0x00000000fff80000)
 ParOldGen       total 7168K, used 974K [0x00000000ff600000, 0x00000000ffd00000, 0x00000000ffd00000)
  object space 7168K, 13% used [0x00000000ff600000,0x00000000ff6f3bf0,0x00000000ffd00000)
 Metaspace       used 3547K, capacity 4536K, committed 4864K, reserved 1056768K
  class space    used 396K, capacity 428K, committed 512K, reserved 1048576K