深入了解JVM

最新推荐文章于 2024-07-08 01:05:37 发布

# Never Give up &

最新推荐文章于 2024-07-08 01:05:37 发布

阅读量197

点赞数 1

分类专栏： Java高级

本文链接：https://blog.csdn.net/qq_41939020/article/details/103624254

版权

Java高级专栏收录该内容

9 篇文章 0 订阅

订阅专栏

JVM的位置

JVM是运行在操作系统之上的，它与硬件没有直接的交互
在这里插入图片描述

JVM体系结构

在这里插入图片描述
接下来就让我们一点点的来了解JVM吧

Class files

是指.java文件通过javac命令编译后生成的.class文件
在这里插入图片描述

类装载器子系统（Class Loader）

简称：类装载器（类加载器）
作用
- 负责加载class文件，class文件在开头有特定的标识（cafe babe，当然还有其他的一些判断，这是其中之一），将class文件加载到内存中，并将这些内容转换成方法区的运行时数据结构，Class Loader只负责加载class文件的加载，至于是否能够运行由Execution Engine（执行引擎）决定。
- 类加载是将class字节码文件实例化成Class对象并进行相关初始化的过程。全小写的class是关键字，用来定义类，首字母大写的Class是所有小class的类（getClass()方法）。
结构
- 3+1
- 虚拟机自带的加载器
  - ①启动类加载器（BootstrapLoader）
    - 该加载器是用c++语言编写的，我们无法在java代码中获取到该加载器
    - 负责加载的路径：sun.boot.class.path
  - ②扩展类加载器（ExtensionLoader）
    - 该加载器是用java语言编写的，我们可以在java代码中获取到该加载器
    - 负责加载的路径：java.ext.dirs
  - ③应用程序类加载器（AppClassLoader）
    - 该加载器是用java语言编写的，我们可以在java代码中获取到该加载器
    - 负责加载的路径：java.class.path
- 用户可以自定义类加载器
  - 继承Java.lang.ClassLoader

加载顺序

BootstrapLoader会在JVM启动之后载入，之后它会载入ExtClassLoader并将ExtClassLoader的parent设为BootstrapLoader，然后BootstrapLoader再加载AppClassLoader，并将AppClassLoader的parent设定为 ExtClassLoader。
- JDK中自带的类，他的加载器为BootstrapLoader，我们输出会是null（因为是C语言编写的，无法获取）
- 我们自己定义的类，加载器为AppClassLoader，其parent为ExtClassLoader，ExtClassLoader的parent为BootstrapLoader

  public class ClassLoader {
      public static void main(String[] args) {
          Object object = new Object();
          System.out.println(object.getClass().getClassLoader());
          
          ClassLoader classLoader = new ClassLoader();
          System.out.println(classLoader.getClass().getClassLoader().getParent().getParent());
          System.out.println(classLoader.getClass().getClassLoader().getParent());
          System.out.println(classLoader.getClass().getClassLoader());
      }
  }

双亲委派
- 当我们加载一个类的时，如果先交给了AppClassLoader，AppClassLoader不会直接去寻找该类，而是先交给其parent：ExtClassLoader，同样ExtClassLoader也会先交给BootstrapLoader，然后BootstrapLoader开始查找该类，如果找到了就由BootstrapLoader来加载该类，如果没找到，那么BootstrapLoader会交给ExtClassLoader来寻找加载，如果ExtClassLoader也没找到，那么交给AppClassLoader来寻找加载，如果AppClassLoader也没找到此时就会抛出异常ClassNotFoundException
- 和ClassNotFoundException很相似的有一个NoClassDefFoundError
  - ClassNotFoundException：加载类时找不到
  - NoClassDefFoundError：编译时没问题，运行时找不到这个类的定义
- 简单来说:如果一个类加载器收到了类载的请求，它首先不会自己去尝试加载这个类，而是把请求委托给父加载器去完成，依次向上。
- 采用双亲委派的一个好处是比如加载位于 rt.jar 包中的类 java.lang.Object，不管是哪个加载器加载这个类，最终都是委托给顶层的启动类加载器进行加载，这样就保证了使用不同的类加载器最终得到的都是同样一个 Object对象。
- 防止内存中出现多份同样的字节码(安全性角度)
- 例如：String这个类是jdk中自带的：java.lang.String，那么如果我们自己也写一个java.lang.String会怎么样呢？
  - ```
    package java.lang;
  
    public class String {
        public static void main(String[] args) {
            System.out.println("Hello String");
        }
    }
```
- 创建好之后我们来运行这个程序
- 结果运行时说在java.lang.String中找不到main方法，我们自己写的String类中是有main方法的，那为什么会找不到呢？
- 因为他最终运行的根本就不是我们自己写的这个String，而是jdk中早已写好的String，最终加载String的时候是由Bootstrap来加载的，这也证明了双亲委派机制

接下来我们先说简单的，复杂的放到后面说

执行引擎（Execution Engine）

负责解释命令，提交操作系统执行。

本地接口（Native Interface）

本地接口的作用是融合不同的编程语言为 Java 所用，它的初衷是融合 C/C++程序，Java 诞生的时候是 C/C++横行的时候，要想立足，必须有调用 C/C++程序，于是就在内存中专门开辟了一块区域处理标记为native的代码，它的具体做法是 Native Method Stack中登记 native方法，在Execution Engine 执行时加载native libraies。
目前该方法使用的越来越少了，除非是与硬件有关的应用，比如通过Java程序驱动打印机或者Java系统管理生产设备，在企业级应用中已经比较少见。因为现在的异构领域间的通信很发达，比如可以使用 Socket通信，也可以使用Web Service等等。
被动接口在java代码中就是那些被native修饰的方法

本地方法栈（Native Method Stack）

这并不是我们平时说的那个栈
它的具体做法是Native Method Stack中登记native方法，在Execution Engine 执行时加载本地方法库。

程序计算器（Programma Counter ）

我记着这个当年是在汇编语言中讲的
每个线程都有一个程序计数器，是线程私有的,就是一个指针，指向方法区中的方法字节码（用来存储指向下一条指令的地址,也即将要执行的指令代码），由执行引擎读取下一条指令，是一个非常小的内存空间，几乎可以忽略不记。
它是当前线程所执行的字节码的行号指示器
这块内存区域很小，字节码解释器通过改变这个计数器的值来选取下一条需要执行的字节码指令。

方法区（Method Area）

供各线程共享的运行时内存区域。
- 方法区存储的是每个class的信息:
  - （1）类加载器引用(ClassLoader)
  - （2）运行时常量池：包含所有常量、字段引用、方法引用、属性
  - （3）字段数据：每个字段的名字、类型(如类的全路径名、类型或接口) 、修饰符（如public、abstract、final）、属性
  - （4）方法数据：每个方法的名字、返回类型、参数类型(按顺序)、修饰符、属性
  - （5）方法代码：每个方法的字节码、操作数栈大小、局部变量大小、局部变量表、异常表和每个异常处理的开始位置、结束位置、代码处理在程序计数器中的偏移地址、被捕获的异常类的常量池索引
方法区可以理解为是一种规范，在不同虚拟机里头实现是不一样的，最典型的就是JDK1.7中的永久代(PermGen space)和JDK1.8中的元空间(Metaspace)。
注意： 方法区中存的是类的结构信息，不是实例变量，变量的引用在栈中，new 出来的对象在Java堆中
- ```
  String str = new String();
  //str在栈中，new String()在堆中
```

Java栈（Java Stack）

也就是我们平时说的栈
- 栈也叫栈内存，主管Java程序的运行，是在线程创建时创建，他的生命周期是跟随线程的生命周期，线程结束栈内存也就释放，对于栈来说不存在垃圾回收问题，只要线程一结束该栈就Over，生命周期和线程一致，是线程私有的。
- 8种基本数据类型的变量+对象的引用变量+实例方法都是在函数的栈内存中分配
栈存储什么？
- 本地变量（Local Variables）：输入参数和输出参数以及方法内的变量
- 栈操作（Operand Stack）：记录出栈、入栈的操作
- 栈帧数据（Frame Data）：包括类文件、方法等等
栈的特点
- 先入后出
  没找到合适的java的动图，找了一张JavaScript的，栈的原理都是一样的

栈+堆+方法区的交互关系

在这里插入图片描述
JDK是使用指针的方式来访问对象：Java堆中会存放访问类元数据的地址，reference存储的就直接是对象的地址

堆（Heap）

一个JVM实例只存在一个堆内存，堆内存的大小是可以调节的。类加载器读取了类文件后，需要把类、方法、常变量放到堆内存中，保存所有引用类型的真实信息，以方便执行器执行。
堆内存结构：
- java8之前
  - 新生区+养老区+永久区（有的也称为新生代、养老代、永久代）
- java8及其以后将永久区改为元空间
  - 此时
    - 堆在逻辑上包含：新生区、养老区、元空间
    - 堆在实际上包含：新生区、养老区
  - 元空间实际上时间本地内存中，并不在堆中，但我们口头上依旧习惯将元空间放到堆中
  - 将元空间从堆中挪出去主要是为了加大元空间的内存容量，尽量减少内容溢出
  - 元空间放置类信息：字段、静态属性、方法、常量等

新生区

新生区又分为三个区
- 伊甸区
- 幸存0区
- 幸存1区

例如：

  String str = new String();
  //此时的new String()是诞生在堆内存中的新生区的伊甸区

对象在堆中的移动
- 新生区是类的诞生、成长、消亡的区域，一个类在这里产生，应用，最后被垃圾回收器收集，结束生命。新生区又分为两部分：伊甸区（Eden space）和幸存者区（Survivor pace），所有的类都是在伊甸区被new出来的。幸存区有两个： 0区（Survivor 0 space）和1区（Survivor 1 space）。当伊甸园的空间用完时，程序又需要创建对象，JVM的垃圾回收器将对伊甸园区进行垃圾回收(Minor GC)，将伊甸园区中的不再被其他对象所引用的对象进行销毁。然后将伊甸园中的剩余对象移动到幸存 0区。若幸存 0区也满了，再对该区进行垃圾回收，然后移动到 1 区。那如果1 区也满了呢？再移动到养老区。若养老区也满了，那么这个时候将产生MajorGC（FullGC），进行养老区的内存清理。若养老区执行了Full GC之后发现依然无法进行对象的保存，就会产生OOM异常“OutOfMemoryError”。
- 如果出现java.lang.OutOfMemoryError: Java heap space异常，说明Java虚拟机的堆内存不够。原因有二：
  - ①Java虚拟机的堆内存设置不够，可以通过参数-Xms、-Xmx来调整。
  - ②代码中创建了大量大对象，并且长时间不能被垃圾收集器收集（存在被引用）。
从GC的角度来看
- ①eden、SurvivorFrom 复制到 SurvivorTo，年龄+1 （幸存区又被称为from区和to区，谁空谁是to）
  - 首先，当Eden区满的时候会触发第一次GC,当GC线程启动时，会通过可达性分析法（对于用可达性分析法搜索不到的对象，GC并不一定会回收该对象。要完全回收一个对象，至少需要经过两次标记的过程）把Eden区和From Space区的存活对象复制到To Space区，同时把这些对象的年龄+1，然后把Eden Space和From Space区的对象释放掉。当GC轮训扫描To Space区一定次数后（15次），把依然存活的对象复制到老年代
- ②清空 eden、SurvivorFrom
  - 然后，清空Eden和SurvivorFrom中的对象，也即复制之后有交换，谁空谁是to
- ③SurvivorTo和 SurvivorFrom 互换
  - 最后，SurvivorTo和SurvivorFrom互换，原SurvivorTo成为下一次GC时的SurvivorFrom区。部分对象会在From和To区域中复制来复制去,如此交换15次(由JVM参数MaxTenuringThreshold决定,这个参数默认是15),最终如果还是存活,就存入到老年代
- ④大对象特殊情况
  - 如果分配的新对象比较大Eden区放不下但Old区可以放下时，对象会被直接分配到Old区（即没有晋升这一过程，直接到老年代了）
- 经研究，不同的对象生命周期不同，98%的对象是临时对象（活不过一次GC）
- 新生区为啥需要Survivor区
  - 不就是新生代到老年代么，直接Eden到Old不好了吗？为啥要这么复杂？想想如果没有Survivor区，Eden区每进行一次MinorGC存活的对象就会被送到老年代，老年代很快就会被填满。而有很多对象虽然一次MinorGC没有消灭但其实也并不会蹦跶多久，或许第2次第3次就需要被清除。这时候移入老年区，很明显不是一个明智的决定。所以Survivor的存在意义就是减少被送到老年代的对象，进而减少FullGC的发生。Survivor的预筛选保证只有经历15次MinorGC还能在新生代中存活的对象，才会被送到老年代。
  - 新生区为啥需要两个Survivor区
    - 设置两个Survivor区最大的好处就是解决内存碎片化。
    - 假设Survivor如果只有一个区域会怎样？MinorGC执行后Eden区被清空了，存活的对象放到了Survivor区，而之前Survivor区中的对象，可能也有一些是需要被清除的。问题来了，这时候我们怎么清除它们？在这种场景下，我们只能标记清除，而我们知道标记清除最大的问题就是内存碎片，在新生代这种经常会消亡的区域，采用标记清除必然会让内存产生严重的碎片化。因为Survivor有2个区域，所以每次MinorGC，会将之前Eden区和From区中的存活对象复制到To区域。第二次MinorGC时，From与To职责兑换，这时候会将Eden区和To区中的存活对象再复制到From区域，以此反复。这种机制最大的好处就是，整个过程中，永远有一个Survivorspace是空的，另一个非空的Survivorspace是无碎片的。那么，Survivor为什么不分更多块呢？比方说分成三个、四个、五个?显然，如果Survivor区再细分下去，每一块的空间就会比较小，容易导致Survivor区满，两块Survivor区是经过权衡之后的最佳方案。