JVM初步理解浅析

本文详细介绍了JVM的结构,包括JVM在操作系统的位置、JVM的内存区域(如堆、方法区、栈、PC寄存器)、类加载器的工作原理、双亲委派机制以及垃圾回收机制。特别强调了堆内存的分配和管理,以及如何处理内存溢出问题。此外,文章还讨论了Java对象实例化的过程和不同JVM版本的特性。
摘要由CSDN通过智能技术生成

一、JVM的位置

  1. JVM的位置
    在这里插入图片描述

JVM在操作系统的上一层,是运行在操作系统上的。JRE是运行环境,而JVM是包含在JRE中

二、JVM体系结构

在这里插入图片描述

垃圾回收主要在方法区和堆,所以”JVM调优“大部分也是发生在方法区和堆中

可以说调优就是发生在堆中,方法区可以理解为在堆中元空间,但是又以“非堆”区分。调优发生在堆中

三、类加载器

3.1、类加载器

1.作用:加载Class文件

在这里插入图片描述

2.代码:

public class Car {
    public static void main(String[] args) {
        //类是模板,对象是具体的
        //同一套类模板,new出三个对象

        //从类到对象
        Car car1 = new Car();
        Car car2 = new Car();
        Car car3 = new Car();

        //打印出三个对象的hashcode值---不一样
        System.out.println(car1.hashCode());
        System.out.println(car2.hashCode());
        System.out.println(car3.hashCode());


        //从对象到类(getClass)
        Class<? extends Car> aClass1 = car1.getClass();
        Class<? extends Car> aClass2 = car2.getClass();
        Class<? extends Car> aClass3 = car3.getClass();

        //打印出由三个实例返回来得到的class的hashcode值---一样
        System.out.println(aClass1.hashCode());
        System.out.println(aClass2.hashCode());
        System.out.println(aClass3.hashCode());

        /* 输出:460141958
        * 1163157884
        * 1956725890
        * 685325104
        * 685325104
        * 685325104
        * */
    }
}

3.分为:

  • 虚拟机自带的加载器
  • 启动类(根)加载器 boot
  • 扩展类加载器 extend
  • 应用程序加载器 application

类加载器加载类时,会先从应用程序加载器找,一层一层往上找

  ClassLoader classLoader = aClass1.getClassLoader();
        System.out.println(classLoader);//AppClassLoader
        System.out.println(classLoader.getParent());//ExtClassLoader
        System.out.println(classLoader.getParent().getParent());//null

null—两种情况

  • 不存在
  • 获取不到 rt.jar

ExtClassLoader

  • jre\lib\ext

3.2、双亲委派机制

4.双亲委派机制 :安全

当加载一个类时,app–>ext–>boot 向上查找,但是执行时向下执行 ,向上加载,向下执行

例如,当自己写一个Stirng类的时候,这个时候是首先在application加载器就能找到,但是还要继续找,boot中也有String类,所以执行时,往下执行,先执行根加载器的类。所以不管你自己重写什么类,系统加载的还是根加载器中的,除非你把JVM改了

步骤:

  • 类加载器收到类加载的请求
  • 将这个请求向上委托给父类加载器去完成,一直向上委托,直到启动类加载器
  • 启动类加载器检查是否能够加载当前这个类,能加载就结束,使用当前的加载器,否则,抛出异常,通知子加载器进行加载…

简单来说,就是虽然说类加载器加载请求,是从最下层开始查找,但是即便子类可以加载,也还是要往上委托,一直委托到启动类加载器,再来看是否能加载,不能再让子加载器去加载

向上委托,向下加载

类装载器采用的机制是双亲委派机制:

  • 从最内层JVM自带类加载器开始加载,外层恶意同名类得不到加载从而无法使用
  • 由于严格通过包来区分访问域,外层恶意的类通过内置代码也无法获得权限访问到内存类,破坏代码就自然无法生效
  • 存取控制器:存取控制器可以控制核心API对操作系统的存取权限,而这个控制的策略设定,可以由用户指定
  • 安全管理器:是核心API和操作系统之间的主要接口,实现权限控制,比存取控制器优先级高
  • 安全软件包:java.security下的类和扩展包下的类,允许用户为自己的应用增加新的安全特性,包括:
    • 安全提供者
    • 消息摘要
    • 数字签名 keytools
    • 加密
    • 鉴别

3.3、沙箱安全机制

5.沙箱安全机制

Java安全模型的核心就是Java沙箱(sandbox);沙箱是一个限制程序运行的环境,沙箱机制就是将Java代码限定在虚拟机特定的运行范围中,并且严格限制代码对本地系统的访问,通过这样的措施来保证对代码的有效隔离,防止对本地系统造成破坏。沙箱主要限制系统资源访问 ,系统资源包括:CPU,内存,文件系统,网络。不同级别的沙箱对这些资源访问的限制也可以不一样。

所有的Java程序运行都可以指定沙箱,可以定制安全策略

在Java中将执行代码分为本地代码和远程代码两种,本地代码默认视为可信任的,而远程代码则被看作是不受信任的。对于授信的本地代码,可以访问一切本地资源,而对于非授信的远程代码在早期 的Java实现中,完全依赖于沙箱机制,如下图:

在这里插入图片描述

但如此严格的安全机制也给程序的功能扩展带来障碍,比如当用户希望远程代码访问本地系统的文件时,就无法实现(远程代码都被沙箱限制),因此在后续Java1.1版本中,针对安全机制做了改进,增加了安全策略,允许用户指定代码对本地资源的访问权限。----在沙箱下,加了受信任权限,用户可以指定代码是受信任的,因此也就可以访问本地资源!!

在Java1.2版本中,再次改进了安全机制,增加了代码签名 ,不论是本地代码还是远程代码,都会按照用户的安全策略设定,由类加载器加载到虚拟机中权限不同的运行空间,来实现差异化的代码执行权限控制。

如下图

在这里插入图片描述

当前最新的安全机制实现,则引入了域的概念,虚拟机会把所有代码加载到不同的系统域和应用域,系统域部分专门负责与关键资源进行交互,而各个应用域部分则通过系统域的部分代理来对各种需要的资源进行访问。虚拟机中不同的的受保护域,对应不一样的权限,存在于不同域中的类文件就具有了当前域的全部权限

如下图:

在这里插入图片描述

  • 组成沙箱的基本组件:

    • 字节码校验器:确保Java类文件遵循Java语言规范。这样可以帮助Java程序实现内存保护。但并不是所有的类文件都会经过字节码校验,比如核心类
    • 类加载器:

    -防止恶意代码去干涉善意的代码;(双亲委派机制)

    -它守护了被信任的类库边界

    -它将代码归入保护域,确定了代码可以进行哪些操作

虚拟机为不同的类加载器载入的类提供不同的命名空间,命名空间由一系列唯一的名称组成,每一个被装载的类将有一个名字,这个命名空间是由java虚拟机为每一个类装载器维护的 ,它们互相之间甚至不可见

重点理解双亲委派机制

四、Native

  1. native:反是带了native关键字的,说明java的作用范围达不到了,会去调用底层C语言的库!会进入本地方法栈—>调用本地方法接口 JNI
  • JNI作用:扩展Java的使用,融合不同的编程语言为Java所用!最初:C、C++
  • 最初是在C、C++横行的时期,Java想要立足,必须要有能调用C、C++的程序,为此它在内存区域中专门开辟了一块标记区域:Native Method Stack (本地方法栈)来登记native方法,在最终执行的时候,加载本地方法库中的方法 通过JNI(本地方法接口)
  • 但是现在在java中用的越来越少了,除非调用底层,比如Java程序驱动打印机,管理系统等,在企业级应用中开发较为少见

五、PC寄存器

  1. 程序计数器:Program Counter Register

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

六、方法区

  1. Method Area 方法区

方法区是被所有线程共享,所有字段和方法字节码,以及一些特殊方法,如构造函数,接口代码也在此定义,简单说,所有定义的方法的信息都保存在该区域,此区域属于共享空间

静态变量、常量、类信息(构造方法、接口定义)、运行时的常量池存在方法区中,但是实例变量存在堆内存中,和方法区无关

方法区:static、final、Class、常量池

在这里插入图片描述

定义一个Test类,new一个对象test1,实例化,赋值,都是在方法区中

七、栈

7.1、栈是什么

1、栈:是一种数据结构

先进后出、后进先出 :类似一个桶

队列:先进先出(FIFO:First Input First Output)

  • 为什么main方法先执行最后结束?

栈~main方法先执行,(先进后出),要等其他方法执行完结束,main方法才会结束

  • 递归,a调b,b调a,为什么会栈溢出

栈~函数调用是通过栈这种数据结构实现的,每当程序执行进入一个函数调用,栈就会加一层栈帧,每当函数返回,栈就会减一层栈帧。由于栈的大小不是无限的,所以,递归调用的次数过多,就会导致栈溢出。

2、栈:栈内存,主管 程序的运行,生命周期和线程同步;

线程结束,栈内存也就释放,对于栈来说,不存在垃圾回收问题 。一旦线程结束,栈就over。栈是运行 时才发生的!线程结束栈就over

3、栈里面:八大基本类型+对象引用+实例的方法

栈运行原理:栈帧

在这里插入图片描述

程序正在执行的方法,一定在栈的顶部!

栈满了-----栈溢出StackOverFlowError

7.2、栈、堆、方法区的交互:

在这里插入图片描述

创建一个类,在栈中引用方法,在堆中对象具体的实例,常量又调用方法区中的常量池

7.3、Java对象在内存中实例化的过程

  1. Java对象在内存中实例化的过程
  • 堆区:
    • 存储的全部都是对象,每个对象包含了一个与之对应的class类的信息
    • jvm只有一个堆区(steap),它会被所有线程共享,堆中不存放基本数据类型和对象引用,它只存放对象本身
  • 栈区:
    • 每个线程都包含一个栈区,栈中只保存基本数据类型的值和对象以及基础数据的引用
    • 每个栈中的数据都是私有的,其他栈无法访问
    • 栈分为三部分:基本类型变量区,执行环境上下文、操作指令区
  • 方法区:
    • 又被称为静态区,它跟堆一样,被所有的线程共享,方法区包含所有的class信息和static修饰的变量
    • 方法区包含的都是整个程序中永远唯一的元素

执行代码:

public class Person {
    String name;
    int age;
    void sing(){
        System.out.println("人的姓名:"+name);
        System.out.println("人的年龄:"+age);

    }

    public static void main(String[] args) {
        Person person = new Person();
        person.age=12;
        person.name="xqh";
        person.sing();
    }

}


1–首先,类中的成员变量和方法体会进入到方法区中

在这里插入图片描述

2–程序执行到main()方法时,main()函数方法体会进入栈区,这一过程叫做压栈,定义了一个用于指向Person实例的变量person

在这里插入图片描述

3–程序执行到 Person person = new Person(); 就会在堆内存开辟一块内存区间 ,用于存放 Person 实例对象,然后将成员变量和成员方法放在 new 实例中都是取成员变量&成员方法的地址值 如图:

在这里插入图片描述

4–接下来对 person 对象进行赋值, person.name = “xqh” ; perison.age = 12;

先在栈区找到 person引用变量,然后根据地址值找到 new Person() 进行赋值操作。

在这里插入图片描述

5–当程序走到 sing() 方法时,还是一样,先到栈区找到 person这个引用变量,然后根据其地址值在堆内存中找到 new Person() 实例,然后进行方法调用。

在这里插入图片描述

在方法体void speak()被调用完成后,就会立刻马上从栈内弹出(出栈 )

最后,在main()函数完成后,main()函数也会出栈

八、三种JVM

  1. HopSpot:Sun公司 我们用的就是这个

Java HotSpot™ 64-Bit Server VM (build 25.321-b07, mixed mode)

  1. JRockit:BEA公司 JRockit JVM是世界上最快的JVM

  2. J9VM : IBM公司

九、堆

9.1、堆是什么

  1. Heap :一个JVM只有一个堆内存,堆内存的大小是可以调节的
  2. 类加载器读取了类文件后,一般会把什么东西放到堆中?类、方法、常量、变量,保存我们所有引用型的真实对象
  3. 堆内存中还要细分为3个区域:
  • 新生区(伊甸园)
  • 养老区
  • 永久区

在这里插入图片描述

GC垃圾回收主要在新生区和养老区,对应轻GC和重GC(Full GC)

  • 假设内存满了,OOM,堆内存不够!java.lang.OutOfMemoryError:Java heap space
  • 在JDK8以后,永久存储区改了个名字叫 元空间

9.2、新生区、养老区

4、新生区 、养老区

  • 类:诞生 和成长以及死亡的地方-----能够活下来就会进入养老区

分为伊甸园和幸存者(0,1)

  • 伊甸园:所有的对象都是在伊甸园区new出来的
  • 幸存者区(0,1) :动态的

真理:百分之99的对象都是临时对象。new

伊甸园区满—>触发轻GC---->还需要引用的放到幸存者区,不再引用的清除 ----->新生区满了后,进行重GC,存活下来的进入养老区---->都满了之后,就报错误 ,堆内存已满

9.3、永久区

5、永久区

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

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

  • jdk1.6之前:叫永久代 ,常量池是在方法区中
  • jdk1.7:永久代,但是慢慢退化了,“去永久代”,常量池在堆中
  • jdk1.8及以后:无永久代,叫元空间,常量池在元空间

在这里插入图片描述

jdk1.8以后,就叫元空间,常量池在方法区中,而方法区则在元空间中。----但是有时候会把方法区叫做非堆,和堆区分开来,理解意思就行。

元空间 — 逻辑上存在,物理上不存在(通过计算内存,发现只有新生代和老年代才算内存)

9.4、OOM报错问题以及分析

  1. OOM报错:
  • 1、尝试扩大堆内存看结果
  • 2、还是堆内存满,分析代码,看一下哪个地方出现了问题(专业工具)
public class Hello {
    public static void main(String[] args) {
        String str = "xqhxuejava";
        while(true){
            str += str+new Random().nextInt(888888)+new Random().nextInt(999999);
        }
    }
}

设置vm options:-Xms8m -Xmx8m -XX:+PrintGCDetails

[GC (Allocation Failure) [PSYoungGen: 1536K->488K(2048K)] 1536K->664K(7680K), 0.0019815 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
[GC (Allocation Failure) [PSYoungGen: 1673K->511K(2048K)] 1849K->1008K(7680K), 0.0009834 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
[GC (Allocation Failure) [PSYoungGen: 1607K->400K(2048K)] 2103K->1775K(7680K), 0.0010556 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
[GC (Allocation Failure) [PSYoungGen: 1844K->432K(2048K)] 3220K->2863K(7680K), 0.0008990 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
[GC (Allocation Failure) [PSYoungGen: 1896K->416K(2048K)] 5735K->4959K(7680K), 0.0009835 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
[Full GC (Ergonomics) [PSYoungGen: 416K->0K(2048K)] [ParOldGen: 4543K->1495K(5632K)] 4959K->1495K(7680K), [Metaspace: 3238K->3238K(1056768K)], 0.0047233 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
[GC (Allocation Failure) [PSYoungGen: 737K->64K(2048K)] 3640K->2966K(7680K), 0.0006234 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
[GC (Allocation Failure) [PSYoungGen: 64K->96K(2048K)] 2966K->2998K(7680K), 0.0003145 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
[Full GC (Allocation Failure) [PSYoungGen: 96K->0K(2048K)] [ParOldGen: 2902K->2714K(5632K)] 2998K->2714K(7680K), [Metaspace: 3238K->3238K(1056768K)], 0.0049125 secs] [Times: user=0.01 sys=0.00, real=0.00 secs] 
[Full GC (Ergonomics) [PSYoungGen: 1518K->0K(2048K)] [ParOldGen: 5530K->2014K(5632K)] 7048K->2014K(7680K), [Metaspace: 3309K->3309K(1056768K)], 0.0044064 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
[Full GC (Ergonomics) [PSYoungGen: 1473K->0K(2048K)] [ParOldGen: 4829K->4854K(5632K)] 6303K->4854K(7680K), [Metaspace: 3324K->3324K(1056768K)], 0.0052257 secs] [Times: user=0.16 sys=0.00, real=0.01 secs] 
[GC (Allocation Failure) [PSYoungGen: 0K->0K(2048K)] 4854K->4854K(7680K), 0.0003076 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
[Full GC (Allocation Failure) [PSYoungGen: 0K->0K(2048K)] [ParOldGen: 4854K->4835K(5632K)] 4854K->4835K(7680K), [Metaspace: 3324K->3324K(1056768K)], 0.0047963 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
Heap
 PSYoungGen      total 2048K, used 46K [0x00000000ffd80000, 0x0000000100000000, 0x0000000100000000)
  eden space 1536K, 3% used [0x00000000ffd80000,0x00000000ffd8b868,0x00000000fff00000)
  from space 512K, 0% used [0x00000000fff80000,0x00000000fff80000,0x0000000100000000)
  to   space 512K, 0% used [0x00000000fff00000,0x00000000fff00000,0x00000000fff80000)
 ParOldGen       total 5632K, used 4835K [0x00000000ff800000, 0x00000000ffd80000, 0x00000000ffd80000)
  object space 5632K, 85% used [0x00000000ff800000,0x00000000ffcb8c10,0x00000000ffd80000)
 Metaspace       used 3358K, capacity 4496K, committed 4864K, reserved 1056768K
  class space    used 366K, capacity 388K, committed 512K, reserved 1048576K
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space

可以清楚的看出,先是轻GC,新生区满了后,进行full GC,然后又是一系列GC,一直到最后,新生区、老生区都满了,于是报堆满了的错误 java.lang.OutOfMemoryError: Java heap space

  1. 使用JProfiler工具分析OOM

在一个项目中,突然出现了OOM故障,在扩大了堆内存后,仍然报错,如何排除?

  • 能够看到代码第几行出错—内存快照分析工具:MAT(eclipse的工具) ,JProfiler(IDEA的工具)

MAT、Jprofiler作用:

  • 分析Dump内存文件,快速定位内存泄露;
  • 获得堆中的数据
  • 获得大的对象

IDEA下载插件Jprofiler ----> 下载客户端Jprofiler ----->在IDEA里测试如何分析OOM

—分析OOM

代码

//DUMP
//-Xms 设置初始化内存分配大小 1/64
//-Xmx 设置最大分配内存 ,默认 1/4
// -XX:PrintGCDetails   打印GC垃圾回收信息
//-XX:+HeapDumpOnOutOfMemoryError  dump出一个文件,来分析出错的代码行和大的对象
//-Xms1m -Xmx8m -XX:+HeapDumpOnOutOfMemoryError



public class Demo03 {
    byte[]array = new byte[1*1024*1024];  //1M

    public static void main(String[] args) {
        ArrayList<Demo03>list = new ArrayList<>();
        int count = 0;
        try{
            while(true){
                list.add(new Demo03());   //问题所在
                count+=1;
            }
        }catch(Error e){
            System.out.println("count:"+count);
            e.printStackTrace();
        }
    }
}

报错OOM

修改VM options:-Xms1m -Xmx8m -XX:+HeapDumpOnOutOfMemoryError

运行,会有一个dump文件,位置在项目文件夹内

输出:

在这里插入图片描述

dump文件在

在这里插入图片描述

打开这个dump出来的文件 ,主要就是看Biggest Objects 和 Thread Dump这两个位置

  • Biggest Objects

在这里插入图片描述

从大对象这里,可以明显看出哪个对象是占内存大的,如图,ArrayList明显有问题,占87%

  • Thread Dump ,点main

在这里插入图片描述

可以看出,有问题的代码是第12行,也就是 list.add(new Demo03()); //问题所在

这样就是一个分析OOM的过程,通过JProfiler来加载dump出来的文件,从而分析出有问题的对象和有问题的代码出现在哪一行

//DUMP
//-Xms 设置初始化内存分配大小 1/64
//-Xmx 设置最大分配内存 ,默认 1/4
// -XX:PrintGCDetails   打印GC垃圾回收信息
//-XX:+HeapDumpOnOutOfMemoryError  dump出一个文件,来分析出错的代码行和大的对象
//-Xms1m -Xmx8m -XX:+HeapDumpOnOutOfMemoryError

-XX:+HeapDumpOnOutOfMemoryError dump出一个文件,来分析出错的代码行和大的对象

Dump后面加上报的错误,就可以给这个错误dump出一个文件,从而分析!!

十、GC介绍之引用计数法

1、GC:垃圾回收 ,作用区域在堆

  • 新生代
  • 幸存区(from to 交替性的过程)
  • 养老区

轻GC、FullGC(重GC,也叫全局GC)

2、GC算法—引用计数法

在这里插入图片描述

对每一个引用的对象标记引用次数,引用次数为0的就垃圾清除。但是这种方法弊端很多,本身标记次数也消耗内存,计数器本身也会有消耗。JVM一般不采用这个算法,不高校,用的比较少

十一、GC算法之复制算法

  1. 每次GC都会将Eden区活的对象移到幸存区,一旦Eden区被GC后,就会是空的!(活的对象移到了幸存区,垃圾对象被gc清除)
  2. 幸存区—谁空谁是to ---- 幸存区to和from一直动态变化,当一个区有对象一个没有,另一个没有对象的就是to区,假如现在两个幸存区都有对象,就会用复制算法 ,将其中一个区的对象复制到另一个区里,然后没有对象的区变为to区,有对象的是from区-----谁空谁是to
  3. 当一个对象在新生代经历了15次(默认值)GC,都还没有死,就会进入养老区
  • -XX:MaxTenuringThreshold=5 通过这个参数,可以设置经历几次gc进入养老区。这也是JVM一个调优的参数。默认是15
  1. 新生代(伊甸园和幸存区)GC主要用的就是这个复制算法
  2. 好处:没有内存的碎片,不会到处放,就是在幸存者to和from中转换
  3. 坏处:浪费了内存空间,多出一个幸存区空间永远是空的。假设对象百分百存活(极端情况),那么幸存区也要复制一个这么大内存的空间,成本很高。极端情况下,这个弊端就会被放大。
  4. 复制算法最佳使用场景:对象存活度较低的情况下------>新生代,这也就是为什么新生代GC主要用复制算法

十二、GC算法之标记清除(压缩)算法

在这里插入图片描述

  • 扫描这些对象,对活着的对象进行标记
  • 清除:对没有标记的对象,进行清除
  1. 缺点:
  • 两次扫描:严重浪费时间,会产生内存碎片。
  • 标记会占内存
  1. 优点:
  • 不需要额外的空间
  1. 标记压缩
  • 再次优化

在这里插入图片描述

再清除后,防止内存碎片的产生,再次扫描,向一段移动存活的对象。这样就没有了内存碎片,是比较高效的。

  • 多了移动成本
  1. 标记清除压缩

再优化:

先标记清除几次(多几次产生的内存碎片多),再进行一次标记压缩。这样节约移动成本—一次移动解决更多的内存碎片

十三、总结

  1. 比较三种算法
  • 内存效率:复制算法>标记清除>标记压缩(也就是比较时间复杂度)
  • 内存整齐度:复制算法=标记压缩>标记清除(前二者的优势体现出来了,没有内存碎片)
  • 内存利用率: 标记清除=标记压缩 >复制算法(前二者不用开辟多的内存,复制算法浪费一半内存)
  1. 没有最好的算法,只有最合适的算法。----->GC:分代收集算法
  • 年轻代:对象存活率低,用复制算法最合适
  • 老年代:存活率高,区域大,标记清除+标记压缩混合实现 -----内存碎片不是太多继续标记清除,当内存碎片到达一定量级,实施标记压缩清除内存碎片。

十四、学习JMM

  1. 什么是JMM
  2. 作用
  3. 如何学习
  4. 面试题以及答案

参考官方,百度,博客,视频等途径进行学习

学习新东西是常态!!

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

Zero摄氏度

感谢鼓励!

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值