Willdas博客

ClassLoader使用的是双亲委托模型来搜索类的，每个ClassLoader实例都有一个父类加载器的引用（不是继承的关系，是一个包含的关系），虚拟机内置的类加载器（Bootstrap ClassLoader）本身没有父类加载器，但可以用作其它ClassLoader实例的的父类加载器。

为了解决这个困境，Java设计团队只好引入了一个不太优雅的设计：线程上下文件类加载器(Thread Context ClassLoader)。这个类加载器可以通过java.lang.Thread类的

程序计数器存储了当前线程正在执行的字节码指令的地址（如果是当前执行的是Native方法，那么计数器为空），字节码解释器就是通过改变计数器的值来选取下一条需要执行的字节码指令。存储了被虚拟机加载的类型信息，常量，静态变量等数据，在JDK1.8以后，存储在元空间中（以前是存储在堆中的永久代中，JDK8以后已经没有永久代了）。本地方法栈与Java虚拟机栈类似，只不过是执行Native方法（C++方法等），在HotSpot虚拟机中直接把本地方法栈与虚拟机栈二合一。3、线程共享的部分(堆,方法区)

当一个ClassLoader实例需要加载某个类时，它会试图亲自搜索某个类之前，先把这个任务委托给它的父类加载器，这个过程是由上至下依次检查的，首先由最顶层的类加载器Bootstrap ClassLoader试图加载，如果没加载到，则把任务转交给Extension ClassLoader试图加载，如果也没加载到，则转交给App ClassLoader 进行加载，如果它也没有加载得到的话，则返回给委托的发起者，由它到指定的文件系统或网络等URL中加载该类。但是，如果基础类又要调用用户的代码，那该怎么办呢。

但是在JVM中会很难解决对象之间相互循环引用的问题，就如果两个对象之间相互调用，这时候就会发生类似死锁的情况，即这个地方相互调用会使得引用计数法始终认为有对象在引用当前对象，就一直计数值大于或等于1，也就无法通知GC收集器回收它们。使用一系列的GC Roots的对象（包括：虚拟机栈中引用的对象，本地方法栈中JNI引用的对象，方法区中类静态属性引用的对象，方法区中常量引用的对象）作为起点，从节点开始向下搜索，当没有被GCRoots链接到的对象就可以回收，如下图的对象4和5就判断为可回收对象。