JVM深入学习与总结

r囧r小猫 2022-05-23 06:29 396阅读 0赞

# 一，JAVA虚拟机JVM内存图解 #

![1710354522-5ad304bfcff05_articlex][]

# 二，JVM区域总体分两类，堆heap区和非堆heap区。 #

## 非heap区： ##

### 1.Program Counter Register(程序计数器)；  ###

程序计数器是一块较小的内存区域，作用可以看做是当前线程执行的字节码的位置指示器。分支、循环、跳转、异常处理和线程恢复等基础功能都需要依赖这个计算器来完成，线程间内存私有互不影响。

### 2.Method Area（Perm Gen永久代）,Jdk1.8以后被Metaspace取代;  ###

方法区内部有一个非常重要的区域，叫做运行时常量池（Runtime Constant Pool，简称 RCP）。在字节码文件（Class文件）中，除了有类的版本、字段、方法、接口等先关信息描述外，还有常量池（Constant Pool Table）信息，用于存储编译器产生的字面量和符号引用。值得注意的是，运行时产生的新常量也可以被放入常量池中，比如 String 类中的 intern() 方法产生的常量。  
　　常量池就是这个类型用到的常量的一个有序集合。包括直接常量(基本类型，String)和对其他类型、方法、字段的符号引用.例如：◆类和接口的全限定名；◆字段的名称和描述符；◆方法和名称和描述符。  
　　池中的数据和数组一样通过索引访问。由于常量池包含了一个类型所有的对其他类型、方法、字段的符号引用，所以常量池在Java的动态链接中起了核心作用.

### 3.Jvm Stack(java虚拟机栈)； ###

虚拟机栈描述的是java执行的内存模型，每个方法被执行的时候都会创建一个栈帧(StackFrame)用户存储局部标量，操作数栈，动态链接，方法出口等信息，可以通过-Xss参数设置大小。

栈帧用于存储：局部变量表、操作数栈、动态链接、方法出口等，每个方法执行中都对应虚拟机栈帧从入栈到处栈的过程，当方法正常返回或者抛出未捕获的异常时，栈帧就会出栈。异常类型有：stackOverFlowError 线程请求栈深度大于虚拟机允许深度 OutOfMemory 内存空间耗尽无法进行扩展。

*  a、局部变量表：包含了方法执行过程中的所有变量，存放了编译期可知的各种数据类型例如： Boolean、byte、char、short、int、float、long、double、对象引用类型(对象内存地址变量，指针或句柄)。局部变量数组所需要的空间在编译期间完成分配，在方法运行期间不会改变局部变量数组的大小。
 *  b、返回值：如果有返回值的话，压入调用者栈帧中的操作数栈中，并且把PC的值指向 方法调用指令 后面的一条指令地址。
 *  c、操作数栈：操作变量的内存模型。操作数栈的最大深度在编译的时候已经确定（写入方法区code属性的max\_stacks项中）。操作数栈的的元素可以是任意Java类型，包括long和double，32位数据占用栈空间为1，64位数据占用2。方法刚开始执行的时候，栈是空的，当方法执行过程中，各种字节码指令往栈中存取数据。
 *  d、动态链接：每个栈帧都持有在运行时常量池中该栈帧所属方法的引用，持有这个引用是为了支持方法调用过程中的动态链接。

### 4.Local/Native Method Statck(本地方法栈)； ###

本地方法栈和虚拟机栈类似，本地方法栈主要存放虚拟机用到的Native方法服务，很多虚拟机(HotSpot)直接将这两块合并。

### 5.直接内存 ： (Direct Memory) ###

直接内存不属于虚拟内存区域，是一种基于通道与缓冲区的IO方式，可以使用本地函数直接分配堆外内存，在堆中存储引用的外部内存地址，通过引用完成对直接引用内存的操作，1.4之后提供的NIO显著提高效率，避免了堆内存与Native内存的来回复制操作，不受虚拟机内存控制，会抛出OUtOfMemory异常。

## heap区分为： ##

虚拟机管理机制的最大一块内存，同时也是被所有线程共享的，在虚拟机启动时创建，主要存放对象实例。几乎所有对象实例和数组都在这里分配内存，这里存放的对象使用GC管理，Java堆内存可以通过-Xmx和-Xms来设置。如果堆中没有可用内存完成实例分配并且堆也无法扩展就会抛出OutOfMermoryError。 有以下特点

*  （1）Java堆是虚拟机管理的内存中最大的一块
 *  （2）Java堆是所有线程共享的区域
 *  （3）在虚拟机启动时创建
 *  （4）此内存区域的唯一目的就是存放对象实例，几乎所有对象实例都在这里分配内存。存放new生成的对象和数组
 *  （5）Java堆是垃圾收集器管理的内存区域，因此很多时候称为“GC堆”

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2llZmxleA_size_16_color_FFFFFF_t_70][]

###  **JVM年轻代**  ###

JVM年轻代分为了三部分：1个Eden Space（伊甸园）区和2个Survivor Space(幸存者区)（分别叫from和to）。分为Eden、Survivor From、Survivor To，比例默认为8：1：1。一般情况下，新创建的对象都会被分配到Eden区(一些大对象特殊处理),这些对象经过第一次Minor GC后，如果仍然存活，将会被移到Survivor区。内存不足时发生Minor GC，对象在Survivor区中每熬过一次Minor GC，年龄就会增加1岁，当它的年龄增加到一定程度时，就会被移动到年老代中。

因为年轻代中的对象基本都是朝生夕死的(80%以上)，所以在年轻代的垃圾回收算法使用的是复制算法，复制算法的基本思想就是将内存分为两块，每次只用其中一块，当这一块内存用完，就将还活着的对象复制到另外一块上面。复制算法不会产生内存碎片。

在GC开始的时候，对象只会存在于Eden区和名为“From”的Survivor区，Survivor区“To”是空的。紧接着进行GC，Eden区中所有存活的对象都会被复制到“To”，而在“From”区中，仍存活的对象会根据他们的年龄值来决定去向。年龄达到一定值(年龄阈值，可以通过-XX:MaxTenuringThreshold来设置)的对象会被移动到年老代中，没有达到阈值的对象会被复制到“To”区域。经过这次GC后，Eden区和From区已经被清空。这个时候，“From”和“To”会交换他们的角色，也就是新的“To”就是上次GC前的“From”，新的“From”就是上次GC前的“To”。不管怎样，都会保证名为To的Survivor区域是空的。Minor GC会一直重复这样的过程，直到“To”区被填满，“To”区被填满之后，会将所有对象移动到年老代中。

### Old Gen老年代 ###

用于存放新生代中经过多次垃圾回收仍然存活的对象，也有可能是新生代分配不了内存的大对象会直接进入老年代。经过多次垃圾回收都没有被回收的对象，这些对象的年代已经足够old了，就会放入到老年代。

当老年代被放满的之后，虚拟机会进行垃圾回收，称之为Major GC。由于Major GC除并发GC外均需对整个堆进行扫描和回收，因此又称为Full GC。

### **heap区即堆内存** ###

整个堆大小=年轻代大小 + 老年代大小。堆内存默认为物理内存的1/64(<1GB)；默认空余堆内存小于40%时，JVM就会增大堆直到-Xmx的最大限制，可以通过MinHeapFreeRatio参数进行调整；默认空余堆内存大于70%时，JVM会减少堆直到-Xms的最小限制，可以通过MaxHeapFreeRatio参数进行调整。

# 三，Metaspace元空间（永久代） #

PermGen space的全称是Permanent Generation space,是指内存的永久保存区域，说说为什么会内存益出：这一部分用于存放Class和Meta的信息,Class在被 Load的时候被放入PermGen space区域，它和和存放Instance的Heap区域不同,所以如果你的APP会LOAD很多CLASS的话,就很可能出现PermGen space错误。这种错误常见在web服务器对JSP进行pre compile的时候。

随着JDK8的到来，JVM不再有PermGen。但类的元数据信息（metadata）还在，只不过不再是存储在连续的堆空间上，而是移动到叫做“Metaspace”的本地内存（Native memory）中。　　元空间的本质和永久代类似，都是对JVM规范中方法区的实现。不过元空间与永久代之间最大的区别在于：元空间并不在虚拟机中，而是使用本地内存。因此，默认情况下，元空间的大小仅受本地内存限制，但可以通过以下参数来指定元空间的大小：

-XX:MetaspaceSize，初始空间大小，达到该值就会触发垃圾收集进行类型卸载，同时GC会对该值进行调整：如果释放了大量的空间，就适当降低该值；如果释放了很少的空间，那么在不超过MaxMetaspaceSize时，适当提高该值。   
　　-XX:MaxMetaspaceSize，最大空间，默认是没有限制的。   
　　除了上面两个指定大小的选项以外，还有两个与 GC 相关的属性：   
　　-XX:MinMetaspaceFreeRatio，在GC之后，最小的Metaspace剩余空间容量的百分比，减少为分配空间所导致的垃圾收集   
　　-XX:MaxMetaspaceFreeRatio，在GC之后，最大的Metaspace剩余空间容量的百分比，减少为释放空间所导致的垃圾收集  
　　-verbose参数是为了获取类型加载和卸载的信息

JVM的参数：PermSize 和 MaxPermSize 会被忽略并给出警告（如果在启用时设置了这两个参数）。

## Metaspace的特点 ##

*  充分利用了Java语言规范中的好处：类及相关的元数据的生命周期与类加载器的一致。
 *  每个加载器有专门的存储空间
 *  只进行线性分配
 *  不会单独回收某个类
 *  省掉了GC扫描及压缩的时间
 *  元空间里的对象的位置是固定的
 *  如果GC发现某个类加载器不再存活了，会把相关的空间整个回收掉

## Metaspace的内存分配模型 ##

*  绝大多数的类元数据的空间都从本地内存中分配
 *  用来描述类元数据的类(klasses)也被删除了
 *  分元数据分配了多个虚拟内存空间
 *  给每个类加载器分配一个内存块的列表。块的大小取决于类加载器的类型; sun/反射/代理对应的类加载器的块会小一些
 *  归还内存块，释放内存块列表
 *  一旦元空间的数据被清空了，虚拟内存的空间会被回收掉
 *  减少碎片的策略

# 四，垃圾收集算法  #

## 一、 判断对象是否要回收的方法：可达性分析法 ##

## 1、 可达性分析法： ##

通过一系列“GC Roots”对象作为起点进行搜索，如果在“GC Roots”和一个对象之间没有可达路径，则称该对象是不可达的。不可达对象不一定会成为可回收对象。进入DEAD状态的线程还可以恢复，GC不会回收它的内存。（把一些对象当做root对象，JVM认为root对象是不可回收的，并且root对象引用的对象也是不可回收的）

## 2、 以下对象会被认为是root对象： ##

（1） 虚拟机栈（栈帧中本地变量表）中引用的对象  
（2） 方法区中静态属性引用的对象  
（3） 方法区中常量引用的对象  
（4） 本地方法栈中Native方法引用的对象

## 3、 对象被判定可被回收，需要经历两个阶段： ##

（1） 第一个阶段是可达性分析，分析该对象是否可达  
（2） 第二个阶段是当对象没有重写finalize()方法或者finalize()方法已经被调用过，虚拟机认为该对象不可以被救活，因此回收该对象。（finalize()方法在垃圾回收中的作用是，给该对象一次救活的机会）

## 4、 方法区中的垃圾回收： ##

（1） 常量池中一些常量、符号引用没有被引用，则会被清理出常量池  
（2） 无用的类：被判定为无用的类，会被清理出方法区。判定方法如下：

*  A、 该类的所有实例被回收
 *  B、 加载该类的ClassLoader被回收
 *  C、 该类的Class对象没有被引用

## 5、 finalize(): ##

（1） GC垃圾回收要回收一个对象的时候，调用该对象的finalize()方法。然后在下一次垃圾回收的时候，才去回收这个对象的内存。  
（2） 可以在该方法里面，指定一些对象在释放前必须执行的操作。

## 二、 频繁full GC解决办法： ##

full GC指的是清理整个堆空间，包括年轻代和永久代  
（1） 首先用命令查看触发GC的原因是什么 jstat –gccause 进程id  
（2） 如果是System.gc()，则看下代码哪里调用了这个方法  
（3） 如果是heap inspection(内存检查)，可能是哪里执行jmap –histo\[:live\]命令  
（4） 如果是GC locker，可能是程序依赖的JNI库的原因

## 三、常见的垃圾回收算法： ##

### 1、Mark-Sweep（标记-清除算法）： ###

（1）思想：标记清除算法分为两个阶段，标记阶段和清除阶段。标记阶段任务是标记出所有需要回收的对象，清除阶段就是清除被标记对象的空间。  
（2）优缺点：实现简单，容易产生内存碎片

### 2、Copying（复制清除算法）： ###

（1）思想：将可用内存划分为大小相等的两块，每次只使用其中的一块。当进行垃圾回收的时候了，把其中存活对象全部复制到另外一块中，然后把已使用的内存空间一次清空掉。  
（2）优缺点：不容易产生内存碎片；可用内存空间少；存活对象多的话，效率低下。

### 3、Mark-Compact（标记-整理算法）： ###

（1）思想：先标记存活对象，然后把存活对象向一边移动，然后清理掉端边界以外的内存。  
（2）优缺点：不容易产生内存碎片；内存利用率高；存活对象多并且分散的时候，移动次数多，效率低下

### 4、分代收集算法：（目前大部分JVM的垃圾收集器所采用的算法）： ###

思想：把堆分成新生代和老年代。（永久代指的是方法区）  
（1） 因为新生代每次垃圾回收都要回收大部分对象，所以新生代采用Copying算法。新生代里面分成一份较大的Eden空间和两份较小的Survivor空间。每次只使用Eden和其中一块Survivor空间，然后垃圾回收的时候，把存活对象放到未使用的Survivor（划分出from、to）空间中，清空Eden和刚才使用过的Survivor空间。  
（2） 由于老年代每次只回收少量的对象，因此采用mark-compact算法。  
（3） 在堆区外有一个永久代。对永久代的回收主要是无效的类和常量

### 5、几种不同的垃圾回收类型： ###

（1）Minor GC：从年轻代（包括Eden、Survivor区）回收内存。

*  A、当JVM无法为一个新的对象分配内存的时候，越容易触发Minor GC。所以分配率越高，内存越来越少，越频繁执行Minor GC
 *  B、执行Minor GC操作的时候，不会影响到永久代（Tenured）。从永久代到年轻代的引用，被当成GC Roots，从年轻代到老年代的引用在标记阶段直接被忽略掉。

（2）Major GC：清理整个老年代，当eden区内存不足时触发。  
（3）Full GC：清理整个堆空间，包括年轻代和老年代。当老年代内存不足时触发

### 6、七种垃圾收集器  ###

(1) Serial（串行GC）-XX: UseSerialGC  
(2) ParNew（并行GC）-XX: UseParNewGC  
(3) Parallel Scavenge（并行回收GC）  
(4) Serial Old（MSC）（串行GC）-XX: UseSerialGC  
(5) CMS（并发GC）-XX: UseConcMarkSweepGC  
(6) Parallel Old（并行GC）-XX: UseParallelOldGC  
(7) G1（JDK1.7update14才可以正式商用）

# 五，HotSpot 虚拟机详解： #

## 1、 Java对象创建过程： ##

（1）虚拟机遇到一条new指令时，首先检查这个指令的参数能否在常量池中定位到一个类的符号引用，并检查这个符号引用代表的类是否已经加载、连接和初始化。如果没有，就执行该类的加载过程。

（2）为该对象分配内存。

*  A、假设Java堆是规整的，所有用过的内存放在一边，空闲的内存放在另外一边，中间放着一个指针作为分界点的指示器。那分配内存只是把指针向空闲空间那边挪动与对象大小相等的距离，这种分配称为“指针碰撞”
 *  B、假设Java堆不是规整的，用过的内存和空闲的内存相互交错，那就没办法进行“指针碰撞”。虚拟机通过维护一个列表，记录哪些内存块是可用的，在分配的时候找出一块足够大的空间分配给对象实例，并更新表上的记录。这种分配方式称为“空闲列表“。
 *  C、使用哪种分配方式由Java堆是否规整决定。Java堆是否规整由所采用的垃圾收集器是否带有压缩整理功能决定。
 *  D、分配对象保证线程安全的做法：虚拟机使用CAS失败重试的方式保证更新操作的原子性。（实际上还有另外一种方案：每个线程在Java堆中预先分配一小块内存，称为本地线程分配缓冲，TLAB。哪个线程要分配内存，就在哪个线程的TLAB上分配，只有TLAB用完并分配新的TLAB时，才进行同步锁定。虚拟机是否使用TLAB，由-XX:+/-UseTLAB参数决定）

（3）虚拟机为分配的内存空间初始化为零值（默认值）

（4）虚拟机对对象进行必要的设置，例如这个对象是哪个类的实例、如何才能找到对象的元数据信息、对象的Hash码、对象的GC分代年龄等信息。这些信息存放在对象的对象头中。

（5） 执行<init>方法，把对象按照程序员的意愿进行初始化。

## 2、 对象的定位访问的方式： ##

通过引用如何去定位到堆上的具体对象的位置

###   句柄方式 ###

使用句柄的方式，Java堆中将会划分出一块内存作为作为句柄池，引用中存储的就是对象的句柄的地址。而句柄中包含了对象实例数据和对象类型数据的地址。  
![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2llZmxleA_size_16_color_FFFFFF_t_70 1][]

### 直接指针 ###

使用直接指针的方式，引用中存储的就是对象的地址。Java堆对象的布局必须必须考虑如何去访问对象类型数据。  
![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2llZmxleA_size_16_color_FFFFFF_t_70 2][]

###  两种方式各有优点 ###

*  A、使用句柄访问的好处是引用中存放的是稳定的句柄地址，当对象被移动（比如说垃圾回收时移动对象），只会改变句柄中实例数据指针，而引用本身不会被修改。
 *  B、使用直接指针，节省了一次指针定位的时间开销。

## 3、HotSpot的GC算法实现： ##

（1）HotSpot怎么快速找到GC Root？  
HotSpot使用一组称为OopMap的数据结构。在类加载完成的时候，HotSpot就把对象内什么偏移量上是什么类型的数据计算出来，在JIT编译过程中，也会在栈和寄存器中哪些位置是引用。这样子，在GC扫描的时候，就可以直接知道哪些是可达对象了。  
（2）安全点：

*  A、HotSpot只在特定的位置生成OopMap，这些位置称为安全点。
 *  B、程序执行过程中并非所有地方都可以停下来开始GC，只有在到达安全点是才可以暂停。
 *  C、安全点的选定基本上以“是否具有让程序长时间执行“的特征选定的。比如说方法调用、循环跳转、异常跳转等。具有这些功能的指令才会产生Safepoint。

（3）中断方式：

*  A、抢占式中断：在GC发生时，首先把所有线程中断，如果发现有线程不在安全点上，就恢复线程，让它跑到安全点上。
 *  B、主动式中断：GC需要中断线程时，不直接对线程操作，仅仅设置一个标志，各个线程执行时主动去轮询这个标志，当发现中断标记为真就自己中断挂起。轮询标记的地方和安全点是重合的。

（4）安全区域：一段代码片段中，对象的引用关系不会发生变化，在这个区域中任何地方开始GC都是安全的。在线程进入安全区域时，它首先标志自己已经进入安全区域，在这段时间里，当JVM发起GC时，就不用管进入安全区域的线程了。在线程将要离开安全区域时，它检查系统是否完成了GC过程，如果完成了，它就继续前行。否则，它就必须等待直到收到可以离开安全区域的信号。

## 4、 GC时为什么要停顿所有Java线程？ ##

因为GC先进行可达性分析。可达性分析是判断GC Root对象到其他对象是否可达，假如分析过程中对象的引用关系在不断变化，分析结果的准确性就无法得到保证。

## 5、 CMS收集器： ##

（1）一种以获取最短回收停顿时间为目标的收集器。  
（2）一般用于互联网站或者B/S系统的服务端  
（3）基于标记-清除算法的实现，不过更为复杂，整个过程为4个步骤：

*  A、初始标记：标记GC Root能直接引用的对象
 *  B、并发标记：利用多线程对每个GC Root对象进行tracing搜索，在堆中查找其下所有能关联到的对象。
 *  C、重新标记：为了修正并发标记期间，用户程序继续运作而导致标志产生变动的那一部分对象的标记记录。
 *  D、并发清除：利用多个线程对标记的对象进行清除

（4）由于耗时最长的并发标记和并发清除操作都是用户线程一起工作，所以总体来说，CMS的内存回收工作是和用户线程一起并发执行的。  
（5）缺点：

*  A、对CPU资源占用比较多。可能因为占用一部分CPU资源导致应用程序响应变慢。
 *  B、CMS无法处理浮动垃圾。在并发清除阶段，用户程序继续运行，可能产生新的内存垃圾，这一部分垃圾出现在标记过程之后，因此，CMS无法清除。这部分垃圾称为“浮动垃圾“
 *  C、需要预留一部分内存，在垃圾回收时，给用户程序使用。
 *  D、基于标记-清除算法，容易产生大量内存碎片，导致full GC（full GC进行内存碎片的整理）

## 6、 对象头部分的内存布局 ##

HotSpot的对象头分为两部分，第一部分用于存储对象自身的运行时数据，比如哈希码、GC分代年龄等。另外一部分用于指向方法区对象类型数据的指针。

## 7、 偏向锁 ##

偏向锁偏向于第一个获取它的线程，如果在接下来的执行过程，没有其他线程获取该锁，则持有偏向锁的线程永远不需要同步。（当一个线程获取偏向锁，它每次进入这个锁相关的同步块，虚拟机不在进行任何同步操作。当有另外一个线程尝试获取这个锁时，偏向模式宣告结束）

#  六，JMM Java内存模型 #

1、 Java的并发采用“共享内存”模型，线程之间通过读写内存的公共状态进行通讯。多个线程之间是不能通过直接传递数据交互的，它们之间交互只能通过共享变量实现。  
2、 主要目的是定义程序中各个变量的访问规则。  
3、 Java内存模型规定所有变量都存储在主内存中，每个线程还有自己的工作内存。  
（1） 线程的工作内存中保存了被该线程使用到的变量的拷贝（从主内存中拷贝过来），线程对变量的所有操作都必须在工作内存中执行，而不能直接访问主内存中的变量。  
（2） 不同线程之间无法直接访问对方工作内存的变量，线程间变量值的传递都要通过主内存来完成。  
（3） 主内存主要对应Java堆中实例数据部分。工作内存对应于虚拟机栈中部分区域。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2llZmxleA_size_16_color_FFFFFF_t_70 3][]

4、Java线程之间的通信由内存模型JMM（Java Memory Model）控制。  
（1）JMM决定一个线程对变量的写入何时对另一个线程可见。  
（2）线程之间共享变量存储在主内存中  
（3）每个线程有一个私有的本地内存，里面存储了读/写共享变量的副本。  
（4）JMM通过控制每个线程的本地内存之间的交互，来为程序员提供内存可见性保证。  
5、可见性、有序性：  
（1）当一个共享变量在多个本地内存中有副本时，如果一个本地内存修改了该变量的副本，其他变量应该能够看到修改后的值，此为可见性。  
（2）保证线程的有序执行，这个为有序性。（保证线程安全）  
6、内存间交互操作：  
（1）lock（锁定）：作用于主内存的变量，把一个变量标识为一条线程独占状态。  
（2）unlock（解锁）：作用于主内存的变量，把一个处于锁定状态的变量释放出来，释放后的变量才可以被其他线程锁定。  
（3）read（读取）：作用于主内存变量，把主内存的一个变量读取到工作内存中。  
（4）load（载入）：作用于工作内存，把read操作读取到工作内存的变量载入到工作内存的变量副本中  
（5）use（使用）：作用于工作内存的变量，把工作内存中的变量值传递给一个执行引擎。  
（6）assign（赋值）：作用于工作内存的变量。把执行引擎接收到的值赋值给工作内存的变量。  
（7）store（存储）：把工作内存的变量的值传递给主内存  
（8）write（写入）：把store操作的值入到主内存的变量中  
6.1、注意：  
（1）不允许read、load、store、write操作之一单独出现  
（2）不允许一个线程丢弃assgin操作  
（3）不允许一个线程不经过assgin操作，就把工作内存中的值同步到主内存中  
（4）一个新的变量只能在主内存中生成  
（5）一个变量同一时刻只允许一条线程对其进行lock操作。但lock操作可以被同一条线程执行多次，只有执行相同次数的unlock操作，变量才会解锁  
（6）如果对一个变量进行lock操作，将会清空工作内存中此变量的值，在执行引擎使用这个变量前，需要重新执行load或者assgin操作初始化变量的值。  
（7）如果一个变量没有被锁定，不允许对其执行unlock操作，也不允许unlock一个被其他线程锁定的变量  
（8）对一个变量执行unlock操作之前，需要将该变量同步回主内存中

# 七，JVM优化 #

## 年轻代JVM参数 ##

### 1、-Xmn ###

一般来说，当survivor区不够大或者占用量达到50%，就会把一些对象放到老年区。通过设置合理的eden区，survivor区及使用率，可以将年轻对象保存在年轻代，从而避免full GC，使用-Xmn设置年轻代的大小 。

### 2、-XX:NewSize和-XX:MaxNewSize ###

用于设置年轻代的大小，建议设为整个堆大小的1/3或者1/4,两个值设为一样大。

### 3、-XX:SurvivorRatio ###

用于设置Eden和其中一个Survivor的比值，这个值也比较重要-XXSurvivorRatio=3，表示年轻代中的分配比率：survivor:eden = 2:3 。

### 4、-XX:InitialTenuringThreshol和-XX:MaxTenuringThreshold ###

用于设置晋升到老年代的对象年龄的最小值和最大值，每个对象在坚持过一次Minor GC之后，年龄就加1。一般情况下，年轻对象放在eden区，当第一次GC后，如果对象还存活，放到survivor区，此后，每GC一次，年龄增加1，当对象的年龄达到阈值，就被放到tenured老年区。这个阈值可以同构-XX:MaxTenuringThreshold设置。如果想让对象留在年轻代，可以设置比较大的阈值。

## 老年代JVM参数 ##

1、大对象进入老年代

对于占用内存比较多的大对象，一般会选择在老年代分配内存。如果在年轻代给大对象分配内存，年轻代内存不够了，就要在eden区移动大量对象到老年代，然后这些移动的对象可能很快消亡，因此导致full GC。 将大对象直接分配到老年代，保持新生代对象的结构的完整性，以提高GC效率， 通过设置参数：-XX:PetenureSizeThreshold=1000000，单位为B，标明对象大小超过1M时，在老年代(tenured)分配内存空间。

## 堆参数设置 ##

\-Xms：堆最小值（新生代和老年代之和）  
\-Xmx：堆最大值（新生代和老年代之和）

1、设置最小堆和最大堆：-Xmx和-Xms稳定的堆大小堆垃圾回收是有利的，获得一个稳定的堆大小的方法是设置-Xms和-Xmx的值一样，即最大堆和最小堆一样，如果这样子设置，系统在运行时堆大小理论上是恒定的，稳定的堆空间可以减少GC次数，因此，很多服务端都会将这两个参数设置为一样的数值。稳定的堆大小虽然减少GC次数，但是增加每次GC的时间，因为每次GC要把堆的大小维持在一个区间内。

2、一个不稳定的堆并非毫无用处。在系统不需要使用大内存的时候，压缩堆空间，使得GC每次应对一个较小的堆空间，加快单次GC次数。基于这种考虑，JVM提供两个参数，用于压缩和扩展堆空间。  
（1）-XX:MinHeapFreeRatio 参数用于设置堆空间的最小空闲比率。默认值是40，当堆空间的空闲内存比率小于40，JVM便会扩展堆空间  
（2）-XX:MaxHeapFreeRatio 参数用于设置堆空间的最大空闲比率。默认值是70， 当堆空间的空闲内存比率大于70，JVM便会压缩堆空间。  
（3）当-Xmx和-Xmx相等时，上面两个参数无效

## 吞吐量优先 ##

1、通过增大吞吐量提高系统性能，可以通过设置并行垃圾回收收集器。  
（1）-XX:+UseParallelGC:年轻代使用并行垃圾回收收集器。这是一个关注吞吐量的收集器，可以尽可能的减少垃圾回收时间。  
（2）-XX:+UseParallelOldGC:设置老年代使用并行垃圾回收收集器。

2、尝试使用大的内存分页：使用大的内存分页增加CPU的内存寻址能力，从而系统的性能。-XX:+LargePageSizeInBytes 设置内存页的大小

3、使用非占用的垃圾收集器。-XX:+UseConcMarkSweepGC老年代使用CMS收集器降低停顿。

## Metaspace调优 ##

使用-XX:MaxMetaspaceSize参数可以设置元空间的最大值，默认是没有上限的，也就是说你的系统内存上限是多少它就是多少。-XX:MetaspaceSize选项指定的是元空间的初始大小，如果没有指定的话，元空间会根据应用程序运行时的需要动态地调整大小。

### MaxMetaspaceSize的调优 ###

*  \-XX:MaxMetaspaceSize=\{unlimited\}
 *  元空间的大小受限于你机器的内存
 *  限制类的元数据使用的内存大小，以免出现虚拟内存切换以及本地内存分配失败。如果怀疑有类加载器出现泄露，应当使用这个参数；32位机器上，如果地址空间可能会被耗尽，也应当设置这个参数。
 *  元空间的初始大小是21M——这是GC的初始的高水位线，超过这个大小会进行Full GC来进行类的回收。
 *  如果启动后GC过于频繁，请将该值设置得大一些
 *  可以设置成和持久代一样的大小，以便推迟GC的执行时间

### CompressedClassSpaceSize的调优 ###

*  只有当-XX:+UseCompressedClassPointers开启了才有效
 *  \-XX:CompressedClassSpaceSize=1G
 *  由于这个大小在启动的时候就固定了的，因此最好设置得大点。
 *  没有使用到的话不要进行设置
 *  JVM后续可能会让这个区可以动态的增长。不需要是连续的区域，只要从基地址可达就行；可能会将更多的类元信息放回到元空间中；未来会基于PredictedLoadedClassCount的值来自动的设置该空间的大小

正如前面提到了，Metaspace VM管理Metaspace空间的增长。但有时你会想通过在命令行显示的设置参数-XX:MaxMetaspaceSize来限制Metaspace空间的增长。默认情况下，-XX:MaxMetaspaceSize并没有限制，因此，在技术上，Metaspace的尺寸可以增长到交换空间，而你的本地内存分配将会失败。

每次垃圾收集之后，Metaspace VM会自动的调整high watermark，推迟下一次对Metaspace的垃圾收集。

这两个参数，-XX：MinMetaspaceFreeRatio和-XX：MaxMetaspaceFreeRatio,类似于GC的FreeRatio参数，可以放在命令行。

## JVM性能调优的工具 ##

（1）jps（Java Process Status）：输出JVM中运行的进程状态信息(现在一般使用**jconsole**)

*  Jps \[option\] \[hostid\]
 *  jps -q 只输出LVMID
 *  jps -m 输出JVM启动时传给主类的方法
 *  jps -l 输出主类的全名，如果是Jar则输出jar的路径
 *  jps -v 输出JVM的启动参数

（2）jstack：查看java进程内线程的堆栈信息。

*  Jstack \[option\] vmid
 *  \-F 当正常输出的请求不响应时强制输出线程堆栈
 *  \-l 除堆栈信息外，显示关于锁的附加信息
 *  \-m 显示native方法的堆栈信息

（3）**jmap -clstats** :map用于生成堆快照（heapdump）。当然我们有很多方法可以取到对应的dump信息，如我们通过JVM启动时加入启动参数 –XX:HeapDumpOnOutOfMemoryError参数，可以让JVM在出现内存溢出错误的时候自动生成dump文件，亦可以通过-XX:HeapDumpOnCtrlBreak参数，在运行时使用ctrl break按键生成dump文件，当然我们也可以使用kill -3 pid的方式去恐吓JVM生成dump文件。Jmap的作用不仅仅是为了获取dump文件，还可以用于查询finalize执行队列、Java堆和永久带的详细信息，如空间使用率、垃圾回收器等。其运行格式如下：

*  Jmap \[option\] vmip
 *  监控堆栈信息主要用来定位问题的原因，生成堆栈快照
 *  .......-dump......:生成对应的dump信息，用法为-dump:\[live,\]format=b,file=\{fileName\}
 *  .......-finalizerinfo......:显示在F-Queue中等待的Finalizer方法的对象（只在linux下生效）
 *  .......-heap......：显示堆的详细信息、垃圾回收器信息、参数配置、分代详情等
 *  .......-histo......：显示堆栈中的对象的统计信息，包含类、实例数量和合计容量
 *  .......-permstat......：以ClassLoder为统计口径显示永久带的内存状态
 *  .......-F......：虚拟机对-dump无响应时可使用这个选项强制生成dump快照
 *  例子：jmap -dump:format=b,file=yhj.dump 20445
 *  **jhat**：用于分析jmap生成的堆转存快照（一般不推荐使用，而是使用Ecplise Memory Analyzer）

（4）jstat主要用于监控虚拟机的各种运行状态信息，如类的装载、内存、垃圾回收、JIT编译器等，在没有GUI的服务器上，这款工具是首选的一款监控工具。其用法如下：

*  jstat \[option vmid \[interval \[s|ms\] \[vount\] \] \]
 *  jstat 监控内容 线程好 刷新时间间隔 次数
 *  jstat –gc 20445 1 20 :监视Java堆，包含eden、2个survivor区、old区和永久带区域的容量、已用空间、GC时间合计等信息
 *  jstat –gcutil 20445 1 20:监视内容与-gc相同，但输出主要关注已使用空间占总空间的百分比
 *  jstat –class 20445 1 20:监视类的装载、卸载数量以及类的装载总空间和耗费时间等
 *  .......-gccapcity......:监视内容与-gc相同，但输出主要关注Java区域用到的最大和最小空间
 *  .......-gccause........:与-gcutil输出信息相同，额外输出导致上次GC产生的原因
 *  .......-gcnew..........:监控新生代的GC情况
 *  .......-gcnewcapacity..:与-gcnew监控信息相同，输出主要关注使用到的最大和最小空间
 *  .......-gcold..........:监控老生代的GC情况
 *  .......-gcoldcapacity..:与-gcold监控信息相同，输出主要关注使用到的最大和最小空间
 *  .......-gcpermcapacity.:输出永久带用到的最大和最小空间
 *  .......-compiler.......:输出JIT编译器编译过的方法、耗时信息
 *  .......-printcompilation:输出已经被JIT编译的方法

（6）jconsole:在JDK的bin目录下,监控内存,thread,堆栈等。

（7）jprofile：类似于jconsole,比jconsole监控信息更全面，内存，线程，包,cup 类，堆栈，等等

## jvm参数详解内存相关 ##

<table> 
 <thead> 
  <tr> 
   <th>选项</th> 
   <th>参数详解</th> 
   <th>默认值</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>-Xms</td> 
   <td>初始堆大小</td> 
   <td>--</td> 
  </tr> 
  <tr> 
   <td>-Xmx</td> 
   <td>最大堆大小</td> 
   <td>--</td> 
  </tr> 
  <tr> 
   <td>-Xmn</td> 
   <td>年轻代大小(1.4or lator)整个JVM内存大小=年轻代大小 + 年老代大小 + 持久代大小。持久代一般固定大小为64m，所以增大年轻代后，将会减小年老代大小。此值对系统性能影响较大，Sun官方推荐配置为整个堆的3/8</td> 
   <td>--</td> 
  </tr> 
  <tr> 
   <td>-XX:newSize</td> 
   <td>表示新生代初始内存的大小，应该小于 -Xms的值</td> 
   <td>--</td> 
  </tr> 
  <tr> 
   <td>-XX:NewRatio</td> 
   <td>设置年轻代和年老代的比值。如:为3，表示年轻代与年老代比值为1：3，年轻代占整个年轻代年老代和的1/4</td> 
   <td>--</td> 
  </tr> 
  <tr> 
   <td>-XX:MaxNewSize</td> 
   <td>年轻代最大值(for 1.3/1.4)</td> 
   <td>--</td> 
  </tr> 
  <tr> 
   <td>-XX:PermSize</td> 
   <td>设置持久代(perm gen)初始值</td> 
   <td>--</td> 
  </tr> 
  <tr> 
   <td>-XX:MaxPermSize</td> 
   <td>设置持久代最大值</td> 
   <td>--</td> 
  </tr> 
  <tr> 
   <td>-Xss</td> 
   <td>每个线程的堆栈大小</td> 
   <td>--</td> 
  </tr> 
  <tr> 
   <td>-XX:ThreadStackSize</td> 
   <td>--</td> 
   <td>--</td> 
  </tr> 
  <tr> 
   <td>-XX:SurvivorRatio</td> 
   <td>Eden区与Survivor区的大小比值， 设置为8,则两个Survivor区与一个Eden区的比值为2:8,一个Survivor区占整个年轻代的1/10</td> 
   <td>--</td> 
  </tr> 
  <tr> 
   <td>-XX:LargePageSizeInBytes</td> 
   <td>内存页的大小不可设置过大， 会影响Perm的大小，基本没用过</td> 
   <td>--</td> 
  </tr> 
  <tr> 
   <td>-XX:+UseFastAccessorMethods</td> 
   <td>原始类型的快速优化 1.7以后不建议使用，1.6之前默认打开的</td> 
   <td>--</td> 
  </tr> 
  <tr> 
   <td>-XX:+UseFastEmptyMethods</td> 
   <td>优化空方法，1.7以后不建议使用，1.6之前默认打开的</td> 
   <td>--</td> 
  </tr> 
  <tr> 
   <td>-XX:+DisableExplicitGC</td> 
   <td>关闭System.gc()</td> 
   <td>--</td> 
  </tr> 
  <tr> 
   <td>-XX:MaxTenuringThreshold</td> 
   <td>设置垃圾最大年龄。如果设置为0的话，则年轻代对象不经过Survivor区，直接进入年老代。对于年老代比较多的应用，可以提高效率。如果将此值设置为一个较大值，则年轻代对象会在Survivor区进行多次复制，这样可以增加对象再年轻代的存活时间，增加在年轻代即被回收的概率</td> 
   <td>--</td> 
  </tr> 
  <tr> 
   <td>-XX:+AggressiveOpts</td> 
   <td>加快编译</td> 
   <td>--</td> 
  </tr> 
  <tr> 
   <td>-XX:+UseBiasedLocking</td> 
   <td>锁机制的性能改善， 有偏见的锁是使得锁更偏爱上次使用到它线程。在非竞争锁的场景下，即只有一个线程会锁定对象，可以实现近乎无锁的开销。</td> 
   <td>默认开启</td> 
  </tr> 
  <tr> 
   <td>-Xnoclassgc</td> 
   <td>禁用类垃圾回收</td> 
   <td>--</td> 
  </tr> 
  <tr> 
   <td>-XX:SoftRefLRUPolicyMSPerMB</td> 
   <td>每兆堆空闲空间中SoftReference的存活时间</td> 
   <td>默认是1S</td> 
  </tr> 
  <tr> 
   <td>-XX:PretenureSizeThreshold</td> 
   <td>对象超过多大是直接在旧生代分配，单位字节 新生代采用Parallel Scavenge GC时无效另一种直接在旧生代分配的情况是大的数组对象,且数组中无外部引用对象.</td> 
   <td>--</td> 
  </tr> 
  <tr> 
   <td>-XX:+CollectGen0First</td> 
   <td>FullGC时是否先YGC</td> 
   <td>false</td> 
  </tr> 
 </tbody> 
</table>

## 收集器相关 ##

<table> 
 <thead> 
  <tr> 
   <th>选项</th> 
   <th>参数详解</th> 
   <th>默认值</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>-XX:+UseParallelGC</td> 
   <td>选择垃圾收集器为并行收集器。此配置仅对年轻代有效。可以同时并行多个垃圾收集线程，但此时用户线程必须停止。</td> 
   <td>--</td> 
  </tr> 
  <tr> 
   <td>-XX:+UseParNewGC</td> 
   <td>设置年轻代收集器ParNew</td> 
   <td>--</td> 
  </tr> 
  <tr> 
   <td>-XX:ParallelGCThreads</td> 
   <td>Parallel并行收集器的线程数</td> 
   <td>--</td> 
  </tr> 
  <tr> 
   <td>-XX:+UseParallelOldGC</td> 
   <td>设置老年代的并行收集器是ParallelOld</td> 
   <td>--</td> 
  </tr> 
  <tr> 
   <td>-XX:+UseG1GC</td> 
   <td>使用G1收集器</td> 
   <td>--</td> 
  </tr> 
  <tr> 
   <td>-XX:MaxGCPauseMillis</td> 
   <td>每次年轻代垃圾回收的最长时间(最大暂停时间)</td> 
   <td>--</td> 
  </tr> 
  <tr> 
   <td>-XX:+UseAdaptiveSizePolicy</td> 
   <td>设置此选项后,并行收集器会自动选择年轻代区大小和相应的Survivor区比例,以达到目标系统规定的最低相应时间或者收集频率等,此值建议使用并行收集器时,一直打开.</td> 
   <td>--</td> 
  </tr> 
  <tr> 
   <td>-XX:GCTimeRatio</td> 
   <td>设置垃圾回收时间占程序运行时间的，百分比公式为1/(1+n)</td> 
   <td>--</td> 
  </tr> 
  <tr> 
   <td>-XX:+ScavengeBeforeFullGC</td> 
   <td>Full GC前调用YGC</td> 
   <td>true</td> 
  </tr> 
  <tr> 
   <td>-XX:+UseConcMarkSweepGC</td> 
   <td>使用CMS内存收集</td> 
   <td>--</td> 
  </tr> 
  <tr> 
   <td>-XX:+AggressiveHeap</td> 
   <td>试图是使用大量的物理内存长时间大内存使用的优化，能检查计算资源（内存， 处理器数量）至少需要256MB内存大量的CPU／内存， （在1.4.1在4CPU的机器上已经显示有提升）</td> 
   <td>--</td> 
  </tr> 
  <tr> 
   <td>-XX:CMSFullGCsBeforeCompaction</td> 
   <td>由于并发收集器不对内存空间进行压缩,整理,所以运行一段时间以后会产生"碎片",使得运行效率降低.此值设置运行多少次GC以后对内存空间进行压缩,整理</td> 
   <td>--</td> 
  </tr> 
  <tr> 
   <td>-XX:+CMSParallelRemarkEnabled</td> 
   <td>降低CMS标记停顿</td> 
   <td>--</td> 
  </tr> 
  <tr> 
   <td>-XX+UseCMSCompactAtFullCollection</td> 
   <td>在FULL GC的时候， 对年老代的压缩，CMS是不会移动内存的， 因此， 这个非常容易产生碎片， 导致内存不够用， 因此， 内存的压缩这个时候就会被启用。 增加这个参数是个好习惯。可能会影响性能,但是可以消除碎片</td> 
   <td>--</td> 
  </tr> 
  <tr> 
   <td>-XX:+UseCMSInitiatingOccupancyOnly</td> 
   <td>使用手动定义初始化定义开始CMS收集，禁止hostspot自行触发CMS GC</td> 
   <td>--</td> 
  </tr> 
  <tr> 
   <td>-XX:CMSInitiatingOccupancyFraction=70</td> 
   <td>使用cms作为垃圾回收使用70％后开始CMS收集</td> 
   <td>--</td> 
  </tr> 
  <tr> 
   <td>-XX:CMSInitiatingPermOccupancyFraction</td> 
   <td>设置Perm Gen使用到达多少比率时触发</td> 
   <td>--</td> 
  </tr> 
  <tr> 
   <td>-XX:+CMSIncrementalMode</td> 
   <td>设置为增量模式</td> 
   <td>--</td> 
  </tr> 
  <tr> 
   <td>-XX:CMSTriggerRatio</td> 
   <td>CMSInitiatingOccupancyFraction = (100 - MinHeapFreeRatio) + (CMSTriggerRatio * MinHeapFreeRatio / 100) 处罚cms收集的比例</td> 
   <td>--</td> 
  </tr> 
  <tr> 
   <td>-XX:MinHeapFreeRatio</td> 
   <td>java堆中空闲量占的最小比例</td> 
   <td>--</td> 
  </tr> 
  <tr> 
   <td>-XX:+CMSClassUnloadingEnabled</td> 
   <td>如果你启用了CMSClassUnloadingEnabled ，垃圾回收会清理持久代，移除不再使用的classes。这个参数只有在 UseConcMarkSweepGC 也启用的情况下才有用。参数如下：</td> 
   <td>--</td> 
  </tr> 
 </tbody> 
</table>

## 辅助信息 ##

<table> 
 <thead> 
  <tr> 
   <th>选项</th> 
   <th>参数详解</th> 
   <th>默认值</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>-XX:+PrintGC</td> 
   <td>输出形式:[GC 118250K-&gt;113543K(130112K), 0.0094143 secs]Full GC 121376K-&gt;10414K(130112K), 0.0650971 secs]</td> 
   <td>--</td> 
  </tr> 
  <tr> 
   <td>-XX:+PrintGCDetails</td> 
   <td>--</td> 
   <td>--</td> 
  </tr> 
  <tr> 
   <td>-XX:+PrintGCTimeStamps</td> 
   <td>--</td> 
   <td>--</td> 
  </tr> 
  <tr> 
   <td>-XX:+PrintGC:PrintGCTimeStamps</td> 
   <td>--</td> 
   <td>--</td> 
  </tr> 
  <tr> 
   <td>-XX:+PrintGCApplicationStoppedTime</td> 
   <td>打印垃圾回收期间程序暂停的时间.可与上面混合使用</td> 
   <td>--</td> 
  </tr> 
  <tr> 
   <td>-XX:+PrintGCApplicationConcurrentTime</td> 
   <td>打印每次垃圾回收前,程序未中断的执行时间.可与上面混合使用</td> 
   <td>--</td> 
  </tr> 
  <tr> 
   <td>-XX:+PrintHeapAtGC</td> 
   <td>打印GC前后的详细堆栈信息</td> 
   <td>--</td> 
  </tr> 
  <tr> 
   <td>-Xloggc:filename</td> 
   <td>把相关日志信息记录到文件以便分析.与上面几个配合使用</td> 
   <td>--</td> 
  </tr> 
  <tr> 
   <td>-XX:+PrintClassHistogram</td> 
   <td>遇到Ctrl-Break后打印类实例的柱状信息，与jmap -histo功能相同</td> 
   <td>--</td> 
  </tr> 
  <tr> 
   <td>-XX:+PrintTenuringDistribution</td> 
   <td>查看每次minor GC后新的存活周期的阈值</td> 
   <td>--</td> 
  </tr> 
  <tr> 
   <td>-XX:PrintHeapAtGC</td> 
   <td>打印GC前后的详细堆栈信息</td> 
   <td>--</td> 
  </tr> 
  <tr> 
   <td>--</td> 
   <td>--</td> 
   <td>--</td> 
  </tr> 
 </tbody> 
</table>

# 八，类加载机制 #

一、 概念：类加载器把class文件中的二进制数据读入到内存中，存放在方法区，然后在堆区创建一个java.lang.Class对象，用来封装类在方法区内的数据结构。类加载的步骤如下：  
1、加载：查找并加载类的二进制数据（把class文件里面的信息加载到内存里面）  
2、连接：把内存中类的二进制数据合并到虚拟机的运行时环境中  
（1）验证：确保被加载的类的正确性。包括：

*     A、类文件的结构检查：检查是否满足Java类文件的固定格式
 *     B、语义检查：确保类本身符合Java的语法规范
 *     C、字节码验证：确保字节码流可以被Java虚拟机安全的执行。字节码流是操作码组成的序列。每一个操作码后面都会跟着一个或者多个操作数。字节码检查这个步骤会检查每一个操作码是否合法。
 *     D、二进制兼容性验证：确保相互引用的类之间是协调一致的。

（2）准备：为类的静态变量分配内存，并将其初始化为默认值  
（3）解析：把类中的符号引用转化为直接引用（比如说方法的符号引用，是有方法名和相关描述符组成，在解析阶段，JVM把符号引用替换成一个指针，这个指针就是直接引用，它指向该类的该方法在方法区中的内存位置）  
3、初始化：为类的静态变量赋予正确的初始值。当静态变量的等号右边的值是一个常量表达式时，不会调用static代码块进行初始化。只有等号右边的值是一个运行时运算出来的值，才会调用static初始化。

二、双亲委派模型：  
1、当一个类加载器收到类加载请求的时候，它首先不会自己去加载这个类的信息，而是把该   
请求转发给父类加载器，依次向上。所以所有的类加载请求都会被传递到父类加载器中，只有当父类加载器中无法加载到所需的类，子类加载器才会自己尝试去加载该类。当当前类加载器和所有父类加载器都无法加载该类时，抛出ClassNotFindException异常。  
2、意义：

提高系统的安全性。用户自定义的类加载器不可能加载应该由父加载器加载的可靠类。（比如用户定义了一个恶意代码，自定义的类加载器首先让系统加载器去加载，系统加载器检查该代码不符合规范，于是就不继续加载了）  
3、定义类加载器：如果某个类加载器能够加载一个类，那么这个类加载器就叫做定义类加载器  
4、初始类加载器：定义类加载器及其所有子加载器都称作初始类加载器。  
5、运行时包：  
（1）由同一个类加载器加载并且拥有相同包名的类组成运行时包  
（2）只有属于同一个运行时包的类，才能访问包可见（default）的类和类成员。作用是 限制用户自定义的类冒充核心类库的类去访问核心类库的包可见成员。  
6、加载两份相同的class对象的情况：A和B不属于父子类加载器关系，并且各自都加载了同一个类。

三、特点：  
1、全盘负责：当一个类加载器加载一个类时，该类所依赖的其他类也会被这个类加载器加载到内存中。  
2、缓存机制：所有的Class对象都会被缓存，当程序需要使用某个Class时，类加载器先从缓存中查找，找不到，才从class文件中读取数据，转化成Class对象，存入缓存中。

三、 类加载器：  
两种类型的类加载器：  
1、 JVM自带的类加载器（3种）：  
（1）根类加载器（Bootstrap）：

*  a、C++编写的，程序员无法在程序中获取该类
 *  b、负责加载虚拟机的核心库，比如java.lang.Object
 *  c、没有继承ClassLoader类

（2）扩展类加载器（Extension）：

*  a、Java编写的，从指定目录中加载类库
 *  b、父加载器是根类加载器
 *  c、是ClassLoader的子类
 *  d、如果用户把创建的jar文件放到指定目录中，也会被扩展加载器加载。

（3）系统加载器（System）或者应用加载器(App)：

*  a、Java编写的
 *  b、父加载器是扩展类加载器
 *  c、从环境变量或者class.path中加载类
 *  d、是用户自定义类加载的默认父加载器
 *  e、是ClassLoader的子类

2、用户自定义的类加载器：  
（1）Java.lang.ClassLoader类的子类  
（2）用户可以定制类的加载方式  
（3）父类加载器是系统加载器  
（4）编写步骤：

*  A、继承ClassLoader
 *  B、重写findClass方法。从特定位置加载class文件，得到字节数组，然后利用defineClass把字节数组转化为Class对象

（5）为什么要自定义类加载器？

*  A、可以从指定位置加载class文件，比如说从数据库、云端加载class文件
 *  B、加密：Java代码可以被轻易的反编译，因此，如果需要对代码进行加密，那么加密以后的代码，就不能使用Java自带的ClassLoader来加载这个类了，需要自定义ClassLoader，对这个类进行解密，然后加载。

问题：Java程序对类的执行有几种方式：  
1、 主动使用（6种情况）：  
JVM必须在每个类“首次 主动使用”的时候，才会初始化这些类。  
（1） 创建类的实例  
（2） 读写某个类或者接口的静态变量  
（3） 调用类的静态方法  
（4） 同过反射的API（Class.forName()）获取类  
（5） 初始化一个类的子类  
（6） JVM启动的时候，被标明启动类的类（包含Main方法的类）  
只有当程序使用的静态变量或者静态方法确实在该类中定义时，该可以认为是对该类或者接口的主动使用。  
2、 被动使用：除了主动使用的6种情况，其他情况都是被动使用，都不会导致类的初始化。  
3、 JVM规范允许类加载器在预料某个类将要被使用的时候，就预先加载它。如果该class文件缺失或者存在错误，则在程序“首次 主动使用”的时候，才报告这个错误。（Linkage Error错误）。如果这个类一直没有被程序“主动使用”，就不会报错。

类加载机制与接口：  
1、 当Java虚拟机初始化一个类时，不会初始化该类实现的接口。  
2、 在初始化一个接口时，不会初始化这个接口父接口。  
3、 只有当程序首次使用该接口的静态变量时，才导致该接口的初始化。

ClassLoader：  
1、 调用Classloader的loadClass方法去加载一个类，不是主动使用，因此不会进行类的初始化。

类的卸载：  
1、 有JVM自带的三种类加载器（根、扩展、系统）加载的类始终不会卸载。因为JVM始终引用这些类加载器，这些类加载器使用引用他们所加载的类，因此这些Class类对象始终是可到达的。  
2、 由用户自定义类加载器加载的类，是可以被卸载的。

[1710354522-5ad304bfcff05_articlex]: /images/20220523/7dd241af3aef488eb51b4ebd7a454157.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2llZmxleA_size_16_color_FFFFFF_t_70]: /images/20220523/b3e5091620e5436ba1f286a90ca4efc1.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2llZmxleA_size_16_color_FFFFFF_t_70 1]: /images/20220523/e8758df6987442ffb5b39b0118f71115.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2llZmxleA_size_16_color_FFFFFF_t_70 2]: /images/20220523/0f201cc9aed6445ea2cb4ab49dfa96d7.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2llZmxleA_size_16_color_FFFFFF_t_70 3]: /images/20220523/d3bb317e89524e298008d533419bcc68.png