深入理解Java虚拟机（三）——JVM内存结构+JVM执行引擎

电玩女神 2022-05-14 15:22 267阅读 0赞

**目录**

[深入理解Java虚拟机（一）——JVM整体架构][Java_JVM]

[深入理解Java虚拟机（二）——类加载器深入解析][Java]

[深入理解Java虚拟机（三）——JVM内存结构+JVM执行引擎][Java_JVM_JVM]

[深入理解Java虚拟机（四）——JVM性能调优监控工具][Java_JVM 1]

--------------------

# JVM内存结构 #

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3o3ODU0OTUyOTU_size_27_color_FFFFFF_t_70][]

•**本地方法栈****(****线程****私有****)**：登记native方法，在Execution Engine执行时加载本地方法库

•**程序计数器****（****线程****私有****）**：就是一个指针，指向方法区中的方法字节码（用来存储指向下一条指令的地址,也即将要执行的指令代码），由执行引擎读取下一条指令，是一个非常小的内存空间，几乎可以忽略不记。

•**方法区****(****线程共享****)**：类的所有字段和方法字节码，以及一些特殊方法如构造函数，接口代码也在此定义。简单说，所有定义的方法的信息都保存在该区域，静态变量\+常量\+类信息(构造方法/接口定义)+运行时常量池都存在方法区中，虽然Java虚拟机规范把方法区描述为堆的一个逻辑部分，但是它却有一个别名叫做 Non-Heap（非堆），目的应该是与 Java 堆区分开来。

•**Java****栈（线程****私有****）**： Java线程执行方法的内存模型，一个线程对应一个栈，每个方法在执行的同时都会创建一个栈帧（用于存储局部变量表，操作数栈，动态链接，方法出口等信息）**不存在垃圾回收问题**，只要线程一结束该栈就释放，生命周期和线程一致

• JVM对该区域规范了两种异常：

1) 线程请求的栈深度大于虚拟机栈所允许的深度，将抛出StackOverFlowError异常

2) 若虚拟机栈可动态扩展，当无法申请到足够内存空间时将抛出OutOfMemoryError，通过jvm参数–Xss指定栈空间，空间大小决定函数调用的深度

•**实例详解****Java****栈**

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3o3ODU0OTUyOTU_size_27_color_FFFFFF_t_70 1][]

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

HotSpot是使用指针的方式来访问对象

Java堆中会存放访问**类元数据**的地址

reference存储的就直接是对象的地址

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3o3ODU0OTUyOTU_size_27_color_FFFFFF_t_70 2][]

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

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3o3ODU0OTUyOTU_size_27_color_FFFFFF_t_70 3][]

•新生区

类诞生、成长、消亡的区域，一个类在这里产生，应用，最后被垃圾回收器收集，结束生命。

新生区分为两部分： 伊甸区（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后释放的元空间。如果释放的空间少，这个高水位线则上升。如果释放空间过多，则高水位线下降。

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

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

# JVM执行引擎 #

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

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3o3ODU0OTUyOTU_size_27_color_FFFFFF_t_70 4][]

[Java_JVM]: https://blog.csdn.net/z785495295/article/details/83472821
[Java]: https://blog.csdn.net/z785495295/article/details/83473079
[Java_JVM_JVM]: https://blog.csdn.net/z785495295/article/details/83473154
[Java_JVM 1]: https://blog.csdn.net/z785495295/article/details/83473307
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3o3ODU0OTUyOTU_size_27_color_FFFFFF_t_70]: /images/20220503/0fff0dc98dd14703888b6726e616575b.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3o3ODU0OTUyOTU_size_27_color_FFFFFF_t_70 1]: /images/20220503/4e7b0410ad06498588f7f5a005386fa2.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3o3ODU0OTUyOTU_size_27_color_FFFFFF_t_70 2]: /images/20220503/b6070650f6ed401eb265a5db7fa17759.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3o3ODU0OTUyOTU_size_27_color_FFFFFF_t_70 3]: /images/20220503/ecaa8a58606c4857bcb3aad83c12448c.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3o3ODU0OTUyOTU_size_27_color_FFFFFF_t_70 4]: /images/20220503/cb354f670ab042b3b7c583b13cdc7a16.png