关于Jvm类加载机制，这一篇就够了

作者：JAVA架构 2019-12-30 11:25:06

云计算

虚拟化 一个月没更新了，这个月发生了太多的事情，导致更新的频率大大降低，不管怎样收拾心情，技术的研究不能落下!

 前言

一个月没更新了，这个月发生了太多的事情，导致更新的频率大大降低，不管怎样收拾心情，技术的研究不能落下!

什么是jvm

平常我们编写代码都是编写的.java文件，怎么部署到机器上运行呢?通过打jar包或者war包，然后部署运行。

如果看过jar包的内容那么就能知道，我们写的.java文件全部被编译成了.class文件。

这里发生了很重要的一个步骤—— 编译 ：将我们写的程序翻译成能被jvm读懂的文件格式。

值得注意的是，每一个 类 都会被编译成一个.class文件，包括内部类等。也就是说每一个.class文件都只对应我们代码中的一个类。

类的生命周期

类被加载到jvm虚拟机内存开始，到卸载出内存为止，他的生命周期可以分为：加载->验证->准备->解析->初始化->使用->卸载。

下面我们来对此一一说明：

加载

当生成一个jar包以后，我们编写的程序就全部编编译成了jvm能读懂的.class格式。此时就需要加载了，将我们的编译好的.class文件加载到jvm中。此时就会有一个“类加载器”的概念。如下图。

接下来一个问题，类加载器何时会将一个.class加载带jvm?也就是说什么情况下会加载一个类?

一个jar包运行的时候会指定一个main()方法作为入口方法。首先就会将main()方法所在的类加载到jvm，当代码执行遇到new的时候又继续将该对象加载到jvm。

所以总结来说，就是在 你的代码中需要用到这个类的时候 ，就会将其加载到jvm中。

验证

这个不需要理解的太深，很直白的道理，不能什么阿猫阿狗都能被加载到jvm中，要不就乱套了。所以该阶段就是来校验加载进来的.class文件是否符合指定的规则。

有一个很有趣的就是，每个.class文件都很浪漫，因为每一个.class文件都是以8个十六进制的 0×CAFEBABE,翻译过来就是咖啡宝贝。浪漫吧?在验证阶段的第一步就是检查.class文件是否以咖啡宝贝来开头的。

所以我们的流程图可以更新为

准备

当我们合法的把一个.class文件加载到jvm中后，此时就会进行一些准备工作。

首先为这个类分配内存空间，然后为类变量(被static修饰的变量)赋值一个默认的初始值。但是如果类变量同时被final修饰的话，就不是赋值初始值而是 具体的值

用下面两种情况来说明：

public class Student{ 
 private static int age = 18; 
} 
//此时就会为age变量分配内存空间并且为其赋值 0 这个初始值。 
public class Student{ 
 private static final int age = 18; 
} 
//age被final修饰，此时就会为age变量分配内存空间并且为其赋值为 18 。 

所以我们的流程图可以更新为

解析

解析阶段就是jvm将常量池的符号引用替换为直接引用。

简单的来说就是我们编写的代码中，当一个变量引用某个对象的时候，这个引用在.class文件中是以符号引用来存储的。在解析阶段就需要将其解析为直接引用。如果有了直接引用，那引用的目标必定已经在内存中存在。

所以我们的流程图可以更新为

初始化

在准备阶段我们已经为加载到jvm的类分配了内存空间并且为类变量赋予了初始值。

而到了初始化阶段，才真正开始执行类中定义的java程序代码。主要有以下步骤：

1. 为类的静态变量赋予正确的初始值。
2. 执行类的静态代码块。

按照顺序自上而下运行类中的变量赋值语句和静态语句，并且只有类或接口被Java程序首次主动使用时才初始化他们。如果有父类，则首先按照顺序运行父类中的变量赋值语句和静态语句。

所以我们的流程图可以更新为

总结

在一个静态方法中我们是不能直接使用非静态变量的。当我们使用静态方法的时候，仅仅是初始化了静态方法所在的类，此时只有静态变量是被赋了值而非静态变量是没有被赋值的。所以在静态方法中是不能直接使用非静态变量的。