jsp加载后的文件jar包天天见可是你知道它的运行机制吗

spi 是 Java 供应的一套用来被第三方实现或者扩展的 API ，它可以用来启用框架扩展和更换组件。
spi 机制是这样的：读取 META-INF/services/ 目录下的元信息，然后 ServiceLoader 根据信息加载对应的类，你可以在自己的代码中利用这个被加载的类。
要利用 Java SPI，须要遵照如下约定：

当做事供应者供应了接口的一种详细实现后，在 jar 包的 META-INF/services 目录下创建一个以 “接口全限定名” 命名的文件，内容为实现类的全限定名；接口实现类所在的 jar 包放在主程序的 classpath 中；主程序通过 java.util.ServiceLoder 动态装载实现模块，它通过扫描 META-INF/services 目录下的配置文件找到实现类的全限定名，把类加载到 JVM ；SPI 的实现类必须携带一个不带参数的布局方法；

现在我们来大略的利用一下吧。

spi 利用示例

建一个 maven 项目，定义一个接口 ( com.test.SpiTest )，并实现该接口（ com.test.SpiTestImpl）；然后在 src/main/resources/ 下建立 /META-INF/services 目录， 新增一个以接口命名的文件 ( com.test.SpiTest)，内容是要运用的实现类（ com.test.SpiTestImpl）。

public interface SpiTest { void test();}public class SpiTestImpl implements SpiTest { @Override public void test() { System.out.println(\"大众test\公众); }}

然后在我们的运用程序中利用 ServiceLoader来加载配置文件中指定的实现。

public static void main(String[] args) { ServiceLoader<SpiTest> load = ServiceLoader.load(SpiTest.class); SpiTest next = load.iterator().next(); next.test();}

这便是 spi 的利用办法了，简约而不大略。

spi 技能的运用

那这一项技能有哪些方面的运用呢？最直接的 jdbc 中我们须要指天命据库驱动的全限定名，这便是 spi 技能。
还有不少框架比如 dubbo ，都会预留 spi 扩展点比如：dubbo spi

为什么要这么做呢？在 Spring 框架中我们注入一个 bean 很随意马虎，通过表明或者 xml 配置即可，然后在其他的地方就能利用这个 bean 。
在非 Spring 框架下，我们想要有同样的效果就可以考虑 spi 技能了。

写过 SpringBoot 的 starter 的都知道，须要在 src/main/resources/ 下建立 /META-INF/spring.factories 文件。
这实在也是一种spi技能的变形。

jar 机制

常日项目中我们打 jar 包都是通过 maven 来进行的，导致很多人忽略了这个东西的存在，就像很多人不知道 jdb.exe 是啥玩意一样。
下面我们不借助任何工具来打一个 jar 包并对 jar 文件构造进行解析。

命令行打 jar 包

首先我们建立一个普通的 java 项目，新建几个 class 类，然后在根目录下新建 META-INF/MAINFEST.MF这个文件包含了 jar 的元信息，当我们实行 java -jar 的时候首先会读取该文件的信息做干系的处理。
我们来看看这个文件中可以配置哪些信息 ：

Manifest-Version：用来定义 manifest 文件的版本，例如：Manifest-Version: 1.0Main-Class：定义 jar 文件的入口类，该类必须是一个可实行的类，一旦定义了该属性即可通过 java -jar x.jar 来运行该 jar 文件。
Class-Path：指定该 jar 包所依赖的外部 jar 包，以当前 jar 包所在的位置为相对路径，无法指定 jar 包内部的 jar 包署名干系属性，包括 Name， Digest-Algorithms， SHA-Digest 等

定义好元信息之后我们就可以打 jar 包了，以下是打包的一些常用命令

默认打包

天生的test.jar中就含test目录和jar自动天生的META-INF目录（内含MAINFEST.MF清单文件）

jar -cvf test.jar test查看包内容

jar -tvf test.jar解压jar包

jar -xvf test.jar提取jar包部分内容

jar -xvf test.jar test\test.class追加内容到jar包

追加 MAINFEST.MF 清单文件以外的文件，会追加全体目录构造

jar -uvf test.jar other\ss.class追加清单文件

会追加全体目录构造( test.jar 会包含 META-INF 目录)

jar -uMvf test.jar META-INF\MAINFEST.MF创建自定义MAINFEST.MF的jar包

jar -cMvf test.jar test META-INF

通过 -m 选项配置自定义 MAINFEST.MF 文件时，自定义MAINFEST.MF 文件必须在位于事情目录下才可以

jar -cmvf MAINFEST.MF test.jar test

jar 运行的过程

jar 运行过程和类加载机制有关，而类加载机制又和我们自定义的类加载器有关，现在我们先来理解一下双亲委派模式。

java 中类加载器分为三个：

BootstrapClassLoader 卖力加载 ${JAVA_HOME}/jre/lib 部分 jar 包ExtClassLoader 加载 ${JAVA_HOME}/jre/lib/ext 下面的 jar 包AppClassLoader 加载用户自定义 -classpath 或者 Jar 包的 Class-Path 定义的第三方包

类的生命周期为：加载（Loading）、验证（Verification）、准备(Preparation)、解析(Resolution)、初始化(Initialization)、利用(Using) 和 卸载(Unloading)七个阶段。

当我们实行 java -jar 的时候 jar 文件以二进制流的形式被读取到内存，但不会加载到 jvm 中，类会在一个得当的机遇加载到虚拟机中。
类加载的机遇：

碰着 new、getstatic、putstatic 或 invokestatic 这四条字节码指令时，如果类没有进行过初始化，则须要先对其进行初始化。
这四条指令的最常见的 Java 代码场景是利用 new 关键字实例化工具的时候，读取或设置一个类的静态字段调用一个类的静态方法的时候。
利用 java.lang.reflect 包的方法对类进行反射调用的时候，如果类没有进行过初始化，则须要先触发其初始化。
当初始化一个类的时候，如果创造其父类还没有进行过初始化，则须要先触发其父类的初始化。
当虚拟机启动时，用户须要指定一个要实行的主类（包含 main() 方法的那个类），虚拟机会先初始化这个主类。

当触发类加载的时候，类加载器也不是直接加载这个类。
首先交给 AppClassLoader ，它会查看自己有没有加载过这个类，如果有直接拿出来，无须再次加载，如果没有就将加载任务通报给 ExtClassLoader ，而 ExtClassLoader 也会先检讨自己有没有加载过，没有又会将任务通报给 BootstrapClassLoader ，末了 BootstrapClassLoader 会检讨自己有没有加载过这个类，如果没有就会去自己要探求的区域去探求这个类，如果找不到又将任务通报给 ExtClassLoader ，以此类推末了才是 AppClassLoader 加载我们的类。
这样做是确保类只会被加载一次。
常日我们的类加载器只识别 classpath （这里的 classpath 指项目根路径，也便是 jar 包内的位置）下 .class 文件。
jar 中其他的文件包括 jar 包被当做了资源文件，而不会去读取里面的 .class 文件。
但实际上我们可以通过自定义类加载器来实现一些特殊的操作

Tomcat 的类加载器

Tomcat 的类加载机制是违反了双亲委托原则的，对付一些未加载的非根本类(Object,String等)，各个 web 运用自己的类加载器(WebAppClassLoader) 会优先加载，加载不到时再交给 commonClassLoader 走双亲委托。

tomcat 的类加载器：

Common 类加载器：卖力加载 /common 目录的类库，这儿存放的类库可被 tomcat 以及所有的运用利用。
Catalina 类加载器：卖力加载 /server 目录的类库，只能被 tomcat 利用。
Shared 类加载器：负载加载 /shared 目录的类库，可被所有的 web 运用利用，但 tomcat 不可利用。
WebApp 类加载器：负载加载单个 Web 运用下 classes 目录以及 lib 目录的类库，只能当前运用利用。
Jsp 类加载器：卖力加载 Jsp ，每一个 Jsp 文件都对应一个 Jsp 加载器。

我们将一堆 jar 包放到 tomcat 的项目文件夹下， tomcat 运行的时候能加载到这些 jar 包的 class 便是由于这些类加载器对读取到的二进制数据进行处理解析从中拿到了须要的类

SpringBoot 的 jar 包

当我们将一个 SpringBoot 项目打好包之后，不妨解压看看里面的构造是什么样子的的

run.jar|——org| |——springframework| |——boot| |——loader| |——JarLauncher.class| |——Launcher.class|——META-INF| |——MANIFEST.MF|——BOOT-INF| |——class| |——Main.class| |——Begin.class| |——lib| |——commons.jar| |——plugin.jar| |——resource| |——a.jpg| |——b.jpg

classpath 可加载的类只有 JarLauncher.class， Launcher.class， Main.class， Begin.class。
在 BOOT-INF/lib 和 BOOT-INF/class 里面的文件不属于 classloader 搜素工具直接访问的话会报 NoClassDefDoundErr 非常。
Jar 包里面的资源以 Stream 的形式存在（他们本就处于 Jar 包之中），java 程序时可以访问到的。
当 springboot 运行 main 方法时在 main 中会运行 org.springframework.boot.loader.JarLauncher 和 Launcher.class 这两个个加载器（你是否还及得前文提到过得 spi 技能），这个加载器去加载受 stream 中的 jar 包中的 class。
这样就实现了加载 jar 包中的 jar 这个功能否则正常的类加载器是无法加载 jar 包中的 jar 的 class 的，只会根据 MAINFEST.MF 来加载 jar 外部的 jar 来读取里面的 class。

如何自定义类加载器

继续 ClassLoader 重写 findClass() 方法

public class MyClassLoader extends ClassLoader{ private String classpath; public MyClassLoader(String classpath) { this.classpath = classpath; } @Override protected Class<?> findClass(String name) throws ClassNotFoundException { // 该方法是根据一个name加载一个类，我们可以利用一个流来读取path中的文件然后从文件中解析出class来 }}

调用 defineClass() 方法加载类

public static void main(String []args) throws ClassNotFoundException, InstantiationException, IllegalAccessException, NoSuchMethodException, SecurityException, IllegalArgumentException, InvocationTargetException{ //自定义类加载器的加载路径 MyClassLoader myClassLoader=new MyClassLoader(\"大众D:\\lib\"大众); //包名+类名 Class c=myClassLoader.loadClass(\"大众com.test.Test\"大众) if(c!=null){ // 做点啥 }}

总结

本文从比较根本的层面解读了我们频繁利用却大部分人不是很理解的两个知识点—— spi 和 jar 机制。
希望大家看完这篇文章后能对 SpringBoot 中的一些“黑邪术”有更深入的理解，而不是勾留在表面。