JVM学习小结1（内存结构与加载器）

JVM生命周期

• 产生：启动一个Java程序时，一个JVM实例就产生了，任何一个拥有public static void main(String[] args)函数的class都可以作为JVM实例运行的起点。
• 运行：main()作为该程序初始线程的起点，任何其他线程均由该线程启动。

Java中的线程分为两种：守护线程 （daemon）和普通线程（non-daemon）。

守护线程是Java虚拟机自己使用的线程，比如负责垃圾收集的线程就是一个守护线程。当然，你也可以把自己的程序设置为守护线程。

包含main()方法的初始线程不是守护线程。

• 消亡：当程序中的所有非守护线程都终止时，JVM才退出，也就是说只要JVM中还有普通的线程在执行，JVM就不会停止；若安全管理器允许，程序也可以使用Runtime类或者System.exit()来退出。

一个运行中的Java虚拟机有着一个清晰的任务：执行Java程序。程序开始执行时他才运行，程序结束时他就停止。你在同一台机器上运行三个程序，就会有三个运行中的Java虚拟机。 Java虚拟机总是开始于一个main()方法，这个方法必须是公有、返回void、直接受一个字符串数组。在程序执行时，你必须给Java虚拟机指明这个包换main()方法的类名。main()方法是程序的起点，他被执行的线程初始化为程序的初始线程。程序中其他的线程都由他来启动。

Java文件的运行流程

Java 源文件，通过编译器，能够生产相应的.Class 文件，也就是字节码文件，字节码文件又通过Java 虚拟机中的解释器，编译成特定机器上的机器码 。

Java 源文件——>编译器——>字节码文件——>JVM——>机器码

每一种平台的解释器是不同的，但是实现的虚拟机是相同的，这也就是Java 为什么能够跨平台的原因了 ，当一个程序开始运行，就进入了JVM的生命周期。

粗略分来，JVM的内部体系结构分为三部分，分别是：类装载器，运行时数据区，和执行引擎。

运行时数据区即JVM的内存结构

Java虚拟机所管理的内存区域：堆(Heap)，方法区(Method Area)，虚拟机栈(VM Stack)，本地方法栈(Native Method Stack)，程序计数器(Program Counter Register)，直接内存(Direct Memory)。

堆(Heap)

是虚拟机管理内存中最大的一部分，被所有线程共享，用于存放对象实例(对象、数组)，在虚拟机启动时创建。物理上不连续的内存空间，由于GC收集器，分代收集，所以划分为：新生代（YoungGeneration）和老年代（OldGeneration）。新生代又可能会划分出多个线程私有的缓冲区，例如eden、From Survivor、To Survivor。此内存区域的唯一目的就是存放对象实例，几乎所有的对象实例都在这里分配内存。

其中新声带存放新生的对象或者年龄不大的对象，老年代则存放老年对象。绝大多数情况下，对象首先分配在eden区，在新生代回收后，如果对象还存活，则进入新生代的其他区，之后每经过一次新生代回收，如果对象存活则它的年龄就加1，对象达到一定的年龄后，则进入老年代。

虚拟机栈(VM Stack)

虚拟机栈也是每个线程私有的一块内存空间，它描述的是方法的内存模型。

虚拟机会为每个线程分配一个虚拟机栈，每个虚拟机栈中都有若干个栈帧，栈帧用于存储：局部变量表、操作数栈、动态链接、返回地址等，每个线程的执行都对应了虚拟机栈帧从入栈到出栈的过程。一个栈帧就对应Java代码中的一个方法，当线程执行到一个方法时，就代表这个方法对应的栈帧已经进入虚拟机栈并且处于栈顶的位置，每一个Java方法从被调用到执行结束，就对应了一个栈帧从入栈到出栈的过程。

虚拟机栈是一种数据结构，是虚拟机中的局部变量表，对应物理层之上的程序数据模型。

局部变量表，是一种程序运行数据模型，存放了编译期可知的各种数据类型例如：Boolean、byte、char、short、int、float、long、double、对象引用类型(对象内存地址变量，指针或句柄)，程序运行时，根据局部变量表分配栈帧空间大小，在运行中，大小是不变的异常类型：stackOverFlowError 线程请求栈深度大于虚拟机允许深度 OutOfMemory 内存空间耗尽无法进行扩展。

本地方法栈(Native Method Stack)

本地方法栈与虚拟机栈所发挥的作用是非常相似的，本地方法栈支持虚拟机的运行服务，具体实现由虚拟机厂商决定，也会抛出 stackOverFlowError、OutOfMemory异常。其区别只不过是虚拟机栈为虚拟机执行Java方法（也就是字节码）服务，而本地方法栈则是为虚拟机使用到的本地方法（Native Method）服务。

程序计数器(Program Counter Register)

程序计数器是一块非常小的内存空间，可以看做是当前线程执行字节码的行号指示器，字节码指令的分支、循环、跳转、异常处理、线程恢复(CPU切换)。每个线程都有一个独立的程序计数器，因此程序计数器是线程私有的一块空间；同时程序计数器也是Java虚拟机规定的唯一不会发生内存溢出的区域（在Java虚拟机规范中没有规定任何OutOfMemoryError情况的区域）。

方法区(Method Area)

HotSpot VM，是Sun JDK和OpenJDK中所带的虚拟机，也是目前使用范围最广的Java虚拟机。

与Java堆一样，是各个线程共享的内存区域，用于存储虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码（动态加载OSGI）等数据。是一种JVM规范。

方法区可以选择不进行垃圾回收，该区域回收目的主要是常量池的回收。常量池是方法区的一部分，Class的版本、字段、接口、方法等，及编译期生成的各种字面量、符号引用，编译类加载后存放在该区域，内存不足时会抛出OutOfMemory异常

永久代(PermGen)

在JDK1.7及其之前，方法区是堆的一个“逻辑部分”（一片连续的堆空间），但为了与堆做区分，方法区还有个名字叫“非堆（Non-Heap）”，也可用“永久代”，来表示方法区。

永久代：JDK1.7以前HotSpot对方法区的实现方法。在JVM内存中开辟区域用于实现方法区的功能。

JDK1.7以前，HotSpot虚拟机使用永久代来实现方法区，永久代的大小在启动JVM的时候可以设置一个固定值（-XX:MaxPermSize），并且设置好后大小不可变。

JDK1.7中，存储在永久代的部分数据就已经转移到堆（Heap）或者本地内存（Native memory）。譬如符号引用（Symbols）转移到了本地内存，原本存放在永久代的字符常量池移出。但永久代仍存在于JDK 1.7中，并没有完全移除。

元数据区(MetaSpace)

在JDK1.8中，元数据区取代了1.7版本及以前的永久代，和永久代类似，元数据区(MetaSpace)也是JVM规范对方法区的实现，存放虚拟机加载的类信息，静态变量，常量等数据。元空间使用本地内存，元空间的大小仅受本地内存限制，可以通过-XX:MetaspaceSize和-XX:MaxMetaspaceSize来指定元空间的大小。

-XX:MaxMetaspaceSize：最大空间默认没有限制。

-XX:MetaspaceSize：初始空间大小，达到该值就会触发垃圾收集进行类型卸载，同时GC会对该值进行调整；如果释放了大量的空间，就适当降低该值；如果释放了很少的空间，那么在不超过MaxMetaspaceSize时，适当提高该值。

两种实现方式的区别，以及去永生代的原因

Metaspace与PermGen最大的区别在于：PermGen在虚拟机中，元空间在本地内存中。

• 字符串存在永久代中，容易出现性能问题和内存溢出。
• 类及方法的信息等比较难确定其大小，因此对于永久代的大小指定比较困难，太小容易出现永久代溢出，太大则容易导致老年代溢出。
• 永久代会为 GC 带来不必要的复杂度，并且回收效率偏低。

运行时常量池(Runtime Constant Pool)

方法区的一部分(虚拟机规范)。 Class文件中除了有类的版本, 字段,方法, 接口等描述信息外, 还有一项信息是常量池(Constant Pool Table), 用于存放编译期生成的各种字面量和符号引用, 这部分内容将在类加载后存放到方法区的运行时常量池中。

运行时常量池相对于Class文件常量池的另外一个重要特征是具备动态性, Java语言并不要求常量一定只能在编译期产生, 也就是并非预置入Class文件中常量池的内容才能进入方法区运行时常量池, 运行期间也可能将新的常量放入池中, 这种特性被开发人员利用的比较多的便是String类的intern() 方法。

直接内存(Direct Memory)

在JDK1.4中新加入的NIO类，引入了一种基于通道（Channel）和缓冲区（Buffer）的I/O 形式，他可以使用本地函数（Native函数）直接分配堆外内存，然后通过一个存储在Java 堆中的DirectByteBuffer对象作为这块内存的引用进行操作。这样能在一些场所显著提高性能，因为避免了在Java堆和Native堆中来回复制数据。

直接内存(Direct Memory) 并不是虚拟机运行时数据区的一部分，也不是Java虚拟机规范中定义的内存区域，但是这部分内存也被频繁地使用，而且也可能导致OutOfMemoryError异常出现。显然，本机直接内存的分配不会受到Java堆大小的限制，但是，既然是内存，则肯定还是会受到本机总内存的大小及处理器寻址空间的限制。服务器管理员配置虚拟机参数时，一般会根据实际内存-Xmx等参数信息，但经常会忽略到直接内存，使得各个内存区域的总和大于物理内存限制(包括物理上的和操作系统级的限制)，从而导致动态扩展时出现OutOfMemoryError异常。

类的加载机制

JVM的加载机制：JVM把描述类的数据从Class文件加载到内存，并对数据进行校验、转换解析和初始化，最终形成可以被虚拟机直接使用的Java类型。

类的生命周期

类从被加载到虚拟机内存中开始，到卸载出内存为止，它的整个生命周期包括了：加载（Loading）、验证（Verification）、准备（Preparation）、解析（Resolution）、初始化（Initialization）、使用（using）、和卸载（Unloading）七个阶段。其中验证、准备和解析三个部分统称为连接（Linking）。

加载

类的装载过程是：第一步将类的.class文件中的二进制数据读入到内存中，将其放在方法区内；第二步将字节流所代表的静态存储结构转化为方法区的运行时存储结构；第三步在堆区创建这个类的java.lang.Class对象，用来封装类在方法区内的数据结构，作为程序访问方法区中这个类的外部接口。

类的加载的最终产品是位于堆区中的Class对象，Class对象封装了类在方法区内的数据结构，并且提供了访问方法区内的数据结构的接口。

加载.class文件的方式有：

• 从本地系统中直接加载

• 通过网络下载.class文件

• 从zip，jar等归档文件中加载.class文件

• 从专有数据库中提取.class文件

• 将Java源文件动态编译为.class文件

加载阶段完成后，虚拟机外部的 二进制字节流就按照虚拟机所需的格式存储在方法区之中，而且在Java堆中也创建一个java.lang.Class类的对象，这样便可以通过该对象访问方法区中的这些数据。

验证

验证的目的是为了确保class文件的字节流包含的内容符合虚拟机的要求，且不会危害虚拟机的安全。大致都会经过以下四个阶段的验证：文件格式的验证、元数据的验证、字节码验证和符号引用验证。

• 文件格式验证：验证字节流是否符合Class文件格式的规范，并且能被当前版本的虚拟机处理，该验证的主要目的是保证输入的字节流能正确地解析并存储于方法区之内。经过该阶段的验证后，字节流才会进入内存的方法区中进行存储。
• 元数据验证：主要对字节码描述的信息进行语义分析，保证其符合Java语言规范，保证不存在不符合Java语法规范的元数据信息 ，比如验证这个类是否有父类（java.lang.Object除外），如果这个类不是抽象类，是否实现了父类或接口中没有实现的方法，等等。
• 字节码验证：字节码验证更为高级，进行数据流和控制流分析，对类的方法体进行校验分析，确保程序是合法的、符合逻辑的以及保证被校验的类的方法在运行时不会做出危害虚拟机安全的行为。
• 符号引用验证：发生在虚拟机将符号引用转化为直接引用的时候，对类自身以外的信息进行匹配性校验。比如通过类名或类的字段名/方法名能否找到对应类、在类中能否找到字段名/方法名对应的字段/方法，如果符号引用验证失败，抛出异常。

准备

正式为类变量分配内存并设置类变量初始值，这些内存都将在方法区中进行分配。

• 这时候进行内存分配的仅包括类变量（static），而不包括实例变量，实例变量会在对象实例化时随着对象一块分配在Java堆中。

• 这里所设置的初始值通常情况下是数据类型默认的零值（如0、0L、null、false等），而不是被在Java代码中被显式地赋予的值。

准备阶段是正式为类变量分配内存并设置类变量的初始值阶段，即在方法区中分配这些变量所使用的内存空间。

注意这里所说的初始值概念，比如一个类变量定义为：

public static int v = 8080;

实际上变量v在准备阶段过后的初始值为0而不是8080。

public static final int v = 8080;

final会为v生成ConstantValue属性，虚拟机会根据ConstantValue属性将v赋值为8080。

解析

解析阶段是指虚拟机将常量池中的符号引用替换为直接引用的过程。

**符号引用：**以一组符号来描述所引用的目标，符号引用与虚拟机实现的内存布局无关，引用的目标不一定已经加载到内存中。各种虚拟机实现的内存布局可以各不相同，但是它们能接受的符号引用必须是一致的，因为符号引用的字面量形式明确定义在Java虚拟机规范的Class文件格式中。

例如：在com.danny.framework.LoggerFactory类引用了com.danny.framework.Logger，但在编译期间是不知道Logger类的内存地址的，所以只能先用com.danny.framework.Logger（假设是这个，实际上是由类似于CONSTANT_Class_info的常量来表示的）来表示Logger类的地址，这就是符号引用。

**直接引用：**可以是指向目标的指针，可以是相对偏移量或是一个能间接定位到目标的句柄。和虚拟机实现的内存布局有关，如果有了直接引用，那引用的目标必定已经在内存中存在。

解析的时候class已经被加载到方法区的内存中，因此要把符号引用转化为直接引用，也就是能直接找到该类实际内存地址的引用。

• 类或接口的解析：判断所要转化成的直接引用是对数组类型，还是普通的对象类型的引用，从而进行不同的解析。

• 字段解析：对字段进行解析时，会先在本类中查找是否包含有简单名称和字段描述符都与目标相匹配的字段，如果有，则查找结束；如果没有，则会按照继承关系从上往下递归搜索该类所实现的各个接口和它们的父接口，还没有，则按照继承关系从上往下递归搜索其父类，直至查找结束。

• 类方法解析：对类方法的解析与对字段解析的搜索步骤差不多，只是多了判断该方法所处的是类还是接口的步骤，而且对类方法的匹配搜索，是先搜索父类，再搜索接口。

• 接口方法解析：与类方法解析步骤类似，只是接口不会有父类，因此，只递归向上搜索父接口就行了。

初始化

初始化阶段是类加载最后一个阶段，前面的类加载阶段之后，除了在加载阶段可以自定义类加载器以外，其它操作都由JVM主导。到了初始化阶段，才开始真正执行类中定义的Java程序代码。初始化阶段是执行类构造器方法的过程。

<client>方法是由编译器自动收集类中的类变量的赋值操作和静态语句块中的语句合并而成的。

注意：只有赋值操作和静态语句块会在初始化阶段执行。

虚拟机会保证子类的方法执行之前，父类的方法已经执行完毕。如果一个类中没有对静态变量赋值也没有静态语句块，那么编译器可以不为这个类生成()方法。

类的6种主动引用（一定会发生类的初始化）：

1.创建类的实例，也就是new的方式

2.访问某个类或接口的静态变量，或者对该静态变量赋值

3.调用类的静态方法

4.反射（如Class.forName(“com.shengsiyuan.Test”)）

5.初始化某个类的子类，则其父类也会被初始化

6.Java虚拟机启动时被标明为启动类的类（Java Test），直接使用java.exe命令来运行某个主类

注意以下几种情况不会执行类初始化：

• 通过子类引用父类的静态字段，只会触发父类的初始化，而不会触发子类的初始化。
• 调取final修饰的静态成员或者静态方法。
• 定义对象数组，不会触发该类的初始化。 A[] as = new A[10];
• 常量在编译期间会存入调用类的常量池中，本质上并没有直接引用定义常量的类，不会触发定义常量所在的类。
• 通过类名获取Class对象，不会触发类的初始化。
• 通过Class.forName加载指定类时，如果指定参数initialize为false时，也不会触发类初始化，其实这个参数是告诉虚拟机，是否要对类进行初始化。
• 通过ClassLoader默认的loadClass方法，也不会触发初始化动作。

使用

new出对象使用就是了，(ﾋ•ω•ﾏ)/禁止抬杠

卸载

在以下情况的时候，Java虚拟机会结束生命周期

• 执行了System.exit()方法
• 程序正常执行结束
• 程序在执行过程中遇到了异常或错误而异常终止
• 由于操作系统出现错误而导致Java虚拟机进程终止

类的加载器

作用

（1）加载class：类加载的加载阶段的第一个步骤，就是通过类加载器来完成的，类加载器的主要任务就是“通过一个类的全限定名来获取描述此类的二进制字节流”，在这里加载.class文件的方式有很多，在上面有描述。也就是类加载器动态加载class文件到虚拟机中，并生成一个java.lang.Class实例，每个实例都代表一个java类，可以根据该实例得到该类的信息，还可以通过newInstance()方法生成该类的一个对象。

（2）确定类的唯一性：对于每一个类，都需要由加载它的加载器和这个类本身共同确立这个类在Java虚拟机中的唯一性。也就是说，两个相同的类，只有是在同一个加载器加载的情况下才“相等”，这里的“相等”是指代表类的Class对象的equals()方法、isAssignableFrom()方法、isInstance()方法的返回结果，也包括instanceof关键字对对象所属关系的判定结果。

分类

类加载器分为如下几种：启动类加载器（Bootstrap ClassLoader）、扩展类加载器（Extension ClassLoader）、应用程序类加载器（Application ClassLoader）和自定义类加载器（User ClassLoader），其中启动类加载器属于JVM的一部分，其他类加载器都由java实现，并且最终都继承自java.lang.ClassLoader。

① 启动类加载器（Bootstrap ClassLoader）：由C/C++编译而来的，看不到源码，主要负责加载JAVA_HOME\lib目录或者被-Xbootclasspath参数指定目录中的能被虚拟机识别的类，具体加载哪些类可以通过

“System.getProperty(“sun.boot.class.path”)”

来查看。

② 扩展类加载器（Extension ClassLoader）：sun.misc.Launcher.ExtClassLoader实现，负责加载JAVA_HOME\lib\ext目录或者被java.ext.dirs系统变量指定的路径中的所有类库，可以用通过

“System.getProperty(“java.ext.dirs”)”

来查看具体都加载哪些类。

③ 应用程序类加载器（Application ClassLoader）：sun.misc.Launcher.AppClassLoader实现，负责加载用户类路径（我们通常指定的classpath）上的类，如果程序中没有自定义类加载器，应用程序类加载器就是程序默认的类加载器。

④ 自定义类加载器（User ClassLoader）：JVM提供的类加载器只能加载指定目录的类（jar和class），如果我们想从其他地方甚至网络上获取class文件，就需要自定义类加载器来实现，自定义类加载器主要都是通过继承ClassLoader或者它的子类来实现，但无论是通过继承ClassLoader还是它的子类，最终自定义类加载器的父加载器都是应用程序类加载器，因为不管调用哪个父类加载器，创建的对象都必须最终调用java.lang.ClassLoader.getSystemClassLoader()作为父加载器，getSystemClassLoader()方法的返回值是sun.misc.Launcher.AppClassLoader即应用程序类加载器。

类加载机制

• 全盘负责：当一个类加载器负责加载某个Class时，该Class所依赖和引用的其他Class也将由该类加载器负责载入，除非显示使用另外一个类加载器来载入
• 双亲委派：先让父类加载器试图加载该类，只有在父类加载器无法加载该类时，才尝试从自己的路径中加载该类。通俗的讲，就是某个特定的类加载器在接到加载类的请求时，首先将加载任务委托给父加载器，依次递归，如果父加载器可以完成类加载任务，就成功返回；只有父加载器无法完成此加载任务时，才自己去加载。
• 缓存机制：缓存机制将会保证所有加载过的Class都会被缓存，当程序中需要使用某个Class时候，类加载器先在缓存区中去寻找该Class，只有缓存区不存在该Class对象时，系统才会读取该类对应的二进制数据，并将其转换为Class对象，存入缓存区。这就是为什么修改了Class后，必须重启JVM，程序的修改才会生效的原因。

双亲委派机制的优势

• Java类随着它的类加载器一起具备了一种带有优先级的层次关系，通过这种层级关系可以避免类的重复加载，当父亲已经加载了该类时，就没有必要子加载器再加载一次。
• 考虑到安全因素，java核心api中定义类型不会被随意替换，假设通过网络传递一个名为java.lang.Integer的类，通过双亲委托模式传递到启动类加载器，而启动类加载器在核心Java API发现这个名字的类，发现该类已被加载，并不会重新加载网络传递的过来的java.lang.Integer，而直接返回已加载过的Integer.class，这样便可以防止核心API库被随意篡改。

加载器加载Class的一般过程

1.检测此Class是否载入过，即在缓冲区中是否有此Class，如果有直接进入第8步，否则进入第2步。

2.如果没有父类加载器，本身就是根类加载器，则跳到第4步，如果有父类加载器存在，则进入第3步。

3.请求使用父类加载器去载入目标类，如果载入成功则跳至第8步，否则接着执行第5步。

4.请求使用根类加载器去载入目标类，如果载入成功则跳至第8步，否则跳至第7步。

5.当前类加载器尝试寻找Class文件，如果找到则执行第6步，如果找不到则执行第7步。

6.从文件中载入Class，成功后跳至第8步。

7.抛出ClassNotFountException异常。

8.返回对应的java.lang.Class对象。

可参考博文：

【1】JVM内存结构

【2】jvm之java类加载机制和类加载器(ClassLoader)的详解

【3】JVM知识点总结