JVM复习目录
JVM内容概览
- 代码执行
- Java源文件 —>编译器 —>字节码文件
- 字节码文件 —>JVM—>机器码
- 内存管理
- 线程同步
- 练习题
JVM复习思维导图
JVM运行时数据区域、线程共享私有等
JVM线程分类
| 线程信息 | 责任 |
|---|---|
| 虚拟机线程（VM thread） | 这个线程等待 JVM 到达安全点操作出现。这些操作必须要在独立的线程里执行，因为当堆修改无法进行时，线程都需要 JVM 位于安全点。这些操作的类型有：stop-the-world 垃圾回收、线程栈 dump、线程暂停、线程偏向锁（biased locking）解除。 |
| 周期性任务线程 | 这线程负责定时器事件（也就是中断），用来调度周期性操作的执行。 |
| GC 线程 | 这些线程支持 JVM 中不同的垃圾回收活动。 |
| 编译器线程 | 这些线程在运行时将字节码动态编译成本地平台相关的机器码。 |
| 信号分发线程 | 这个线程接收发送到 JVM 的信号并调用适当的 JVM 方法处理。 |
JVM内存区域
- 程序计数器(线程私有)：
当前线程所执行的字节码的行号指示器每条线程都要有一个独立的程序计数器，这类内存也称为“线程私有”的内存。正在执行java方法的话，计数器记录的是虚拟机字节码指令的地址（当前指令的地址）。如果还是Native方法，则为空。这个内存区域是唯一一个在虚拟机中没有规定任何OutOfMemoryError情况的区域 - 虚拟机栈(线程私有)：描述java方法执行的内存模型，每个方法在执行的同时都会创建一个栈帧（Stack Frame）用于存储局部变量表、操作数栈、动态链接、方法出口等信息。每一个方法从调用直至执行完成的过程，就对应着一个栈帧在虚拟机栈中入栈到出栈的过程。
- 本地方法栈(线程私有)：本地方法区和Java Stack作用类似, 区别是虚拟机栈为执行Java方法服务, 而本地方法栈则为Native方法服务, 如果一个VM实现使用C-linkage模型来支持Native调用, 那么该栈将会是一个C栈，但HotSpot VM直接就把本地方法栈和虚拟机栈合二为一。
- 堆(线程共享)：是被线程共享的一块内存区域，创建的对象和数组都保存在Java堆内存中，也是垃圾收集器进行垃圾收集的最重要的内存区域。由于现代VM采用分代收集算法, 因此Java堆从GC的角度还可以细分为: 新生代(Eden区、From Survivor区和To Survivor区)和老年代
- 方法区/永久代(线程共享)：用于存储被JVM加载的类信息、常量、静态变量、即时编译器编译后的代码等数据，
运行时常量池（Runtime Constant Pool）是方法区的一部分，用于存放编译期生成的各种字面量和符号引用，这部分内容将在类加载后存放到方法区的运行时常量池中。 Java虚拟机对Class文件的每一部分（自然也包括常量池）的格式都有严格的规定，每一个字节用于存储哪种数据都必须符合规范上的要求，这样才会被虚拟机认可、装载和执行
直接内存：并不是JVM运行时数据区的一部分, 但也会被频繁的使用: 在JDK 1.4引入的NIO提供了基于Channel与Buffer的IO方式, 它可以使用Native函数库直接分配堆外内存, 然后使用DirectByteBuffer对象作为这块内存的引用进行操作(详见: Java I/O 扩展), 这样就避免了在Java堆和Native堆中来回复制数据, 因此在一些场景中可以显著提高性能。
JVM堆内存
Java堆从GC的角度还可以细分为: 新生代(Eden区、From Survivor区和To Survivor区)和老年代
新生代
- 新生代：是用来存放新生的对象。一般占据堆的1/3空间。由于频繁创建对象，所以新生代会频繁触发MinorGC进行垃圾回收。新生代又分为 Eden区、ServivorFrom、ServivorTo三个区
- Eden区：Java新对象的出生地（如果新创建的对象占用内存很大，则直接分配到老年代）。当Eden区内存不够的时候就会触发MinorGC，对新生代区进行一次垃圾回收
- ServivorFrom：上一次GC的幸存者，作为这一次GC的被扫描者。
- ServivorTo：保留了一次MinorGC过程中的幸存者。
MinorGC的过程（复制->清空->互换），MinorGC采用
复制算法，当Eden区内存不够的时候就会触发MinorGC
- eden、servivorFrom 复制到ServivorTo，年龄+1
首先，把Eden和ServivorFrom区域中存活的对象复制到ServivorTo区域（如果有对象的年龄以及达到了老年的标准，则赋值到老年代区），同时把这些对象的年龄+1（如果ServivorTo不够位置了就放到老年区 ，默认情况下年龄到达15的对象会被移到老年代中）；- 清空eden、servivorFrom
然后，清空Eden和ServivorFrom中的对象；- ServivorTo和ServivorFrom互换
最后，ServivorTo和ServivorFrom互换，原ServivorTo成为下一次GC时的ServivorFrom区。
老年代
主要存放应用程序中生命周期长的内存对象。老年代的对象比较稳定，所以MajorGC不会频繁执行。在进行MajorGC前一般都先进行了一次MinorGC，使得有新生代的对象晋身入老年代，导致空间不够用时才触发。当无法找到足够大的连续空间分配给新创建的较大对象时也会提前触发一次MajorGC进行垃圾回收腾出空间。
MajorGC采用
标记清除算法：首先扫描一次所有老年代，标记出存活的对象，然后回收没有标记的对象。MajorGC的耗时比较长，因为要扫描再回收。MajorGC会产生内存碎片，为了减少内存损耗，我们一般需要进行合并或者标记出来方便下次直接分配。当老年代也满了装不下的时候，就会抛出OOM（Out of Memory）异常
永久代
指内存的永久保存区域，主要存放Class和Meta（元数据）的信息,Class在被加载的时候被放入永久区域，它和和存放实例的区域不同,GC不会在主程序运行期对永久区域进行清理。所以这也导致了永久代的区域会随着加载的Class的增多而胀满，最终抛出OOM异常。
JAVA8与元数据
在Java8中，永久代已经被移除，被一个称为“元数据区”（元空间）的区域所取代。元空间的本质和永久代类似，元空间与永久代之间最大的区别在于：元空间并不在虚拟机中，而是使用本地内存。因此，默认情况下，元空间的大小仅受本地内存限制。类的元数据放入 native memory, 字符串池和类的静态变量放入java堆中，这样可以加载多少类的元数据就不再由MaxPermSize控制, 而由系统的实际可用空间来控制。
JVM垃圾回收
垃圾判断方式
- 引用计数法
在Java中，引用和对象是有关联的。如果要操作对象则必须用引用进行。因此，很显然一个简单的办法是通过引用计数来判断一个对象是否可以回收。简单说，即一个对象如果没有任何与之关联的引用，即他们的引用计数都不为0，则说明对象不太可能再被用到，那么这个对象就是可回收对象。 - 可达性分析
为了解决引用计数法的循环引用问题，Java使用了可达性分析的方法。通过一系列的“GC roots”对象作为起点搜索。如果在“GC roots”和一个对象之间没有可达路径，则称该对象是不可达的。要注意的是，不可达对象不等价于可回收对象，不可达对象变为可回收对象至少要经过两次标记过程。两次标记后仍然是可回收对象，则将面临回收
gc roots对象有哪些
（1）虚拟机栈（栈帧中的本地变量表）中引用的对象。
（2）方法区中的类静态属性引用的对象。
（3）方法区中常量引用的对象。
（4）本地方法栈中JNI(即一般说的Native方法)引用的对象。
（5）正在运行的线程。
垃圾回收算法
标记清除算法（Mark-Sweep）
最基础的垃圾回收算法，分为两个阶段，标注和清除。标记阶段标记出所有需要回收的对象，清除阶段回收被标记的对象所占用的空间
劣势：从图中我们就可以发现，该算法最大的问题是内存碎片化严重，后续可能发生大对象不能找到可利用空间的问题
复制算法（copying）
为了解决Mark-Sweep算法内存碎片化的缺陷而被提出的算法。按内存容量将内存划分为等大小的两块。每次只使用其中一块，当这一块内存满后将尚存活的对象复制到另一块上去，把已使用的内存清掉
劣势：算法虽然实现简单，内存效率高，不易产生碎片，但是最大的问题是可用内存被压缩到了原本的一半。且存活对象增多的话，Copying算法的效率会大大降
标记整理算法(Mark-Compact)
结合了以上两个算法，为了避免缺陷而提出。标记阶段和Mark-Sweep算法相同，标记后不是清理对象，而是将存活对象移向内存的一端。然后清除端边界外的对象
优点：
- 消除了标记-清楚算法当中，内存区域分散的缺点，我们需要给新对象分配内存时，JVM只需要维持有一个内存的起始地址即可。
- 消除了复制算法当中，内存减半的高额代价。
缺点：
- 从效率上来说，标记-整理算法低于复制算法。
- 移动对象的同时，如果对象被其他对象引用，则还需要调整引用的地址。
- 移动过程中，需要全程暂停用户应用程序。即：STW。
四种引用类型
- 强引用
在Java中最常见的就是强引用，把一个对象赋给一个引用变量，这个引用变量就是一个强引用。当一个对象被强引用变量引用时，它处于可达状态，它是不可能被垃圾回收机制回收的，即使该对象以后永远都不会被用到JVM也不会回收。因此强引用是造成Java内存泄漏的主要原因之一。 - 软引用
软引用需要用SoftReference类来实现，对于只有软引用的对象来说，当系统内存足够时它不会被回收，当系统内存空间不足时它会被回收。软引用通常用在对内存敏感的程序中。 - 弱引用
弱引用需要用WeakReference类来实现，它比软引用的生存期更短，对于只有弱引用的对象来说，只要垃圾回收机制一运行，不管JVM的内存空间是否足够，总会回收该对象占用的内存。 - 虚引用
虚引用需要PhantomReference类来实现，它不能单独使用，必须和引用队列联合使用。虚引用的主要作用是跟踪对象被垃圾回收的状态。
垃圾收集器
Serial
单线程、复制算法，曾经是JDK1.3.1之前新生代唯一的垃圾收集器。Serial是一个单线程的收集器，它不但只会使用一个CPU或一条线程去完成垃圾收集工作，并且在进行垃圾收集的同时，必须暂停其他所有的工作线程，直到垃圾收集结束。 Serial垃圾收集器虽然在收集垃圾过程中需要暂停所有其他的工作线程，但是它简单高效，对于限定单个CPU环境来说，没有线程交互的开销，可以获得最高的单线程垃圾收集效率，因此Serial垃圾收集器依然是java虚拟机运行在Client模式下默认的新生代垃圾收集器
ParNew垃圾收集器
多线程、复制算法，ParNew垃圾收集器其实是Serial收集器的多线程版本，也使用复制算法，除了使用多线程进行垃圾收集之外，其余的行为和Serial收集器完全一样，ParNew垃圾收集器在垃圾收集过程中同样也要暂停所有其他的工作线程。ParNew收集器默认开启和CPU数目相同的线程数，可以通过-XX:ParallelGCThreads参数来限制垃圾收集器的线程数。【Parallel：平行的】 ParNew虽然是除了多线程外和Serial收集器几乎完全一样，但是ParNew垃圾收集器是很多java虚拟机运行在Server模式下新生代的默认垃圾收集器。
Parallel Scavenge收集器
多线程、复制算法，Parallel Scavenge收集器也是一个新生代垃圾收集器，同样使用复制算法，也是一个多线程的垃圾收集器，它重点关注的是程序达到一个可控制的吞吐量（Thoughput，CPU用于运行用户代码的时间/CPU总消耗时间，即吞吐量=运行用户代码时间/(运行用户代码时间+垃圾收集时间)），高吞吐量可以最高效率地利用CPU时间，尽快地完成程序的运算任务，主要适用于在后台运算而不需要太多交互的任务。自适应调节策略也是ParallelScavenge收集器与ParNew收集器的一个重要区别。
Serial Old收集器
单线程标记整理算法，Serial Old是Serial垃圾收集器年老代版本，它同样是个单线程的收集器，使用标记-整理算法，这个收集器也主要是运行在Client默认的java虚拟机默认的年老代垃圾收集器。
在Server模式下，主要有两个用途：
- 在JDK1.5之前版本中与新生代的Parallel Scavenge收集器搭配使用。
- 作为年老代中使用CMS收集器的后备垃圾收集方案。
新生代Serial与年老代Serial Old搭配垃圾收集过程图
新生代Parallel Scavenge/ParNew与年老代Serial Old搭配垃圾收集过程图
Parallel Old收集器
多线程标记整理算法，Parallel Old收集器是Parallel Scavenge的年老代版本，使用多线程的标记-整理算法，在JDK1.6才开始提供。 在JDK1.6之前，新生代使用ParallelScavenge收集器只能搭配年老代的Serial Old收集器，只能保证新生代的吞吐量优先，无法保证整体的吞吐量，Parallel Old正是为了在年老代同样提供吞吐量优先的垃圾收集器，如果系统对吞吐量要求比较高，可以优先考虑新生代Parallel Scavenge和年老代Parallel Old收集器的搭配策略
新生代Parallel Scavenge和年老代Parallel Old收集器搭配运行过程图：
CMS收集器
Concurrent mark sweep(CMS)收集器是一种年老代垃圾收集器，其最主要目标是获取最短垃圾回收停顿时间，和其他年老代使用标记-整理算法不同，它使用多线程的标记-清除算法。 最短的垃圾收集停顿时间可以为交互比较高的程序提高用户体验。 CMS工作机制相比其他的垃圾收集器来说更复杂，整个过程分为以下4个阶段：
- 初始标记
只是标记一下GC Roots能直接关联的对象，速度很快，仍然需要暂停所有的工作线程。 - 并发标记
进行GC Roots跟踪的过程，和用户线程一起工作，不需要暂停工作线程。 - 重新标记
为了修正在并发标记期间，因用户程序继续运行而导致标记产生变动的那一部分对象的标记记录，仍然需要暂停所有的工作线程。 - 并发清除
清除GC Roots不可达对象，和用户线程一起工作，不需要暂停工作线程。由于耗时最长的并发标记和并发清除过程中，垃圾收集线程可以和用户现在一起并发工作，所以总体上来看CMS收集器的内存回收和用户线程是一起并发地执行
G1收集器
Garbage first 垃圾收集器是目前垃圾收集器理论发展的最前沿成果，相比与 CMS 收集器， G1 收
集器两个最突出的改进是：
- 基于标记-整理算法，不产生内存碎片。
- 可以非常精确控制停顿时间，在不牺牲吞吐量前提下，实现低停顿垃圾回收。
G1 收集器避免全区域垃圾收集，它把堆内存划分为大小固定的几个独立区域，并且跟踪这些区域
的垃圾收集进度，同时在后台维护一个优先级列表，每次根据所允许的收集时间， 优先回收垃圾
最多的区域。区域划分和优先级区域回收机制，确保 G1 收集器可以在有限时间获得最高的垃圾收
集效率。
JVM IO/NIO
阻塞IO
案例：data = socket.read();如果数据没有就绪，就会一直阻塞在 read 方法
缺点：会让用户线程进入阻塞
非阻塞IO
需要一个用户线程while循环不间断地询问数据是否就绪
while(true){
data = socket.read();
if(data!= error){
//处理数据
break;
}
}
缺点：CPU占用率变高
多路复用IO
selector.select()：一个线程不间断地询问多路数据是否就绪
- 优点：多路复用 IO 为何比非阻塞 IO 模型的效率高是因为在非阻塞 IO 中，不断地询问 socket 状态是通过用户线程去进行的，而在多路复用 IO 中，轮询每个 socket 状态是内核在进行的，这个效率要比用户线程要高的多
- 缺点：于多路复用 IO 模型来说， 一旦事件响应体很大，那么就会导致后续的事件迟迟得不到处理，并且会影响新的事件轮询
异步IO
最理想的IO模型：当用户线程发起 read 操作之后，立刻就可以开始去做其它的事。而另一方面，从内核的角度，当它受到一个 asynchronous read 之后，它会立刻返回，说明 read 请求已经成功发起了，因此不会对用户线程产生任何 block。然后，内核会等待数据准备完成，然后将数据拷贝到用户线程，当这一切都完成之后，内核会给用户线程发送一个信号，告诉它 read 操作完成了
只需要先发起一个请求，当接收内核返回的成功信号时表示 IO 操作已经完成，可以直接去使用数据了
注意：异步 IO 是需要操作系统的底层支持，在 Java 7 中，提供了 Asynchronous IO
JAVA IO包
IO 包中用到的设计模式
- 装饰器模式（Decorator Pattern）
// 创建一个文件并写入内容
File file = new File("example.txt");
OutputStream outputStream = new FileOutputStream(file);
outputStream.write("Hello, World!".getBytes());
outputStream.close();
// 使用装饰器模式添加缓冲功能
InputStream inputStream = new BufferedInputStream(new FileInputStream(file));
int data = inputStream.read();
while(data != -1){
System.out.print((char) data);
data = inputStream.read();
}
inputStream.close();
- 适配器模式（Adapter Pattern）
// 创建一个文件并写入内容
File file = new File("example.txt");
OutputStream outputStream = new FileOutputStream(file);
outputStream.write("Hello, World!".getBytes());
outputStream.close();
// 使用适配器模式将字节流转换为字符流
Reader reader = new InputStreamReader(new FileInputStream(file));
int data = reader.read();
while(data != -1){
System.out.print((char) data);
data = reader.read();
}
reader.close();
JAVA NIO
NIO 主要有三大核心部分：
- Channel(通道)：Channel 和 IO 中的 Stream(流)是差不多一个等级的。 只不过 Stream 是单向的，譬如： InputStream, OutputStream， 而 Channel 是双向的，既可以用来进行读操作，又可以用来进行写操作
NIO 中的 Channel 的主要实现有：
FileChannel
DatagramChannel
SocketChannel
ServerSocketChannel
这里看名字就可以猜出个所以然来：分别可以对应文件 IO、 UDP 和 TCP（Server 和 Client）。
-
Buffer(缓冲区)：缓冲区，实际上是一个容器，是一个连续数组。 Channel 提供从文件、网络读取数据的渠道，但是读取或写入的数据都必须经由 Buffer
-
Selector：Selector 能够检测多个注册的通道上是否有事件发生，如果有事件发生，便获取事件然后针对每个事件进行相应的响应处理。只是用一个单线程就可以管理多个通道，也就是管理多个连接。这样使得只有在连接真正有读写事件发生时，才会调用函数来进行读写，就大大地减少了系统开销，并且不必为每个连接都创建一个线程，不用去维护多个线程，并且避免了多线程之间的上下文切换导致的开销
传统 IO 基于字节流和字符流进行操作， 而 NIO 基于 Channel 和 Buffer(缓冲区)进行操作，数据总是从通道读取到缓冲区中，或者从缓冲区写入到通道中。 Selector(选择区)用于监听多个通道的事件（比如：连接打开，数据到达）。因此，单个线程可以监听多个数据通道。
NIO 和传统 IO 之间第一个最大的区别是， IO 是面向流的， NIO 是面向缓冲区的
缓冲区的作用
为什么需要缓冲区？
在理解缓冲区之前，我们需要了解一下 IO 操作的工作原理。在进行 IO 操作时，数据是从输入源（比如文件或网络）读取到内存中，或者从内存写入到输出源。这个过程需要频繁地访问底层资源，比如磁盘、网络等。直接对底层资源进行读写操作，会导致频繁的系统调用，从而增加了 IO 操作的开销。
缓冲区的作用就是在内存中创建一个缓存区域，将需要读写的数据先读取到缓冲区中，在缓冲区中进行操作，最后再一次性将数据写入到底层资源中。这样可以减少对底层资源的访问次数，提高 IO 操作的效率。
缓冲区的类型（直接/非直接）
- 非直接缓冲区：
NIO通过通道连接磁盘文件与应用程序，通过缓冲区存取数据进行双向的数据传输。物理磁盘的存取是操作系统进行管理的，与物理磁盘的数据操作需要经过内核地址空间；而我们的Java应用程序是通过JVM分配的内存空间，属于应用程序的内存空间。数据需要在内核地址空间和用户地址空间，在操作系统和JVM之间进行数据的来回拷贝，无形中增加的中间环节使得效率与后面要提的之间缓冲区相比偏低。
读操作：当有数据读取的时候，os系统现将数据先读入内核地址空间中，然后将内核空间的数据复制一份到用户地址空间中，然后再读入用户程序。
写操作：当有数据要写入的时候，现将数据通过管道写入用户地址空间中，然后将用户地址空间的数据复制一份到内核地址空间中，然后再由os写入磁盘。（复制到内核地址空间后数据什么时候写入磁盘，不是程序所决定的）
- 直接缓冲区
直接缓冲区则不再通过内核地址空间和用户地址空间的缓存数据的复制传递，而是在物理内存中申请了一块空间，这块空间映射到应用程序和物理磁盘，不再经过内核地址空间和用户地址空间，应用程序与磁盘之间的数据存取之间通过这块直接申请的物理内存进行，起到了中间媒介的作用。
使用Native函数库直接分配堆外内存,然后通过一个存储在Java堆中的DirectByteBuffer对象作为这块内存的引用进行操作，在垃圾回收时并不能用程序区控制堆外内存的回收，因为不属于虚拟机，只能是垃圾回收机制按需对堆内的DirectByteBuffer对象进行回收，回收后将与直接缓存区失去联系，也就意味着直接缓冲区被回收。
在直接缓冲区谨慎使用原因：
（1）不安全
（2）消耗更多，因为它不是在JVM中直接开辟空间。这部分内存的回收只能依赖于垃圾回收机制，垃圾什么时候回收不受我们控制；
（3）数据写入物理内存缓冲区中，程序就失去了对这些数据的管理，即什么时候这些数据被最终写入从磁盘只能由操作系统来决定，应用程序无法再干涉。
（4）堆外空间分配比较耗时。
JVM 类加载
类加载过程
JVM 类加载机制分为五个部分：加载，验证，准备，解析，初始化，下面我们就分别来看一下这五个过程
- 加载
加载是类加载过程中的一个阶段， 这个阶段会在内存中生成一个代表这个类的 java.lang.Class 对象， 作为方法区这个类的各种数据的入口。注意这里不一定非得要从一个 Class 文件获取
可以从 ZIP 包中读取（比如从 jar 包和 war 包中读取
运行时计算生成（动态代理）
由其它文件生成（比如将 JSP 文件转换成对应的 Class 类）
- 验证
这一阶段的主要目的是为了确保 Class 文件的字节流中包含的信息是否符合当前虚拟机的要求，并且不会危害虚拟机自身的安全。 - 准备
准备阶段是正式为类变量分配内存并设置类变量的初始值阶段，即在方法区中分配这些变量所使用的内存空间。
public static int v = 8080;
实际上变量 v 在准备阶段过后的初始值为 0 而不是 8080， 将 v 赋值为 8080 的 put static 指令是
程序被编译后， 存放于类构造器方法之中。
但是注意如果声明为：
public static final int v = 8080;
在编译阶段会为 v 生成 ConstantValue 属性，在准备阶段虚拟机会根据 ConstantValue 属性将 v
赋值为 8080。 - 解析
虚拟机将常量池中的符号引用替换为直接引用的过程
符号引用就是 class 文件中的：
CONSTANT_Class_info
CONSTANT_Field_info
CONSTANT_Method_info
等类型的常量。 - 初始化
初始化阶段是类加载最后一个阶段，前面的类加载阶段之后，除了在加载阶段可以自定义类加载
器以外，其它操作都由 JVM 主导。到了初始阶段，才开始真正执行类中定义的 Java 程序代码。
初始化阶段是执行类构造器方法的过程。 方法是由编译器自动收集类中的类变量的赋值操作和静态语句块中的语句合并而成的。虚拟机会保证子方法执行之前，父类的方法已经执行完毕， 如果一个类中没有对静态变量赋值也没有静态语句块，那么编译器可以不为这个类生成()方法
注意以下几种情况不会执行类初始化：
- 通过子类引用父类的静态字段，只会触发父类的初始化，而不会触发子类的初始化。
- 定义对象数组，不会触发该类的初始化。
- 常量在编译期间会存入调用类的常量池中，本质上并没有直接引用定义常量的类，不会触发定义常量所在的类。
- 通过类名获取 Class 对象，不会触发类的初始化。
- 通过 Class.forName 加载指定类时，如果指定参数 initialize 为 false 时，也不会触发类初始化，其实这个参数是告诉虚拟机，是否要对类进行初始化。
- 通过 ClassLoader 默认的 loadClass 方法，也不会触发初始化动作
类加载器
- 启动类加载器(Bootstrap ClassLoader)
负责加载 JAVA_HOME\lib 目录中的， 或通过-Xbootclasspath 参数指定路径中的， 且被虚拟机认可（按文件名识别， 如 rt.jar） 的类 - 扩展类加载器(Extension ClassLoader)
负责加载 JAVA_HOME\lib\ext 目录中的，或通过 java.ext.dirs 系统变量指定路径中的类库 - 应用程序类加载器(Application ClassLoader)：
负责加载用户路径（classpath）上的类库。JVM 通过双亲委派模型进行类的加载， 当然我们也可以通过继承 java.lang.ClassLoader实现自定义的类加载器。
加载过程：当一个类收到了类加载请求，他首先不会尝试自己去加载这个类，而是把这个请求委派给父类去完成，每一个层次类加载器都是如此，因此所有的加载请求都应该传送到启动类加载其中，只有当父类加载器反馈自己无法完成这个请求的时候（在它的加载路径下没有找到所需加载的Class）， 子类加载器才会尝试自己去加载。
采用双亲委派的一个好处是比如加载位于 rt.jar 包中的类 java.lang.Object，不管是哪个加载器加载这个类，最终都是委托给顶层的启动类加载器进行加载，这样就保证了使用不同的类加载器最终得到的都是同样一个 Object 对象
2894
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
