Invoke {@link #findLoadedClass(String)} to check if the class * has already been loaded.
Invoke the {@link #loadClass(String) loadClass} method * on the parent class loader. If the parent is null the class * loader built-in to the virtual machine is used, instead.
Invoke the {@link #findClass(String)} method to find the * class.
If the class was found using the above steps, and the * resolve flag is true, this method will then invoke the {@link * #resolveClass(Class)} method on the resulting Class object. * *
Subclasses of ClassLoader are encouraged to override {@link * #findClass(String)}, rather than this method.
* * Unless overridden, this method synchronizes on the result of
* {@link #getClassLoadingLock getClassLoadingLock} method
* during the entire class loading process.
*
* @param name
* The binary name of the class
*
* @param resolve
* If true then resolve the class
*
* @return The resulting Class object
*
* @throws ClassNotFoundException
* If the class could not be found
*/
protected Class loadClass(String name, boolean resolve)
throws ClassNotFoundException
{
synchronized (getClassLoadingLock(name)) {
// First, check if the class has already been loaded
// c就是要加载的类，这里会首先试图查找这个类是否已经被加载过
Class c = findLoadedClass(name);
if (c == null) {
long t0 = System.nanoTime();
try {
if (parent != null) {
//当父类不为Null的时候就继续委托，注意这里是一个递归
c = parent.loadClass(name, false);
} else {
c = findBootstrapClassOrNull(name);
}
} catch (ClassNotFoundException e) {
// ClassNotFoundException thrown if class not found
// from the non-null parent class loader
}
if (c == null) {
// If still not found, then invoke findClass in order
// to find the class.
long t1 = System.nanoTime();
// findClass这个方法就相当于我们调用readClassFile读取二进制流
c = findClass(name);
// this is the defining class loader; record the stats
sun.misc.PerfCounter.getParentDelegationTime().addTime(t1 - t0);
sun.misc.PerfCounter.getFindClassTime().addElapsedTimeFrom(t1);
sun.misc.PerfCounter.getFindClasses().increment();
}
}
if (resolve) {
resolveClass(c);
}
return c;
}
}
```
我们可以简单的阅读一下JRE中的源码，其中比较关键的部分已经用中文注释标注出来了，阅读这个代码应该能够帮助理解。**我们也非常鼓励同学能够自己尝试阅读源码**，去看看官方是如何实现的(~~然后你就会知道助教有多菜~~)，对这个loadClass方法的阅读我们助教也是先查看注释，注释中给出了关键信息line8-line16，这就很快的帮助我们理解了具体是怎么样的执行流程，在没有更好的实现之前，官方的写法也是非常好的学习模板。
### 1.2 Defining & Initiating
在有了对双亲加载机制的一定了解之后，让我们来看看规范中的细节。因为每一个类加载器都非常的懒，它们会优先让自己的父类去完成搜索。那么可以肯定的是，最后一定有一个类加载器在它自己的搜索空间中找到的对应的类，这个时候最初进行委托的加载器被称为Initiating loader，而最终找到的加载器被称为defining loader。
摘一段原文，这里的L是指loader，C是要被加载的类，还有个D(这里没出现)是指引用C的类。含义是D中出现了C(不一定是显式的出现)，C如果没有被加载，那么就通过L加载C。
> If `L` creates C directly, we say that `L` *defines* C or, equivalently, that `L` is the *defining loader* of C
>
> When one class loader delegates to another class loader, the loader that initiates the loading is not necessarily the same loader that completes the loading and defines the class. If `L` creates C, either by defining it directly or by delegation, we say that `L` initiates loading of C or, equivalently, that `L` is an *initiating loader* of C
从我的解读来看，defining loader和initiating loader的概念并不绝对，它们是根据出现场景不同而有不同的名字。例如，假设D的defining loader是L1，那么C被加载时也会首先去试图让L1来加载，但是由于双亲加载机制的存在，最终加载C的加载器也许是L2，那么可以说L1是D的initiating loader，L2是D的defining loader。
设置这两个概念的意义是支持双亲加载机制，当一个类的defining loader越接近上层，即越接近bootstrap loader，对应可搜索空间越少，这也就杜绝了java/lang/Object去调用你写的某个类的情况出现。
在实验中，在JClass中有一个loadEntryType，这对应了defining loader的含义。(在对规范的解读中并没有看出保留initiating loader有什么作用，因此就没有写在里面。如果有同学认为保留initiating loader可以做一些事欢迎和我们讨论\~）
```
private EntryType loadEntryType;
```
### 1.3 方法区 Method Area
在某些教材中方法区被认为是堆的一部分，也有些教材中将它称之为Non-Heap。无论教材中或者实现中是如何划分它的，方法区的作用就是存放类信息的，在我们的框架中即JClass(运行时常量池是JClass的一部分)。每当有类被加载进JVM中，类的相关信息就要被储存进方法区。
在JVM中，一个类由完全限定名(之前的作业中提到过)和类加载器来唯一确定一个类。那么能出现由boostrap loader加载的java/lang/Object类和user loader加载的java/lang/Object类共存的情况吗？**理论上**可以 ，但是双亲加载机制杜绝了它。(如果你没能理解这个逻辑，建议再回到前一部分理解一下)
> 代码中为了简化理解，只是用了完全限定名来保证唯一性
储存这件事情本身的最终目的就是加快访问。方法区作为JVM的一部分存储，在加载类之前会首先尝试直接获取这个类的信息，如果方法区中没有就再进行加载。
### **1.4 解析**
解析的根本目的是为了实现延迟加载，延迟加载的根本目的是节省时间和空间。试想，如果不存在延迟加载，那么JVM必须一次性将所有的要用到的类加载进内存，首先这会在启动时带来巨大的延迟，并且会占用更多的内存。而使用了延迟加载之后，只有当使用到某个类时才会加载这个类，并且在JVM检测到这个类不需要时又会释放对应的空间。
为了支持延迟加载，JVM把“需要引用某个类”这个信息变成了一个运行时常量池中的常量，这类常量叫做Ref引用。而解析就是将引用变为真正的类并加载到内存的过程。
更多的解析算法你需要去阅读JVM规范对应章节，其中本次只需要用到类和接口的解析算法，其他可以暂时不看。
## 2.实验要求
因为实验整体要求就是基本按照JVM规范所规定的细节来模拟正确的流程，所以不是很好形式化。大致内容如下，**部分细节会在2.3中说明**，其余请参考代码中的**注释提示**以及**实验指导**
1. 完成ClassFileReader中的双亲委托机制
2. 完成ClassLoader中的defineClass方法
3. 完成ClassLoader中的link阶段的prepare方法
4. 完成SymRef中的resolveClassRef方法
5. 完成JClass中的权限验证: 参考规范要求(代码指导中会给出示例)
### 2.1 实验输入
测试中会调用的接口：ClassLoader中的loadClass，ClassRef中的resolveClassRef。其余接口由框架代码实现，不要随意删除即可。除了这两个方法以外的，实验要求中完成的方法都是可以更改的。我们这样进行划分只是为了在理解时更贴近JVM规范的语义，你可以自由实现。
### 2.2 实验输出
抛出所有的ClassNotFoundException和IllegalAccessException，无异常时没有任何输出。
### 2.3 实验要求(部分细节，更多请参考实验指导)
* 加载时的顺序严格遵守：对于每一个类来说，都是先加载superclass然后按顺序加载自身的所有接口。对于每一个接口来说，superclass都是java/lang/Object，它一定已经被加载过了。需要注意接口之间也可以继承（并且是多继承），因此每一个接口还会去加载自身的父接口superinterface，在JClass的代码中的命名是interfaces。
> 一个例子是 A extends B implements C， B implements D，那么加载A的时候在方法区中的结果顺序是 java/lang/Object → D → B → C → A。如果是A extends B implements C，C extends D，那么结果顺序是java/lang/Object → B → D → C → A。
>
> 需要注意的是这里说的是方法区中的顺序，实际尝试加载是从A开始的。可以理解成——要加载的类一定是一个最后被放进方法区中，这样就保证了它的相关类都已经被保存到方法区了。
## 3.实验指导
### 3.1 双亲加载
双亲加载看起来上面写了非常长的一段，但实际上实现起来并不困难，在实验中不到10行就可以解决它。
```java
/**
* @param className class to be read
* @param privilege privilege of relevant class
* @return content of class file and the privilege of loaded class
*/
public Pair