类加载器概念、过程、双亲委派机制、类的主动、被动使用

类加载器作用：
将.class文件加载进内存，但类加载器只进行加载，并不对其可运行性进行判断。

整体过程概述：
加载---->链接---->初始化

整体类加载是为了将.class文件作为类的模板加入内存，作为元数据模板，为后续类的实例化提供模板。

加载：
①通过类的全限定名获取自定义类的二进制字节流（类信息从物理存入内存采用流的形式）
②将该流代表的静态存储结构存入方法区内的运行时数据结构
③针对加载的.class在内存中产生代表该类的java.lang.class对象

链接：
链接分三步：验证 准备 初始化

验证：保证类文件的正确性、安全性（如验证开头为cafebabe）

准备：为类变量（即static修饰）赋初始值（0，false，null）
（此处注意所有final在编译时就已经分配好空间，对其中又被static修饰的在此处进行显式初始化）
对static、final初始化赋值还是不太清楚，就又查了一些：
单独final：编译时申请空间，创建实例时赋值
单独static：准备阶段赋初值，初始化阶段赋值
static final共同修饰：
①String、八大基本类型：在JVM规范中，在初始化阶段再赋值，而在实际的hotspot中是在准备阶段赋值
②其他复杂类同单独static修饰情况

初始化：
调用类构造器方法：() 该方法实际由两部分组成：
①自动收集类中赋值动作
②合并静态代码块（整体按代码顺序执行）

此处有两个方法（在字节码文件中可以看到）：
<clinit>()和<init>()（此处就是final赋值的地方）

注：JVM也给多线程下单个类的()方法加锁，举例：
C类处于一个无限循环情况下，线程A与线程B都去生成类C，假如B先去生成C，而C会卡在无限循环，就会导致线程A无法生产C，整体系统就只有一个C产生。

看这部分需要结合字节码文件查看：
字节码可以用jclasslib查看
反编译在控制台用javap -v xxx.class查看

类加载器介绍：
在JVM规范中，将类加载器分为两类：
①引导类加载器bootstrap，该类加载用c、c++编写，用java无法看到内部结构
②自定义类加载器（如jvm中的扩展类、系统类加载器），该类的类加载器都用java编写，并且都间接继承于ClassLoader接口

接下来对JVM里的几个类加载器介绍一下：
首先类加载器之间并无继承关系，因为类加载器本身也是java类，那么自身也就需要被加载，所以类加载器中的父子关系并不指继承中的父子，而是加载与被加载、每个加载器职能不同的说法。

引导类加载器：最底层的加载器，用于加载java、javax、sun开头的包

扩展类加载器：被引导类加载器加载，用于加载扩展目录下的类

系统类加载器：被扩展类加载器加载，用于加载环境变量下的类和用户自定义类

后续还有由用户自定义的一些类加载器：由系统类加载器加载。

类加载器除了本身加载过程，还有调用时的双亲委派机制：
概念是当用户调用一个类，并不是直接由系统类加载器在自身加载类中查找，而是逐层向上层抛，由最高层在自身加载的类中找，没有再交由下面的加载器查找。

举例说明：用户写一个java.lang包，其中写一个String类，当用户想要调用自己写的String类时，引导类加载器会发现这个java包是由它加载的，那么就会默认调用JAVA本身的String类，而不是用户自己写的String。

双亲委派机制的优点：防止类的重复加载，也保证了内部底层类的安全性

而额外介绍一个加载器（抽象概念）：线程上下文加载器context。
这个加载器的使用环境：
当父CL想要去调用子CL加载的类时，因为双亲委派机制是从下向上递交申请的，就类似引导类CL在加载类时需要扩展类CL中加载的类，因为双亲委派就无法取到，那么JVM中就将当前线程用的加载器保存在contextCL中，当上层需要时，可以调用该上下文加载器进行临时取类。
所以说上下文加载器并不是和上述四类加载器并列的，实际只是将当前线程用的加载器保存起来而已。

类的主动被动使用：
主动引用：即使用的类经过了初始化过程，正常平时实例化、调用其中的静态成员等都是主动引用。
被动引用：即类不经过初始化过程，分为三种情况：
①类数组：如A[] num = new A[5];这个过程并没有将A类进行初始化，只是在内存中依据A类大小申请好了空间。
②引用类中的final static成员（即静态常量）
③父类A中有static成员num，子类B继承于父类但没有num成员，当引用B.num时，实际是在调用父类A中的成员，A类就不会经过初始化阶段