JVM相关

最新推荐文章于 2023-12-20 14:52:12 发布

Mickey_967

最新推荐文章于 2023-12-20 14:52:12 发布

阅读量814

点赞数

文章标签： java

本文链接：https://blog.csdn.net/weixin_49920327/article/details/124350659

版权

1、JVM的位置

2、JVM的体系结构

3.结构分类

线程私有的：

程序计数器
虚拟机栈
本地⽅法栈

线程共享的：

堆
⽅法区
直接内存(⾮运⾏时数据区的⼀部分

4、类加载器

在这里插入图片描述
我们在IDE中编写的Java源代码被编译器编译成.class的字节码文件。然后由我们的ClassLoader负责将这些class文件给加载到JVM中去执行。 JVM中提供了三层的ClassLoader：

Bootstrap classLoader:主要负责加载核心的类(java.lang.*等)，构造ExtClassLoader和APPClassLoader
ExtClassLoader：主要负责加载jre/lib/ext目录下的一些扩展的jar。
AppClassLoader：主要负责加载应用程序的主函数类

public class Car {
    public static void main(String[] args) {
        Car car1 = new Car();
        Car car2 = new Car();
        Car car3 = new Car();
        System.out.println(car1.hashCode());//1360875712
        System.out.println(car2.hashCode());//1625635731
        System.out.println(car3.hashCode());//1580066828
        Class c1 = car1.getClass();
        Class c2 = car1.getClass();
        Class c3 = car1.getClass();
        System.out.println(c1.hashCode());//1627674070
        System.out.println(c2.hashCode());//1627674070
        System.out.println(c3.hashCode());//1627674070
        System.out.println("-----------------------------");
        ClassLoader classLoader = c1.getClassLoader();//这个类模板用什么加载器加载
        System.out.println(classLoader);//AppClassLoader
        System.out.println(classLoader.getParent());//ExtClassLoader   \jre\lib\ext
        System.out.println(classLoader.getParent().getParent());//null  rt.jar 1.不存在 2.java程序获取不到   
    }
}

这里会出现一个双亲委派机制

5、双亲委派机制

* 双亲委派机制：安全
* 1.APP-->EXT-->BOOT(最终执行)
* BOOT
* EXC
* APP
* 这个自己写的String不会被加载器加载进去，加载的是根加载器rt.jar里的String类
* 1.类加载器收到类加载器的请求
* 2.将这个请求向上委托给父类加载器去完成，一直向上委托，直到启动类加载器
* 3.启动加载器检查是否能够加载当前这个类，能加载就结束，使用当前的加载器，否则就抛出异常，遇到子加载器进行加载
* 4.重复步骤 3
    class Not Found~

A、说明：
当某个类加载器需要加载某个.class文件时，它首先把这个任务委托给他的上级类加载器，递归这个操作，如果上级的类加载器没有加载，自己才会去加载这个类。
B、作用：
1、防止重复加载同一个.class。通过委托去向上面问一问，加载过了，就不用再加载一遍。保证数据安全。
2、保证核心.class不能被篡改。通过委托方式，不会去篡改核心.class，即使篡改也不会去加载，即使加载也不会是同一个.class对象了。不同的加载器加载同一个.class也不是同一个Class对象。这样保证了Class执行安全。

//双亲委派机制 -----
public Class<?> loadClass(String name) throws ClassNotFoundException {
        return loadClass(name, false);
    }
    //              -----??-----
    protected Class<?> loadClass(String name, boolean resolve)
        throws ClassNotFoundException
    {
            // 首先，检查是否已经被类加载器加载过
            Class<?> c = findLoadedClass(name);
            if (c == null) {
                try {
                    // 存在父加载器，递归的交由父加载器
                    if (parent != null) {
                        c = parent.loadClass(name, false);
                    } else {
                        // 直到最上面的Bootstrap类加载器
                        c = findBootstrapClassOrNull(name);
                    }
                } catch (ClassNotFoundException e) {
                    // ClassNotFoundException thrown if class not found
                    // from the non-null parent class loader
                }
 
                if (c == null) {
                    // If still not found, then invoke findClass in order
                    // to find the class.
                    c = findClass(name);
                }
            }
            return c;
    }

流程图

$[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-LkAWplOR-1650619364451)(C:\Users\LENOVO\AppData\Roaming\Typora\typora-user-images\image-20220414203540367.png)]$

从上图中我们就更容易理解了，当一个Hello.class这样的文件要被加载时。不考虑我们自定义类加载器，首先会在AppClassLoader中检查是否加载过，如果有那就无需再加载了。如果没有，那么会拿到父加载器，然后调用父加载器的loadClass方法。父类中同理也会先检查自己是否已经加载过，如果没有再往上。注意这个类似递归的过程，直到到达Bootstrap classLoader之前，都是在检查是否加载过，并不会选择自己去加载。直到BootstrapClassLoader，已经没有父加载器了，这时候开始考虑自己是否能加载了，如果自己无法加载，会下沉到子加载器去加载，一直到最底层，如果没有任何加载器能加载，就会抛出ClassNotFoundException。

6、Native（主要用于方法上）

native:凡是带了native关键字的，说明java的作用范围达不到了，会去调用底层c语言的库！

$[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-WDYB4VXq-1650619364452)(C:\Users\LENOVO\AppData\Roaming\Typora\typora-user-images\image-20220413222456510.png)]$

//native:凡是带了native关键字的，说明java的作用范围达不到了，会去调用底层C语言的库
//会进入本地方法栈
//调用本地方法本地接口  JNI
//JNI作用：扩展Java的使用，融合不同的编程语言为Java所用   最初：C/C++
//Java诞生的时候 C C++横行，想要立足必须要有调用C、C++ 的程序
//它在内存区域中专门开辟了一块标记区域  Native Method Stack 登记native方法
//在最终执行的时候，加载本地方法库中的方法通过JNI
//Java程序驱动打印机  管理系统  Robot():会用到很多native方法

1、一个native方法就是一个Java调用非Java代码的接口。一个native方法是指该方法的实现由非Java语言实现，比如用C或C++实现。
2、在定义一个native方法时，并不提供实现体（比较像定义一个Java Interface），因为其实现体是由非Java语言在外面实现的
主要是因为JAVA无法对操作系统底层进行操作，但是可以通过JNI(java native interface java本地方法接口)调用其他语言来实现底层的访问。
举例：Thread类中的start() 方法中调用一个start0()的native方法。

7、PC寄存器

程序计数器: Program Counter Register
每个线程都有一个程序计数器，是线程私有的，就是一个指针, 指向方法区中的方法字节码(用来存储指向像一条指令的地址，也即将要执行的指令代码)，在执行引擎读取下一条指令, 是一个非常小的内存空间，几乎可以忽略不计

8、方法区

方法区是被所有线程共享，所有字段和方法字节码，以及一些特殊方法，如构造函数，接口代码也在此
定义,简单说，所有定义的方法的信息都保存在该区域，此区域属于共享区间;
静态变量、常量、类信息(构造方法、接口定义)、运行时的常量池存在方法区中，但是实例变量存在堆内存中，和方法区无关
static、final、Class、常量池

1.放了些什么：每个类的结构信息（字段、方法数据、普通方法、构造方法），运行时常量池，静态变量内容。（这是规范，不同虚拟机的实现是不同的最典型的就是永久代PermGen space和元空间Metaspace）
实例变量在堆内存中，和方法区无关。
2.绝对不是用来放方法的
3.这块区域所有线程共享，存在垃圾回收。

9、栈

栈：先进后出

队列：先进先出（FIFO：First Input First Output）

栈：栈内存

主管程序的运行，生命周期和线程同步

线程结束，栈内存也就是释放，对于栈来说，不存在垃圾回收问题

一旦线程结束，栈就Over。

为什么main()先执行，最后结束

$[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-fmw7kCTp-1650619364453)(C:\Users\LENOVO\AppData\Roaming\Typora\typora-user-images\image-20220414210105120.png)]$

每个线程都有自己的栈，栈中的数据都是以栈帧的格式存在；在这个线程上正在执行的每一个方法都各自对应一个栈帧；栈帧是一个内存区块，是一个数据集维系着方法执行过程中的各种数据信息。

栈：8大基本类型+对象引用+实例的方法

栈运行原理：栈帧

栈帧：局部变量表+操作数栈

栈存放：方法的引用，变量的引用…

每执行一个方法，就会产生一个栈帧。程序正在运行的方法永远都会在栈的顶部

栈是运行时的单位，Java 虚拟机栈，线程私有，生命周期和线程一致。描述的是 Java 方法执行的内存模型：每个方法在执行时都会创建一个栈帧(Stack Frame)用于存储局部变量表、操作数栈、动态链接、方法出口等信息。每一个方法从调用直至执行结束，就对应着一个栈帧从虚拟机栈中入栈到出栈的过程。（方法头开始入栈，结束出栈，方法里面调用别的方法新的方法就会把旧的压在底下，最上面永远是正在执行的方法，也对应先入后出。）

局部变量表：存放了编译期可知的各种基本类型(boolean、byte、char、short、int、float、long、double)、对象引用(reference 类型)和 returnAddress 类型(指向了一条字节码指令的地址)

栈满了：StackOverflowError

10.Java对象在内存中实例化过程

来源https://blog.csdn.net/GUDUzhongliang/article/details/123335536

整体流程

从整天上来看对象的整个实例化过程如下图所示：

Java类实例化过程

类初始化检查

这里我们使用 new 关键字创建对象，Java 中创建对象的方式还有好多种，比如反射，克隆，序列化与反序列化等等。这些方式不一而同，但是经过编译器编译之后，对应到 Java 虚拟机中其实就是一条 new（这里的 new 指令与前面提到的 new 关键字不同，这是虚拟机级别的指令）指令。当 Java 虚拟机碰到一条 new 指令时，会首先根据这条指令所对应的参数去常量池中查找是否有该类所对应的符号引用，并判断该类是否已经被加载、解析、初始化过，也就是到方法区中检查是否有该类的类型信息，如果没有，首先要进行类加载与初始化。如果类已经加载和初始化，那么继续后续的操作。

这里假设 DemoClass 类还没有被加载与初始化，也就是方法区中还没有 DemoClass 的类型信息，这时需要进行 DemoClass 类的加载与初始化。

类加载过程
类加载过程总的可分为7个步骤：**加载、验证、准备、解析、初始化、使用、卸载。**这里我们看一下前六个阶段。

1.加载
加载阶段主要干了三件事：

根据类的全限定名获取类的二进制字节流。

将二进制字节流所代表的静态存储结构转化为方法区中运行时数据结构。

在内存中创建一个代表该类的Java.lang.Class对象，作为方法区这个类的各种数据的访问入口。

具体到这里就是首先根据 package.DemoClass 全限定名定位 DemoClass.class 二进制文件，然后将该 .class 文件加载到内存进行解析，将解析之后的结果存储在方法区中，最后在堆内存中创建一个 Java.lang.Class 的对象，用来访问方法区中加载的这些类信息。

2.验证
验证阶段完成的任务主要是确保 class 文件中字节流中包含的信息符合 Java 虚拟机的规范，虽然说得很简单，但是 Java 虚拟机进行了很多复杂的验证工作，总的来说可分为四个方面：

文件格式验证

元数据验证

字节码验证

符号引用验证

具体到这里就是对于加载进内存的 DemoClass.class 中存储的信息进行虚拟机级别的校验，以确保 DemoClass.class 中存储的信息不会危害到 Java 虚拟机的运行。

3.准备
准备阶段完成的工作就是为类变量（也就是静态变量）分配内存并赋予初始值，通常情况下是变量所对应的数据类型的零值。但是在这个阶段，被 final 修饰的变量也就是常量会在这个阶段准确的被赋值。

具体到这里，在这个阶段 DemoClass 中的 a 会被赋值为 1，b 与 c 均被赋值为 0。

4.解析
这个阶段主要的任务是将常量池中的符号引用替换为直接引用。

5.初始化
在之前的阶段中，除了加载阶段通过自定义的类加载器可以干预虚拟机的加载过程外，其他的阶段都是虚拟机完全主导，而在初始化阶段才开始根据程序员的意愿执行类的初始化，这个阶段主要完成的工作是执行类构造器方法()，同时虚拟机会保证执行该类的类构造器方法时，其父类的类构造器方法已经被正确的执行，同时，由于类的初始化只进行一次，当多个线程并发的进行初始化时，虚拟机可以确保多个线程只有一个可以完成类的初始化工作，保证线程安全工作。

具体到 DemoClass类，在这个阶段会将 b 赋值为 2，c 赋值为 3。

分配内存

当类加载过程完成后，或者类本身之前已经被加载过，下一步就是虚拟机要为新生对象分配内存。对象所需要的内存空间在类加载过程完成后就可以完全确定下来，为对象分配内存空间就相当于从堆内存中划分出一块合适的内存来，分配内存的主要方式有两种：指针碰撞和空闲列表。

指针碰撞：这种方式将堆内存分为空闲空间与已分配空间，使用一个指针来作为二者之间的分界线，当要为新生对象分配内存空间的时候，相当于将指针向着空闲空间的方向移动一段与对象大小相等的距离，可见这种分配方式 Java 堆内存必须是规整的，所有空闲空间在一边，已分配空间在另外一边。

空闲列表：在虚拟机中维护一个列表，用来记录堆中哪一块内存是空闲可用的，在为新生对象分配内存时，从列表中寻找一块合适大小的可用内存块，分配完成后更新空闲列表，这种方式下堆内存的空闲空间与分配空间可以交错存在。

从上面来看，选择采用指针碰撞还是空闲列表法分配内存，主要由 Java 堆内存是否规整决定的，而 Java 堆内存是否规整又取决于所采用的垃圾收集算法，这就涉及到垃圾回收机制，GC 之后是否具有压缩或者整理的动作等等。

同时，由于创建对象的动作是十分频繁的，多线程可能存在多个线程同时申请为对象分配内存空间，这个时候如果不采取一定的同步机制，就有可能导致一个线程还未来得及修改指针，另一个线程就使用了原来的指针分配内存空间，因此衍生出来了两种解决方案：CAS 配上失败重试、TLAB 方式。

第一种方式很好理解，多个线程使用 CAS 的方式更新指针，多线程下只有一个线程可以更新完成，其他线程通过不断重试完成内存指针的重新移动。

第二种方式是每个线程提前分配一块内存空间，这个内存空间就是线程本地缓冲 TLAB，这样线程每次要分配内存时，先去 TLAB 中获取，当 TLAB 中内存空间不足的时候才采用同步机制继续申请一块 TLAB 空间，这样就降低了同步锁的申请次数。

具体到这个阶段，是在堆内存中为 DemoClass 对象，也就是 dc 对象实例开辟了一块内存空间。

初始化零值

在为对象分配内存完成之后，虚拟机会将分配到的这块内存初始化为零值，这样也就使得 Java 中的对象的实例变量可以在不赋初值的情况下使用，因为代码所访问当的就是虚拟机为这块内存分配的零值。

具体到这里，就是 Java 虚拟机将上面分配的内存空间初始化为零值，这一步使得现在 DemoClass 中的 d 与 e 均被赋值为 0。

设置对象头

对象头就像我们人的身份证一样，存放了一些标识对象的数据，也就是对象的一些元数据，我们首先看一下对象的构成。

在初始化了零值之后，怎么知道对象是哪个类的实例，就需要设置指向方法区中类型信息的指针，对象 Mark Word 中相关信息的设置，就在这个阶段完成。

实例对象初始化

这一步虚拟机将调用实例构造器方法()，根据我们程序员的意愿初始化对象，在这一步会调用构造函数，完成实例对象的初始化。

具体到这里就是 DemoClass 的 d 被赋值为 4，e 被赋值为 5。

创建引用，入栈

执行到这一步，堆内存中已经存在被完成创建完成的对象，但是我们知道，在 Java 中使用对象是通过虚拟机栈中的引用来获取对象属性，调用对象的方法，因此这一步将创建对象的引用，并压如虚拟机栈中，最终返回引用供我们使用。

在这里就是讲对象的引入入栈，并返回赋值给 dc，至此，一个对象被创建完成。

对象实例化的完整流程

11、三种JVM

Sun公司 HotSpot(TM) 64-Bit Server VM (build 25.281-b09, mixed mode)
BEA JRockit
IBM J9 VM

12、堆

堆：Heap，一个JVM只有一个堆内存，堆内存的大小是可以调节的。

类加载器读取了类文件后，一般会把什么东西放到堆中？类，方法，常量，变量~保存我们所有引用类型的真实对象

堆内存中还要细分为三个区域：

新生区（伊甸园区）Young/New
养老区 old
永久区 Perm

GC：Garbage recycling

轻GC：轻量级垃圾回收，主要是在新生区

重GC（Full GC）：重量级垃圾回收，主要是养老区，重GC就说明养老区也满了

永久区：这个区域常驻内存的。用来存放JDK自身携带的class对象，interface元数据，储存的是java运行时的一些环境或类信息，这个区域不存在垃圾回收，关闭VM虚拟机就会释放这个区域的内存

（下图为jdk8之前的，jdk8以后永久存储区的名字改为“元空间”）

GC垃圾回收，主要是在伊甸园区和养老区

假设内存满了，OOM(Out Of Memory)，堆内存不够！java.lang.OutOfMemoryError：Java heap space

什么时候出现永久区满
一个启动类，加载了大量的第三方jar包，tomcat部署了太多的应用，大量动态生成的反射类，不断的被加载，直到内存满，就会出现OOM

堆结构

发生OOM内存溢出，解决方法
A、尝试扩大堆内存看结果
B、分析内存，看一下哪个地方出现问题（专业工具）

1、内存溢出：（Out Of Memory—-OOM）
系统已经不能再分配出你所需要的空间，比如系统现在只有1G的空间，但是你偏偏要2个G空间，这就叫内存溢出
例子：一个盘子用尽各种方法只能装4个果子，你装了5个，结果掉倒地上不能吃了。这就是溢出。比方说栈，栈满时再做进栈必定产生空间溢出，叫上溢，栈空时再做退栈也产生空间溢出，称为下溢。就是分配的内存不足以放下数据项序列,称为内存溢出。说白了就是我承受不了那么多，那就报错。

2、内存泄漏： (Memory Leak)
强引用所指向的对象不会被回收，可能导致内存泄漏，虚拟机宁愿抛出OOM也不会去回收他指向的对象，意思就是你用资源的时候为他开辟了一段空间，当你用完时忘记释放资源了，这时内存还被占用着，一次没关系，但是内存泄漏次数多了就会导致内存溢出

3、JProfiler工具分析OOM原因：
分析Dump内存文件，快速定位内存泄漏
获得堆中的数据
获得大的对象

-XX:+HeapDumpOnOutOfMemoryError配置jvm参数，获取Heap Dump文件，用于分析结果

4、jvm调优
对JVM内存的系统级的调优主要的目的是减少GC的频率和Full GC的次数。

JVM性能调优方法和步骤：
1.监控GC的状态；
2.生成堆的dump文件；
3.分析dump文件；
4.分析结果，判断是否需要优化；
5.调整GC类型和内存分配；
6.不断的分析和调整

13、新生区、老年区

新生区：（GC算法：复制算法）

类：诞生和成长的地方，甚至死亡
伊甸园区，所有的对象都是在伊甸园区new出来的
幸存者区（from，to）

**老年区（养老区）：**多次轻GC存活下来的对象放在老年区

经过研究，99%的对象都是临时对象

14、永久区

这个区域常驻内存的，用来存放JDK自身携带的Class对象，Interface元数据，存储的是Java运行时的一些环境或类信息，这个区域不存在垃圾回收！关闭JVM虚拟就会释放这个区域的内存

一个启动类，加载了大量的第三方jar包。Tomcat部署了太多的应用，大量动态生成的反射类。不断的被加载，直到内存满，就会出现OOM；

jdk1.6之前：永久代，常量池是在方法区

jdk1.7：永久代，但是慢慢的退化了 去永久代，常量池在堆中

jdk1.8：无永久代，常量池在元空间中

图中方法区中那个小框是：常量池

元空间又被称为非堆，但它不是堆，也有人认为是堆，每个人理解不同

元空间：逻辑上存在，物理上不存在（因为存储在本地磁盘内）而并不算在JVM虚拟机内存中，也就是并不没有占堆内存。元空间在本机内存中

15、堆内存调优

package com.hong.jvm_;
/**
 * 返回虚拟机的最大内存
 * 返回虚拟机的总内存
 * //可以手动调这种参数 jvm调优  -Xms1024m -Xmx1024m -XX:+PrintGCDetails
 */
public class VM_RAM1 {
    public static void main(String[] args) {
        //返回虚拟机可使用的最大内存
        long max = Runtime.getRuntime().maxMemory();//字节 / 1024*1024
        //返回虚拟机的初始化总内存
        long total = Runtime.getRuntime().totalMemory();
        System.out.println("max="+max+"字节\t"+(max/(double)1024/1024)+"MB");//max=1908932608字节  1820.5MB
        System.out.println("total="+total+"字节\t"+(total/(double)1024/1024)+"MB");//total=128974848字节 123.0MB
        //默认情况下，分配的总内存 是电脑内存的1/4  而初始化的内存：1/64
        //可以手动调这种参数 -Xms1024m -Xmx1024m -XX:+PrintGCDetails
    }
    //OOM：
         //1.尝试扩大堆内存看结果
         //2.分析内存，看一下那个地方出现了问题（专业工具）
    //-Xms8m -Xmx8m -XX:+PrintGCDetails
    //305664K+699392K=1005056k = 981.5MB

在一个项目中，突然出现了OOM故障，那么该如何排除~ 研究为什么出错~

能够看到代码第几行出错：内存快照分析工具
Debug 一行行分析代码！

使用JProfiler工具分析OOM原因

MAT，Jprofiler作用

分析Dump内存文件，快速定位内存泄漏；
获得堆中的数据
获得大的对象

安装JProfiler

package com.hong.jvm_;
import java.util.ArrayList;
/**
 * -Xms 设置初始化内存分配大小  默认1/64
 * -Xmx 设置最大分配内存大小   默认1/4
 * -XX:+PrintGCDetails    //打印垃圾回收信息
 * -XX:+HeapDumpOnOutOfMemoryError
 * -Xms1m -Xmx8m -XX:+HeapDumpOnOutOfMemoryError   打印OOM的Dump异常信息
 */
public class JProfiler_1 {
    byte[] array=new byte[1*1024*1024];//1MB
    public static void main(String[] args) {
        ArrayList<JProfiler_1> list = new ArrayList<>();
        int count=0;
        try {
            while(true){
                list.add(new JProfiler_1());//问题所在
                count=count+1;
            }
        } catch (Error e) {//OOM是错误不是异常了
            System.out.println("count:"+count);
            e.printStackTrace();
        }
    }
}

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-VQ9huOcj-1650619364462)(file:///C:/Users/HongHua/AppData/Roaming/Typora/typora-user-images/image-20211103001649047.png)]

16、GC（垃圾回收器）

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-W1j2LJvD-1650619364462)(C:\Users\LENOVO\AppData\Roaming\Typora\typora-user-images\image-20220415203955138.png)]

JVM在进行GC时，并不是对着三个区域统一回收。大部分时候，回收都是新生代

新生代（伊甸园区）
幸存区（from，to）
老年区

GC两种清理方式：轻GC，重GC（Full GC）

常用算法:复制算法，标记清除算法，标记整理（压缩）算法，分代收集算法 （引用计数法）

引用计数法：

在这里插入图片描述

复制算法：（对象存活度较低）
在这里插入图片描述

在这里插入图片描述

在新生区主要用的就是复制算法，存活时间不长的区域可以用复制算法（谁空谁是to)

好处：没有内存的碎片
复制算法缺点：会导致一半的to内存浪费。如果对象存活时间不长，这样通过轻GC清理from区的内存也就不会满，也就可以给to区，然后两个重复调用。而养老区的对象存活时间长，会导致内存不断叠加，这时候用复制算法会浪费内存空间（因为复制算法会空出一半to的内存）

标记清除算法：
在这里插入图片描述

优点：不需要额外的空间
缺点：两次扫描，严重浪费时间，会产生内存碎片（碎片是因为空间不连续，有些大数据无法使用）

标记(整理)压缩算法：

在这里插入图片描述

总结

内存效率：复制算法>标记清除算法>标记压缩算法（时间复杂度）

内存整齐度：复制算法=标记压缩算法>标记清除算法

内存利用率：标记压缩算法=标记清除算法>复制算法

思考一个问题:难道没有最优算法了？

答案：没有最好的算法，只有最合适的算法————->GC：分代收集算法

年轻代：存活率低用复制算法

老年代：区域大，存活率高用标记清除+标记整理混合实现（调优：在进行几次标记清除后再一次标记压缩）,碎片很多的情况下就标记整理压缩一次

Mickey_967

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
JVM相关

1、JVM的位置2、JVM的体系结构3.结构分类线程私有的：程序计数器虚拟机栈本地⽅法栈线程共享的：堆⽅法区直接内存(⾮运⾏时数据区的⼀部分4、类加载器我们在IDE中编写的Java源代码被编译器编译成.class的字节码文件。然后由我们的ClassLoader负责将这些class文件给加载到JVM中去执行。 JVM中提供了三层的ClassLoader：Bootstrap classLoader:主要负责加载核心的类(java.lang.*等)，构造ExtClas
复制链接

扫一扫