Java虚拟机（JVM）面试专题中（初级程序员P6）

金鳞踏雨

已于 2023-01-03 15:20:09 修改

阅读量277

点赞数 1

分类专栏： JVM Java面试题汇总文章标签： jvm java 开发语言类加载内存溢出

于 2022-09-19 01:38:22 首次发布

本文链接：https://blog.csdn.net/weixin_43715214/article/details/126926016

版权

Java面试题汇总同时被 2 个专栏收录

25 篇文章 6 订阅

订阅专栏

JVM

3 篇文章 0 订阅

订阅专栏

Java虚拟机（JVM）面试专题中（初级程序员P6）

四、内存溢出

1. 误用线程池导致的内存溢出

（1）问题描述（newFixedThreadPool）

解决方案

（2）问题描述（newCachedThreadPool）

将常量池的符号引用变成直接引用（解析阶段）

Java虚拟机（JVM）面试专题中（初级程序员P6）

四、内存溢出

误用线程池导致的内存溢出
查询数据量太大导致的内存溢出
动态生成类导致的内存溢出

1. 误用线程池导致的内存溢出

我们模拟一个发送短信的案例

一般来说我们要发送短信，都是调用第三方的API，所以有可能发生因网络问题导致的调用超时，或者是第三方服务“挂了”

（1）问题描述（newFixedThreadPool）

我们来看一下下面的代码

// 设置堆内存为-Xmx64m  64MB
// 模拟短信发送超时，但这时仍有大量的任务进入队列
public class TestOomThreadPool {
    public static void main(String[] args) {
        ExecutorService executor = Executors.newFixedThreadPool(2);
        LoggerUtils.get().debug("begin...");

        // 不断发送短信
        while (true) {
            executor.submit(()->{
                try {
                    // 模拟调第三方API
                    LoggerUtils.get().debug("send sms...");
                    // 模拟超时30s
                    TimeUnit.SECONDS.sleep(30);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
            });
        }
    }
}

运行结果

显然内存溢出了！

我们来看看 newFixedThreadPool() 的源码

public static ExecutorService newFixedThreadPool(int nThreads) {
    return new ThreadPoolExecutor(nThreads, nThreads,
            0L, TimeUnit.MILLISECONDS,
            new LinkedBlockingQueue<Runnable>());
}

根据我们上面代码的传参来说：

最大线程数、核心线程数都是2

new LinkedBlockingQueue<Runnable>()：表示任务队列，也就是说，当我们这个线程池中最大线程数被占用后，其它的待处理任务会被放到这个任务队列，当任务队列容量超过内存，则发生内存溢出！！！（不会拒绝，只不断添加）

解决方案

不要使用 工具类Executors.newFixedThreadPool(2) 来创建线程池

使用 ThreadPoolExecutor 的构造方法来创建！这样子我们可以指定 LinkedBlockingQueue 的策略。

（2）问题描述（newCachedThreadPool）

// 设置堆内存为-Xmx64m  64MB
// 模拟短信发送超时，但这时仍有大量的任务进入队列
public class TestOomThreadPool {
    
    static AtomicInteger c = new AtomicInteger();

    public static void main(String[] args) {
        ExecutorService executor = Executors.newCachedThreadPool();

        while (true) {
            System.ont.println(c.incrementAndGet());
            executor.submit(()->{
                try {
                    TimeUnit.SECONDS.sleep(30);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
            });
        }
    }
}

运行结果

我们来看看 newCachedThreadPool() 的源码

public static ExecutorService newCachedThreadPool() {
    return new ThreadPoolExecutor(0, Integer.MAX_VALUE,
            60L, TimeUnit.SECONDS,
            new SynchronousQueue<Runnable>());
}

显然，这里和上面的 newFixedThreadPool() 不同， newFixedThreadPool() 的核心线程数默认是0，但是临时线程可以开“无数”个！

SynchronousQueue<Runnable>()：表示最多只有一个任务！

临时线程数 = 最大线程数 - 核心线程数

所以，这里的错误是因为Java线程池开辟的线程数达到了系统的上限

解决方案

和上面的那个一样，就是不要用 Executors 自带的方法来设置线程池，要自己来new 一个ThreadPoolExecutor！

2. 查询数据量太大导致的内存溢出

在开发中一次性查询过多内容导致内存不足，引发内存溢出！

这里的解决方法很简单

就是一定要使用 limit 关键字！！！

3. 动态生成类导致的内存溢出

问题描述

// -XX:MaxMetaspaceSize=24m
// 模拟不断生成类, 但类无法卸载的情况
public class TestOomTooManyClass {

    static GroovyShell shell = new GroovyShell();

    public static void main(String[] args) {
        AtomicInteger c = new AtomicInteger();
        while (true) {
            try (FileReader reader = new FileReader("script")) {
                shell.evaluate(reader);
                System.out.println(c.incrementAndGet());
            } catch (IOException e) {
                e.printStackTrace();
            }
        }
    }
}

运行结果

每次调用evaluate() 方法的时候，都会动态生成一个类，这个类是通过GroovyClassLoader加载器加载的！

但是只要类的类加载器存在，类存在，类的实例对象存在，那么这个类是不能被卸载的！类不能被卸载，会导致云空间的内存不能释放！！！

又因为这个GroovyShell是一个 static ，所以不会被垃圾回收，从而就导致了元空间内存不足！

解决方案

很简单，就是不要将其设置为static，将其设置为局部变量，这样子，当内存空间不足的时候，就进行类卸载，可以触发垃圾回收！

五、类加载

1. 类加载过程的三个阶段

类加载过程有三个阶段——加载、链接、初始化

（1）加载

将类的字节码载入方法区，并创建类.class 对象（堆中）
如果此类的父类没有加载，先加载父类
加载是懒惰执行（用到才加载）

（2）链接

可以分成3个小的步骤

验证 – 验证类是否符合 Class 规范，合法性、安全性检查
准备 – 为 static 变量分配空间，设置默认值（注意，并不是赋值！）
解析 – 将常量池的符号引用解析为直接引用

（3）初始化

执行 静态代码块 与 非final的静态变量 的赋值（如果是final的变量，在链接阶段就会赋好值的！）
初始化是懒惰执行

类初始化的原理

static int a = 0x77; // 类初始化
static {
    System.out.println("Student.class init");
} // 类初始化
static int b = 0x88;

static final int c = 0x99;
static final int m = Short.MAV_VALUE + 1;
static final Object n = new Object; //类初始化

看上述代码，编译器会把静态变量的赋值语句、静态代码块中的语句、用final修饰的引用类型的静态变量 全部合到一起，变成一个方法，在类初始化的时候调用！

c 和 m在链接过程就已经赋值了！

final 修饰的基本数据类型的变量

如果只是使用到final修饰的基本类型，是不会触发类加载的！

public class TestFinal {
    public static void main(String[] args) throws IOException {
        System.out.println(Student.c); // c 是 final static 基本类型
        System.in.read();

        System.out.println(Student.m); // m 是 final static 基本类型
        System.in.read();

        System.out.println(Student.n); // n 是 final static 引用类型
        System.in.read();
    }
}

上述代码中的c与m是final修饰，又是基本类型，其它类想要使用c和m的时候，根本就不会用到它们所在的类（Student）；而是直接从常量池中去拿c和m的值，并复制一份到TestFinal 类中！

将常量池的符号引用变成直接引用（解析阶段）

在编译的时候一个每个java类都会被编译成一个class文件，但在编译的时候虚拟机并不知道所引用类的地址，所以就用符号引用来代替，而在解析阶段就是为了把这个符号引用转化成真正的地址的阶段。

2. jdk 8 的类加载器

名称	加载哪的类	说明
Bootstrap ClassLoader	JAVA_HOME/jre/lib	无法直接访问
Extension ClassLoader	JAVA_HOME/jre/lib/ext	上级为 Bootstrap，显示为 null
Application ClassLoader	classpath	上级为 Extension
自定义类加载器	自定义	上级为 Application

像 String.class 就是由 Bootstrap ClassLoader 加载器加载

自定义的 Student.class 在上级加载器（Bootstrap、Extension）中没有找到，所以最后由Application加载！

3. 双亲委派机制

所谓的双亲委派，就是指优先委派上级类加载器进行加载，如果上级类加载器

能找到这个类，由上级加载，加载后该类也对下级加载器可见（避免重复加载）
找不到这个类，则下级类加载器才有资格执行加载

双亲委派的目的有两点

让上级类加载器中的类对下级共享（反之不行），即能让你的类能依赖到 jdk 提供的核心类
让类的加载有优先次序，保证核心类优先加载

【BUG】对双亲委派的误解

【问题一】自己编写类加载器就能加载一个假冒的 java.lang.System 吗?

答案是不行！！！

假设你自己的类加载器用双亲委派，那么优先由启动类加载器加载真正的 java.lang.System，自然不会加载假冒的
假设你自己的类加载器不用双亲委派，那么你的类加载器加载假冒的 java.lang.System 时，它需要先加载父类 java.lang.Object，而你没有用委派，找不到 java.lang.Object 所以加载会失败
以上也仅仅是假设！事实上操作你就会发现，自定义类加载器加载以 java. 打头的类时，会抛安全异常，在 jdk9 以上版本这些特殊包名都与模块进行了绑定，更连编译都过不了