JVM-01 JVM内存结构

- 日理万妓 2022-03-16 03:18 237阅读 0赞

### 文章目录 ###

*  1.JVM整体架构
 *   *  1.1 JVM(虚拟机)
     *  1.2 Java虚拟机阵营
 *  2.JVM子系统构成
 *  3.JVM内存结构
 *   *  3.1 名词解释
     *  3.2 JVM对该区域规范了两种异常
     *  3.3 实例详解Java栈
     *  3.4 栈+堆+方法区的交互关系
     *  3.5 堆(线程共享)
     *   *  3.5.1 \*\*为什么jdk1.8用元数据区取代了永久代\*\*？
         *  3.5.2 java虚拟机调优的目的
     *  3.6 JVM执行案例分析
     *   *  3.6.1 编写java类
         *  3.6.2 执行编译
         *  3.6.3 Jvm指令分析
 *  4.JVM执行引擎

# 1.JVM整体架构 #

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMxNDYzOTk5_size_16_color_FFFFFF_t_70]

## 1.1 JVM(虚拟机) ##

> 指以软件的方式模拟具有完整硬件系统功能、运行在一个完全隔离环境中的完整计算机系统，是物理机的软件实现。常用的虚拟机有VMWare，Virtual Box，Java Virtual Machine

## 1.2 Java虚拟机阵营 ##

*  Sun HotSpot VM
 *  BEA JRockit VM
 *  IBM J9 VM
 *  Azul VM
 *  Apache Harmony
 *  Google Dalvik VM
 *  Microsoft JVM
 *  …

**补充知识**：  
提起HotSpot VM，相信所有Java程序员都知道，它是Sun JDK和OpenJDK中所带的虚拟机，也是目前使用范围最广的Java虚拟机。但不一定所有人都知道的是，这个目前看起来“血统纯正”的虚拟机在最初并非由Sun公司开发，而是由一家名为“Longview Technologies”的小公司设计的；甚至这个虚拟机最初并非是为Java语言而开发的，它来源于Strongtalk VM，而这款虚拟机中相当多的技术又是来源于一款支持Self语言实现“达到C语言50%以上的执行效率”的目标而设计的虚拟机，Sun公司注意到了这款虚拟机在JIT编译上有许多优秀的理念和实际效果，在1997年收购了Longview Technologies公司，从而获得了HotSpot VM。HotSpot VM既继承了Sun之前两款商用虚拟机的优点（如前面提到的准确式内存管理），也有许多自己新的技术优势，如它名称中的HotSpot指的就是它的热点代码探测技术（其实两个VM基本上是同时期的独立产品，HotSpot还稍早一些，HotSpot一开始就是准确式GC，而Exact VM之中也有与HotSpot几乎一样的热点探测。为了Exact VM和HotSpot VM哪个成为Sun主要支持的VM产品，在Sun公司内部还有过争论，HotSpot打败Exact并不能算技术上的胜利），HotSpot VM的热点代码探测能力可以通过执行计数器找出最具有编译价值的代码，然后通知JIT编译器以方法为单位进行编译。如果一个方法被频繁调用，或方法中有效循环次数很多，将会分别触发标准编译和OSR（栈上替换）编译动作。通过编译器与解释器恰当地协同工作，可以在最优化的程序响应时间与最佳执行性能中取得平衡，而且无须等待本地代码输出才能执行程序，即时编译的时间压力也相对减小，这样有助于引入更多的代码优化技术，输出质量更高的本地代码。

在2006年的JavaOne大会上，Sun公司宣布最终会把Java开源，并在随后的一年，陆续将JDK的各个部分（其中当然也包括了HotSpot VM）在GPL协议下公开了源码，并在此基础上建立了OpenJDK。这样，HotSpot VM便成为了Sun JDK和OpenJDK两个实现极度接近的JDK项目的共同虚拟机。

在2008年和2009年，Oracle公司分别收购了BEA公司和Sun公司，这样Oracle就同时拥有了两款优秀的Java虚拟机：JRockit VM和HotSpot VM。Oracle公司宣布在不久的将来（大约应在发布JDK 8的时候）会完成这两款虚拟机的整合工作，使之优势互补。整合的方式大致上是在HotSpot的基础上，移植JRockit的优秀特性，譬如使用JRockit的垃圾回收器与MissionControl服务，使用HotSpot的JIT编译器与混合的运行时系统。

# 2.JVM子系统构成 #

*  类加载器子系统
 *  运行时数据区（内存结构）
 *  执行引擎

# 3.JVM内存结构 #

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMxNDYzOTk5_size_16_color_FFFFFF_t_70 1]

## 3.1 名词解释 ##

*  **本地方法栈(线程私有)**：登记native方法，在Execution Engine执行时加载本地方法库
 *  **程序计数器（线程私有）**：就是一个指针，指向方法区中的方法字节码（用来存储指向下一条指令的地址,也即将要执行的指令代码），由执行引擎读取下一条指令，是一个非常小的内存空间，几乎可以忽略不记。
 *  **方法区(线程共享)**：类的所有字段和方法字节码，以及一些特殊方法如构造函数，接口代码也在此定义。简单说，所有定义的方法的信息都保存在该区域，静态变量+常量+类信息(构造方法/接口定义)+运行时常量池都存在方法区中，虽然Java虚拟机规范把方法区描述为堆的一个逻辑部分，但是它却有一个别名叫做 Non-Heap（非堆），目的应该是与 Java 堆区分开来。
 *  **Java栈（线程私有）**： Java线程执行方法的内存模型，一个线程对应一个栈，每个方法在执行的同时都会创建一个栈帧（用于存储局部变量表，操作数栈，动态链接，方法出口等信息）不存在垃圾回收问题，只要线程一结束该栈就释放，生命周期和线程一致

## 3.2 JVM对该区域规范了两种异常 ##

1.  线程请求的栈深度大于虚拟机栈所允许的深度，将抛出StackOverFlowError异常
2.  若虚拟机栈可动态扩展，当无法申请到足够内存空间时将抛出OutOfMemoryError，通过jvm参数–Xss指定栈空间，空间大小决定函数调用的深度

## 3.3 实例详解Java栈 ##

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMxNDYzOTk5_size_16_color_FFFFFF_t_70 2]

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

*  HotSpot是使用指针的方式来访问对象
 *  Java堆中会存放访问类元数据的地址
 *  reference存储的就直接是对象的地址

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMxNDYzOTk5_size_16_color_FFFFFF_t_70 3]

## 3.5 堆(线程共享) ##

虚拟机启动时创建，用于存放对象实例，几乎所有的对象（包含常量池）都在堆上分配内存，当对象无法再该空间申请到内存时将抛出OutOfMemoryError异常。同时也是垃圾收集器管理的主要区域。可通过 -Xmx –Xms 参数来分别指定最大堆和最小堆

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMxNDYzOTk5_size_16_color_FFFFFF_t_70 4]

*  **新生区**  
    类诞生、成长、消亡的区域，一个类在这里产生，应用，最后被垃圾回收器收集，结束生命。  
    新生区分为两部分： 伊甸区（Eden space）和幸存者区（Survivor pace） ，所有的类都是在伊甸区被new出来的。幸存区有两个： 0区（Survivor 0 space）和1区（Survivor 1 space）。当伊甸园的空间用完时，程序又需要创建对象，JVM的垃圾回收器将对伊甸园区进行垃圾回收(Minor GC)，将伊甸园区中的不再被其他对象所引用的对象进行销毁。然后将伊甸园中的剩余对象移动到幸存 0区。若幸存 0区也满了，再对该区进行垃圾回收，然后移动到1区。那如果1区也满了呢？
 *  **老年区**  
    新生区经过多次GC仍然存活的对象移动到老年区。若老年区也满了，那么这个时候将产生MajorGC（FullGC），进行老年区的内存清理。若老年区执行了Full GC之后发现依然无法进行对象的保存，就会产生OOM异常“OutOfMemoryError”
 *  **元数据区**  
    元数据区取代了永久代(jdk1.8以前)，本质和永久代类似，都是对JVM规范中方法区的实现，区别在于元数据区并不在虚拟机中，而是使用本地物理内存，永久代在虚拟机中，永久代逻辑结构上属于堆，但是物理上不属于堆，堆大小=新生代+老年代。元数据区也有可能发生OutOfMemory异常。
 *  Jdk1.6及之前： 有永久代, 常量池在方法区
 *  Jdk1.7：有永久代，但已经逐步“去永久代”，常量池在堆
 *  Jdk1.8及之后： 无永久代，常量池在元空间

元数据区的动态扩展，默认–XX:MetaspaceSize值为21MB的高水位线。一旦触及则Full GC将被触发并卸载没有用的类（类对应的类加载器不再存活），然后高水位线将会重置。新的高水位线的值取决于GC后释放的元空间。如果释放的空间少，这个高水位线则上升。如果释放空间过多，则高水位线下降。

### 3.5.1 **为什么jdk1.8用元数据区取代了永久代**？ ###

官方解释：移除永久代是为融合HotSpot JVM与 JRockit VM而做出的努力，因为JRockit没有永久代，不需要配置永久代

### 3.5.2 java虚拟机调优的目的 ###

> 减少full gc 或者让每次full gc(早期-停止虚拟机所有线程去做垃圾回收-STW 主要回收老年代)时间变短

## 3.6 JVM执行案例分析 ##

### 3.6.1 编写java类 ###

public class JvmTest {
    
        public int add(){
            int a=1;
            int b=2;
            int c=(a+b)*10;
            return c;
        }
        public static void main(String[] args) {
            JvmTest jvmTest =new JvmTest();
            jvmTest.add();
        }
    }

### 3.6.2 执行编译 ###

javac JvmTest.java 
    javap -c JvmTest.class  #Java class文件分解

### 3.6.3 Jvm指令分析 ###

public class JvmTest {
      public JvmTest();
        Code:
           0: aload_0
           1: invokespecial #1                  // Method java/lang/Object."<init>":()V
           4: return
    
      public int add();
        Code:
           0: iconst_1
           1: istore_1
           2: iconst_2
           3: istore_2
           4: iload_1
           5: iload_2
           6: iadd
           7: bipush        10
           9: imul
          10: istore_3
          11: iload_3
          12: ireturn
    
      public static void main(java.lang.String[]);
        Code:
           0: new           #2                  // class JvmTest
           3: dup
           4: invokespecial #3                  // Method "<init>":()V
           7: astore_1
           8: aload_1
           9: invokevirtual #4                  // Method add:()I
          12: pop
          13: return
    }

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMxNDYzOTk5_size_16_color_FFFFFF_t_70 5]

# 4.JVM执行引擎 #

读取运行时数据区的Java字节码并逐个执行

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMxNDYzOTk5_size_16_color_FFFFFF_t_70 6]

混合模型  
![在这里插入图片描述][2019022611160161.png]

***更多JVM相关知识请参考目录***：[JVM学习目录][JVM]

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMxNDYzOTk5_size_16_color_FFFFFF_t_70]: /images/20220316/10e55714a40e4818ac52f28cab867215.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMxNDYzOTk5_size_16_color_FFFFFF_t_70 1]: /images/20220316/fc14602410034e42b57fdd3faa7835d4.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMxNDYzOTk5_size_16_color_FFFFFF_t_70 2]: /images/20220316/1cd498ac8ee44c63a2bd351406f1990e.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMxNDYzOTk5_size_16_color_FFFFFF_t_70 3]: /images/20220316/81aa640b03aa4229800beaaf0433f096.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMxNDYzOTk5_size_16_color_FFFFFF_t_70 4]: /images/20220316/94cb689b5a434a1ea3e5199c0d26c5ea.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMxNDYzOTk5_size_16_color_FFFFFF_t_70 5]: /images/20220316/6ddf3c98bcdb42a995d2228fd609be39.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMxNDYzOTk5_size_16_color_FFFFFF_t_70 6]: /images/20220316/7769d134ceea4cd09009b4f24647dfb7.png
[2019022611160161.png]: /images/20220316/4111cf7ec40e4382a19a9276d7be7ec4.png
[JVM]: https://blog.csdn.net/qq_31463999/article/details/87966505