java虚拟机——轻松搞懂jvm

一、JVM体系结构概述

• JVM位置
  
  

• JVM体系结构
  
  

1.1 类加载器 ClassLoader

  类加载器(ClassLoader)负责加载class文件，class文件在文件开头有特定的文件标示，并且ClassLoader只负责class文件的加载，至于它是否可以运行，则由Execution Engine决定。

大致流程图如下图所示：

1.1.1 类加载器的分类

  在java中类加载器共分为两大类，分别是：虚拟机自带的加载器 和 用户自定义加载器。

其中：

虚拟机自带的加载器

• 启动类加载器（Bootstrap）C++

• 扩展类加载器（Extension）Java

• 应用程序类加载器（AppClassLoader）Java（也叫系统类加载器，加载当前应用的classpath的所有类）

用户自定义加载器

• Java.lang.ClassLoader的子类，用户可以定制类的加载方式

1.1.2 类加载器的加载过程

  类加载器对于类的加载有两个机制，分别是：双亲委派机制和砂箱安全机制。

  类加载器加载类的过程如图所示：

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

1.2 本地方法栈

  至于jvm中的本地方法栈，该方法栈是针对native方法来进行压栈的。具体过程为：

  执行native方法的时候需要将native方法压入到本地方法栈，本地方法栈中的方法就需要操作系统来执行，这个时候需要执行引擎Execution Engine 来负责进行解释，然后调用执行本地方法接口(这时会用到本地方法库)。

1.3 程序计数器

程序计数器就是一个小小的指针(是一个非常小的内存空间，几乎可以忽略不记)，通过它来确定执行完一个方法之后再执行下一个方法。其所处位置类似于两节车厢的连接处。

1.4 Execution Engine

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

1.5 方法区 Method Area

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

  静态变量 + 常量 + 类信息(构造方法/接口定义) + 运行时常量池存在方法区中

  但是一定要注意：实例变量存在于堆内存中，和方法区无关。

1.6 栈 Stack

1.6.1 栈是什么

  栈也叫栈内存，主管Java程序的运行，是在线程创建时创建，它的生命期是跟随线程的生命期，线程结束栈内存也就释放，对于栈来说不存在垃圾回收问题，只要线程一结束该栈就Over，生命周期和线程一致，是线程私有的。8种基本类型的变量+对象的引用变量+实例方法都是在函数的栈内存中分配。

1.6.2 栈运行原理

  栈中的数据都是以栈帧（Stack Frame）的格式存在，栈帧是一个内存区块，是一个数据集，是一个有关方法(Method)和运行期数据的数据集，当一个方法A被调用时就产生了一个栈帧 F1，并被压入到栈中，

  A方法又调用了 B方法，于是产生栈帧 F2 也被压入栈，

  B方法又调用了 C方法，于是产生栈帧 F3 也被压入栈，

  ……

  执行完毕后，先弹出F3栈帧，再弹出F2栈帧，再弹出F1栈帧……

  遵循“先进后出”/“后进先出”原则。

1.7 堆（Heap）体系结构

  堆内具体划分得看从逻辑上划分还是从物理上划分。

1.7.1 从逻辑上划分

  堆从逻辑上分为新生区、养老区和永久区。

  其中新生区又分为伊甸园区和幸存者区，幸存区分为幸存0区(from区)和幸存1区(to区)

  大致结构图如下图所示：

  new的对象首先被放到伊甸园区，如果经过垃圾回收这个对象没有被回收掉，那么会把它移动到幸存0区，

  如果再次经过垃圾回收这个对象仍然没有被回收掉，那么这次会把它移动到幸存1区，再垃圾回收，仍然幸存的话，就移动到养老区。

  在养老区之后，就不会被minor GC垃圾回收。

1.7.2 垃圾回收 GC

  垃圾回收分为minor GC 和full GC，其中minor GC针对 Eden区和from区，full GC针对新生区和养老区。

垃圾回收过程：

  新new的对象在伊甸园区(Eden)出生，随着对象越来越多，如果要是放不下的话，会触发轻量级的垃圾回收(minor GC),minor GC会回收Eden区和from区。

  针对Eden区，minor GC垃圾回收后,会将Eden中的幸存者移到to区。

  针对from区，minor GC垃圾回收后,会根据from区中的对象的age来先进行一个判断，如果from中的对象的age<15那么会将该对象移动到to区，如果age>=15就会将该对象移动到养老区，这些对象的age，每移动一次，其age就会加1。

这个时候，Eden区中的幸存对象移动到了to区，from区中age<15的也移动到了to区，然后把Eden区清空，from区也清空，

  然后from和to区交换位置，即from区变成了to区，to区变成了from区。因此：to总为空。

如此不断循环。

  特殊情况：如果new的对象比较大，伊甸园区放不下的话，就会在养老区创建，如果养老区空间也不够的话，直接就报oom了。

  经过不断的minor GC，养老区中的对象会越来越多，如果养老区空间放不下的话，就会触发Full GC，Full GC对新生区和养老区都会进行回收，如果Full GC也回收不了内存的话，就会出现OOM。

产生OOM有两个原因：

（1）Java虚拟机的堆内存设置不够，可以通过参数-Xms、-Xmx来调整。

（2）代码中创建了大量大对象，并且长时间不能被垃圾收集器收集（存在被引用）。

1.7.3 永久区

  永久存储区是一个常驻内存区域，用于存放JDK自身所携带的 Class,Interface 的元数据，也就是说它存储的是运行环境必须的类信息，被装载进此区域的数据是不会被垃圾回收器回收掉的，关闭 JVM 才会释放此区域所占用的内存。

  如果出现java.lang.OutOfMemoryError: PermGen space，说明是Java虚拟机对永久代Perm内存设置不够。一般出现这种情况，都是程序启动需要加载大量的第三方jar包。例如：在一个Tomcat下部署了太多的应用。或者大量动态反射生成的类不断被加载，最终导致Perm区被占满。

Jdk1.6及之前： 有永久代, 常量池1.6在方法区

Jdk1.7： 有永久代，但已经逐步“去永久代”，常量池1.7在堆

Jdk1.8及之后： 无永久代，常量池1.8在元空间

其中1.1.2节参考博文原文链接：https://blog.csdn.net/codeyanbao/article/details/82875064