moon不讲武德!!!一个类加载机制给面试官说蒙了！！

目录

• 目录
• 1 前言
• 2 类加载机制
  • 2.1 什么是类加载机制
  • 2.2 案例
  • 2.3 类加载的过程
• 3 类加载器
  • 3.1 什么是类加载器
  • 3.2 双亲委派模型
  • 3.3 破坏双亲委派模型
• 3 结语

1 前言

距离上次发表文章已经一周了，本来是打算早点肝出来的，但是由于不可抗力因素，年终了，需求急剧增加，再加上moon得给自己留出点学习时间，这篇文章也就拖到了现在，羞愧羞愧。

今天我们来聊点基础却又不简单的东西，类加载机制，也是为moon的下一篇文章做个铺垫.

2 类加载机制

2.1 什么是类加载机制

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

2.2 案例

我们先来看一个案例

public class World{
  static{
     System.out.println("hello");
  }
  public static final String WORLD = "world";
}
public class Home extends World{
  static{
     System.ou.println("home");
  }
}
public  class Test{
  public static void main(String[] args){
      System.out.println(Home.word);
  }
}

上面这个代码，究竟会输出什么？答案moon先告诉大家，最后的结果只会输出“world”,但是其中的原因你明白吗？我们接着往下看。

2.3 类加载的过程

这是一张很经典的图，标明了一个类的生命周期，而很多人一眼看过去就以为明白了类的生命周期，但是这只是其中一种情况。

真实情况是加载、验证、准备、初始化、卸载这五个阶段的顺序是确定的，是依次有序的。但是解析阶段有可能会在初始化之后才会进行，这是为了支持java动态绑定的特性。

动态绑定: 在运行时根据具体对象的类型进行绑定。提供了一些机制，可在运行期间判断对象的类型，并分别调用适当的方法。也就是说，编译器此时依然不知道对象的类型，但方法调用机制能自己去调查，找到正确的方法主体。

举个例子：

  class a{
    void test(){};
  }
  class b extends  a{
    void test(){};
  }
  class c {
    main(){
      A a = new B();
      a.test();
    }
  }

上述代码就可以很快的让你理解动态绑定了。

A a = new B();这行代码在编译器的时候程序其实并不知道new B()真正的引用是谁，在执行a.test()时 ，也就是直到运行期间才确定,调用的是子类的test(),其实这就是动态绑定。

《java虚拟机规范》规定，只有以下6种情况才会触发初始化：(以下参考《深入理解java虚拟机》)

• 遇到 new、getstatic、putstatic 或 invokestatic 这 4 条字节码指令；
• 使用 java.lang.reflect 包的方法对类进行反射调用的时候；（这里可能就会出现面试题，反射的缺点是什么）
• 当初始化一个类的时候，发现其父类还没有进行初始化的时候，需要先触发其父类的初始化；
• 当虚拟机启动时，用户需要指定一个要执行的主类，虚拟机会先初始化这个类；
• 当使用 JDK 1.7 的动态语言支持时，如果一个 java.lang.invoke.MethodHandle 实例最后的解析结果 REF_getStatic、REF_putStatic、REF_invokeStatic 的方法句柄，并且这个方法句柄所对应的类没有初始化。
• 使用java8新加入的default默认方法，如果这个接口的实现类发生了初始化，那么该接口要在其之前被初始化。

我们回到刚才的案例，正常来说当我们执行Home.word时，World类就应该已经被加载了，但是关键点在于word这是个静态字段,而且Home这个类是继承了World类，而针对于静态变量，只有直接定义这个字段的类才会被初始化，所以说，如果这个静态变量没有被final修饰，那么正常情况下应该输出“hello”，“world",但是，由于是被final修饰的，就会在编译阶段直接存储在常量池中，最终调用的情况其实是Test类对常量池的引用，这下大家应该明白了。

3 类加载器

3.1 什么是类加载器

实现"通过一个类的全限定名来获取描述该类的二进制流"的动作的代码就叫做类加载器。

简单点来说，就是我知道你的名字后，我能知道你的全部，完成这个操作的就是"类加载器"。

3.2 双亲委派模型

这是一张很经典的图，通常情况下，各个类加载器的协作关系就是这样的。

双亲委派模型：简而言之，就是说一个类加载器收到了类加载的请求，不会自己先加载，而是把它交给自己的父类去加载，层层迭代。

用上图来说明就是如果应用程序类加载器收到了一个类加载的请求，会先给扩展类加载器，然后再给启动类加载器，如果启动类加载器无法完成这个类加载的请求，再返回给扩展类加载器，如果扩展类加载器也无法完成，就返回给应用类加载器。

那么双亲委派模型的好处是什么？说这个问题前我要先和大家说一个概念，jvm中类的唯一性是由类本身和加载这个类的类加载器决定的，简单的说，如果有个a类，如果被两个不同的类加载器加载，那么他们必不相等。你看到这里会不会想到所有类的父类都是Object是怎么实现的了吗？是因为无论哪一个类加载器加载Object类，都会交给最顶层的启动类加载器去加载，这样就保证了Object类在jvm中是唯一的。

3.3 破坏双亲委派模型

当然，不是所有的类加载器都是遵循双亲委派模型的，和大家简单描述一个场景。

我们在最初学习的时候肯定学习过JDBC,其连接数据库的方式其实是通过一个Driver类去实现的，由于原生的JDBC中的类是放在rt.jar包的，是由启动类加载器进行类加载的，且需要动态去加载不同数据库类型的Driver类，而mysql-connector-.jar中的Driver类是用户自己写的代码，所以启动类加载器是不能进行加载的，需要由应用程序类加载器进行加载。此时，通过线程上下文类加载器获得应用程序类加载器，通过应用程序类加载器去加载这个Driver类，从而避开了双亲委派模型的局限性。

3 结语

其实这些东西都是死记硬背的东西，尤其是类加载的过程，其中有很多东西是没有什么值得关注的，只是为了应付面试，但是你需要明白的是为什么会这样设计,设计的好处是什么？

比如：

为什么解析阶段有可能会在初始化阶段后才执行？ 双亲委派模型的好处是什么？为什么会这样设计？ 为什么会出现破坏双亲委派的模型？是解决了什么问题？

大部分人学习一个新知识可能都是死记硬背，加上简单的理解，但是其实代码的世界很多地方都是互通的，要学会提取知识的精华，也就是思想，在自己的知识库中去训练一个模型，当你再学一个新知识的时候，很有可能你就会发现，这个知识，虽然我没有完全了解，但是它的设计思想我以前学过。真实的情况就是这样，尤其是你学到越多的框架，越多的技能，这种感知就会越来越深，一定要学会提炼，提炼，再提炼。