虚拟机运行机制

JVM运行在操作系统上，不与硬件设施间接交互。

Java程序执行流程：Java源代码文件（ Hello.java）被编译器编译成字节码文件（ Hello.class），字节码文件被JVM中的解释器编译成机器码在不同操作系统上运行。

Java程序具体运行过程：

Java源文件被编译成字节码文件

JVM将字节码文件通过JVM外部解释器编译成与操作系统对应的机器码

机器码调用相应操作系统的Native Method库执行相应办法

Java跨平台的起因：每种操作系统的解释器都是不同的，但基于解释器实现的虚拟机是雷同的。

虚拟机实例生命周期形容：在一个Java过程开始运行后，虚拟机就开始实例化，有多个过程启动就会实例化多个虚拟机实例。过程退出或敞开，则虚拟机实例销毁，java培训在多个虚拟机实例之间不能共享数据。

虚拟机内部结构

JVM包含一个类加载器子系统（Class Loader Subsystem）、运行时数据区（Runtime Data Area）、执行引擎（Engine）和本地接口库（Nateive Interface Library）。

本地接口库调用本地办法库（Native Method Library）与OS交互。

JVM外部结构图如下：

其中：

类加载器子系统用于将编译好的字节码文件（ .class）加载到JVM。

运行时数据区用于存储在JVM运行过程中产生的数据，包含程序计数器（PC）、办法区（Method Area）、本地办法区（Native Method Area）、虚拟机栈（JVM Stack）、虚拟机堆（JVM Heap）。

执行引擎包含即时编译器（JIT Compiler）和垃圾回收器（Garbage Collection）。

即时编译器用于将字节码编译成具体的机器码。

垃圾回收器用于治理内存，回收在运行过程中不再应用的对象。

本地接口库用于调用操作系统的本地办法库实现具体的指令操作。

虚拟机与多线程

在多核操作系统上，JVM容许在一个过程内同时并发执行多个线程。

JVM中的线程与操作系统中的线程是互相对应的。

JVM线程的调度是交给操作系统负责的。

有些程序语言有协程的概念，如Golang的并发，协程能够粗略地看成是轻量级的线程，一个协程并非对应一个操作系统线程，而是多个协程对应一个操作系统线程，协程之间通过调度器协调。

这种设计有以下的益处：

轻量级，资源占用较少。

调度是基于语言层面，缩小操作系统线程调度的开销。

从JVM角度看，Java线程的执行流程：

筹备：实现JVM线程的本地存储、缓冲区调配、同步对象、栈、程序计数器等初始化工作。

创立：调用操作系统接口创立一个与之对应的原生线程。

调度：操作系统负责调度所有线程，并为其调配CPU工夫片。

执行：在原生线程初始化结束时，调用Java线程的 run()办法执行线程逻辑。

完结：在 run()办法逻辑执行结束后，开释原生线程和Java线程所对应的资源。

回收：在Java线程运行完结时，原生线程随之被回收。

在JVM后盾运行的线程次要有：

虚拟机线程（JVM Thread）：虚拟机线程在JVM达到平安点（Safe Point）时呈现。

周期性工作线程：通过定时器调度线程来实现周期性操作的执行。

GC线程：GC线程反对JVM中不同的垃圾回收流动。

编译器线程：编译器线程在运行时将字节码动静编译成本地平台机器码，是JVM跨平台的具体实现。

信号散发线程：接管发送到JVM的信号并调用JVM办法。

虚拟机内存区域

JVM的内存区域分为：

线程公有区域：线程公有区域包含的组件有程序计数器、虚拟机栈、本地办法区。

线程共享区域：虚拟机堆、办法区。

间接内存

线程公有区域的生命周期与线程雷同，随线程的启动而创立，随线程的完结而销毁。

在JVM中，每个Java线程与操作系统本地线程间接映射，因而这部分内存区域的存在与否和本地线程的启动和销毁对应。

线程共享区域随虚拟机的启动而创立，随虚拟机的敞开而销毁。

间接内存又称为对外内存，间接内存不是JVM运行时数据区的一部分，但在并发编程中被频繁调用。

JDK的NIO模块提供的基于 Channel与 Buffer的I/O操作就是基于堆外内存实现的，NIO模块通过调用Native Method Library间接在操作系统上调配堆外内存，而后应用 DirectByteBuffer对象作为这块内存的援用对内存进行操作，Java过程能够通过堆外内存技术防止在Java堆和Native堆中来回复制数据带来的资源占用和性能耗费，因而堆外内存在高并发利用场景下被宽泛应用（Netty、Flink、HBase、Hadoop都有用到堆外内存）。

程序计数器

程序计数器（PC）属于线程公有区域，程序计数器是惟一无内存溢出（Out of Memory）问题的区域。

程序计数器是一块很小的内存空间，用于存储以后运行的线程所执行的字节码的行号指示器。

每个运行中的线程都有一个独立的程序计数器，在办法正在执行时，该办法的程序计数器记录的是实时虚拟机字节码指令的地址。

注：如果该办法执行的是 native办法，则程序计数器的值为空（Undefined）。

虚拟机栈

虚拟机栈（JVM Stack）属于线程公有区域，形容Java办法的执行过程。

虚拟机栈是形容Java办法的执行过程的内存模型，它在以后栈帧（Stack Frame）中次要存储了以下信息：

局部变量表

操作数栈

动静链接

办法进口

同时，栈帧用来存储局部运行时数据及其数据结构，解决动静链接（Dynamic Linking）办法的返回值和异样分派（Dispatch Exception）。

栈帧：栈帧用来记录办法的执行过程。

办法被执行时，虚构机会为其创立一个与之对应的栈帧。

虚拟机栈中的入栈操作：办法的执行。

虚拟机栈中的出栈操作：办法的返回。

无论办法是失常运行实现，还是异样（抛出了在办法内未被捕捉的异样）退出，都认为办法运行完结。

线程运行及栈帧的变动过程如下：

线程1在CPU1上运行，线程2在CPU2上运行，在CPU资源不够时其余线程将处于期待状态（图中的线程N），期待获取CPU工夫片。而在线程外部，每个办法的执行和返回都对应一个栈帧的入栈和出栈，每个运行中的线程以后只有一个栈帧处于活动状态。

本地办法区

本地办法区（Native Method Area）和虚拟机栈的作用相似，区别是虚拟机栈是为执行Java办法服务的，本地办法区是为Native办法服务的。

虚拟机堆

虚拟机堆（JVM Heap），也称为运行时数据区，虚拟机堆是线程共享的。

在JVM运行过程中创立的对象和产生的数据都被存储在堆中，堆是被线程共享的内存区域，也是垃圾回收器进行垃圾回收的最次要的内存区域。

因为古代JVM采纳分代收集算法，因而Java堆从GC（Garbage Collection，垃圾回收）的角度还能够细分为：新生代、老年代和永恒代。

办法区

办法区（Method Area），也被称为永恒代，用于存储常量、动态变量、类信息、JIT编译后的机器码、运行时常量池等数据。

JVM把GC分代收集扩大至办法区，即应用Java堆的永恒代来实现办法区，这样JVM的垃圾收集器就能够像治理Java堆一样治理这部分内存。永恒带的内存回收次要针对常量池的回收和类的卸载，因而可回收的对象很少。

常量被存储在运行时常量池（Runtime Constant Pool）中，是办法区的一部分。动态变量也属于办法区的一部分。在类信息（Class文件）中岂但保留了类的版本、字段、办法、接口等形容信息，还保留了常量信息。

在即时编译后，代码的内容将在执行阶段（类加载实现后）被保留在办法区的运行时常量池中。Java虚拟机对Class文件每一部分的格局都有明确的规定，只有合乎JVM标准的Class文件能力通过虚拟机的查看，而后被装载、执行。

虚拟机运行时内存

JVM的运行时内存也叫做JVM堆，从GC的角度能够将JVM堆分为新生代、老年代和永恒代。

其中，新生代默认占1/3堆空间，老年代默认占2/3堆空间。

新生代又分为Eden区、ServivorFrom和ServivorTo区。

Eden区默认占8/10新生代空间。

ServivorForm区和ServivorTo区默认别离占1/10新生代空间。

JVM堆分代分区的构造如下：

JVM新创建的对象（除了大对象）都会被寄存在新生代，默认占1/3堆内存空间。

因为JVM会频繁创建对象，所以新生代会频繁登程MinorGC进行垃圾回收。

新生代

新生代分为Eden区（8/10新生代空间）、ServivorFrom区（1/10新生代空间）、ServivorTo区（1/10新生代空间）。

Eden区：Java新创建的对象首先会被寄存在Eden区，如果新创建的对象属于大对象，则间接将其调配到老年代。

大对象的定义和具体的JVM版本、堆大小和垃圾回收策略无关，个别为 2KB～128KB，可通过 XX:PretenureSizeThreshold设置其大小。

在Eden区的内存空间有余时会触发MinorGC，对新生代进行一次垃圾回收。

ServivorTo区：保留上一次MinorGC时的幸存者。

ServivorFrom区：将上一次MinorGC时的幸存者作为这一次MinorGC的被扫描者。

新生代的GC过程叫做MinorGC，采纳复制算法实现，具体过程如下：

将Eden区和ServivorFrom区中存活的对象复制到ServivorTo区，如果某对象的年龄达到老年代的规范，则将其复制到老年代，同时将这些对象年龄加1。

对象降职老年代的规范由 XX:MaxTenuringThreshold设置，默认为 15。

如果ServivorTo区的内存空间不够，则也间接将其复制到老年代。

如果对象属于大对象，也间接将其复制到老年代。

清空Eden区和ServivorFrom区对象。

将ServivorTo区和ServivorFrom区调换，原来的ServivorTo区成为下一次GC时的ServivorFrom区。

老年代

老年代次要寄存长生命周期对象和大对象。

老年代的GC过程叫做MajorGC，在老年代，对象比较稳定，MajorGC不会被频繁触发。

在进行MajorGC之前，JVM会进行一次MinorGC，在MinorGC过后依然呈现老年代空间有余或无奈找到足够大的间断内存空间调配给新创建的大对象时，会触发MajorGC进行垃圾回收流动，开释JVM的内存空间。

MajorGC采纳标记革除算法，该算法首先会扫描所以对象并标记存活的对象，而后回收未被标记的对象，并开释内存空间。

因为要先扫描老年代的所有对象再回收，所以MajorGC的耗时比拟长，MajorGC的标记革除算法容易产生内存碎片。

在老年代没有内存空间可调配时，会抛出OOM异样。

永恒代

永恒代指内存的永恒保留区域，次要寄存 Class和 Meta（元数据）的信息。

Class在类加载时被放入永恒代。

永恒代和老年代、新生代不同，GC不会在程序运行期间对永恒代的内存进行清理，这也导致了永恒代的内存会随着加载的Class文件的减少而减少，在加载的Class文件过多时会抛出Out OfMemory异样，比方Tomcat援用Jar文件过多导致JVM内存不足而无奈启动。

须要留神的是，在Java 8中永恒代曾经被元数据区（也叫作元空间）取代。

元数据区的作用和永恒代相似，二者最大的区别在于：元数据区并没有应用虚拟机的内存，而是间接应用操作系统的本地内存。

因而，元空间的大小不受JVM内存的限度，只和操作系统的内存无关。

在Java 8中，JVM将类的元数据放入本地内存（Native Memory）中，将常量池和类的动态变量放入Java堆中，这样JVM可能加载多少元数据信息就不再由JVM的最大可用内存（MaxPermSize）空间决定，而由操作系统的理论可用内存空间决定。

垃圾回收与算法

确定垃圾

Java采纳援用计数法和可达性剖析来确定对象是否须要被回收。

援用计数法容易产生循环援用问题。

可达性剖析通过根搜索算法（GC Roots Tracing）来实现。

根搜索算法以一系列GC Roots的点作为终点向下搜寻，在一个对象到任何 GC Roots都没有援用链相连时，阐明其已死亡。

根搜索算法次要针对栈中的援用、办法区中的动态援用和JNI中的援用开展剖析。

援用计数法

在Java中如果要操作对象，就必须先获取该对象的援用，因而能够通过援用计数法来判断一个对象是否能够被回收。

在为对象增加一个援用时，援用计数加1；在为对象删除一个援用时，引进计数减1；如果一个对象的援用计数为0，则示意此刻该对象没有被援用，能够被回收。

援用计数法容易产生循环援用问题。

循环援用指两个对象互相援用，导致它们的援用始终存在，而不能被回收。

可达性剖析

为了解决援用计数法的循环援用问题，Java还采纳了可达性剖析来判断对象是否能够被回收。

可达性剖析的过程：

首先定义一些GC Roots对象，而后以这些GC Roots对象作为终点向下搜寻，如果在GC roots和一个对象之间没有可达门路，则称该对象是不可达的。

不可达对象要通过至多两次标记能力断定其是否能够被回收，如果在两次标记后该对象依然是不可达的，则将被垃圾收集器回收。

罕用垃圾回收算法

Java中罕用的垃圾回收算法有：

标记革除（Mark-Sweep）算法

复制（Copying）算法

标记整顿（Mark Compact）算法

分代收集（Generational Collecting）算法

标记革除算法

标记革除算法是根底的垃圾回收算法，其过程分为标记和革除阶段。

在标记阶段标记所以须要回收的对象，在革除阶段革除可回收的对象并开释其所占用的内存空间。

因为标记革除算法在清理对象所占用的内存空间后并没有重新整理可用的内存空间，因而如果内存中可被回收的小对象居多，则会引起内存碎片化的问题，继而引起大对象无奈取得间断可用空间的问题。

复制算法

复制算法是为了解决标记革除算法内存碎片化的问题而设计的。

复制算法的基本原理：

首先将内存划分为两块大小相等的内存区域，即区域1和区域2，新生成的对象都被寄存在区域1中。

在区域1内的对象存储满后会对区域1进行一次标记，并将标记后依然存活的对象全副复制到区域2中，这时区域1将不存在任何存活的对象，间接清理整个区域1的内存即可。

复制算法的内存清理效率高且易于实现，但因为同一时刻只有一个内存区域可用，即可用的内存空间被压缩到原来的一半，因而存在大量的内存节约。

同时，在零碎中有大量长时间存活的对象时，这些对象将在内存区域1和内存区域2之间来回复制而影响零碎的运行效率。

因而，该算法只在对象为“朝生夕死”状态时运行效率较高。

标记整顿算法

标记整顿算法联合了标记革除算法和复制算法的长处，其标记阶段和标记革除算法的标记阶段雷同，在标记实现后将存活的对象移到内存的另一端，而后革除该端的对象并开释内存。

分代收集算法

无论是标记革除算法、复制算法还是标记整顿算法，都无奈对所有类型（长生命周期、短生命周期、大对象、小对象）的对象都进行垃圾回收。

因而，针对不同的对象类型，JVM采纳了不同的垃圾回收算法，该算法被称为分代收集算法。

分代收集算法依据对象的不同类型将内存划分为不同的区域，JVM将堆划分为新生代和老年代。

新生代次要寄存新生成的对象，其特点是对象数量多然而生命周期短，在每次进行垃圾回收时都有大量的对象被回收。

老年代次要寄存大对象和生命周期长的对象，因而可回收的对象绝对较少。

因而，JVM依据不同的区域对象的特点抉择了不同的算法。

目前，大部分JVM在新生代都采纳了复制算法，因为在新生代中每次进行垃圾回收时都有大量的对象被回收，须要复制的对象（存活的对象）较少，不存在大量的对象在内存中被来回复制的问题，因而采纳复制算法能平安、高效地回收新生代大量的短生命周期的对象并开释内存。

JVM将新生代进一步划分为一块较大的Eden区和两块较小的Servivor区，Servivor区又分为ServivorFrom区和ServivorTo区。

JVM在运行过程中次要应用Eden区和ServivorFrom区，进行垃圾回收时会将在Eden区和ServivorFrom区中存活的对象复制到ServivorTo区，而后清理Eden区和ServivorFrom区的内存空间。

老年代次要寄存生命周期较长的对象和大对象，因此每次只有大量非存活的对象被回收，因此在老年代采纳标记革除算法。

在JVM中还有一个区域，即办法区的永恒代，永恒代用来存储Class类、常量、办法形容等。

在永恒代次要回收废除的常量和无用的类。

JVM内存中的对象次要被调配到新生代的Eden区和ServivorFrom区，在多数状况下会被间接调配到老年代。

在新生代的Eden区和ServivorFrom区的内存空间有余时会触发一次GC，该过程被称为MinorGC。

在MinorGC后，在Eden区和ServivorFrom区中存活的对象会被复制到ServivorTo区，而后Eden区和ServivorFrom区被清理。

如果此时在ServivorTo区无奈找到间断的内存空间存储某个对象，则将这个对象间接存储到老年代。

若Servivor区的对象通过一次GC后依然存活，则其年龄加1。

在默认状况下，对象在年龄达到15时，将被移到老年代。

援用类型

在Java中，所有皆对象，对象的操作是通过该对象的援用（Reference）实现的。

在Java中，援用类型有4种：

强援用

软援用

弱援用

虚援用

强援用

在Java中最常见的就是强援用。

强援用：在把一个对象赋给一个援用变量时，这个援用变量就是一个强援用。

有强援用的对象肯定为可达性状态，所以不会被垃圾回收机制回收。

因而，强援用是造成Java内存透露（Memory Link）的次要起因。

软援用

软援用：软援用通过 SoftReference类实现。

如果一个对象只有软援用，则在零碎内存空间有余时该对象将被回收。

弱援用

弱援用：弱援用通过 WeakReference类实现。

如果一个对象只有弱援用，则在垃圾回收过程中肯定会被回收。

虚援用

虚援用：虚援用通过 PhantomReference类实现。

虚援用和援用队列联结应用，次要用于跟踪对象的垃圾回收状态。

分代收集算法

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

新生代与复制算法

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

老年代与标记整顿算法

老年代次要寄存长生命周期的对象和大对象，可回收的对象个别较少，因而JVM采纳标记整顿算法进行垃圾回收，间接开释死亡状态的对象所占用的内存空间即可。

分区收集算法

分区算法将整个堆空间划分为间断的大小不同的小区域，对每个小区都独自进行内存应用和垃圾回收，这样做的益处是能够依据每个小区域内存的大小灵便应用和开释内存。

分区收集算法能够依据零碎可承受的进展工夫，每个都疾速回收若干个小区域的内存，以缩短垃圾回收零碎进展的工夫，最初以屡次并行累加的形式逐渐实现整个内存区域的垃圾回收。

如果垃圾回收机制一次回收整个堆内存，则须要更长的零碎进展工夫，长时间的零碎进展将影响零碎运行的稳定性。

垃圾收集器

Java堆内存分为新生代和老年代。

新生代次要存储短生命周期的对象，适宜应用复制算法进行垃圾回收。

老年代次要存储长生命周期对象和大对象，适宜应用标记整顿算法进行垃圾回收。

JVM针对新生代和老年代别离提供了多种不同的垃圾收集器，针对新生代提供的垃圾收集器有 SerialOld、 ParallelOld、 CMS，还有针对不同区域的 G1分区收集算法。

Serial

Serial：单线程、复制算法。

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

Serial垃圾收集器采纳了复制算法，简略、搞笑，对于单CPU运行环境来说，没有线程交互开销，能够取得最高的单线程垃圾收集效率，因而Serial垃圾收集器是JVM运行在Client模式下的新生代的默认垃圾收集器。

ParNew

ParNew：多线程、复制算法。

ParNew垃圾收集器是Serial垃圾收集器的多线程实现，同样采纳了复制算法，它采纳多线程模式工作，除此之外和Serial收集器简直一样。

ParNew垃圾收集器在垃圾收集过程中会暂停所有其余工作线程，是Java虚拟机运行在Server模式下的新生代的默认垃圾收集器。

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

Parallel Scavenge

Parallel Scavenge：多线程、复制算法。

Parallel Scavenge收集器是为进步新生代垃圾收集效率而设计的垃圾收集器，基于多线程复制算法实现，在零碎吞吐量上有很大的优化，能够更高效地利用CPU尽快实现垃圾回收工作。

Parallel Scavenge通过自适应调节策略进步零碎吞吐量，提供了三个参数用于调节、管制垃圾回收的进展工夫及吞吐量，别离是管制最大垃圾收集进展工夫的 -XX:MaxGCPauseMillis参数，管制吞吐量大小的 -XX:GCTimeRatio参数和管制自适应调节策略开启与否的 UseAdaptiveSizePolicy参数。

Serial Old

Serial Old：单线程、标记整顿算法。

Serial Old垃圾收集器是Serial垃圾收集器的老年代实现，同Serial一样采纳单线程执行，不同的是，Serial Old针对老年代长生命周期的特点基于标记整顿算法实现。

Serial Old垃圾收集器是JVM运行在Client模式下的老年代的默认垃圾收集器。

新生代的Serial垃圾收集器和老年代的Serial Old垃圾收集器可搭配应用，别离针对JVM的新生代和老年代进行垃圾回收，其垃圾收集过程如图所示。

在新生代采纳Serial垃圾收集器基于复制算法进行垃圾回收，未被其回收的对象在老年代被Serial Old垃圾收集器基于标记整顿算法进行垃圾回收。

Parallel Old

Parallel Old：多线程、标记整顿算法。

Parallel Old垃圾收集器采纳多线程并发进行垃圾回收，它依据老年代长生命周期的特点，基于多线程的标记整顿算法实现。

Parallel Old垃圾收集器在设计上优先思考零碎吞吐量，其次思考进展工夫等因素，如果系统对吞吐量的要求较高，则能够优先思考新生代的Parallel Scavenge垃圾收集器和老年代的Parallel Old垃圾收集器的配合应用。

新生代的Parallel Scavenge垃圾收集器和老年代的Parallel Old垃圾收集器的搭配运行过程如图。

新生代基于Parallel Scavenge垃圾收集器的复制算法进行垃圾回收，老年代基于Parallel Old垃圾收集器的标记整顿算法进行垃圾回收。

CMS

CMS（Concurrent Mark Sweep）垃圾收集器是为老年代设计的垃圾收集器，其次要目标是达到最短的垃圾回收进展工夫，基于线程的标记革除算法实现，以便在多线程并发环境下以最短的垃圾收集进展工夫进步零碎的稳定性。

CMS的工作机制绝对简单，垃圾回收过程蕴含如下4个步骤。

初始标记：只标记和GC Roots间接关联的对象，速度很快，须要暂停所有工作线程。

并发标记：和用户线程一起工作，执行GC Roots跟踪标记过程，不须要暂停工作线程。

从新标记：在并发标记过程中用户线程持续运行，导致在垃圾回收过程中局部对象的状态发生变化，为了确保这部分对象的状态正确性，须要对其从新标记并暂停工作线程。

并发革除：和用户线程一起工作，执行革除GC Roots不可达对象的工作，不须要暂停工作线程。

CMS垃圾收集器在和用户线程一起工作时（并发标记和并发革除）不须要暂停用户线程，无效缩短了垃圾回收时零碎的进展工夫，同时因为CMS垃圾收集器和用户线程一起工作，因而其并行度和效率也有很大晋升。

G1

G1（Garbage First）垃圾收集器为了防止全区域垃圾收集引起的零碎进展，将堆内存划分为大小固定的几个独立区域，独立应用这些区域的内存资源并且跟踪这些区域的垃圾收集进度，同时在后盾保护一个优先级列表，在垃圾回收过程中依据零碎容许的最长垃圾收集工夫，优先回收垃圾最多的区域。

G1垃圾收集器通过内存区域独立划分应用和依据不同优先级回收各区域垃圾的机制，确保了G1垃圾收集器在无限工夫内取得最高的垃圾收集效率。

绝对于CMS收集器，G1垃圾收集器两个突出的改良。

基于标记整顿算法，不产生内存碎片。

能够准确地管制进展工夫，在不就义吞吐量的前提下实现短进展垃圾回收。

类加载机制

JVM的类加载阶段

JVM的类加载分为5个阶段：加载、验证、筹备、解析、初始化。

在类初始化实现后就能够应用该类的信息，在一个类不再被须要时能够从JVM中卸载。

加载

加载：加载是指JVM读取 Class文件，并且依据 Class文件形容创立 java.lang.Class对象的过程。

类加载过程次要蕴含将 Class文件读取到运行时区域的办法区内，在堆中创立 java.lang.Class对象，并封装类在办法区的数据结构的过程，在读取 Class文件时既能够通过文件的模式读取，也能够通过 JAR包、 WAR包读取，还能够通过代理主动生成 Class或其余形式读取。

验证

验证：验证次要用于确保 Class文件合乎以后虚拟机的要求，保障虚拟机本身的平安，只有通过验证的 Class文件能力被JVM加载。

筹备

筹备：筹备次要工作是在办法区中为类变量分配内存空间并设置类中变量的初始值。

初始值指不同数据类型的默认值，这里须要留神 final类型的变量和非 final类型的变量在筹备阶段的数据初始化过程不同。

栗如，一个成员变量的定义如下：

public static long value = 1000;

在以上代码中，动态变量value在筹备阶段的初始值是0，将value设置为1000的动作是在对象初始化时实现的，因为JVM在编译阶段会将动态变量的初始化操作定义在结构器中。然而，如果将变量value申明为final类型：

public static final int value = 1000;

则JVM在编译阶段后会为final类型的变量value生成其对应的ConstantValue属性，虚拟机在筹备阶段会依据ConstantValue属性将value赋值为1000。

解析

解析：解析是指JVM会将常量池中的符号援用替换为间接援用。

初始化

初始化：初始化次要通过执行类结构器的 <client>办法为类进行初始化。

<client>办法是在编译阶段由编译器主动收集类中动态语句块和变量的赋值操作组成的。

JVM规定，只有在父类的 <client>办法都执行胜利后，子类中的 <client>办法才能够被执行。

在一个类中既没有动态变量赋值操作也没有动态语句块时，编译器不会为该类生成 <client>办法。

在产生以下几种状况时，JVM不会执行类的初始化流程。

常量在编译时会将其常量值存入应用该常量的类的常量池中，该过程不须要调用常量所在的类，因而不会触发该常量类的初始化。

在子类援用父类的动态字段时，不会触发子类的初始化，只会触发父类的初始化。

定义对象数组，不会触发该类的初始化。

在应用类名获取 Class对象时不会触发类的初始化。

在应用 Class.forName加载指定的类时，能够通过 initialize参数设置是否须要对类进行初始化。

在应用 ClassLoader默认的 loadClass办法加载类时不会触发该类的初始化。

类加载器

JVM提供了3品种加载器，别离是启动类加载器、扩大类加载器和应用程序类加载器。

类加载器分为：启动类加载器、扩大类加载器、应用程序类加载器、自定义加载器。

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

扩大类加载器：负责加载 Java_HOME/lib/ext目录中的类库，或通过 java.ext.dirs零碎变量加载指定门路中的类库。

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

除了上述3品种加载器，咱们也能够通过继承 java.lang.ClassLoader实现自定义的类加载器。

双亲委派机制

JVM通过双亲委派机制对类进行加载。

双亲委派机制指一个类在收到类加载申请后不会尝试本人加载这个类，而是把该类加载申请向上委派给其父类去实现，其父类在接管到该类加载申请后又会将其委派给本人的父类，以此类推，这样所有的类加载申请都被向上委派到启动类加载器中。

若父类加载器在接管到类加载申请后发现自己也无奈加载该类（通常起因是该类的 Class文件在父类的类加载门路中不存在），则父类会将该信息反馈给子类并向下委派子类加载器加载该类，直到该类被胜利加载，若找不到该类，则JVM会抛出 ClassNotFoud异样。

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

将自定义加载器挂载到应用程序类加载器。

应用程序类加载器将类加载申请委托给扩大类加载器。

扩大类加载器将类加载申请委托给启动类加载器。

启动类加载器在加载门路下查找并加载 Class文件，如果未找到指标 Class文件，则交由扩大类加载器加载。

扩大类加载器在加载门路下查找并加载 Class文件，如果未找到指标 Class文件，则交由应用程序类加载器加载。

应用程序类加载器在加载门路下查找并加载 Class文件，如果未找到指标 Class文件，则交由自定义加载器加载。

在自定义加载器下查找并加载用户指定目录下的 Class文件，如果在自定义加载门路下未找到指标 Class文件，则抛出 ClassNotFoud异样。

双亲委派机制的外围是保障类的唯一性和安全性。

例如在加载 rt.jar包中的 java.lang.Object类时，无论是哪个类加载器加载这个类，最终都将类加载申请委托给启动类加载器加载，这样就保障了类加载的唯一性。

如果在JVM中存在包名和类名雷同的两个类，则该类将无奈被加载，JVM也无奈实现类加载流程。

OSGI

OSGI（Open Service Gateway Initiative）是Java动态化模块化零碎的一系列标准，旨在为实现Java程序的模块化编程提供根底条件。

基于OSGI的程序能够实现模块级的热插拔性能，在程序降级更新时，能够只针对须要更新的程序进行停用和重新安装，极大进步了系统升级的安全性和便捷性。

OSGI提供了一种面向服务的架构，该架构为组件提供了动静发现其余组件的性能，这样无论是退出组件还是卸载组件，都能被零碎的其余组件感知，以便各个组件之间能更好地协调工作。

OSGI岂但定义了模块化开发的标准，还定义了实现这些标准所依赖的服务与架构，市场上也有成熟的框架对其进行实现和利用，但只有局部利用适宜采纳OSGI形式，因为它为了实现动静模块，不再遵循JVM类加载双亲委派机制和其余JVM标准，在安全性上有所就义。