java基础巩固-宇宙第一AiYWM：为了维持生计，JVM_Part2~(类加载器&双亲委派机制、内存泄漏etc..)整起

本文链接：https://blog.csdn.net/m0_52436398/article/details/122523953

详细的图又需要的，评论区留言，后面发给你
自己整理的笔记框图

上一篇博客就开了个头，除了一些获奖感言性质的开场白后，就引出了咱们写一个类，比如DemoByywm.java，然后咱们就有了两种处理方式：

如果是IDEA或者eclipse写的，咱们写的DemoByywm.java肯定也经过编译和执行两个过程了，只不过生成的DemoByywm.class需要根据个人环境设置在代码目录层级中找找
如果咱们使用记事本写的，那么可能需要自己在命令行黑窗口中输入：

javac DemoByywm.java //这不就是咱们自己进行了“编译”嘛

等到咱们的指定目录下生成DemoBuywm.class，然后咱们接着输入，咱们写的java程序就会执行了（正常情况下）

java DemoByywm//这不就是“执行”嘛

上面有几个注意点，我记得学基础的时候有些印象：

类名必须要用大驼峰，然后涉及到名字的地方必须保持一致（这其实大家不用太专门记，因为你把java编译器可以想象成一个，你丢了东西帮你找东西的警察。你至少得把名字，涉及到名字的地方该对应一致就对应一致，不然编译器找不到他咋帮你执行）
上面写的路径以及类名，要根据个人电脑具体路径情况而来，不能生套

然后呢，咱们有了DemoByywm.class字节码文件之后，这个东西下来被发配到哪里去了呢。
网上找的有关JVM的类加载机制的一些面试常问问题
Notes:首先可以知道咱们编译生成的字节码文件DemoByywm.class会被放入类加载器中加载(类加载器的作用就是用来加载Class文件到运行时数据区域的方法区，这个Class文件是经.java文件编译而生成的)并且初始化。

类加载器是指：通过一个类的全限定性类名获取该类的二进制字节流叫做类加载器；（虚拟机设计团队把类加载器阶段中的“通过一个类的全限定名来获取描述此类的二进制字节流”这个动作放到Java虚拟机外部去实现，以便让应用程序自己决定如何去获取所需要的类，实现这个动作的代码模块称为"类加载器"）
- 类加载器不仅仅只有实现类的加载动作这个功能，
- 还有对于任意一个类都需要这个加载这个类的类加载器和这个类本身一同确立这个类在Java虚拟机中的唯一性（每一个类加载器都有一个独立的类名称空间）
  - 这里补充个小点，两个类相等要相等需要类本身相等（这里的相等，包括类的Class对象的equals()方法，isAssignableFrom()方法，isInstance()都返回true，也包括使用instanceof关键字做对象的所属关系判定结果为true），并且使用同一个类加载器进行加载。这是因为每一个类加载器都拥有一个独立的类名称空间

别看里面东西很多，但是暂且咱以面试为目前目标的话（上面思维导图是网上找的有关JVM的类加载机制的一些面试常问问题），重点也就下面几个。

虚拟机的类加载机制：虚拟机把描述类的数据从存储着字节码的Class文件中加载到内存中，然后对其中的数据进行校验、转换解析和初始化，最终形成可以被虚拟机直接使用的class对象，这个过程就可以成为虚拟机的类加载机制。
- 类加载发生在所有实例化操作之前。
  - 实例化不是类加载的一个过程
  - 类加载只进行一次，而实例化可以进行多次
- 类是在**运行期间第一次使用时动态加载的**（而不是一次性加载所有类，因为不是所有类都要一次性使用得到，要是一次性加载所有类包括那些不会被用到的，那这些闲人多么占内存呀）
  - 其实就是为了灵活，比如编写一个面向接口的应用程序，就可以等到运行时再指定其实际的子实现类
  - 而且作为用户咱们也可以通过Java中的各种类加载器让一个本地的应用程序可以在运行时从网络上或者其他地方加载进来一个二进制流作为程序代码的一部分，这手可不是伸的很长了嘛
- 在这里，可以和大家分享一下，如果两个类模板要相等，需要满足很多条件，如下框图：
- 这意思就是，咱们一个类的类模板（我个人习惯叫做类模板）只有一个，然后咱们的new操作都是根据这个类模板实例化一个有一个（也就是说虽然new出了很多对象，但是这些对象用的类模板都是同一个类模板）。下面这个例子程序大家也可以看出来，因为多个对象用的是同一个类模板，所以打印出来的是同一个hashcode值（假设身份证可以重复的话，大家可以把这个值包括地址值想象成为咱们的身份证，纸面上来说如果两个人身份证相同我就可以把这两个人认为是同一个人，）然后每个对象按照类模板会在堆中new出自己的一块地盘（所以各自占各自的地盘，那地盘就不一样了），然后在用栈中的引用对象（变量）指向堆中的自己划定的地盘。
  - 这里补充个小点，两个类相等要相等需要类本身相等（这里的相等，包括类的Class对象的equals()方法，isAssignableFrom()方法，isInstance()都返回true，也包括使用instanceof关键字做对象的所属关系判定结果为true），并且使用同一个类加载器进行加载。这是因为每一个类加载器都拥有一个独立的类名称空间
下来就是了解了这些类似班规的东西之后，就得看看类加载过程到底是怎样的呢？
- 类的整个生命周期（从类被加载到虚拟机内存中开始到卸载出内存为止） 包括：加载（Loading）、验证（Verification）、准备(Preparation)、解析(Resolution)、初始化(Initialization)、使用(Using)和卸载(Unloading)7个阶段。其中准备、验证、解析3个部分统称为连接（Linking）。如图所示
  - 加载、验证、准备、初始化和卸载这5个阶段的顺序是确定的。类的加载过程必须按照这种顺序按部就班地开始，而解析阶段则不一定，它在某些情况下可以在初始化阶段之后再开始，这是为了支持Java语言的运行时绑定（也称为动态绑定或晚期绑定）
  - 加载阶段和连接阶段的开始时间是保持着固定的先后顺序，但是这两个阶段是交叉进行的
类加载过程如下：（加载阶段用户应用程序可以通过自定义类加载器参与之外，其余动作都由虚拟机主导和控制）。到了初始化阶段才真正开始执行类中定义的Java代码（字节码）
- 加载，加载是类加载过程的第一步，加载分为三步：
  - 1、通过类的全限定性类名获取该类的二进制字节流；
    - 从哪里取怎么取，虚拟机规范没有限定，任由使用者发挥创意，如下
    - 一个非数组类的加载阶段（加载阶段获取类的二进制字节流的动作）是可控性最强的阶段，这一步我们 可以去完成还可以自定义类加载器去控制字节流的获取方式（重写一个类加载器的 loadClass() 方法）。数组类型不通过类加载器创建，它由 Java 虚拟机直接创建。
  - 2、将该二进制流所代表的静态存储结构转为方法区的运行时数据结构；
  - 3、在堆内存中为该类生成一个代表这个类的java.lang.Class对象，作为方法区这个类的各种数据的访问入口；
    - 对于HotSpot虚拟机来说Class对象比较特殊，不放在堆中而放在方法区中，并且这个对象将作为程序访问方法区中的这些类型数据的外部接口
    - 加载阶段和连接阶段的部分内容是交叉进行的，加载阶段尚未结束，连接阶段可能就已经开始了
- 验证：验证该class文件中的字节流信息复合虚拟机的要求，不会威胁到jvm的安全；
  - 意思是，Class文件不一定是用Java语言写的源码产生的（至少语义上可以表达出来），所以如果不进行验证有可能会因为载入了有害的字节流而导致系统崩溃
  - 如果验证到输入的字节流不符合Class文件格式虚拟机就应该抛出一个java.lang.VerifyError异常或者子类异常
  - 验证阶段大致上会完成四个阶段的检验动作：
    - 文件格式验证
    - 元数据验证
    - 字节码验证：主要通过数据流和控制流分析确定程序语义是合法符合逻辑的
    - 符号引用验证
- 准备：为class对象的静态变量（记住，不包含实例变量哦）分配内存，并初始化其初始值（零值），这些类变量所使用的内存都将在方法区中进行分配；
  - 假设一个类变量定义为：private static int value = 123;变量value在准备阶段过后的初始值为0而不是123，（把value赋值为123的putstatic指令是程序被编译后存放于类构造器()方法中），把value赋值为123的动作将在初始化阶段才会执行
    - 实例变量会在对象实例化时随着对象一块分配在 Java 堆中
    - 从概念上讲，类变量所使用的内存都应当在方法区中进行分配。不过有一点需要注意的是：JDK 7 之前，HotSpot 使用永久代来实现方法区的时候，实现是完全符合这种逻辑概念的。而在 JDK 7 及之后，HotSpot 已经把原本放在永久代的字符串常量池、静态变量等移动到堆中，这个时候类变量则会随着 Class 对象一起存放在 Java 堆中
  - 基本数据类型的零值
- 解析：（该阶段主要将常量池中的符号引用替换成直接引用，也就是得到类或者字段、方法在内存中的指针或者偏移量）；要能解析，这个方法在程序真正运行前就得有一个确定的调用版本并且这个方法的调用版本在运行期间不可被改变（运行期不可变）（也就是说调用目标在代码写好、编译器进行编译时就必须确定下来（编译期可知）），这类方法的调用称为解析
  - 解析（调用） 是个静态过程，也就是说在类装载的解析阶段就会把涉及到的符号引用转变为可确定的直接引用并不会延迟到运行期再去完成
    - 解析动作主要针对类或接口、字段、类方法、接口方法、方法类型、方法句柄和调用限定符 7 类符号引用进行。
  - 只要能被invokestatic和invokespecial指令调用的方法（这类方法叫做非虚方法，除了被这俩指令调用的方法，还有被final修饰的方法也叫做非虚方法）都可以在解析阶段中确定唯一的调用版本，符合条件的有：静态方法、私有方法、实例构造器（构造方法）、父类方法4类，也就是说这四类方法（也可以叫做非虚方法）在类加载时就会把符号引用解析为该方法的直接引用
  - 咱们Java中符合“编译期可知，运行期不可变”的方法主要就是：静态方法（与类直接关联或者说属于类）和私有方法（在外部不可被访问），也就是说这两种方法适合在类加载阶段进行解析。
  - 符号引用在Class文件中~（这篇文章中也提到：所有方法调用中的目标方法在Class文件中其实都是一个常量池中的符号引用）。在类加载的解析阶段会将常量池中的一部分符号引用转化为直接引用。
    - 符号引用就是一组符号来描述目标，可以是任何字面量。直接引用就是直接指向目标的指针、相对偏移量或一个间接定位到目标的句柄。在程序实际运行时，只有符号引用是不够的，举个例子：在程序执行方法时，系统需要明确知道这个方法所在的位置。Java 虚拟机为每个类都准备了一张方法表来存放类中所有的方法。当需要调用一个类的方法的时候，只要知道这个方法在方法表中的偏移量就可以直接调用该方法了。通过解析操作符号引用就可以直接转变为目标方法在类中方法表的位置，从而使得方法可以被调用。
- 初始化：到了初始化阶段（初始化阶段是执行类构造器()方法的过程），这一步 JVM 才开始真正执行类中定义的 Java 程序代码(字节码)。；初始化阶段是调用类构造器的过程（加载、验证、准备等阶段必须要在初始化之前完成）
  - ()方法是编译之后自动生成的
  - 对于 () 方法的调用，虚拟机会自己确保其在多线程环境中的安全性。因为 <clinit> () 方法是带锁线程安全，所以在多线程环境下进行类初始化的话可能会引起多个线程阻塞，并且这种阻塞很难被发现。
  - 初始化阶段虚拟机严格规定有且只有5种情况必须立刻对类进行初始化 （这五种场景中的行为叫做对一个类进行主动引用，除此之外的所有引用类的方式都不会触发初始化，这也叫作被动引用）
    - 遇到new、getstatic、putstatic、invokestatic（后面这三个就是读取或者设置一个类的静态字段（被final修饰、已在编译器把结果放入常量池的静态字段除外、调用一个类的静态方法时））这四条字节码指令时，如果类还没有进行过初始化就需要先触发初始化
      - 比如 new 一个类，读取一个静态字段(未被 final 修饰)、或调用一个类的静态方法时。
        当 jvm 执行 new 指令时会初始化类。即当程序创建一个类的实例对象。
        当 jvm 执行 getstatic 指令时会初始化类。即程序访问类的静态变量(不是静态常量，常量会被加载到运行时常量池)
        当 jvm 执行 putstatic 指令时会初始化类。即程序给类的静态变量赋值
        当 jvm 执行 invokestatic 指令时会初始化类。即程序调用类的静态方法。
    - 使用java.lang.reflect包的方法对类进行反射调用时，如果类还没有进行过初始化就需要先触发初始化
    - 当初始化一个类时如果发现这个类的父类还没有进行过初始化就需要先触发父类的初始化
      - 但是一个接口在初始化时并不要求其父接口全部完成了初始化，只有在真正使用到父接口时（比如引用接口中定义的常量）才会初始化
    - 当虚拟机启动时用户需要指定一个要执行的主类（主类就是包含main()方法的那个类），虚拟机就会先初始化这个主类
    - 当一个接口中定义了 JDK8 新加入的默认方法（被 default 关键字修饰的接口方法）时，如果有这个接口的实现类发生了初始化，那该接口要在其之前被初始化。
    - 下图中如果类还没有进行过初始化就需要先触发初始化【MethodHandle 和 VarHandle 可以看作是轻量级的反射调用机制，而要想使用这 2 个调用，就必须先使用 findStaticVarHandle 来初始化要调用的类】
- 卸载:卸载类即该类的 Class 对象被 GC。
  - 卸载类需要满足 3 个要求:
    - 该类的所有的实例对象都已被 GC，也就是说堆不存在该类的实例对象。
    - 该类没有在其他任何地方被引用
    - 该类的类加载器的实例已被 GC
      - 所以，在 JVM 生命周期内，由 jvm 自带的类加载器加载的类是不会被卸载的。但是由我们自定义的类加载器加载的类是可能被卸载的。jdk 自带的 BootstrapClassLoader, ExtClassLoader, AppClassLoader 负责加载 jdk 提供的类，所以它们(类加载器的实例)肯定不会被回收。而我们自定义的类加载器的实例是可以被回收的，所以使用我们自定义加载器加载的类是可以被卸载掉的。

好大几个字，其实我感觉就是这么一个过程。小胡和他媳妇敏小言去民政&局领证了（开心^（+∞）），然后刚进门。

工作人员说，hello呀，为了表示你们成为一对夫妻了，我要开始把你们变成这个证上的文字和图片了哦（其实说到底，就是用证书上的文字和图片表示，小胡和敏小言结婚了）。

（从业IT的小胡心里想，这不就是类加载器的加载过程嘛，把表示我和我媳妇从哪里来的家庭信息、表示我俩叫啥名字、性别以及职业等信息获取成为计算机能够识别的二进制代码，然后转换成为其他调用我这些信息的机器或者人或者其他文字或者图片们（不错，这些东西现在都活了，文字会说话、机器会说话、图片也学人说话）能认出来的一些标识或者标志）
然后，民政&局工作人员开始，边操作边碎碎念：
- 两人没有参加法轮功
- 两人都符合共和国合法公民
  （从业IT的小胡心里想，这不就开始类加载器的验证过程了吗，你加载进去的信息，java的大管家（或者叫运行平台）JVM要验证你安不安全呀，符不符合规范呀，有没有自带病毒呀…）
然后，工作人员在众多结婚证的证件号注册表中找个位置把我和敏小言的证件号挤进去，并且工作人员验证了一下民政&局自己的各项手续和证书上他们要填的东西（保证自己官方的东西不能出错）。然后同时让我和敏小言给结婚证上的很多信息填这填那…
(从业IT的小胡心里想，这不就是类加载中的准备过程嘛，不过这工作人员也太懒了吧，凭啥都让我和我家敏敏填，(￢︿̫̿￢☆)…)
然后，工作人员把我俩填好的拿过去看。哎呀，你这小胡，真虎，性别你画的这个是啥，♂，好好写字，就用一个什么涂改液给我涂了，让我重写，并且还在那碎碎念。哎，现在这小伙，光会打字都不会写字了…
(小胡心里又想，也是，人家说得对，电脑用的时间长了都不会写字了…。不对，想错了，怎么开始感慨人生了，类加载器加载过程还没想完呢，重来内心独白。从业IT的小胡心里重新想，这不就是解析过程嘛，其实感觉还是JVM在验证我俩的信息对不对，真细致真认真，修的共枕眠确实得好好努力呀)
然后，工作人员重新验证了一下民政&局自己的各项手续和证书上他们要填的东西，然后核对了一下我们俩自己填的东西，最后把官方的各项信息以及我和敏敏填好的各项信息（也就是整个证书，为了体现过程性，我就拆分开来了）去放到机器上印了出来
（从业IT的小胡心里想，哎呦，这不就是初始化过程嘛）

可能例子不是很具体贴切到各个知识点，但是希望大家根据框图在脑海中形成自己的“民政&局领证过程”。很令人激动的哦，希望大家都能顺心如意碰到自己的枕边人。
下来大家就得下下苦工啦，这些可能得多记记了。不过呢，我还是给大家准备好了框架，方便大家记忆。我一般习惯分两个角度来看，其实就是一个角度分的多（一个分的细），一个角度分的少（一个分的粗）。不觉得这句话在任何东西的分类上都能应用嘛
从开发人员角度来看

有的说法也是：类加载器分为以下四种【JVM 中内置了三个重要的 ClassLoader，除了 BootstrapClassLoader 其他类加载器均由 Java 实现且全部继承自java.lang.ClassLoader：】

启动类加载器（BootStrapClassLoader）：用来加载java核心类库，无法被java程序直接引用；
- 最顶层的加载类，由 C++实现，负责加载 %JAVA_HOME%/lib目录下的 jar 包和类或者被 -Xbootclasspath参数指定的路径中的所有类
扩展类加载器（Extension ClassLoader）：用来加载java的扩展库，java的虚拟机实现会提供一个扩展库目录，该类加载器在扩展库目录里面查找并加载java类；
- 主要负责加载 %JRE_HOME%/lib/ext 目录下的 jar 包和类，或被 java.ext.dirs 系统变量所指定的路径下的 jar 包。
系统类加载器（AppClassLoader）：它根据java的类路径来加载类，一般来说，java应用的类都是通过它来加载的；
- 面向我们用户的加载器，负责加载当前应用 classpath 下的所有 jar 包和类
自定义类加载器：由java语言实现，继承自ClassLoader；

其实就是分三个呗：

一个是民政&局人家盖好的房子、买好的仪器，这你是没办法改的，这是根
一个是民政&局局子里面的不同小部门，这些小部分有的可能会设在其他地方。比如你办证的过程中要调档案，你是不是得去组织部或者政府（民政&局的扩展部门）
最后一个我觉得可能就是民政&局对应的线上的一些app或者小程序等等，咱们自己可以在家就办些啥业务。

下来就是上面 不同的类加载器之间的层次关系，构成了双亲委派模型(Parents Delegation Model)【一个类加载器收到了类加载的请求，不会自己先加载，而是把它交给自己的父类去加载，层层迭代。】。也就是说如果应用程序类加载器收到了一个类加载的请求，会先给扩展类加载器，然后再给启动类加载器，如果启动类加载器无法完成这个类加载的请求，再返回给扩展类加载器，如果扩展类加载器也无法完成，就返回给应用类加载器。
在这里插入图片描述

类加载器收到类加载请求之后，先检查是否已经被加载过，已经被加载的类会直接返回。若没有加载会先调用父类加载器的loadClass()方法，（你有结婚请求，你能先去找扩展部门吗？先去app上瞎操作啥玩意嘛，肯定不是呀，肯定是先到民政&局，看他要咱们去啥扩展部门或者其他啥线上业务，咱们在根据提示去办就行）。这一步就叫将类加载请求委托给父类加载器去完成，若父加载器为空则默认一直向上委托直到跟加载器（启动类加载器）。然后启动类加载器检查自己能够加载当前这个类（调用findClass()方法进行加载）（你民政&局子能办好这个业务不？）。
- 双亲委派模型要求除了顶层的启动类加载器外其余的类加载器都要有自己的父类加载器（以组合关系来复用父加载器的代码而不是使用继承）
  - 双亲委派模型，即在类加载的时候，系统会首先判断当前类是否被加载过。已经被加载的类会直接返回，否则才会尝试加载。加载的时候，首先会把该请求委派给父类加载器的 loadClass() 处理，因此所有的请求最终都应该传送到顶层的启动类加载器 BootstrapClassLoader 中。当父类加载器无法处理时，才由自己来处理。当父类加载器为 null 时，会使用启动类加载器 BootstrapClassLoader 作为父类加载器。
  - 双亲委派模型的实现代码都集中在 java.lang.ClassLoader 的 loadClass() 中
```
private final ClassLoader parent;
protected Class<?> loadClass(String name, boolean resolve)
        throws ClassNotFoundException
    {
        synchronized (getClassLoadingLock(name)) {
            // 首先，检查请求的类是否已经被加载过
            Class<?> c = findLoadedClass(name);
            if (c == null) {
                long t0 = System.nanoTime();
                try {
                    if (parent != null) {//父加载器不为空，调用父加载器loadClass()方法处理
                        c = parent.loadClass(name, false);
                    } else {//父加载器为空，使用启动类加载器 BootstrapClassLoader 加载
                        c = findBootstrapClassOrNull(name);
                    }
                } catch (ClassNotFoundException e) {
                   //抛出异常说明父类加载器无法完成加载请求
                }

                if (c == null) {
                    long t1 = System.nanoTime();
                    //自己尝试加载
                    c = findClass(name);

                    // this is the defining class loader; record the stats
                    sun.misc.PerfCounter.getParentDelegationTime().addTime(t1 - t0);
                    sun.misc.PerfCounter.getFindClassTime().addElapsedTimeFrom(t1);
                    sun.misc.PerfCounter.getFindClasses().increment();
                }
            }
            if (resolve) {
                resolveClass(c);
            }
            return c;
        }
    }
```
- 启动类加载器（民政&局说能干，他就帮你干了）能加载就加载完成请求
- 启动类加载器干不了，就抛出ClassNotFoundException异常，通知自己的子加载器进行这个类加载请求的加载。
  - 双亲委派模型的好处：Jvm 中类的唯一性是由类本身和加载这个类的类加载器决定的，简单的说，如果有个a类，如果被两个不同的类加载器加载，那么他们必不相等。你看到这里会不会想到所有类的父类都是 Object 是怎么实现的了吗？是因为无论哪一个类加载器加载 Object 类，都会交给最顶层的启动类加载器去加载，这样就保证了 Object 类在 Jvm 中是唯一的。
    - 双亲委派模型保证了 Java 程序的稳定运行，可以避免类的重复加载（JVM 区分不同类的方式不仅仅根据类名，相同的类文件被不同的类加载器加载产生的是两个不同的类），也保证了 Java 的核心 API 不被篡改。如果没有使用双亲委派模型，而是每个类加载器加载自己的话就会出现一些问题，比如我们编写一个称为 java.lang.Object 类的话，那么程序运行的时候，系统就会出现多个不同的 Object 类
  - AppClassLoader的父类加载器为ExtClassLoader， ExtClassLoader的父类加载器为 null，null 并不代表ExtClassLoader没有父类加载器，而是 BootstrapClassLoader

为什么要有双亲委派模型（双亲委派模型的优点：当一个类加载器收到一个类加载的请求，他首先不会尝试自己去加载，而是将这个请求委派给父类加载器去加载，只有父类加载器在自己的搜索范围类查找不到给类时，子加载器才会尝试自己去加载该类；为了防止内存中出现多个相同的字节码；因为如果没有双亲委派的话，用户就可以自己定义一个java.lang.String类，那么就无法保证类的唯一性）。

怎么说呢，就一句话，有了双亲委派模型，假如有人冒充说是，我是民政&局的扩展机构、我是民政&局的线上app或者小程序。民政&局会亲自打假，不会让一对又一对新人受到欺骗和损失。

具体一点的话，咱们java这里Object和String这些类很多人在用吧，要是有人冒充，用自己写的一个里面满是不良打印信息的Object和String类去冒充，那不就出事了。但是有咱们双亲委派模型存在，这种隐患就不复存在了。
在这里插入图片描述

如果我们不想用双亲委派模型怎么办？那怎么打破双亲委派模型：自定义类加载器，需要继承ClassLoader类，重写loadClass方法和findClass方法【如果我们不想打破双亲委派模型，就重写 ClassLoader 类中的 findClass() 方法即可，无法被父类加载器加载的类最终会通过这个方法被加载。但是，如果想打破双亲委派模型则需要重写 loadClass() 方法】
- 列举一些你知道的打破双亲委派机制的例子以及为什么要打破
  - JNDI 通过引入线程上下文类加载器，可以在Thread.setContextClassLoader 方法设置，默认是应用程序类加载器，来加载 SPI 的代码。有了线程上下文类加载器，就可以完成父类加载器请求子类加载器完成类加载的行为。打破的原因，是为了 JNDI 服务的类加载器是启动器类加载，为了完成高级类加载器请求子类加载器（即上文中的线程上下文加载器）加载类
  - Tomcat，应用的类加载器优先自行加载应用目录下的 class，并不是先委派给父加载器，加载不了才委派给父加载器。tomcat之所以造了一堆自己的classloader，大致是出于下面四类目的：
    - 对于各个 webapp中的 class和 lib，需要相互隔离，不能出现一个应用中加载的类库会影响另一个应用的情况，而对于许多应用，需要有共享的lib以便不浪费资源
    - 与 jvm一样的安全性问题。使用单独的 classloader去装载 tomcat自身的类库，以免其他恶意或无意的破坏
    - 打破的原因是为了实现模块热替换。OSGi，实现模块化热部署（修改后，不用重启可继续按照新的使用。换句话说实现模块级的热插拔功能，当程序升级更新或者调试除错时，可以只停用、重新安装然后启用程序的其中一部分），为每个模块都自定义了类加载器，需要更换模块时，模块与类加载器一起更换。其类加载的过程中，有平级的类加载器加载行为。
  - OSGI(Open Service Gateway Initiative)是OSGI联盟制定的一个基于Java语言的动态模块化规范，目的是使服务提供商通过住宅网关为各种家用智能设备提供各种服务，现在已经成为Java世界中事实上的模块化标准。OSGI著名的应用案例就是Eclipse IDEA
    - OSGi在提供强大功能时也带来了线程死锁（类加载器们想加载被对方锁定的类（当类加载器想加载每个包下的类时首先需要锁定当前类加载器的实例对象，然后把请求委派给某个类加载器去处理））和内存泄露的风险
      - 内存泄漏原因：在Java中，内存泄漏就是存在一些被分配的对象，首先，这些对象是有被引用的。其次，这些对象是无用的，即程序以后不会再使用这些对象。这些对象不会被GC所回收，然而它却占用内存。
        几种常见的内存泄漏：
        
        定位及解决：
        
        1.把Java应用程序使用的heap dump下来
        2.使用Java heap分析工具，找出内存占用超出预期（一般是因为数量太多）的嫌疑对象
        博客园这位老师关于用MAT分析线上故障的连载文章，很赞
        使用Eclipse Memory Analyzer Tool（MAT）分析线上故障(一) - 视图&功能篇
        
        3.必要时，需要分析嫌疑对象和其他对象的引用关系
        4.查看程序的源代码，找出嫌疑对象数量过多的原因。
      - 内部类持有外部类会导致内存泄露
        非静态内部类会持有外部类，如果有地方引用了这个非静态内部类，会导致外部类也被引用，垃圾回收时无法回收这个外部类（即使外部类已经没有其他地方在使用了），不就相当于导致内存泄露了嘛
        
        解决方案：
        不要让其他的地方持有这个非静态内部类的引用，直接在这个非静态内部类执行业务【静态内部类无法持有外部类和其非静态字段】
        
        将非静态内部类改为静态内部类。内部类改为静态的之后，它所引用的对象或属性也必须是静态的，所以静态内部类无法获得外部对象的引用，只能从 JVM 的 Method Area（方法区）获取到static类型的引用
      - 若内部类持有外部类的引用，对内部类的使用很多时，会导致外部类数目很多。此时，就算是外部类的数据没有被用到，外部类的数据所占空间也不会被释放。
    - 打破的原因，是为了添加模块化的特性。
  - JDK 9，Extension ClassLoader 被 Platform ClassLoader 取代，当平台及应用程序类加载器收到类加载请求，在委派给父加载器加载前，要先判断该类是否能够归属到某一个系统模块中，如果可以找到这样的归属关系，就要优先委派给负责那个模块的加载器完成加载。

下面是经典的双亲委派模型图(Tomcat服务器的类加载架构)：

委派关系是：上面的类加载器能加载的类都可以被下面的类加载器使用
同一层的类加载器各自自己能加载的类与同层对方相互隔离
JsperLoader的加载范围仅仅是这个JSP文件所编译出来的那一个Class,他出现的目的就是为了被丢弃（当服务器检测到JSP文件被修改时会替换掉目前的JasperLoader的实例，并通过再建立一个新的Jsp类加载器来实现JSP文件的热替换功能）

把框图里面的图片放大一下，太小了看不见。
在这里插入图片描述

咱们可以在程序中通过代码得到这几个的对应关系：类模板、通过类模板实例化而来的对象、类加载器。代码就是一两句，主要是之间的逻辑联系关系。框图贴上，大家可以看看。

下来把类加载到java运行时数据区域（java内存）中，载到哪里了，怎么用，用完了，产生了什么垃圾没有，怎样处理垃圾，谁来处理…
欲知后事如何…拜拜。