Github issues:https://github.com/littlejoyo/Blog/issues/
微信公众号：Joyo说
JVM的内容是面试的重点内容，常见的重点内容集中于：类加载机制的理解以及JVM垃圾回收机制的理解，这里先介绍一下JVM的类加载机制，总结一下类加载机制的过程。
一、类加载过程
JVM类加载分为下面几个个过程：加载，验证，准备，解析，初始化，使用，卸载，如下图所示：
主要是理解好加载、验证、准备、解析、初始化这5个过程以及对应的作用。
1.1加载
加载主要是将.class文件（并不一定是.class。可以是ZIP包，网络中获取）中的二进制字节流读入到JVM中。
在加载阶段，JVM需要完成3件事：
1）通过类的全限定名获取该类的二进制字节流；
2）将字节流所代表的静态存储结构转化为方法区的运行时数据结构；
3）在内存中生成一个该类的java.lang.Class对象，作为方法区这个类的各种数据的访问入口。
1.2连接
1.2.1 验证
验证是连接阶段的第一步，主要确保加载进来的字节流符合JVM规范。
验证阶段会完成以下4个阶段的检验动作：
1）文件格式验证
2）元数据验证(是否符合Java语言规范)
3）字节码验证（确定程序语义合法，符合逻辑）
4）符号引用验证（确保下一步的解析能正常执行）
1.2.2 准备
准备是连接阶段的第二步，主要为静态变量在方法区分配内存，并设置默认初始值。
1.2.3 解析
解析是连接阶段的第三步，是虚拟机将常量池内的符号引用替换为直接引用的过程。
1.3初始化
初始化阶段是类加载过程的最后一步，主要是根据程序中的赋值语句主动为类变量赋值。
注：
1）当有父类且父类为初始化的时候，先去初始化父类；
2）再进行子类初始化语句。
什么时候需要对类进行初始化？
1）使用new该类实例化对象的时候；
2）读取或设置类静态字段的时候（但被final修饰的字段，在编译器时就被放入常量池的静态字段除外static final）；
3）调用类静态方法的时候；
4）使用反射Class.forName(“xxxx”)对类进行反射调用的时候，该类需要初始化；
5） 初始化一个类的时候，有父类，先初始化父类（注：1. 接口除外，父接口在调用的时候才会被初始化；2.子类引用父类静态字段，只会引发父类初始化）；
6） 被标明为启动类的类（即包含main()方法的类）要初始化；
2.举例验证
2.1通过一道代码实例题了解类加载过程
class Singleton1{
private static Singleton1 singleton1 = new Singleton1();
public static int value1;
public static int value2 = 0;
private Singleton1(){
value1++;
value2++;
}
public static Singleton1 getInstance(){
return singleton;
}
}
class Singleton2{
public static int value1;
public static int value2 = 0;
private static Singleton2 singleton2 = new Singleton2();
private Singleton2(){
value1++;
value2++;
}
public static Singleton2 getInstance2(){
return singleton2;
}
}
public static void main(String[] args) {
Singleton1 singleton = Singleton1.getInstance();
System.out.println("Singleton1 value1:" + singleton.value1);
System.out.println("Singleton1 value2:" + singleton.value2);
Singleton2 singleton2 = Singleton2.getInstance2();
System.out.println("Singleton2 value1:" + singleton2.value1);
System.out.println("Singleton2 value2:" + singleton2.value2);
}
上面两个单例类主要的区别就是创建实例语句的放置位置的不同，这里会涉及到初始化操作对value值的影响。解析前先看输出的结果是怎样的？
输出结果：
Singleton1 value1 : 1
Singleton1 value2 : 0
Singleton2 value1 : 1
Singleton2 value2 : 1
2.2解析
Singleton输出结果：1 0
1 首先执行main中的Singleton singleton = Singleton.getInstance();
2 类的加载：加载类Singleton
3 类的验证
4 类的准备：为静态变量分配内存，设置默认值。这里为singleton(引用类型)设置为null,value1,value2（基本数据类型）设置默认值0
5 类的初始化（按照赋值语句进行修改）：
执行private static Singleton singleton = new Singleton();
执行Singleton的构造器：value1++;value2++; 此时value1，value2均等于1
执行
public static int value1;
public static int value2 = 0;
此时value1=1，value2=0
Singleton2输出结果：1 1
1 首先执行main中的Singleton2 singleton2 = Singleton2.getInstance2();
2 类的加载：加载类Singleton2
3 类的验证
4 类的准备：为静态变量分配内存，设置默认值。这里为value1,value2（基本数据类型）设置默认值0,singleton2(引用类型)设置为null,
5 类的初始化（按照赋值语句进行修改）：
执行
public static int value2 = 0;
此时value2=0(value1不变，依然是0);
执行
private static Singleton singleton = new Singleton();
执行Singleton2的构造器：value1++;value2++;
此时value1，value2均等于1,即为最后结果
二、类加载器与双亲委派模型
一开始我一直很难理解为什么要叫做双亲委派，后来才发现这只是翻译过来约定俗成的说法罢了，Parent翻译成了双亲。
类加载器实现的功能是即为加载阶段获取二进制字节流的时候。
JVM提供了以下3种系统的类加载器：
- 启动类加载器（Bootstrap ClassLoader）：最顶层的类加载器，负责加载 JAVA_HOME\lib 目录中的，或通过-Xbootclasspath参数指定路径中的，且被虚拟机认可（按文件名识别，如rt.jar）的类。
- 扩展类加载器(Extension ClassLoader)：负责加载 JAVA_HOME\lib\ext 目录中的，或通过java.ext.dirs系统变量指定路径中的类库。
- 应用程序类加载器(Application ClassLoader)：也叫做系统类加载器，可以通过getSystemClassLoader()获取，负责加载用户路径（classpath）上的类库。如果没有自定义类加载器，一般这个就是默认的类加载器。
类加载器之间的层次关系：
双亲委派模型要求除了顶层的启动类加载器（Bootstrap ClassLoader）外，其余的类加载器都应当有自己的父类加载器。这里的类加载器之间的父子关系一般不是以继承关系实现的，而是用组合实现的。
底层的类加载器可以通过getSystemClassLoader()方法来获取到父类的类加载器，但是最顶层无法执行这个方法，因为启动类加载器是由C++语言设计的，没有提供该方法。
双亲委派模型的工作过程
如果一个类接受到类加载请求，他自己不会去加载这个请求，而是将这个类加载请求委派给父类加载器，这样一层一层传送，直到到达启动类加载器（Bootstrap ClassLoader）。 只有当父类加载器无法加载这个请求时，子加载器才会尝试自己去加载。
双亲委派模型的作用
防止不可信任的类被当做可信类，保证了程序的安全性。
双亲委派模型的代码实现
双亲委派模型的代码实现集中在java.lang.ClassLoader的loadClass()方法当中。
1）首先检查类是否被加载，没有则调用父类加载器的loadClass()方法；
2）若父类加载器为空，则默认使用启动类加载器作为父加载器；
3）若父类加载失败，抛出ClassNotFoundException 异常后，再调用自己的findClass() 方法。
loadClass源代码如下：
protected synchronized Class<?> loadClass(String name, boolean resolve) throws ClassNotFoundException {
//1 首先检查类是否被加载
Class c = findLoadedClass(name);
if (c == null) {
try {
if (parent != null) {
//2 没有则调用父类加载器的loadClass()方法；
c = parent.loadClass(name, false);
} else {
//3 若父类加载器为空，则默认使用启动类加载器作为父加载器；
c = findBootstrapClass0(name);
}
} catch (ClassNotFoundException e) {
//4 若父类加载失败，抛出ClassNotFoundException 异常后
c = findClass(name);
}
}
if (resolve) {
//5 再调用自己的findClass() 方法。
resolveClass(c);
}
return c;
}
findClass（）用于写类加载逻辑、loadClass（）方法的逻辑里如果父类加载器加载失败则会调用自己的findClass（）方法完成加载，保证了双亲委派规则。
1、如果不想打破双亲委派模型，那么只需要重写findClass方法即可
2、如果想打破双亲委派模型，那么就重写整个loadClass方法
破坏双亲委派模型的情况
双亲委派模型很好的解决了各个类加载器加载基础类的统一性问题。即越基础的类由越上层的加载器进行加载。
若加载的基础类中需要回调用户代码，而这时顶层的类加载器无法识别这些用户代码，怎么办呢？这时就需要破坏双亲委派模型了。
下面介绍两个例子来讲解破坏双亲委派模型的过程。
JNDI破坏双亲委派模型
JNDI是Java标准服务，它的代码由启动类加载器去加载。但是JNDI需要回调独立厂商实现的代码，而类加载器无法识别这些回调代码（SPI）。
为了解决这个问题，引入了一个线程上下文类加载器。 可通过Thread.setContextClassLoader()设置。
利用线程上下文类加载器去加载所需要的SPI代码，即父类加载器请求子类加载器去完成类加载的过程，而破坏了双亲委派模型。Spring破坏双亲委派模型
Spring要对用户程序进行组织和管理，而用户程序一般放在WEB-INF目录下，由WebAppClassLoader类加载器加载，而Spring由Common类加载器或Shared类加载器加载。
那么Spring是如何访问WEB-INF下的用户程序呢？
使用线程上下文类加载器。 Spring加载类所用的classLoader都是通过Thread.currentThread().getContextClassLoader()获取的。当线程创建时会默认创建一个AppClassLoader类加载器（对应Tomcat中的WebAppclassLoader类加载器）： setContextClassLoader(AppClassLoader)。
利用这个来加载用户程序。即任何一个线程都可通过getContextClassLoader()获取到WebAppclassLoader。
Tomcat目录下有4组目录：
- /common目录下：类库可以被Tomcat和Web应用程序共同使用；由 Common ClassLoader类加载器加载目录下的类库；
- /server目录：类库只能被Tomcat可见；由 Catalina ClassLoader类加载器加载目录下的类库；
- /shared目录：类库对所有Web应用程序可见，但对Tomcat不可见；由 Shared ClassLoader类加载器加载目录下的类库；
- /WebApp/WEB-INF目录：仅仅对当前web应用程序可见。由 WebApp ClassLoader类加载器加载目录下的类库；
- 每一个JSP文件对应一个JSP类加载器。
文章参考来源：https://blog.csdn.net/noaman_wgs/article/details/74489549?
微信公众号
扫一扫关注Joyo说公众号，共同学习和研究开发技术。
