JVM

追梦不止～

已于 2023-04-27 11:04:33 修改

阅读量499

点赞数 3

文章标签： jvm java linux

于 2023-04-11 14:53:14 首次发布

本文链接：https://blog.csdn.net/m0_64318128/article/details/130054092

版权

JVM内存区域划分

JVM在启动的时候,会申请到一块很大的内存空间, JVM会将这块空间分成很多区域, 每个区域都有自己的功能和作用.

如下图:

本地方法栈是给调用JVM内部的native方法准备的空间.

这个部分是记录当前线程执行到哪个指令,每个线程都各自有一份.

虚拟机栈是给Java代码使用的栈,这里存储的是方法与方法之间的调用关系.

在虚拟机站中,有很多个元素,每个方法都代表一个元素,这个元素被称之为"栈帧".

在每个栈帧里面,会存储这个方法的入口地址、返回地址、局部变量、形参......

每个线程都各自有一个自己的栈。

堆是JVM里面最大的区域，我们new出来的对象（对象的成员变量）都存放在堆中，并且所有的线程都共用一个堆。

元数据区（方法区），类对象就是存放在这里的，这里面存储还有常量池、类方法（静态方法）

总结：局部变量存储在栈上；类的普通成员变量存储在堆上；静态成员变量存储在元数据区。

类加载机制

类加载流程

类加载就是将 .class 文件，从文件（硬盘）读取到内存（元数据区）中的过程。

如下图：

加载：将 .class 文件找到，读取文件内容。

验证：根据JVM虚拟机规范，验证 .class 文件的格式是否符合要求。

准备：给类对象分配空间，此时内存初始化为全0，静态成员也就设置为0值了。

解析：针对字符串常量进行初始化，将字符引用转为直接引用。

初始化：真正将类对象里面的内容初始化，加载父类，执行静态代码块里面的代码。

解析中的字符引用和直接引用：

字符串常量需要一块空间来存储字符串的内容，同时也需要一个引用来保存它的其实地址。

在类加载之前，字符串常量是处于 .class 文件中的，此时它的引用记录的并非是字符串常量的真正地址，而是它在文件中的“偏移量”，这个偏移量就是上面说的符号引用。

当类加载之后，才会真正的把这个字符串常量给放到内存中，此时才有“内存地址”，此时这个引用才能真正赋值成指定的内存地址。

类加载的时机

类加载属于懒汉模式，只有真正被用到的时候才会被真正加载。

1. 构造类的实例

2. 调用这个类的静态方法/使用静态属性

3. 加载子类，在这之前会先加载父类

上述过程用到了才加载。并且，一旦加载过之后，后续再使用就不必再重复加载了。

双亲委派模型

双亲委派模型，描述的是在加载过程中，找 .class 文件的基本过程。

JVM里面默认提供了三个类加载器，并且他们存在“父子关系”：

BootstrapClassLoader（ExtensionClassLoader的父亲）负责加载标准库中的类

ExtensionClassLoader（ApplicationClassLoader的父亲）负责加载JVM扩展库中的类

ApplicationClassLoader 负责加载用户提供的第三方库/用户项目代码中的类

上述类加载器配合工作过程：

首先加载一个类的时候会先从ApplicationClassLoader开始。

但是ApplicationClassLoader会先将加载任务交给他的父亲ExtensionClassLoader

然后，ExtensionClassLoader同样会将任务交给它的父亲BootstrapClassLoader

当来到BootstrapClassLoader时，它的父亲是null，然后就由它进行加载，如果找到，就进行加载，如果没找到，就交给它的 子类加载器

如果ApplicationClassLoader也没找到，由于当前已经没有子类加载器了，此时就会抛出类找不到这样的异常

这个流程大致如下图：

通过流程图可以发现，从ApplicationClassLoader到BootstrapClassLoader这个过程是没有进行查找操作的，而出现这种顺序的原因是JVM实现代码的逻辑是一个类似于递归这样的方式。

同时这个顺序还可以保证BootstrapClassLoader先加载，ApplicationClassLoader后加载

因为，如果用户给类起了一些奇形怪状的名，比如：用户起了一个java.long.String这个类名，如果按照上述加载流程，加载的会是标准库里面的类，而不会加载到用户写的这个类。

这样就可以保证：即使出现上述问题，也不会让JVM已有代码发生混乱，最多就是用户自己写的类不生效罢了。

除了上述的这些类加载器，用户还可以自定义类加载器，用户自定义的类加载器页可以加入到上述流程中和现有的类加载器配合使用，同时自定义的类加载器也可以破坏这个双亲委派模型。

比如：Tomcat 在加载 webapp 的时候就时单独的类加载器，并且不会遵守双亲委派模型，因为webapp 的加载，其他的类加载器大概率是加载不到的，索性就直接自己加载。

GC垃圾回收机制

所谓垃圾，就是指不再使用的内存，而垃圾回收就是将不用的内存进行释放，而GC垃圾回收机制就是帮我们程序员自动释放这些不用的内存。

GC的优缺点

好处：方便省心，让程序员写代码更简单，不容易出错。

坏处：需要消耗额外的系统资源，和额外的性能开销，同时，GC还有一个STW问题。

STW问题：

如果在某一时段，内存中的垃圾非常的多，此时触发一次GC操作，开销可能会非常大，甚至会将系统资源吃掉很多，就会导致这次GC操作会让程序发生卡顿，这样的卡顿，在极端情况下可能会持续几十毫秒甚至上百毫秒。

GC如何寻找垃圾

在GC中，回收垃圾是以对象为基本单位的。

如果想释放掉垃圾内存，首先要先找到并判断哪个对象是垃圾，哪个对象不是垃圾。

而判断的思路就是：抓住一个对象，查看是否有“引用”指向它。

这个思路有两种典型实现。

方法1：引用计数（非Java做法）

引用计数就是给每个对象都分配了一个计数器（整数），每创建一个引用执行该对象，该对象的计数器就+1，反之，指向该对象的引用每销毁一个，计数器就-1。

举个例子：

public static void main(String[] args) {
    Test t1 = new Test();//计数器为+1 为 1
    Test t2 = t1;//        计数器为+1 为 2
    Test t3 = t1;//        计数器为+1 为 3
    Test t3 = null;//      计数器为-1 为 2
}
//大括号结束,上述三个引用超出作用域,失效,此时引用计数为0,此时 new Test() 就是垃圾了

引用计数的优点：简单有效。

引用计数的缺点：

1. 内存空间浪费（利用率低）

因为每个对象都需要分配一个计数器。

如果每个计数器都是4个字节，并且对象比较多，此时占用的内存空间就会很多，尤其是对象比较小的时候。

如果一个对象本身就只占了4个字节，那加上一个计数器4个字节，就相当体积于翻了一倍。

2. 存在循环引用的问题

如下：

class Test {
    Test t = null;
}

class T {
    public static void main(String[] args) {
        // a 指向的对象为对象1; b指向的对象为对象2
        Test a = new Text(); //对象1 计数器为1
        Test b = new Text(); //对象2 计数器为1
        a.t = b;//             对象2 计数器为2
        b.t = a;//             对象1 计数器为2

        a = null;//            a指向断开 对象1计数器-1 为1
        b = null;//            b指向断开 对象2计数器-1 为1
    }
}

上述代码，理论上对象1和对象2都已经成为垃圾内存，但是他们的计数器却没有清0。

这就是循环引用问题，它的解决需要搭配其他的机制去配合（此处不说明）。