万字图文，将ampampquot类加载器ampampquot

　　引子
　　大家想必都有过平时开发springboot项目的时候稍微改动一点代码，就得重启，就很烦
　　网上一般介绍2种方式springbootdevtools，或者通过JRebel插件来实现热部署
　　热部署就是当应用正在运行时，修改应用不需要重启应用。
　　其中springbootdevtools其实是自动重启，主要是节省了我们手动点击重启的时间，不算真正意义上的热部署。JRebel插件啥都好，就是需要收费
　　但如果平时我们在调试debug的情况下，只是在方法块内代码修改了一下，我们还得重启项目，就很浪费时间。这个时候我们其实可以直接build，不重启项目，即可实现热部署。
　　我们先来写一个例子演示一下：RestControllerpublicclassTestController｛RequestMapping（valuetest，method｛RequestMethod。GET，RequestMethod。POST｝）publicvoidtestclass（）｛Sintweight100；System。out。println（name：name）；System。out。println（weight：weight）；｝｝
　　结果：
　　name：zjweight：100
　　修改代码，然后直接build项目，不重启项目，我们再请求这个测试接口：Sintweight300；
　　神奇的一幕出现了，结果为：
　　name：mingweight：300
　　当我们修改。java文件，只需重新生成对应的。class文件，就能影响到程序运行结果，无需重启，Why？背后JVM的操作原理且看本文娓娓道来。了解。class文件
　　首先我们得先了解一下什么是。class文件
　　举个简单的例子，创建一个Person类：publicclassPerson｛状态or属性S姓名S性别身高体重行为publicvoidsleep（）｛System。out。println（this。name睡觉）；｝publicvoideat（）｛System。out。println（吃饭）；｝publicvoidDance（）｛System。out。println（跳舞）；｝｝
　　我们执行javac命令，生成Person。class文件
　　然后我们通过vim16进制打开它打开file文件vimPerson。class在命令模式下输入。。以16进制显示：！xxd在命令模式下输入。。切换回默认显示：！xxdr
　　不同的操作系统，不同的CPU具有不同的指令集，JAVA能做到平台无关性，依靠的就是Java虚拟机。。java源码是给人类读的，而。class字节码是给JVM虚拟机读的，计算机只能识别0和1组成的二进制文件，所以虚拟机就是我们编写的代码和计算机之间的桥梁。
　　虚拟机将我们编写的。java源程序文件编译为字节码格式的。class文件，字节码是各种虚拟机与所有平台统一使用的程序存储格式，class文件主要用于解决平台无关性的中间文件
　　类加载的过程
　　在之前的一篇文章谈谈JAVA中对象和类、this、super和static关键字中，我们知晓Java是如何创建对象的PersonzhangnewPerson（）；
　　虽然我们写的时候是简单的一句，但是JVM内部的实现过程却是复杂的：将硬盘上指定位置的Person。class文件加载进内存执行main方法时，在栈内存中开辟了main方法的空间（压栈进栈），然后在main方法的栈区分配了一个变量zhang。执行new，在堆内存中开辟一个实体类的空间，分配了一个内存首地址值调用该实体类对应的构造函数，进行初始化（如果没有构造函数，Java会补上一个默认构造函数）。将实体类的首地址赋值给zhang，变量zhang就引用了该实体。（指向了该对象）
　　其中上图步骤1Classloader（类加载器）将class文件加载到内存中具体分为3个步骤：加载、连接、初始化
　　类的生命周期一般有如下图有7个阶段，其中阶段15为类加载过程，验证、准备、解析统称为连接
　　加载
　　加载阶段：指的是将类对应的。class文件中的二进制字节流读入到内存中，将这个字节流转化为方法区的运行时数据结构，然后在堆区创建一个java。lang。Class对象，作为对方法区中这些数据的访问入口
　　相对于类加载的其他阶段而言，加载阶段（准确地说，是加载阶段获取类的二进制字节流的动作）是我们最可以控制的阶段，因为开发人员既可以使用系统提供的类加载器来完成加载，也可以自定义类加载器来完成加载。这个我们文章后面再详细讲验证
　　验证阶段：校验字节码文件正确性。这一阶段的目的是为了确保Class文件的字节流中包含的信息符合当前虚拟机的要求，并且不会危害虚拟机自身的安全。
　　这部分对开发者而言是无法干预的，以下内容了解即可
　　验证阶段大致会完成4个阶段的检验动作：文件格式验证：验证字节流是否符合Class文件格式的规范；例如：是否以0xCAFEBABE开头、主次版本号是否在当前虚拟机的处理范围之内、常量池中的常量是否有不被支持的类型。
　　元数据验证：对字节码描述的信息进行语义分析（注意：对比javac编译阶段的语义分析），以保证其描述的信息符合Java语言规范的要求；例如：这个类是否有父类，除了java。lang。Object之外。
　　字节码验证：通过数据流和控制流分析，确定程序语义是合法的、符合逻辑的。
　　符号引用验证：确保解析动作能正确执行。
　　验证阶段是非常重要的，但不是必须的，它对程序运行期没有影响，如果所引用的类经过反复验证，那么可以考虑采用Xverifynone参数来关闭大部分的类验证措施，以缩短虚拟机类加载的时间。准备
　　准备阶段：为类变量（static修饰的变量）分配内存，并将其初始化为默认值
　　注意此阶段仅仅是为类变量即静态变量分配内存，并将其初始化为默认值
　　举个例子，在这个准备阶段：staticintvalue3；类变量初始化，设为默认值0，不是3哦！！！intnum4；类成员变量，在这个阶段不初始化；在new类，调用对应类的构造函数才进行初始化finalstaticvalFin5；这个比较特殊，在这个阶段也不会分配内存！！！
　　注意：valFin是被finalstatic修饰的常量在编译的时候已分配好了，所以在准备阶段此时的值为5，所以在这个阶段也不会初始化！解析
　　解析阶段：是虚拟机将常量池内的符号引用替换为直接引用的过程，解析动作主要针对类或接口、字段、类方法、接口方法、方法类型、方法句柄和调用点限定符7类符号引用进行。
　　符号引用就是一组符号来描述目标，可以是任何字面量。
　　直接引用就是直接指向目标的指针、相对偏移量或一个间接定位到目标的句柄。
　　这个阶段了解一下即可初始化
　　直到初始化阶段，Java虚拟机才真正开始执行类中编写的Java程序代码，将主导权移交给应用程序。
　　初始化阶段是类加载过程的最后一个步骤，之前介绍的几个类加载的动作里，除了在加载阶段用户应用程序可以通过自定义类加载器的方式局部参与外，其余动作都完全由Java虚拟机来主导控制。
　　Java程序对类的使用方式可分为两种：主动使用与被动使用。一般来说只有当对类的首次主动使用的时候才会导致类的初始化，所以主动使用又叫做类加载过程中初始化开始的时机。
　　类实例初始化方式，主要是以下几种：1、创建类的实例，也就是new的方式
　　2、访问某个类或接口的静态变量，或者对该静态变量赋值
　　3、调用类的静态方法
　　4、反射（如Class。forName（com。test。Person））
　　5、初始化某个类的子类，则其父类也会被初始化
　　6、Java虚拟机启动时被标明为启动类的类（JavaTest），还有就是Main方法的类会首先被初始化
　　这边就不展开说了，大家记住即可使用
　　当JVM完成初始化阶段之后，JVM便开始从入口方法开始执行用户的程序代码卸载
　　当用户程序代码执行完毕后，JVM便开始销毁创建的Class对象，最后负责运行的JVM也退出内存
　　在如下几种情况下，Java虚拟机将结束生命周期执行了System。exit（）方法
　　程序正常执行结束
　　程序在执行过程中遇到了异常或错误而异常终止
　　由于操作系统出现错误而导致Java虚拟机进程终止类加载器与双亲委派机制
　　上文类加载过程中，是需要类加载器的参与，类加载器在Java中非常重要，它使得Java类可以被动态加载到Java虚拟机中并执行
　　那什么是类加载器？通过一个类的全限定名来获取描述此类的二进制字节流到JVM中，然后转换为一个与目标类对应的java。lang。Class对象实例
　　Java虚拟机支持类加载器的种类：主要包括3中：引导类加载器（BootstrapClassLoader）、扩展类加载器（ExtensionClassLoader）、应用类加载器（系统类加载器，AppClassLoader），另外我们还可以自定义加载器用户自定义类加载器
　　引导类加载器（BootstrapClassLoader）：BootStrapClassLoader是由c实现的。引导类加载器加载java运行过程中的核心类库JRElibrt。jar，sunrsasign。jar，charsets。jar，jce。jar，jsse。jar，plugin。jar以及存放在JREclasses里的类，也就是JDK提供的类等常见的比如：Object、Stirng、List等扩展类加载器（ExtensionClassLoader）：它用来加载jrelibext目录以及java。ext。dirs系统变量指定的类路径下的类。应用类加载器（AppClassLoader）：它主要加载应用程序ClassPath下的类（包含jar包中的类）。它是java应用程序默认的类加载器。其实就是加载我们一般开发使用的类用户自定义类加载器：用户根据自定义需求，自由的定制加载的逻辑，只需继承应用类加载器AppClassLoader，负责加载用户自定义路径下的class字节码文件线程上下文类加载器：除了以上列举的三种类加载器，其实还有一种比较特殊的类型就是线程上下文类加载器。ThreadContextClassLoader可以是上述类加载器的任意一种，这个我们下文再细说
　　我们来看一个例子：publicclassTestClassLoader｛publicstaticvoidmain（String〔〕args）throwsClassNotFoundException｛ClassLoaderclassLoaderTestClassLoader。class。getClassLoader（）；System。out。println（classLoader）；System。out。println（classLoader。getParent（））；获取其父类加载器System。out。println（classLoader。getParent（）。getParent（））；获取父类的父类加载器｝｝
　　结果：sun。misc。Launcher
　　ExtClassLoader5caf905dnull
　　结果显示分别打印应用类加载器、扩展类加载器和引导类加载器
　　由于引导类加载器是由c实现的，所以并不存在一个Java的类，因此会打印出null
　　我们还可以看到结果里面打印了sun。misc。Launcher，这个是什么东东？
　　其实Launcher是JRE中用于启动程序入口main（）的类，我们看下Launcher的源码：publicclassLauncher｛privatestaticLauncherlaunchernewLauncher（）；privatestaticStringbootClassPathSystem。getProperty（sun。boot。class。path）；publicstaticLaunchergetLauncher（）｛｝privateClassLpublicLauncher（）｛CreatetheextensionclassloaderClassLtry｛extclExtClassLoader。getExtClassLoader（）；加载扩展类类加载器｝catch（IOExceptione）｛thrownewInternalError（Couldnotcreateextensionclassloader，e）；｝Nowcreatetheclassloadertousetolaunchtheapplicationtry｛loaderAppClassLoader。getAppClassLoader（extcl）；加载应用程序类加载器，并设置parent为extClassLoader｝catch（IOExceptione）｛thrownewInternalError（Couldnotcreateapplicationclassloader，e）；｝Thread。currentThread（）。setContextClassLoader（loader）；设置AppClassLoader为线程上下文类加载器｝Returnstheclassloaderusedtolaunchthemainapplication。publicClassLoadergetClassLoader（）｛｝Theclassloaderusedforloadinginstalledextensions。staticclassExtClassLoaderextendsURLClassLoader｛｝Theclassloaderusedforloadingfromjava。class。path。runsinarestrictedsecuritycontext。staticclassAppClassLoaderextendsURLClassLoader｛｝
　　其中loaderAppClassLoader。getAppClassLoader（extcl）；的核心方法源码如下：privateClassLoader（Voidunused，ClassLoaderparent）｛this。设置parentif（ParallelLoaders。isRegistered（this。getClass（）））｛parallelLockMapnewConcurrentHashMap（）；package2certsnewConcurrentHashMap（）；assertionLocknewObject（）；｝else｛lockontheclassloaderinstanceparallelLockMpackage2certsnewHashtable（）；assertionL｝｝
　　通过以上源码我们可以知晓：Launcher的ClassLoader是BootstrapClassLoader，在Launcher创建的同时，还会同时创建ExtClassLoader，AppClassLoader（并设置其parent为extClassLoader）。其中代码中sun。boot。class。path是BootstrapClassLoader加载的jar包路径。这几种类加载器都遵循双亲委派机制
　　双亲委派机制说的其实就是，当一个类加载器收到一个类加载请求时，会去判断有没有加载过，如果加载过直接返回，否则该类加载器会把请求先委派给父类加载器。每个类加载器都是如此，只有在父类加载器在自己的搜索范围内找不到指定类时，子类加载器才会尝试自己去加载。
　　双亲委派模式优势：避免类的重复加载，当父亲已经加载了该类时，就没有必要子ClassLoader再加载一次，这样保证了每个类只被加载一次。保护程序安全，防止核心API被随意篡改，比如java核心api中定义类型不会被随意替换
　　我们这里看一个例子：
　　我们新建一个自己的类String放在srcjavalang目录下publicclassString｛static｛System。out。println（自定义String类）；｝｝
　　新建StringTest类：publicclassStringTest｛publicstaticvoidmain（String〔〕args）｛Stringstrnewjava。lang。String（）；System。out。println（starttest）；｝｝
　　结果：
　　starttest
　　可以看出，程序并没有运行我们自定义的String类，而是直接返回了String。class。像String，Integer等类是JAVA中的核心类，是不允许随意篡改的！ClassLoader
　　ClassLoader是一个抽象类，负责加载类，像ExtClassLoader，AppClassLoader都是由该类派生出来，实现不同的类装载机制。这块的源码太多了，就不贴了
　　我们来看下它的核心方法loadClass（），传入需要加载的类名，它会帮你加载：protectedC？loadClass（Stringname，booleanresolve）throwsClassNotFoundException｛synchronized（getClassLoadingLock（name））｛一开始先检查是否已经加载该类C？cfindLoadedClass（name）；if（cnull）｛longt0System。nanoTime（）；try｛如果未加载过类，则遵循双亲委派机制，来加载类if（parent！null）｛cparent。loadClass（name，false）；｝else｛如果父类是null就是BootstrapClassLoader，使用启动类类加载器cfindBootstrapClassOrNull（name）；｝｝catch（ClassNotFoundExceptione）｛ClassNotFoundExceptionthrownifclassnotfoundfromthenonnullparentclassloader｝if（cnull）｛longt1System。nanoTime（）；如果还是没有加载成功，调用findClass（），让当前类加载器加载cfindClass（name）；recordthestatssun。misc。PerfCounter。getParentDelegationTime（）。addTime（t1t0）；sun。misc。PerfCounter。getFindClassTime（）。addElapsedTimeFrom（t1）；sun。misc。PerfCounter。getFindClasses（）。increment（）；｝｝if（resolve）｛resolveClass（c）；｝｝｝继承的子类得重写该方法protectedC？findClass（Stringname）throwsClassNotFoundException｛thrownewClassNotFoundException（name）；｝
　　loadClass（）源码展示了，一般加载。class文件大致流程：先去缓存中检查是否已经加载该类，有就直接返回，避免重复加载；没有就下一步遵循双亲委派机制，来加载。class文件上面两步都失败了，调用findClass（）方法，让当前类加载器加载
　　注意：由于ClassLoader类是抽象类，而抽象类是无法通过new创建对象的，所以它最核心的findClass（）方法，没有具体实现，只抛了一个异常，而且是protected的，这是应用了模板方法模式，具体的findClass（）方法丢给子类实现，所以继承的子类得重写该方法。自定义类加载器编写一个自定义的类加载器
　　那我们仿照ExtClassLoader，AppClassLoader来实现一个自定义的类加载器，我们同样是继承ClassLoader类
　　编写一个测试类TestPersonpublicclassTestPerson｛Spublicvoidprint（）｛System。out。println（hellomynameis：name）；｝｝
　　接着编写一个自定义类加载器MyTestClassLoader：publicclassMyTestClassLoaderextendsClassLoader｛finalStringclassNameSpecifyTestPpublicMyTestClassLoader（）｛｝publicMyTestClassLoader（ClassLoaderparent）｛super（parent）；｝protectedC？findClass（Stringname）throwsClassNotFoundException｛FilefilegetClassFile（name）；try｛byte〔〕bytesgetClassBytes（file）；C？cthis。defineClass（name，bytes，0，bytes。length）；｝catch（Exceptione）｛e。printStackTrace（）；｝returnsuper。findClass（name）；｝privateFilegetClassFile（Stringname）｛FilefilenewFile（D：ideaProjectssrcmainjavacomzjideaprojectstest2classNameSpecify。class）；｝privatebyte〔〕getClassBytes（Filefile）throwsException｛这里要读入。class的字节，因此要使用字节流FileInputStreamfisnewFileInputStream（file）；FileChannelfcfis。getChannel（）；ByteArrayOutputStreambaosnewByteArrayOutputStream（）；WritableByteChannelwbcChannels。newChannel（baos）；ByteBufferbyByteBuffer。allocate（1024）；while（true）｛intifc。read（by）；if（i0i1）by。flip（）；wbc。write（by）；by。clear（）；｝fis。close（）；returnbaos。toByteArray（）；｝我们这边要打破双亲委派模型，重写整个loadClass方法OverridepublicC？loadClass（Stringname）throwsClassNotFoundException｛C？cfindLoadedClass（name）；if（cnullname。contains（classNameSpecify））｛指定的类，不走双亲委派机制，自定义加载cfindClass（name）；if（c！null）｛｝｝returnsuper。loadClass（name）；｝｝
　　最后在编写一个测试controller：RestControllerpublicclassTestClassController｛RequestMapping（valuetestClass，method｛RequestMethod。GET，RequestMethod。POST｝）publicvoidtestClassLoader（）throwsClassNotFoundException，InstantiationException，IllegalAccessException，NoSuchMethodException，InvocationTargetException｛MyTestClassLoadermyTestClassLoadernewMyTestClassLoader（）；C？c1Class。forName（com。zj。ideaprojects。test2。TestPerson，true，myTestClassLoader）；Objectobjc1。newInstance（）；System。out。println（当前类加载器：obj。getClass（）。getClassLoader（））；obj。getClass（）。getMethod（print）。invoke（obj）；｝｝
　　先找到TestPerson所在的目录，执行命令：javacTestPerson，生成TestPerson。class这里没有使用idea的build，是因为我们代码的class读取路径是写死了的，不走默认CLASSPATH
　　D：ideaProjectssrcmainjavacomzjideaprojectsest2TestPerson。class
　　我们然后用postman调用testClassLoader（）测试接口
　　结果：当前类加载器：com。zj。ideaprojects。test2。MyTestClassLoader1d75e392
　　hellomynameis：xiaoming
　　然后修改TestPerson，将name改为xiaoniupublicclassTestPerson｛Spublicvoidprint（）｛System。out。println（hellomynameis：name）；｝｝
　　然后在当前目录重新编译，执行命令：javacTestPerson，会在当前目录重新生成TestPerson。class不重启项目，直接用postman直接调这个测试接口结果：当前类加载器：com。zj。ideaprojects。test2。MyTestClassLoader7091bd27
　　hellomynameis：xiaoniu
　　这样就实现了热部署！！！
　　为什么我们这边要打破双亲委派机制？
　　如果不打破的话，结果当前类加载器会显示sun。misc。LauncherAppClassLoader，原因是由于idea启动项目的时候会自动帮我们编译，将class放到CLASSPATH路径下。其实可以把默认路径下的。class删除也行。这里也是为了展示如何打破双亲委派机制，才如此实现的。
　　官方推荐我们自定义类加载器时，遵循双亲委派机制。但是凡事得看实际需求嘛
　　自定义类加载器时，如何打破双亲委派机制
　　通过上面的例子我们可以看出：1、如果不想打破双亲委派机制，我们自定义类加载器，那么只需要重写findClass方法即可
　　2、如果想打破双亲委派机制，我们自定义类加载器，那么还得重写整个loadClass方法SPI机制与线程上下文类加载器
　　如果你阅读到这里，你会发现双亲委派机制的各种好处，但万物都不是绝对正确的，我们需要一分为二地看待问题。
　　在某些场景下双亲委派制过于局限，所以有时候必须打破双亲委派机制来达到目的。比如：SPI机制、线程上下文类加载器SPI（ServiceProviderInterface）服务提供接口。它是jdk内置的一种服务发现机制，将装配的控制权移到程序之外，在模块化设计中这个机制尤其重要，其核心思想就是让服务定义与实现分离、解耦。
　　线程上下文类加载器（contextclassloader）是可以破坏Java类加载委托机制，使程序可以逆向使用类加载器，使得java类加载体系显得更灵活。
　　Java应用运行的初始线程的上下文类加载器是应用类加载器，在线程中运行的代码可以通过此类加载器来加载类和资源。Java。lang。Thread中的方法getContextClassLoader（）和setContextClassLoader（ClassLoadercl）用来获取和设置线程的上下文类加载器。如果没有通过setContextClassLoader（ClassLoadercl）方法进行设置的话，线程将继承其父线程的上下文类加载器。
　　SPI机制在框架的设计上应用广泛，下面举几个常用的例子：JDBC
　　平时获取jdbc，我们可以这样：ConnectionconnectionDriverManager。getConnection（jdbc：localhost：3306）；
　　我们读DriverManager的源码发现：其实就是查询classPath下，所有METAINF下给定Class名的文件，并将其内容返回，使用迭代器遍历，这里遍历的内部使用Class。forName加载了类。
　　其中有一处非常重要ServiceLoaderloadedDriversServiceLoader。load（Driver。class）；我们看下它的实现：publicstaticSServiceLoaderSload（ClassSservice）｛ClassLoaderclThread。currentThread（）。getContextClassLoader（）；important！returnServiceLoader。load（service，cl）；｝
　　我们可以看出JDBC，DriverManager类和ServiceLoader类都是属于核心库rt。jar的，它们的类加载器是BootstrapClassLoader类加载器。而具体的数据库驱动相关功能却是第三方提供的，第三方的类不能被引导类加载器（BootstrapClassLoader）加载。
　　所以java。util。ServiceLoader类进行动态装载时，使用了线程的上下文类加载器（ThreadContextClassLoader）让父级类加载器能通过调用子级类加载器来加载类，这打破了双亲委派机制。Tomcat
　　Tomcat是web容器，我们把war包放到tomcat的webapp目录下，这意味着一个tomcat可以部署多个应用程序。
　　不同的应用程序可能会依赖同一个第三方类库的不同版本，但是不同版本的类库中某一个类的全路径名可能是一样的。防止出现一个应用中加载的类库会影响另一个应用的情况。如果采用默认的双亲委派类加载机制，那么是无法加载多个相同的类。
　　如果Tomcat本身的依赖和Web应用还需要共享，Common类加载器（CommonClassLoader）来装载实现共享Catalina类加载器（CatalinaClassLoader）用来隔绝Web应用程序与Tomcat本身的类Shared类加载器（SharedClassLoader）：如果WebAppClassLoader自身没有加载到某个类，那就委托SharedClassLoader去加载WebAppClassLoader：为了实现隔离性，优先加载Web应用自己定义的类，所以没有遵照双亲委派的约定，每一个应用自己的类加载器WebAppClassLoader（多个应用程序，就有多个WebAppClassLoader），负责优先加载本身的目录下的class文件，加载不到时再交给CommonClassLoader以及上层的ClassLoader进行加载，这破坏了双亲委派机制。Jsp类加载器（JasperLoader）：实现热部署的功能，修改文件不用重启就自动重新装载类库。JasperLoader的加载范围仅仅是这个JSP文件所编译出来的那一个。Class文件，它出现的目的就是为了被丢弃：当Web容器检测到JSP文件被修改时，会替换掉目前的JasperLoader的实例，并通过再建立一个新的Jsp类加载器来实现JSP文件的HotSwap功能。
　　我们来模拟一下tomcat多个版本代码共存：
　　这边的例子换了个电脑，所以目录结构、路径与上面的例子有点变化
　　我们先编写App类publicclassApp｛Stringnamewebapp1；publicvoidprint（）｛System。out。println（thisisname）；｝｝
　　javacApp生成的App。class放入tomcatTestwar1comzjdemotestomcatTest目录下
　　将name改为webapp2，重新生成的App。class放入tomcatTestwar2comzjdemotestomcatTest目录下
　　然后我们编写类加载器：publicclassMyTomcatClassloaderextendsClassLoader｛privateStringclassPpublicMyTomcatClassloader（StringclassPath）｛this。classPathclassP｝OverrideprotectedC？findClass（Stringname）throwsClassNotFoundException｛FilefilegetClassFile（name）；try｛byte〔〕bytesgetClassBytes（file）；C？cthis。defineClass（name，bytes，0，bytes。length）；｝catch（Exceptione）｛e。printStackTrace（）；｝returnsuper。findClass（name）；｝privateFilegetClassFile（Stringname）｛namename。replaceAll（。，）；FilefilenewFile（classPathname。class）；拼接路径，找到class文件｝privatebyte〔〕getClassBytes（Filefile）throwsException｛这里要读入。class的字节，因此要使用字节流FileInputStreamfisnewFileInputStream（file）；FileChannelfcfis。getChannel（）；ByteArrayOutputStreambaosnewByteArrayOutputStream（）；WritableByteChannelwbcChannels。newChannel（baos）；ByteBufferbyByteBuffer。allocate（1024）；while（true）｛intifc。read（by）；if（i0i1）｛｝by。flip（）；wbc。write（by）；by。clear（）；｝fis。close（）；returnbaos。toByteArray（）；｝我们这边要打破双亲委派模型，重写整个loadClass方法OverridepublicC？loadClass（Stringname）throwsClassNotFoundException｛C？cfindLoadedClass（name）；if（cnullname。contains（tomcatTest））｛指定的目录下的类，不走双亲委派机制，自定义加载cfindClass（name）；if（c！null）｛｝｝returnsuper。loadClass（name）；｝｝
　　最后编写测试controller：RestControllerpublicclassTestController｛RequestMapping（valuetestTomcat，method｛RequestMethod。GET，RequestMethod。POST｝）publicvoidtestclass（）throwsClassNotFoundException，IllegalAccessException，InstantiationException，NoSuchMethodException，InvocationTargetException｛MyTomcatClassloadermyTomcatClassloadernewMyTomcatClassloader（D：GiteeProjectsstudyjavademotestsrcmainjavacomzjdemotesttomcatTestwar1）；ClassclmyTomcatClassloader。loadClass（com。zj。demotest。tomcatTest。App）；Objectobjcl。newInstance（）；System。out。println（当前类加载器：obj。getClass（）。getClassLoader（））；obj。getClass（）。getMethod（print）。invoke（obj）；MyTomcatClassloadermyTomcatClassloader22newMyTomcatClassloader（D：GiteeProjectsstudyjavademotestsrcmainjavacomzjdemotesttomcatTestwar2）；Classcl22myTomcatClassloader22。loadClass（com。zj。demotest。tomcatTest。App）；Objectobj22cl22。newInstance（）；System。out。println（当前类加载器：obj22。getClass（）。getClassLoader（））；obj22。getClass（）。getMethod（print）。invoke（obj22）；｝｝
　　然后postman调一下这个接口，结果：当前类加载器：com。zj。demotest。tomcatTest。MyTomcatClassloader18fbb876
　　thisiswebapp1
　　当前类加载器：com。zj。demotest。tomcatTest。MyTomcatClassloader5f7ed4a9
　　thisiswebapp2
　　我们发现2个同样的类能共存在同一个JVM中，互不影响。
　　注意：同一个JVM内，2个相同的包名和类名的对象是可以共存的，前提是他们的类加载器不一样。所以我们要判断多个类对象是否是同一个，除了要看包名和类名相同，还得注意他们的类加载器是否一致SpringBootStarter
　　springboot自动配置的原因是因为使用了EnableAutoConfiguration注解。
　　当程序包含了EnableAutoConfiguration注解，那么就会执行下面的方法，然后会加载所有spring。factories文件，将其内容封装成一个map，spring。factories其实就是一个名字特殊的properties文件。
　　在springboot应用启动时，会调用loadFactoryNames方法，其中传递的一个参数就是：org。springframework。boot。autoconfigure。EnableAutoConfigurationprotectedListStringgetCandidateConfigurations（AnnotationMetadatametadata，AnnotationAttributesattributes）｛ListStringconfigurationsSpringFactoriesLoader。loadFactoryNames（this。getSpringFactoriesLoaderFactoryClass（），this。getBeanClassLoader（））；Assert。notEmpty（configurations，NoautoconfigurationclassesfoundinMETAINFspring。factories。Ifyouareusingacustompackaging，makesurethatfileiscorrect。）；｝
　　METAINFspring。factories会被读取到。
　　它还使用了this。getBeanClassLoader（）获取类加载器。所以我们立刻明白了文章一开始的例子，SpringBoot项目直接build项目，不重启项目，就能实现热部署效果。尾语
　　类加载器是Java语言的一个创新，它使得动态安装和更新软件组件成为可能。同时我们应该了解双亲委派机制的优缺点和应用场景，这些可能比较难但对于我们来说却很重要。