- 内存模型
- 垃圾回收
- 类加载
1.GC算法
根搜索算法、标记-清除算法、复制算法、标记-整理算法
根搜索算法：设立若干种根对象，当任何一个根对象到某一个对象均不可达时，则认为这个对象是可以被回收的。
可以当做GC roots的对象有以下几种：
1、虚拟机栈中的引用的对象。
2、方法区中的类静态属性引用的对象。
3、方法区中的常量引用的对象。
4、本地方法栈中JNI的引用的对象。
标记-清除算法：当堆中的有效内存空间（available memory）被耗尽的时候，就会停止整个程序（也被成为stop the world），然后进行两项工作，第一项则是标记，第二项则是清除。
（1）标记：标记的过程其实就是，遍历所有的GC Roots，然后将所有GC Roots可达的对象标记为存活的对象。
（2）清除：清除的过程将遍历堆中所有的对象，将没有标记的对象全部清除掉。
复制算法：复制算法将内存划分为两个区间，在任意时间点，所有动态分配的对象都只能分配在其中一个区间（称为活动区间），而另外一个区间（称为空闲区间）则是空闲的，当有效内存空间耗尽时，JVM将暂停程序运行，开启复制算法GC线程。接下来GC线程会将活动区间内的存活对象，全部复制到空闲区间，且严格按照内存地址依次排列，与此同时，GC线程将更新存活对象的内存引用地址指向新的内存地址。此时，空闲区间已经与活动区间交换，而垃圾对象现在已经全部留在了原来的活动区间，也就是现在的空闲区间。事实上，在活动区间转换为空间区间的同时，垃圾对象已经被一次性全部回收。
标记/整理算法：标记/整理算法与标记/清除算法非常相似，它也是分为两个阶段：标记和整理。
（1）标记：它的第一个阶段与标记/清除算法是一模一样的，均是遍历GC Roots，然后将存活的对象标记。
（2）整理：移动所有存活的对象，且按照内存地址次序依次排列，然后将末端内存地址以后的内存全部回收。因此，第二阶段才称为整理阶段。
标记/整理算法不仅可以弥补标记/清除算法当中，内存区域分散的缺点，也消除了复制算法当中，内存减半的高额代价，标记/整理算法唯一的缺点就是效率也不高，不仅要标记所有存活对象，还要整理所有存活对象的引用地址。
参考：JVM学习之GC常用算法
*2.Java内存模型
所有线程共享的数据区：堆、方法区；
线程隔离的数据区：虚拟机栈、本地方法栈、程序计数器；
1，程序计数器（Program Counter Register）：程序计数器是一个比较小的内存区域，用于指示当前线程所执行的字节码执行到了第几行，可以理解为是当前线程的行号指示器。字节码解释器在工作时，会通过改变这个计数器的值来取下一条语句指令。每个程序计数器只用来记录一个线程的行号，所以它是线程私有（一个线程就有一个程序计数器）的。
2，虚拟机栈（JVM Stack）：一个线程的每个方法在执行的同时，都会创建一个栈帧（Statck Frame），栈帧中存储的有局部变量表、操作数栈、动态链接、方法出口等，当方法被调用时，栈帧在JVM栈中入栈，当方法执行完成时，栈帧出栈。每个线程对应着一个虚拟机栈，因此虚拟机栈也是线程私有的。
3，本地方法栈（Native Method Statck）：本地方法栈在作用，运行机制，异常类型等方面都与虚拟机栈相同，唯一的区别是：虚拟机栈是执行Java方法的，而本地方法栈是用来执行native方法的，在很多虚拟机中（如Sun的JDK默认的HotSpot虚拟机），会将本地方法栈与虚拟机栈放在一起使用。本地方法栈也是线程私有的。
4，堆区（Heap）：堆区是理解Java GC机制最重要的区域，没有之一。在JVM所管理的内存中，堆区是最大的一块，堆区也是Java GC机制所管理的主要内存区域，堆区由所有线程共享，在虚拟机启动时创建。堆区的存在是为了存储对象实例，原则上讲，所有的对象都在堆区上分配内存（不过现代技术里，也不是这么绝对的，也有栈上直接分配的）。
5，方法区（Method Area）：方法区是各个线程共享的区域，用于存储已经被虚拟机加载的类信息（即加载类时需要加载的信息，包括版本、field、方法、接口等信息）、final常量、静态变量、编译器即时编译的代码等。
*3.内存分配及GC机制
这里所说的内存分配，主要指的是在堆上的分配。Java内存分配和回收的机制概括的说，就是：分代分配，分代回收。对象将根据存活的时间被分为：年轻代（Young Generation）、年老代（Old Generation）、永久代（Permanent Generation，也就是方法区）。
- 年轻代（Young Generation）：对象被创建时，内存的分配首先发生在年轻代（大对象可以直接被创建在年老代），大部分的对象在创建后很快就不再使用，因此很快变得不可达，于是被年轻代的GC机制清理掉（IBM的研究表明，98%的对象都是很快消亡的），这个GC机制被称为Minor GC或叫Young GC。注意，Minor GC并不代表年轻代内存不足，它事实上只表示在Eden区上的GC。
年轻代上的内存分配是这样的，年轻代可以分为3个区域：Eden区（伊甸园，亚当和夏娃偷吃禁果生娃娃的地方，用来表示内存首次分配的区域，再贴切不过）和两个存活区（Survivor 0 、Survivor 1）。
-
绝大多数刚创建的对象会被分配在Eden区，其中的大多数对象很快就会消亡。Eden区是连续的内存空间，因此在其上分配内存极快；
-
最初一次，当Eden区满的时候，执行Minor GC，将消亡的对象清理掉，并将剩余的对象复制到一个存活区Survivor0（此时，Survivor1是空白的，两个Survivor总有一个是空白的）；
-
下次Eden区满了，再执行一次Minor GC，将消亡的对象清理掉，将存活的对象复制到Survivor1中，然后清空Eden区；
-
将Survivor0中消亡的对象清理掉，将其中可以晋级的对象晋级到Old区，将存活的对象也复制到Survivor1区，然后清空Survivor0区；
- 当两个存活区切换了几次（HotSpot虚拟机默认15次，用-XX:MaxTenuringThreshold控制，大于该值进入老年代，但这只是个最大值，并不代表一定是这个值）之后，仍然存活的对象（其实只有一小部分，比如，我们自己定义的对象），将被复制到老年代。
从上面的过程可以看出，Eden区是连续的空间，且Survivor总有一个为空。经过一次GC和复制，一个Survivor中保存着当前还活着的对象，而Eden区和另一个Survivor区的内容都不再需要了，可以直接清空，到下一次GC时，两个Survivor的角色再互换。因此，这种方式分配内存和清理内存的效率都极高，这种垃圾回收的方式就是著名的“停止-复制（Stop-and-copy）”清理法（将Eden区和一个Survivor中仍然存活的对象拷贝到另一个Survivor中），这不代表着停止复制清理法很高效，其实，它也只在这种情况下高效，如果在老年代采用停止复制，则挺悲剧的。
- 年老代（Old Generation）：对象如果在年轻代存活了足够长的时间而没有被清理掉（即在几次Young GC后存活了下来），则会被复制到年老代，年老代的空间一般比年轻代大，能存放更多的对象，在年老代上发生的GC次数也比年轻代少。当年老代内存不足时，将执行Major GC，也叫 Full GC。
老年代存储的对象比年轻代多得多，而且不乏大对象，对老年代进行内存清理时，如果使用停止-复制算法，则相当低效。一般，老年代用的算法是标记-整理算法，即：标记出仍然存活的对象（存在引用的），将所有存活的对象向一端移动，以保证内存的连续。
- 方法区（永久代）：
永久代的回收有两种：常量池中的常量，无用的类信息，常量的回收很简单，没有引用了就可以被回收。对于无用的类进行回收，必须保证3点：
- 类的所有实例都已经被回收
- 加载类的ClassLoader已经被回收
- 类对象的Class对象没有被引用（即没有通过反射引用该类的地方）
4.GC是在什么时候，对什么东西，做了什么事情？
分析：列举一些我期望的回答：eden满了minor gc，升到老年代的对象大于老年代剩余空间full gc，或者小于时被HandlePromotionFailure参数强制full gc；gc与非gc时间耗时超过了GCTimeRatio的限制引发OOM，调优诸如通过NewRatio控制新生代老年代比例，通过MaxTenuringThreshold控制进入老年前生存次数等
Java与C++之间有一堵由动态内存分配和垃圾收集技术所围成的高墙，墙外面的人想进去，墙里面的人想出来。
对于从事C和C++程序开发的开发人员来说，在内存管理领域，他们既是拥有最高权利的皇帝，也是从事最基础工作的劳动人民-----既拥有每一个对象的所有权，又担负着每一个对象从生命开始到终结的维护责任。
对于Java程序员来说，虚拟机的自动内存分配机制的帮助下，不再需要为每一个new操作去写配对的delete/free代码，而且不容易出现内存泄露和内存溢出问题，看起来由虚拟机管理内存一切都很美好。不过，也正是因为Java程序员把内存控制的权利交给Java虚拟机，一旦出现内存泄露和溢出方面的问题，如果不了解虚拟机是怎样使用内存的，那排查错误将会是一项异常艰难的工作。
并且好的Java程序在编写的时候肯定要考虑GC的问题，怎样定义static对象，怎样new对象效率更高等等问题，简称面向GC的编程
也可以说Java的内存分配管理是一种托管的方式，托管于JVM。
C++经过编译时直接编译成机器码，而Java是编译成字节码，由JVM解释执行。
C++是编译型语言，而Java兼具编译型和解释型语言的特点。
①引用计数算法
给对象中添加一个引用计数器，每当有一个地方引用它时，计数器就加1；当引用失效时，计数器值就减1；任何时刻计数器都为0的对象就是不可能再被使用的。
Java语言没有选用引用计数法来管理内存，因为引用计数法不能很好的解决循环引用的问题。
②根搜索算法
在主流的商用语言中，都是使用根搜索算法来判定对象是否存活的。
GC Root Tracing 算法思路就是通过一系列的名为"GC Roots"的对象作为起始点，从这些节点开始向下搜索，搜索所走过的路径称为引用链（Reference Chain），当一个对象到GC Roots没有任何引用链相连，即从GC Roots到这个对象不可达，则证明此对象是不可用的。
虚拟机栈（栈帧中的本地变量表）中的引用的对象
方法区中的类静态属性引用的对象
方法区中的常量引用的对象
本地方法栈中JNI（Native方法）的引用对象
垃圾收集器
七种垃圾收集器：
Serial(年轻代）、ParNew(年轻代）、Parallel Scavenge(年轻代）、
Serial Old(年老代）、Parallel Old(年老代）、CMS(Concurrent Mark Sweep年老代）、
G1（Garbage Firest）
- Serial收器
Serial收集器是最基本、发展历史最悠久的收集器。这个收集器是一个单线程的收集器，当它工作时必须暂停其他线程的工作，也就是Stop The World。这显示是它的缺点， 这也是垃圾收集器一直努力的方向。当然，对于相比其它单线程收集器，Serial收集器简单而高效。对于桌面应用来说，分配的管理内存不会太多，停顿时间完全可以控制在几十毫秒最多一百毫秒以内。所以，Serial收集器对于运行在Client模式下的虚拟机来说是一个很好的选择。下图为Serial结合Serial Old收集器（后续介绍）的运行过程：
Serial收集器优点：简单而高效，对于限定单个CPU的环境来说，Serial收集器由于没有线程交互的开销，专心做垃圾收集自然可以获得较高的收集效率。Serial收集器依然是Client模式下的默认的新生代垃圾收集器。
- ParNew收集器
ParNew收集器其实就是Serial收集器的多线程版本（多CPU下使用效果较好），下图为ParNew结合Serial Old收集器（后续介绍）的运行过程：
ParNew收集器对于Serial来说并没有太多的创新之处，但它却是许多运行在Server模式下的虚拟机中首选的新生代收集器，因为除了Serial收集器外，剩下只有它能与CMS收集器（后续介绍）配合工作了。所以，遗憾的是CMS作为老年代的收集器，却无法与JDK1.4中已经存在的新生代收集器Parallel Scavenge配合工作。
并行（Parallel）：指多条垃圾收集线程并行工作，但此时用户线程仍然处于等待状态；
并发（Concurrent）：指用户线程与垃圾收集线程同时执行（但不一定是并行的，可能会交替执行），用户程序在继续运行，而垃圾收集程序运行于另一个CPU上；
- Parallel Scavenge收集器
Parallel Scavenge收集器是一个新生代收集器，它也是使用复制算法的收集器，又是并行的多线程收集器，看上去跟ParNew差不多。但是Parallel Scavenge收集器与其他收集器不同在于：CMS等收集器的关注点在于尽可能地缩短垃圾收集时用户线程的停顿时间，而Parallel Scavenge收集器的目标则是达到一个可控制的吞吐量（Throughput）。所谓的吞吐量就是CPU用于运行用户代码的时间与CPU总消耗时间的比值，即吞吐量 = 运行用户代码时间/（运行用户代码时间+垃圾收集时间），虚拟机总共运行了100分钟，其中垃圾收集花费1分钟，那吞吐量就是99%。
Parallel Scavenge收集器也经常称为“吞吐量优先”收集器；
停顿时间越短越适合需要与用户交互的程序，良好的响应速度能提升用户体验，而高吞吐量则可以高效率地利用CPU时间，尽快完成程序的运算任务，主要适合在后台运算而不需要太多交互的任务。
Parallel Scavenge收集器参数：
-XX:MaxGCPauseMillis参数控制最大垃圾收集停顿时间
以及直接设置吞吐量大小的-XX:GCTimeRatio参数。
Parallel Scavenge收集器还有一个-XX:UseAdaptiveSizePolicy开关参数，打开参数后就不需要手动指定新生代的大小、Eden与Survivor区的比例、晋升老年代对象年龄等细节参数了，虚拟机会根据当前系统的运行情况收集性能监控信息，动态调整相关参数。这种调节方式叫自适应的调节策略，也是Parallel Scavenge收集器与ParNew收集器的一个重要区别。
- Serial Old收集器
Serial Old是一个老年代收集器，它同样是一个单线程收集器，使用的是“标记-整理”算法。这个收集器的主要意义也是在于给Client模式下的虚拟机使用。如果在Server模式下，那么它主要还有两大用途：一种用途是在JDK1.5以及之前的版本中与Parallel Scavenge收集器搭配使用；另一种用途就是作为CMS收集器的后备方案，在并发收集发生ConCurrent Mode Failure时使用。
- Parallel Old收集器
Parallel Old是Parallel Scavenge收集器的老年代版本，使用多线程和“标记-整理”算法。这个收集器是在JDK1.6中才开始提供的，在此之前，新生代的Parallel Scavenge收集器一直处于比较尴尬的状态。原因是新生代如果选择了Parallel Scavenge收集器，老年代除了Serial Old收集器别无选择（因为它无法与CMS配合使用）。在都CPU时代，由于Serial Old收集器在服务端性能上的“拖累”，使用了Parallel Scavenge收集器也未必能在整体应用上获得吞吐量最大化的效果。直到Parallel Old收集器的出现后，“吞吐量优先”收集器才有了比较名副其实的应用组合。在注重吞吐量以及CPU资源敏感的场合，都可以优先考虑Parallel Scavenge加Parallel Old收集器，如下图所示：
- CMS收集器
CMS（Concurrent Mark Sweep）收集器是一种以获得最短回收停顿时间为目标的收集器。目前很大一部分的Java应用集中在互联网站或者B/S系统的服务端上，这类应用尤其重视服务的响应速度，希望系统停顿时间最短，以给用户带来较好的体验。从名字上就可以看出，CMS收集器是基于“标记-清除”算法实现的。但它的实际运作过程对于前面几种收集器来说更复杂一些，整个过程分为4个步骤：
- 初始标记（CMS initial mark）
- 并发标记（CMS concurrent mark）
- 重新标记（CMS remark）
- 并发清除（CMS concurrent sweep）
其中，初始标记、重新标记这两个步骤仍然需要“Stop The World”。初始标记仅仅只是标记一下GC Roots能直接关联到的对象，速度很快；并发标记阶段就是进行GC Roots Tracing的过程；而重新标记阶段则是为了修正并发标记期间用用户程序继续运作而导致标记产生变动的那一部分对象的标记记录。这个阶段的停顿时间一般会比初始标记阶段稍长一些，但远比并发标记时间短。由于整个过程中耗时最长的并发标记和并发清除过程收集器线程都可以与用户线程一起工作，所以，从总体上来说，CMS收集器的内存回收过程是与用户线程一起并发执行的（注意并发与并行的概念），如下图所示：
CMS是一款优秀的收集器，但是还远达不到的完美程度，它有以下3个明显缺点：
- CMS收集器对CPU资源非常敏感。因为在并发阶段，它会占用了一部分线程（或者说CPU资源）而导致应用程序变慢，总吞吐量会降低。
- CMS收集器无法处理浮动垃圾，可能出现“Concurrent Mode Failure”失败而导致另一次Full GC的产生。由于CMS并发清理阶段用户线程还在运行着，伴随着程序运行自然就还会有新的垃圾不断产生，这部分垃圾出现在标记过程之后，CMS无法在当次收集中处理它们，只好留待在下一次GC时再清理掉，这一部分垃圾就称为“浮动垃圾”。
- 还有最后一点，CMS是一款基于“标记-清除”算法实现的收集器，这意味着收集结束时会有大量的空间碎片产生。空间碎片过多时，将会给大对象分配带来很大麻烦，往往会出现老年代还有很大空间剩余，但是无法找到足够大的连接空间来分配当前对象，不得不提前出发一次Full GC。为了解决这个问题，CMS收集器提供了一个-XX:+UseCMSCompactAtFullColletion开关参数（默认是开启的），用于在CMS收集器顶不住要进行Full GC时开启内存碎片合并整理过程，内存整理的过程是无法并发的，空间的碎片问题没有了，但停顿的时间不得不变长了。虚拟机设计者还提供了另外一个参数-XX:CMSFullGCsBeforeCompaction，这个参数是用于设置执行多少次不压缩的Full GC后，跟着来一次带压缩的（默认值为0，表示每次进入Full GC时都进行碎片整理）。
- G1收集器
G1（Garbage First）收集器是当今收集器技术发展的最前沿成果之一，从JDK 6u14中开始就有Early Acsess版本的G1收集器供开发人员实验、试用，由此开始G1收集器的 “Experimental” 状态持续了数年时间，直到JDK7u4，Sun公司才认为它达到足够成熟的商用程度，移除了“Experimental”的标识。G1是一款面向服务端应用的垃圾收集器。HotSpot开发团队赋予它的使命是未来可以替换掉JDK1.5中发布的CMS收集器。其与其它收集器相比，G1具备如下特点：
- 并行与并发：充分利用多个CPU、多核环境下的硬件优势，使用多个CPU来缩短stop-the-world停顿的时间，通过并发的方式让Java程序继续执行；
- 分代收集：分代概念在G1中依然得以保留。虽然G1可以不需要其它收集器配合就能独立管理整个GC堆，但它能够采用不同的方式去处理新创建的对象和已经存活了一段时间、熬过多次GC的旧对象以获取更好的收集效果。也就是说G1可以自己管理新生代和老年代了。
- 空间整合：由于G1使用了独立区域（Region）概念，G1从整体来看是基于“标记-整理”算法实现收集，从局部（两个Region）上来看是基于“复制”算法实现的，但无论如何，这两种算法都意味着G1运作期间不会产生内存空间碎片。
- 可预测的停顿：这是G1相对于CMS的另一大优势，降低停顿时间是G1和CMS共同的关注点，但G1除了追求低停顿外，还能建立可预测的停顿时间模型，能让使用这明确指定一个长度为M毫秒的时间片段内，消耗在垃圾收集上的时间不得超过N毫秒。
与其它收集器相比，G1变化较大的是它将整个Java堆划分为多个大小相等的独立区域（Region），虽然还保留了新生代和来年代的概念，但新生代和老年代不再是物理隔离的了它们都是一部分Region（不需要连续）的集合。同时，为了避免全堆扫描，G1使用了Remembered Set来管理相关的对象引用信息。当进行内存回收时，在GC根节点的枚举范围中加入Remembered Set即可保证不对全堆扫描也不会有遗漏了。
如果不计算维护Remembered Set的操作，G1收集器的运作大致可划分为以下几个步骤：
- 初始标记（Initial Making）
- 并发标记（Concurrent Marking）
- 最终标记（Final Marking）
- 筛选回收（Live Data Counting and Evacuation）
看上去跟CMS收集器的运作过程有几分相似。初始阶段仅仅只是标记一下GC Roots能直接关联到的对象，并且修改TAMS（Next Top Mark Start）的值，让下一阶段用户程序并发运行时，能在正确可以用的Region中创建新对象，这个阶段需要停顿线程，但耗时很短。并发标记阶段是从GC Roots开始对堆中对象进行可达性分析，找出存活对象，这一阶段耗时较长但能与用户线程并发运行。而最终标记阶段需要吧Remembered Set Logs的数据合并到Remembered Set中，这阶段需要停顿线程，但可并行执行。最后筛选回收阶段首先对各个Region的回收价值和成本进行排序，根据用户所期望的GC停顿时间来制定回收计划，这一过程同样是需要停顿线程的，但Sun公司透露这个阶段其实也可以做到并发，但考虑到停顿线程将大幅度提高收集效率，所以选择停顿。下图为G1收集器运行示意图：
1、Serial收集器
新生代单线程的收集器，采用复制算法，在进行收集垃圾时，必须stop the world，
它是虚拟机运行在Client模式下的默认新生代收集器；可以和Serial Old、CMS组合使用；
2、ParNew收集器
是Serial收集器的多线程版本，采用复制算法，回收时需要stop-the-world；
许多运行在Server模式下的虚拟机中首选的新生代收集器；可以和Serial Old、CMS组合使用；
除Serial外，只有它能与CMS收集器配合工作；
3、Parallel Scavenge收集器
新生代收集器，使用复制算法又是并行的多线程收集器，关注系统吞吐量；
参数：
-XX:MaxGCPauseMillis：最大垃圾收集停顿时间；
-XX:GCTimeRatio：吞吐量大小；
-XX:UseAdaptiveSizePolicy：自适应的调节策略；打开参数后就不需要手动指定新生代的大小、Eden与Survivor区的比例、晋升老年代对象年龄等细节参数了，虚拟机会根据当前系统的运行情况收集性能监控信息，动态调整相关参数；
4、Serial Old收集器
是Serial收集器的老年代版本，同样是单线程收集器，使用标记整理算法。
5、Parallel Old收集器
是Parallel Scavenge收集器的老年代版本，使用多线程和标记整理算法。
6、CMS收集器（Concurrent Mark Sweep）
老年代收集器；是一种以获得最短回收停顿时间为目标的收集器，基于标记清除算法。
过程如下：初始标记，并发标记，重新标记，并发清除；其中初始标记和重新标记过程需要stop-the-world；
优点是并发收集，低停顿，缺点是对CPU资源非常敏感，无法处理浮动垃圾，收集结束会产生大量空间碎片。
参数：
UserCMSCompactAtFullCollection：默认开启，FullGC时进行内存碎片整理，整理时用户进程需停止，即发生Stop The World；
CMSFullGCsBeforeCompaction：设置执行多少次不压缩的Full GC后，执行一个带压缩的（默认为0，表示每次进入Full GC时都进行碎片整理）；
7、G1收集器
是基于标记整理算法实现的，不会产生空间碎片，
过程：初始标记、并发标记、最终标记、筛选回收
优点：并行与并发、分代收集、空间整合、可预测的停顿；
可以精确地控制停顿，将堆划分为多个大小固定的独立区域，并跟踪这些区域的垃圾堆积程度，在后台维护一个优先列表，每次根据允许的收集时间，优先回收垃圾最多的区域（Garbage First）。
*1.ClassLoader类加载器
- 启动类加载器：Bootstrap ClassLoader，它负责加载存放在JDKjrelib(JDK代表JDK的安装目录，下同)下，或被-Xbootclasspath参数指定的路径中的，并且能被虚拟机识别的类库（如rt.jar，所有的java.*开头的类均被Bootstrap ClassLoader加载）。启动类加载器是无法被Java程序直接引用的。
- 扩展类加载器：Extension ClassLoader，该加载器由sun.misc.Launcher$ExtClassLoader实现，它负责加载JDKjrelibext目录中，或者由java.ext.dirs系统变量指定的路径中的所有类库（如javax.*开头的类），开发者可以直接使用扩展类加载器。
- 应用程序类加载器：Application ClassLoader，该类加载器由sun.misc.Launcher$AppClassLoader来实现，它负责加载用户类路径（ClassPath）所指定的类，开发者可以直接使用该类加载器，如果应用程序中没有自定义过自己的类加载器，一般情况下这个就是程序中默认的类加载器。
*2.双亲委派模型
双亲委派模型的工作流程是：如果一个类加载器收到了类加载的请求，它首先不会自己去尝试加载这个类，而是把请求委托给父加载器去完成，依次向上，因此，所有的类加载请求最终都应该被传递到顶层的启动类加载器中，只有当父加载器在它的搜索范围中没有找到所需的类时，即无法完成该加载，子加载器才会尝试自己去加载该类。
使用双亲委派模型来组织类加载器之间的关系，有一个很明显的好处，就是Java类随着它的类加载器（说白了，就是它所在的目录）一起具备了一种带有优先级的层次关系，这对于保证Java程序的稳定运作很重要。例如，类java.lang.Object类存放在JDKjrelib下的rt.jar之中，因此无论是哪个类加载器要加载此类，最终都会委派给启动类加载器进行加载，这便保证了Object类在程序中的各种类加载器中都是同一个类。
3.类加载简单过程
3、Bootstrap Loader（启动类加载器）是最顶级的类加载器了，其父加载器为null.
public static void main(String[] args) throws ClassNotFoundException {
ClassLoader loader = HelloWorld.class.getClassLoader();
System.out.println(loader);
//使用ClassLoader.loadClass()来加载类，不会执行初始化块
loader.loadClass("Test2");
//使用Class.forName()来加载类，默认会执行初始化块
// Class.forName("Test2");
//使用Class.forName()来加载类，并指定ClassLoader，初始化时不执行静态块
// Class.forName("Test2", false, loader);
}
}
static {
System.out.println("静态初始化块执行了！");
}
}
6.类加载器结构
Java 中的类加载器大致可以分成两类：
一类是系统提供的：
- 引导类加载器（bootstrapclass loader）：它用来加载 Java 的核心库，是用原生代码而不是java来实现的，并不继承自java.lang.ClassLoader，除此之外基本上所有的类加载器都是java.lang.ClassLoader类的一个实例。
- 扩展类加载器（extensionsclass loader）：它用来加载 Java 的扩展库。Java 虚拟机的实现会提供一个扩展库目录（一般为%JRE_HOME%/lib/ext）。该类加载器在此目录里面查找并加载 Java 类。
- 系统类加载器（systemclass loader或 App class loader）：它根据当前Java 应用的类路径（CLASSPATH）来加载 Java 类。一般来说，Java 应用的类都是由它来完成加载的。可以通过 ClassLoader.getSystemClassLoader() 来获取它。
另外一类则是由 Java 应用开发人员编写的：
- 开发人员可以通过继承java.lang.ClassLoader 类的方式实现自己的类加载器，以满足一些特殊的需求
从1.2版本开始，Java引入了双亲委托模型，从而更好的保证Java平台的安全。在此模型下，当一个装载器被请求装载某个类时，它首先委托自己的parent去装载，若parent能装载，则返回这个类所对应的Class对象，若parent不能装载，则由parent的请求者去装载。（为什么更加安全？因为在此模型下用户自定义的类装载器不可能装载应该由父亲装载器装载的可靠类，从而防止不可靠甚至恶意的代码代替由父亲装载器装载的可靠代码。）
具体示例：
假如loader2的parent为loader1，loader1的parent为system class loader。假设loader2被要求装载类MyClass，在parent delegation模型下，loader2首先请求loader1代为装载，loader1再请求系统类装载器去装载MyClass。若系统装载器能成功装载，则将MyClass所对应的Class对象的reference返回给loader1，loader1再将reference返回给loader2，从而成功将类MyClass装载进虚拟机。若系统类装载器不能装载MyClass，loader1会尝试装载MyClass，若loader1也不能成功装载，loader2会尝试装载。若所有的parent及loader2本身都不能装载，则装载失败。
参考：ClassLoader
*8.类加载过程
类从被加载到虚拟机内存中开始，到卸载出内存为止，它的整个生命周期包括：加载、验证、准备、解析、初始化、使用和卸载七个阶段。它们开始的顺序如下图所示：
其中类加载的过程包括了加载、验证、准备、解析、初始化五个阶段。在这五个阶段中，加载、验证、准备和初始化这四个阶段发生的顺序是确定的，而解析阶段则不一定，它在某些情况下可以在初始化阶段之后开始，这是为了支持Java语言的运行时绑定（也成为动态绑定或晚期绑定）。另外注意这里的几个阶段是按顺序开始，而不是按顺序进行或完成，因为这些阶段通常都是互相交叉地混合进行的，通常在一个阶段执行的过程中调用或激活另一个阶段。
加载
加载时类加载过程的第一个阶段，在加载阶段，虚拟机需要完成以下三件事情：
（1.字节流；2.方法区数据结构；3.访问入口）
1、通过一个类的全限定名来获取定义此类的二进制字节流。
2、将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构。
3、在内存中生成一个代表这个类的java.lang.Class对象，作为对方法区中这些数据的访问入口。
验证
验证的目的是为了确保Class文件中的字节流包含的信息符合当前虚拟机的要求，而且不会危害虚拟机自身的安全。不同的虚拟机对类验证的实现可能会有所不同，但大致都会完成以下四个阶段的验证：文件格式的验证、元数据的验证、字节码验证和符号引用验证。
- 文件格式的验证：验证字节流是否符合Class文件格式的规范，并且能被当前版本的虚拟机处理，该验证的主要目的是保证输入的字节流能正确地解析并存储于方法区之内。经过该阶段的验证后，字节流才会进入内存的方法区中进行存储，后面的三个验证都是基于方法区的存储结构进行的。
- 元数据验证：对类的元数据信息进行语义校验（其实就是对类中的各数据类型进行语法校验），保证不存在不符合Java语法规范的元数据信息。
- 字节码验证：该阶段验证的主要工作是进行数据流和控制流分析，对类的方法体进行校验分析，以保证被校验的类的方法在运行时不会做出危害虚拟机安全的行为。
- 符号引用验证：这是最后一个阶段的验证，它发生在虚拟机将符号引用转化为直接引用的时候（解析阶段中发生该转化，后面会有讲解），主要是对类自身以外的信息（常量池中的各种符号引用）进行匹配性的校验。
准备
准备阶段是正式为类变量分配内存并设置类变量初始值的阶段，这些内存都将在方法区中分配。对于该阶段有以下几点需要注意：
1、这时候进行内存分配的仅包括类变量（static），而不包括实例变量，实例变量会在对象实例化时随着对象一块分配在Java堆中。
2、这里所设置的初始值通常情况下是数据类型默认的零值（如0、0L、null、false等），而不是被在Java代码中被显式地赋予的值。
解析