谈谈对 OOM 的认识

🍀 java.lang.StackOverflowError

package com.brian.interview.study.jvm.oom;

/**
 * Copyright (c) 2020 ZJU All Rights Reserved
 * <p>
 * Project: JavaSomeDemo
 * Package: com.brian.interview.study.jvm.oom
 * Version: 1.0
 * <p>
 * Created by Brian on 2020/2/15 12:50
 */
public class StackOverflowErrorDemo {
    public static void main(String[] args) {
        stackOverflowError();
    }

    private static void stackOverflowError() {
        stackOverflowError();  // Exception in thread "main" java.lang.StackOverflowError
    }
}

🍀 java.lang.OutOfMemoryError: Java heap space

package com.brian.interview.study.jvm.oom;

import java.util.Random;

/**
 * Copyright (c) 2020 ZJU All Rights Reserved
 * <p>
 * Project: JavaSomeDemo
 * Package: com.brian.interview.study.jvm.oom
 * Version: 1.0
 * <p>
 * Created by Brian on 2020/2/15 12:56
 */

public class JavaHeapSpaceDemo {
    public static void main(String[] args) {

//        byte[] bytes = new byte[80 * 1024 * 1024];

        String str = "hello";

        while (true) {
            str += str + new Random().nextInt(11111111) + new Random().nextInt(22222222);
            str.intern();
        }



        // Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
    }
}

🍀 java.lang.OutOfMemoryError: GC overhead limit exceeded

JVM参数配置演示
-Xms10m -Xmx10m -XX:MaxDirectMemorySize=5m

GC回收时间过长时会抛出 OutOfMemoryError。过长的定义是, 超过98%的时间用来做GC并且回收了不到2%的对内存
连续多次 GC 都只回收了不到2%的极端情况下才会抛出。假如不抛出 GC overhead limit 错误会发生什么情况呢?
那就是 GC 清理的这么点内存很快会再次填满, 迫使 GC 再次执行。这样就形成恶性循环,
CPU 使用率一直是 100%, 而 GC 却没有任何成果。
在这里插入图片描述

package com.brian.interview.study.jvm.oom;

/**
 * Copyright (c) 2020 ZJU All Rights Reserved
 * <p>
 * Project: JavaSomeDemo
 * Package: com.brian.interview.study.jvm.oom
 * Version: 1.0
 * <p>
 * Created by Brian on 2020/2/15 13:52
 */

import java.util.ArrayList;
import java.util.List;

/**
 * JVM参数配置演示
 * -Xms10m -Xmx10m -XX:+PrintGCDetails -XX:MaxDirectMemorySize=5m
 *
 * GC回收时间过长时会抛出 OutOfMemoryError。过长的定义是, 超过98%的时间用来做GC并且回收了不到2%的对内存
 * 连续多次 GC 都只回收了不到2%的极端情况下才会抛出。假如不抛出 GC overhead limit 错误会发生什么情况呢?
 * 那就是 GC 清理的这么点内存很快会再次填满, 迫使 GC 再次执行。这样就形成恶性循环,
 * CPU 使用率一直是 100%, 而 GC 却没有任何成果。
 */
public class GCOverheadDemo {
    public static void main(String[] args) {
        int i = 0;
        List<String> list = new ArrayList<>();

        try {
            while (true) {
                list.add(String.valueOf(++i).intern());
            }
        } catch (Throwable e) {
            System.out.println("******************i:" + i);
            e.printStackTrace();  // Exception in thread "main" java.lang.OutOfMemoryError: GC overhead limit exceeded
            throw e;
        }
    }
}

🍀 java.lang.OutOfMemoryError: Direct buffer memory

package com.brian.interview.study.jvm.oom;

/**
 * Copyright (c) 2020 ZJU All Rights Reserved
 * <p>
 * Project: JavaSomeDemo
 * Package: com.brian.interview.study.jvm.oom
 * Version: 1.0
 * <p>
 * Created by Brian on 2020/2/15 14:06
 */

import java.nio.ByteBuffer;

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

        try {
            Thread.sleep(3000);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }

        // -XX:MaxDirectMemorySize=5m   我们配置为5MB, 但实际使用6MB, 故意使坏
        ByteBuffer bb = ByteBuffer.allocateDirect(6 * 1024 * 1024);
    }
}

🍀 java.lang.OutOfMemoryError: unable to create new native thread

package com.brian.interview.study.jvm.oom;

/**
 * Copyright (c) 2020 ZJU All Rights Reserved
 * <p>
 * Project: JavaSomeDemo
 * Package: com.brian.interview.study.jvm.oom
 * Version: 1.0
 * <p>
 * Created by Brian on 2020/2/15 14:36
 */

/**
 * 高并发请求服务器时, 经常出现如下异常:java.lang.OutOfMemoryError: unable to create new native thread
 * 准确的讲该 native thread 异常与对应的平台有关
 *
 * 导致原因:
 *      1、你的应用创建了太多线程了, 一个应用进程创建多个线程, 超过系统承载极限
 *      2、你的服务器并不允许你的应用程序创建这么多线程, linux 系统默认允许单个进程可以创建的线程数是 1024 个,
 *      你的应用创建超过这个数量, 就会报 java.lang.OutOfMemoryError: unable to create new native thread
 *
 * 解决办法:
 * 1、想办法降低你应用程序创建线程的数量, 分析应用是否真的需要创建这么多线程, 如果不是, 改代码将线程数降到最低
 * 2、对于有的应用, 确定需要创建很多线程, 远超过 linux 系统的默认 1024 个线程的限制, 可以通过修改 linux 服务器配置, 扩大 linux 默认限制
 */
public class UnableCreateNewThreadDemo {
    public static void main(String[] args) {

        for (int i = 1; ; i++) {
            System.out.println("***************** i=" + i);

            new Thread(() -> {
                try {
                    Thread.sleep(Integer.MAX_VALUE);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
            }, "" + i).start();
        }

    }
}
📌 非 root 用户登录 Linux 系统测试
📌 服务器级别调参调优

vim /etc/security/limits.d/90-nproc.conf
在这里插入图片描述
打开后发现除了 root,其他账号都限制在 1024 个
在这里插入图片描述
如果我们想要张三这个用户运行,希望他生成的线程多一些,我们可以如下配置
在这里插入图片描述

🍀 java.lang.OutOfMemoryError: Metaspace

package com.brian.interview.study.jvm.oom;

/**
 * Copyright (c) 2020 ZJU All Rights Reserved
 * <p>
 * Project: JavaSomeDemo
 * Package: com.brian.interview.study.jvm.oom
 * Version: 1.0
 * <p>
 * Created by Brian on 2020/2/15 15:14
 */

import net.sf.cglib.proxy.Enhancer;
import net.sf.cglib.proxy.MethodInterceptor;
import net.sf.cglib.proxy.MethodProxy;

import java.lang.reflect.Method;

/**
 * JVM 参数
 * -XX:MetaspaceSize=8m -XX:MaxMetaspaceSize=8m
 *
 * Java 8 及之后的版本使用 Metaspace 来替代永久代。
 *
 * Metaspace 是方法区在 HotSpot 中的实现, 它与持久代最大的区别在于:Metaspace 并不在虚拟机内存中而是使用本地内存
 * 也即在 java8 中, classes metadata(the virtual machines internal presentation of Java class), 被存储在叫做
 * Metaspace 的 native memory
 *
 * 永久代(java8 后被元空间 Metaspace 取代了)存放了以下信息:
 *
 *  虚拟机加载的类信息
 *  常量池
 *  静态变量
 *  即时编译后的代码
 *
 * 模拟 Metaspace 空间溢出, 我们不断生成类往元空间灌, 类占据的空间总是会超过 Metaspace 指定的空间大小的
 */
public class MetaspaceOOMTest {

    static class  OOMTest{

    }

    public static void main(String[] args) {
        int i = 0;  // 模拟计数多少次以后发生异常

        try {
            while (true) {
                i++;
                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.invokeSuper(o, args);
                    }
                });
                enhancer.create();
            }
        } catch (Throwable e) {
            System.out.println("***********多少次后发生了异常:" + i);
            e.printStackTrace();
        }
    }
}

// java.lang.OutOfMemoryError: Metaspace

📌 使用 java -XX:+PrintFlagsInitial 命令查看本机的初始化参数,-XX:MetaspaceSize 为21810376B(大约20.8M)
  • 1
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值