Java程序员面试冲刺day01

1.1JVM的运行机制

jvm为java虚拟机，是用于运行java字节码的虚拟机，jvm主要包括一套字节码指令集、一组程序寄存器、一个虚拟机栈、一个虚拟机堆、一个方法区和一个垃圾回收器。jvm是运行在操作系统上的，与硬件设备之间也是靠操作系统进行交互的

Java源文件在通过编译器文件后被译成相应的字节码.class文件（class字节码文件是程序编译后生成的中间代码），字节码文件又被JVM中的解释器编译成机器码在不同的操作系统上运行。

Java程序的具体运行过程如下：

（1）Java源文件被编译器编译成字节码文件

（2）JVM将字节码文件编译成相应操作系统的机器码

（3）机器码调用相应操作系统的本地方法库执行相应的方法

1. 字节码文件.class经过类加载器子系统（类加载系统能够把class文件装载到内存）加载到JVM中，JVM有两种类加载器，分别是启动类装载器和用户自定义类装载器，JVM通过解释器将封装类的数据结构解释到运行时数据区；
2. 运行时数据区用于存储在JVM运行过程中产生的数据，包括程序计数器、方法区、本地方法区、虚拟机栈和虚拟机堆；方法区中主要存储的是运行时的常量，本地方法区则存放本地的方法
3. 执行引擎包括即时编译器和垃圾回收器，即时编译器用于将JAVA字节码编译成具体的机器码，垃圾回收器用于回收在运行过程中不再能过获取内存的对象；
4. 本地接口库用于调用操作系统的本地方法库完成具体的指令操作

1.2多线程

在一个多核的操作系统中，JVM允许在一个进程内同时并发执行多个线程。JVM中的线程与操作系统中的线程是相互对应的，在JVM线程的本地存储、缓冲区分配等准备工作完成后，JVM会调用操作系统的接口创建一个与之对应的原生线程；在JVM线程运行结束时，原生线程随之被回收。操作系统负责调度所有线程，并为其分配CPU时间片，在原生线程初始化完毕时，就会调用Java线程的run（）执行该线程；在线程结束时，会释放原生线程与Java线程所对应的资源

1.虚拟机线程：虚拟机线程在JVM到达安全点时出现

2. 周期性任务线程：通过定时器调度线程来实现周期性操作的执行
3. GC线程：GC线程支持JVM中不同垃圾回收活动
4. 编译器线程：编译器线程在运行时将字节码动态编译成本地平台机器码，是JVM跨平台的具体实现
5. 信号分发线程：接收发送到JVM的信号并调用JVM方法

1.3JVM的内存区域

JVM的内存区域主要分为三个部分：私有区域、共享区域和直接内存。

私有区域则为某一线程单一拥有

共享区域则为多个线程共同拥有

线程私有区域：程序计数器（pc）、虚拟机栈和本地方法区，这三个区域的生命周期和线程相同，随线程的启动而创建，随线程的结束而销毁。在JVM内，每个线程都与操作系统的本地线程直接映射，因此这部分内存区域的存在与否和本地线程的启动和销毁对应。

线程共享区域：方法区、虚拟机堆，线程共享区域随虚拟机的启动而创建，随虚拟机的关闭而销毁。

直接内存也叫做堆外内存，它并不是JVM运行时数据区的一部分，但在并发编程中被频繁使用。JDK的NIO模块提供的基于Channel与Buffer的IO操作方式就是基于堆外内存实现的，因此堆外内存在高并发应用场景下被广泛使用。

程序计数器PC：属于线程私有区域的，并且没有内存溢出的问题

程序计数器主要用于存储当前运行的线程所执行的字节码的执行信号指示器，每个运行中的线程都有一个独立的程序计数器，在方法正在执行时，该方法的程序计数器记录的是实时虚拟机字节码指令的地址

解释器的工作原理就是通过改变这个计数器来确定下一条需要被执行的字节码指令，程序控制的流程（循环、分支、异常处理、线程恢复）都是通过这个计数器完成的。

虽然程序计数器只有一块很小的内存空间，但是由于存储的是字节码指令的地址因此大小为一个定长值，因此不会出现OOM内存溢出的情况

虚拟机栈：属于线程私有区域的，主要用来描述Java方法的执行过程

虚拟机栈式描述Java方法的执行过程的内存模型，它在当前栈帧中存储了局部变量表、操作数栈、动态链接、方法出口等信息。同时，栈帧用来存储部分运行时数据及其数据结构，处理动态链接方法的返回值和异常分派。

栈帧用来记录方法的执行过程，在方法被执行时虚拟机会为其创建一个与之对应的栈帧，方法的执行和返回对应栈帧在虚拟机栈中的入栈和出栈。每个运行中的线程当前只有一个栈帧处于活动状态。

多线程运行时，当其一个线程获取到cpu时间片后，执行方法创建栈帧，方法返回结果执行结束之后，将当前栈帧出栈。继续执行下一个栈帧，在该线程所有栈帧即所有方法执行完成后释放CPU资源，将CPU时间片分配到另一个线程。

本地方法区：属于线程私有区域

本地方法区又叫本地方法栈，它的作用和虚拟机栈的作用是类似的，区别就是虚拟机栈主要是为执行的Java方法服务，而本地方法栈则是为了Native方法服务，本地方法指的则是外部方法，有点像接口，但是其代码是由不同的语言实现，当线程调用Java方法时，JVM会创建一个新的栈帧并压入虚拟机栈，然而在调用本地方法时，虚拟机栈保持不变，不会在线程的虚拟机栈中压入新的帧，而是简单地动态链接并直接调用指定的本地方法。如果某个虚拟机实现的本地方法接口使用的是C++连接模型，那么它的本地方法就是C++栈。

堆：属于线程共享区域，也叫做运行时数据区

在JVM运行过程中new及创建的对象和产生的数据都被存储到了堆中即运行时数据区，堆是被线程共享的内存区域，也是垃圾回收器进行垃圾回收的最主要的内存区域。在运行时数据区中进行分代收集算法，将堆划分为新生代、老年代和永久代。垃圾回收最主要的活动区域就是新生代，其次是老年代。代码解释被执行创建的对象获取到内存存储到堆中即运行时数据区，随着周期的变化，进行垃圾回收或者幸存即年代升级

方法区：属于线程共享区域

方法区也被叫做永久代，永久代存储的主要是常量、static修饰的静态变量、类的信息（类的版本、字段、方法及接口描述）、即时编译器编译后的机器码、运行时常量池（1.6jdk最典型的应用就是字符串常量，例如String s=‘hello’，其中hello就是字符串常量，存储在常量池中，而从jdk1.7开始字符串常量池则被移动到了堆区当中）等数据。由于方法区区域是所有线程共享的区域，因此它被设计为线程安全的。

JVM把GC分代收集扩展至方法区即永久代，即使用Java堆的永久代来实现方法区，这样JVM的垃圾收集器就可以像管理Java运行时数据区。由于永久代的内存回收主要针对的是常量池的回收和类的卸载，因此能够回收的对象非常少。

常量被存储在运行时常量池中，是方法区的一部分。静态变量也属于方法区永久代的一部分。在类信息中不但保存了类的版本、字段、方法、接口等描述信息，还保存了常量信息。

在即时编译后，代码的内容将在执行阶段被保存在方法区的运行时常量池中。Java虚拟机对字节码文件每一部分的格式都有明确规定，只有符合jvm规范的字节码文件才能通过虚拟机的检查，然后被装载、执行。

执行引擎

执行引擎主要负责执行字节码，方法的字节码是由JAVA虚拟机的指令序列构成的，每一条指令包含一个单字节的操作码，后面跟随0个或多个操作数。当执行引擎执行字节码时，首先会取一个操作码，如果操作码有操作数，那么会接着取得它的操作数。然后执行这个操作，执行完成后会继续取得下一个操作码执行。

在执行方法时，JVM提供了四种指令来执行：

（1）invokestatic：调用类的static方法

（2）invokevirtual：调用对象实例的方法

（3）invokeinterface：将属性定义为接口来进行调用

（4）invokesecial：调用一个初始化方法、私有方法或者父类的方法

1.4JVM的运行时内存

Java的运行时内存也叫作JVM堆，从GC的角度可以将JVM堆分为新生代、老年代和永久代。其中新生代默认占1/3堆空间，老年代默认占2/3堆空间。新生代又分为Eden区、ServivorFrom去和ServivorTo区，Eden区默认占8/10新生代空间，剩下的各占1/10区间

新生代;Eden区、ServivorTo区和ServivorFrom区

JVM新创建的对象会被存放在新生代中，但是需要大内存的对象除外，默认占1/3堆内存空间，由于JVM会频繁地创建对象，因此新生代中内存不管的话很快就会满的，因此也会频繁地触发MinorGC进行垃圾回收，MinorGC采用复制的方法进行垃圾回收

（1）Eden区：Java新创建的对象首先会被存放在Eden区中，如果新创建的对象那个属于大对象，则将对象直接分配到老年代中。一般大对象的定义和Java具体的JVM版本、堆大小有关。在Eden区的内存空间不足时会触发MinorGC，对新生代进行一次垃圾回收

（2）ServivorTo区：保留上一次MinorGC时的幸存者，在进行一次垃圾回收后保留下的对象成为幸存者

（3）ServivorFrom区：将上一次MinorGC时的幸存者作为这一次的扫描者

MinorGC采用复制算法：把Eden区和ServivorFrom区中存活的对象复制到To区中，如果对象的年龄到达老年代的标准，则将对象直接复制到老年代，清空Eden区和ServivorFrom区中的对象，将后两个区域互换，原有的To区域成为下一次GC时的From区

老年代

老年代主要存放有长生命周期的对象和大对象，老年代的GC过程叫作MajorGC。存放代码、字符串常量池、静态变量等可以持久化的数据。在老年代中，对象的话一般是比较稳定的，因此很少会进行垃圾回收，在进行MajorGC之前，会进行一次MinorGC，如果在进行MinorGC过后如果老年代的空间依然不够的话，才会触发MajorGC进行垃圾回收，释放JVM的内存空间。

MajorGC采用标记清除的算法，该算法首先会扫描所有对象并且标记存活的对象然后回收未被标记的对象，并且释放内存空间

因为要先扫描老年代的所有对象再回收，所以MajorGC的耗时比较长。MajorGC的标记清除算法容易产生内存碎片。在老年代没有内存时间可分配时，会抛出内存溢出异常。

永久代

永久代指的是内存的永久保存区域，主要存放Class和Meta元数据的信息。Class在类加载时被放入永久代。GC不会在程序运行期间对永久代的内存进行清理，这也导致了永久代的内存会随着加载的Class文件的增加而增加，在加载的Class问价如果过多的话会抛出内存溢出异常，比如Tomcat引用Jar文件过多导致JVM内存不足而无法启动。

到Java8之后，元数据区即元空间替代了永久代，元数据区并没有使用虚拟机的内存，二是直接使用的操作系统的内存，Jvm将类的元数据放入本地内存中，将常量池和类的静态变量放入Java堆中这样JVM能够加载多少元数据信息就由操作系统的实际可用内存空间决定。

1.5垃圾回收算法

如何确定垃圾

常用的是使用引用计数法和可达性分析来确定是否应该被回收，其中引用计数法容易产生循环引用的问题，可达性分析通过根搜索算法来实现。根搜索算法以一系列GC Roots的点作为起点向下搜索在一个对象到任何GC roots都没有引用链相连时，说明其已经死亡了。根搜索算法主要针对栈中的引用、方法区中的静态引用和JNI中的引用展开分析。

引用计数法

在Java中如果要操作对象，首先就需要获取对象的引用，因此可以通过引用计数法来判断一个对象是否可以被回收。在为一个对象添加一个引用时，引用计数加1；在为对象删除一个引用时，引进计数减1；如果一个对象的引用计数为0，则表示此刻该对象没有被引用，可以被回收。

引用计数法容易产生循环引用问题，即两个对象互相引用，因此导致它们的引用一直存在，而不能被回收，两个对象之间互相引用，因此其计数都为1，因此都不能被回收。

可达性分析

可达性分析首先定义一些GC Roots对象，然后以这些GC Roots对象作为起点向下搜索，如果GC Roots和一个对象之间没有可达路径，则称该对象是不可达的。不可达的对象要经过至少两次标记才能判定其是否可以被回收，如果两次都不可达，则将被垃圾收集器回收。

Java中常用的垃圾回收算法

Java中常用的垃圾回收算法主要有标记清除（Mark-Sweep）、复制、标记整理和分代收集这4种垃圾回收舒服那

标记清除算法

标记清除算法是基础的垃圾回收算法，其过程分为标记和清除两个阶段。在标记阶段标记所有需要回收的对象，在清除阶段清除可回收的对象并释放其所占用的内存空间

当可回收的对象被GC回收过后原有的对象空间就变为可使用的空间，这样也就导致了空间的不连续也就是碎片化

复制算法

复制算法是为解决标记清除算法内存碎片化的问题而设计的。复制算法首先将内存划分为两块大小相等的内存区域，即区域1和区域2，新生成的对象都被存放在区域1中，在区域1内的对象存储满后会对区域1进行一次标记，并将标记后仍然存活的对象全部复制到区域2中，这是区域1将不存在任何存活的对象，直接清理整个区域1的内存即可

复制算法最大的问题就是内存空间被压缩到原来的一半，因此存在大量的内存浪费及内存利用率降低，同时在系统中有大量长时间存活的对象时，这些对象将在内存区域1和内存区域2之间来回复制而影响到系统的运行效率。

标记整理算法

标记整理算法结合了标记清除算法和复制算法的优点，其标记阶段和标记清除阶段类似相同，在标记完成之后将存活的对象移到内存的另一端，然后清除该端的对象并释放内存

分代收集算法

无论是标记清除算法、复制算法还是标记整理算法，都无法对所有类型（长生命周期、短生命周期、大对象和小对象）的对象都进行垃圾回收。因此，针对不同的对象类型，JVM采用了不同的垃圾回收算法，该算法被称为分代收集算法

1.6Java中的4种引用类型

在Java中所有都为对象，对象的操作时通过对获取该对象的引用（Reference）来实现的，Java中的引用类型有4种，分别为强引用、软引用、弱引用和虚引用

强引用：在Java中最常见的引用类型就是强引用。在把一个对象赋给一个引用变量时，这个引用变量就是一个强引用。有强引用的对象一定为可达性状态，所以一定不会被垃圾回收机制回收，正因为如此强引用是造成Java内存泄漏最主要的原因。

软引用：软引用通过SoftReference类实现。如果一个对象只有软引用，则在系统内存不足时该对象将被回收，软引用是用来描述一些还有用但非必须的对象，只被软引用关联着的对象，在系统将要发生内存溢出前，会把这些对象列进回收范围中进行二次回收，如果这次回收还是没有足够的内存，才会抛出内存异常异常

内存充足时：

public static void softRef_Memory_Enough(){

Object o1 = new Object();
SoftReference<Object> softReference = new SoftReference<>(o1);
System.out.println(o1);
System.out.println(softReference.get());

o1 = null;
System.gc();

System.out.println(o1);
System.out.println(softReference.get());

弱引用：弱引用通过WeakReference类实现，弱引用也是用来描述那些非必须对象，但是它的强度比软引用更弱一些，被弱引用关联的对象只能生存到下一次垃圾收集发生为止，其在垃圾回收过程中一定会被回收。

public static void weakRef_Memory(){

Object o1 = new Object();
WeakReference<Object> weakReference= new WeakReference<>(o1);
System.out.println(o1);
System.out.println(weakReference.get());

o1 = null;
System.gc();

System.out.println(o1);
System.out.println(weakReference.get());

虚引用：虚引用通过PhantomReference类实现，虚引用又称为“幽灵引用”或者“幻影引用”，它是最弱的一种引用关系，一个对象是否有虚引用的存在，完全不会对其生存时间构成影响，也无法通过虚引用来获得一个对象实例。为一个对象设置虚引用关联的唯一目的只是为了能在这个对象被收集器回收时收到一个系统通知。虚引用和引用队列联合使用，主要用于跟踪对象的垃圾回收状态。

1.7分代收集算法和分区收集算法

分代收集算法

JVM根据对象存活周期的不同将内存划分为新生代、老年代和永久代，并根据各年代的特点分别采用不同的GC算法。

1、新生代与复制算法

新生代主要存储短生命周期的对象，因此在垃圾回收的标记阶段会标记大量已死亡的对象及少量存活的对象，因此只需要选用复制算法将少量存活的对象复制到内存的另一端并清理原区域的内存即可。

2、老年代与标记整理算法

老年代主要存放生命周期比较长的对象和大对象，可回收的对象一般比较少，因此JVM采用标记整理算法进行垃圾回收，直接释放死亡状态的对象所占用的内存空间即可。

分区收集算法

分区算法将整个堆空间划分为连续的大小不同的小区域，对每个区域都单独进行内存使用和垃圾回收，这样做的好处就是可以根据每个区域内存的大小灵活使用和释放内存

分区收集算法可以根据系统可接受的停顿时间，每次都快速回收若干个小区域的内存，以缩短垃圾回收时系统停顿的时间，最后以多次并行累加的方式逐步完成整个内存区域的垃圾回收。如果垃圾回收机制一次回收珍格格堆内存，则需要更长的系统停顿时间，长时间的系统停顿将影响系统运行的稳定性。

1.8垃圾收集器

Java堆内存分为新生代和老年代：JVM对新生代和老年代分别提供了多种不同的垃圾收集器，针对新生代提供的垃圾收集器有Serial、ParNew、Parallel、Scavenge，针对老年代提供的垃圾收集器有Serial Old、Parallel Old、CMS，还有针对不同区域的G1收集算法

Serial垃圾收集器：单线程复制算法

Serial垃圾收集器基于复制算法实现，他是一个单线程收集器，在它正在进行垃圾收集时，必须暂停其他所有工作线程，直到垃圾收集结束。

Serial垃圾收集器采用了复制算法，简单、高效，对于单CPU运行环境来说，没有线程交互开销，可以获得最高的单线程垃圾收集效率，因此Serial垃圾收集器是Java虚拟机运行在Client模式下的新生代的默认垃圾收集器。

ParNew垃圾收集器：多线程复制算法

ParNew垃圾收集器是Serial垃圾收集器的多线程实现，同样采用复制算法，除此之外和Serial收集器几乎一样。PaeNew垃圾收集器在垃圾收集过程中会暂停所有其他工作线程，是虚拟机运行在Server模式下的新生代的默认垃圾收集器。

ParNew垃圾收集器默认开启与CPU同等数量的线程进行垃圾回收，在Java应用启动时可通过-XX：ParallelGCHreads参数调节ParNew垃圾收集器的工作效率

Parallel Scavenge垃圾收集器：多线程复制算法

Parallel Scavenage收集器是为提高新生代垃圾收集效率而设计的垃圾收集器，基于多线程复制算法实现，在系统吞吐量上有很大的优化，可以高效地利用CPU尽快完成垃圾回收任务。

Parallel Scavenage通过自适应调节策略提高系统吞吐量，提供了三个参数用于调节、控制垃圾回收的停顿时间及吞吐量，分别是控制最大的垃圾收集停顿时间MaxGCPauseMillis参数，控制吞吐量大小的GCTimeRatio参数和控制自适应调节策略开启与否的UseAdaptiveSizePolicy参数

Serial Old垃圾收集器：单线程标记整理算法

Serial Old垃圾收集器是Serial垃圾收集器的老年代实现，同Serial一样采用单线程执行，不同的是Serial Old针对老年代长生命周期的特点基于标记整理算法实现。Serial Old垃圾收集器是JVM运行在Client模式下的默认垃圾收集器。

新生代的Serial垃圾收集器和老年代的Serial Old垃圾收集器可搭配使用，分别针对JVM的新生代和老年代进行垃圾回收，其垃圾收集过程如下图所示。在新生代采用Serial垃圾收集器基于复制算法进行垃圾回收，未被其回收的对象在老年代被Serial Old垃圾收集器基于标记整理算法进行垃圾回收。

Parallel Old垃圾收集器：多线程标记整理算法

该收集器采用多线程并发进行垃圾回收，它根据老年代长生命周期的特点，基于多线程的标记整理算法实现。该垃圾收集器在设计上优先考虑系统吞吐量，其次考虑停顿时间等因素，如果系统对吞吐量要求比较高的话，则可以优先考虑新生代的Parallel Scavenage垃圾收集器和老年代的Parallel Old垃圾收集器配合使用

CMS垃圾收集器

CMS（Concurrent Mark Sweep）垃圾收集器是为老年代设计的垃圾收集器，其主要的目的是达到最短的垃圾回收停顿时间，基于线程的标记清除算法实现。官方的名字就是最大并发量的标记清除垃圾回收器，它在老年代中使用的是最大并发量的标记清除算法，算法的目的就是为了避免在清理老年代的内存的时候，让用户线程暂停太长的时间。在一些对响应时间有很高的要求的应用或网站中，用户程序不能有长时间的停顿，CMS可用于此场景。

它主要通过如下两种方法来实现这个目的：

1）使用空闲链表来管理回收的空间，而非压缩老年代的内存

2）将多数标记清理工作和应用程序并发执行

CMS的执行可以分成如下几个阶段：
（1）初始标记：主要作用是标记在老年代中可以从root集直接可达或者被年轻代中节点引用的对象。这一步的操作会暂停用户线程的执行

（2）并发标记：这一步垃圾回收器会遍历老年代，从上一步标记的结点开始，标记所有被引用的对象。由于这一操作是与用户线程并发执行的，因此这一步并不一定会标记所有被引用的对象，因为应用程序在这个运行过程中还会修改对象的引用。

（3）并发预清理:这一步是与应用程序并发执行的。由于在上一步执行的过程中，有些对象的引用关系发生了变化，会导致标记的不准确，这一步将会考虑这些结点，在上一步中发生引用变化的节点被标记为dirty，在这一步中，对从这些dirty节点触发可以到达的结点进行标记。

（4）并行的可被终止的预清理：这一阶段的目的是使这种垃圾回收算法更加可控一些，也是执行一些预清理，以减少最终标记阶段对应于暂停的时间。

（5）重新标记：在并发标记过程总用户线程继续运行，导致在垃圾回收过程中对象的状态发生变化，为了确保这部分对象的状态正确性，需要对其重新标记并暂停工作线程

（6)并发清除：和用户线程一起工作，执行清除GC Roots不可达对象的任务，不需要暂停工作线程

CMS垃圾收集器在和用户线程一起工作时（并发标记和并发清楚）不需要暂停用户线程，有效缩短了垃圾回收时系统的停顿时间，同时由于CMS垃圾收集器和用户线程一起工作，因此其并行度和效率也有很大提升。

G1垃圾收集器

G1（Garbage First）垃圾收集器为了避免全区域垃圾收集引起的系统停顿，将堆内存划分为大小固定的几个独立区域，独立使用这些区域的内存资源并且跟踪这些区域的垃圾收集进度，同时在后台维护一个优先级列表，在垃圾回收过程中根据系统允许的最长垃圾收集时间，优先回收垃圾最多的区域。G1垃圾收集器通过内存区域独立划分使用和根据不同优先级回收垃圾的机制，确保了G1垃圾收集器在有限时间内获得最高的垃圾收集效率。

由于之前介绍的所有垃圾回收器或多或少都会暂停应用程序，因此在一些特定情况下垃圾回收器有可能会对应用程序的影响非常大。G1的出现可以很好地解决了垃圾回收器暂停用户线程时间的不确定性，它是一款面向服务器的垃圾回收器，主要配备多核处理器及大容量内存的机器。在以极高的概率满足GC暂停用户线程时间要求的同时，还具有很高的吞吐量。

相对于CMS收集器，G1垃圾收集器两个突出的改进：

（1）基于标记整理算法，不产生内存碎片

（2）可以精确控制停顿时间，在不牺牲吞吐量的前提下实现短停顿垃圾回收

1.9JVM的类加载机制

JVM的类加载阶段

JVM的类加载分为5个阶段：加载、验证、准备、解析、初始化。在类初始化完成后就可以使用该类的信息，在一个类不再被需要时可以从JVM中卸载。



加载

指JVM读取Class文件，并且根据Class文件描述创建java.lang.Class对象的过程。类加载的过程主要包含将Class文件读取到运行时区域的方法区内，在堆中创建java.lang.Class对象，并封装在方法区的数据结构的过程，在读取Class文件时既可以通过文件的形式读取，也可以通过jar包、war包读取，还可以通过代理自动生成Class或其他方式读取

根据查找路径找打相对于的class文件，然后导入

验证

主要用于确保Class文件符合当前虚拟机的要求，保障虚拟机自身的安全，只有通过验证的Class文件才能被JVM加载

准备

主要工作是在方法区中为类变量分配内存空间并设置类中变量的初始值（给类中的静态变量分配存储空间）。初始值指不同数据类型的默认值，这里需要注意FINAL类型的变量和非final类型的变量在准备阶段的数据初始化过程不同。

解析

JVM会将常量池中的符号引用替换为直接引用

初始化

主要通过执行类构造器的<cilent>方法为类进行初始化。该方法是在编译阶段由编译器自动收集类中静态语句块和变量的复制操作组成的。JVM规定只有在父类的<cilent>方法都执行成功后，子类中的<cilent>方法才可以被执行。

类加载器

JVM提供了3种类加载器，分别是启动类加载器、扩展类加载器和应用程序类加载器



启动类加载器：负责加载Java_home/LIB目录下的类库，或通过Xbootclasspath参数指定路径中被虚拟机认可的类库。

扩展类加载器：负责加载java_home/lib/ext目录中的类库，或通过java.ext.dirs系统变量加载指定路径中的类库

应用程序类加载器：负责加载用户路径（classpath）上的类库

除了上述三类加载器，我们也可以通过继承java.lang.ClassLoader实现自定义的类加载器

它们之间的层次关系被称为类加载器的双亲委派模型。这种模型要求除了顶层的启动类加载器外，其余的类加载器由自己的父类加载，而这种父子关系是通过组合关系来实现，而不是通过继承。

输出结果：

由此可以知道TestLoader类是由AppClassLoader加载的，而BootStrap Loader使用C++语言实现的，因此在Java语言是看不见的，因此此程序输出为null

双亲委派机制

JVM通过双亲委派机制对类进行加载，双亲委派机制只一个类在收到类加载请求后不会尝试自己加载这个类，二十吧该类加载请求向上委派给其父类去完成，其父类在接收到该类加载请求后又会委派给自己的父类，一次类推，这样所有的类加载请求都被向上委派到启动类加载器中。若父类加载器在接收到类加载请求后发现自己也无法加载该类（通常原因是该类的Class文件在父类的类加载路径中不存在），则父类会将该信息反馈给子类并向下委派子类加载器加载该类，直到该类被成功加载，若找不到该类，则JVM会抛出ClassNotFound异常。

双亲委派加载机制的类加载流程如下：

（1）将自定义加载器挂在到应用程序类加载器，加载类通过调用java.lang.ClassLoader类的loadClass方法实现的，这个方法会首先检查类是否已经被加载过，如果没有被加载，那么它会吧类加载请求委派给父类加载器去完成

（2）委派给父类加载器即将应用程序类加载器请求委托给扩展类加载器，同理父类加载器也把类加载请求委派给它的父类加载器，知道所有的请求都传递给顶层的启动类加载器，即将扩展类加载器将加载器请求委托给启动类加载器

（3）启动类加载器在加载路径下查找并加载Class文件，如果未找到目标Class文件，则交还给扩展类加载器加载。

（4）扩展类加载器在加载路径下查找并加载Class文件，如果未找到目标Class文件，则交由加载器应用程序程序类加载

（5）依次往下如果加载成功，那么说明类已经被成功加载，否则加载失败，同时不再会调用其子类加载器去进行类加载。

laodClass方法

    protected Class<?> loadClass(String name,boolean resolve) throws ClassNotFoundException{
//        加上锁，使其能够在多线程环境下运行
        synchronized (getClassLoadingLock(name)){
//            判断类是否已经被加载过
            Class c=findLoadedClass(name);
            if (c==null){
                try {
//                    如果不是顶层类加载器，那么调用父类的loadClass进行加载
                    if (parent!=null){
                        c=parent.loadClass(name,false);
                    }else{
//                        没有父类加载器（Bootstrap类加载器），直接调用
                        c=findBootstrapClassOrNull(name);
                    }
                }catch (ClassNotFoundException){
//                    抛出异常
                }
                if (c==null){
//                    父类加载类失败，调用自己的findClass方法进行类加载
                    c=findClass(name);
                }
                
            }
            if(resolve){
                resolveClass(c);
            }
            return c;
        }
    }

双亲委派机制的核心就是保障类的唯一性和安全性。例如在加载rt.jar包中的java.lang.Object类时，无论是哪个类加载器加载这个类，最终都将类加载请求委托给启动类加载器加载，这样就保证了类加载的唯一性。如果在JVM中存在包名和类名相同的两个类，则则该类将无法加载，JVM也无法完成类加载流程。