Java SPI机制源码

文章目录

- SPI简介
- 使用案例
- SPI的应用
- SPI机制源码
- SPI与类加载器
- 双亲委派机制

SPI简介

Java的SPI（Service Provider Interface）机制允许第三方为应用程序提供插件式的扩展，而不需要修改应用程序本身的代码，从而实现了解耦。Java标准库本身就提供了SPI机制，通常是通过在META-INF/services目录下放置文件来实现的。

在这里插入图片描述
SPI机制的核心组件包括：

服务接口：这是一个Java接口，定义了服务提供者需要实现的方法，应用程序将使用这个接口与具体的服务实现进行交互。
服务实现：这是实现了服务接口的具体类，第三方可以为服务接口提供多个实现。
服务提供者配置文件：这是一个位于META-INF/services目录下的文件，文件名与服务接口的全限定名相同，该文件包含了服务实现类的全限定名，每行一个接口的具体实现类，在运行时就可以加载这些实现类。
ServiceLoader：这是Java标准库中的一个类，用于加载服务实现，应用程序可以使用ServiceLoader来获取服务接口的所有具体实现类。

SPI的工作流程如下：

定义服务接口。
实现服务接口，创建具体的服务实现类。
在META-INF/services目录下创建服务提供者配置文件，列出所有服务实现类的全限定名。
使用ServiceLoader加载服务具体实现类，并根据需要使用它们。

总结就是说SPI机制使得应用程序可以在运行时动态地选择和加载服务实现，从而提高了应用程序的可扩展性和灵活性。

使用案例

首先定义一个服务的接口

public interface Service {
    void execute();
}

接着创建两个两个服务实现类去实现接口，并重写接口中的方法

public class Implementation1 implements Service {
    @Override
    public void execute() {
        System.out.println("服务实现类1");
    }
}

// Implementation2.java
public class Implementation2 implements Service {
    @Override
    public void execute() {
        System.out.println("服务实现类2");
    }
}

然后在META-INF/services目录下创建一个名为com.xydp.SPI.Service(全限定名要与接口的名称对应)的文件，用于存储服务实现类的全限定名。文件内容如下：
在这里插入图片描述

com.xydp.SPI.Implementation1
com.xydp.SPI.Implementation2

编写对应的测试类进行验证

public class SPITest {
    public static void main(String[] args) {
     ServiceLoader<Service> loader = ServiceLoader.load(Service.class);
        Iterator<Service> iterator = loader.iterator();
        while(iterator.hasNext()){
            System.out.println(iterator.next().getClass());
        }
    }
}

输出结果

class com.xydp.SPI.Implementation1
class com.xydp.SPI.Implementation2

SPI的应用

SPI 机制被用于加载和注册 JDBC 驱动程序，JDBC的使用方法如下
首先，导入依赖

 <dependency>
     <groupId>mysql</groupId>
     <artifactId>mysql-connector-java</artifactId>
     <version>8.0.18</version>
</dependency>

public class JDBCTest {
    @SneakyThrows
    public static void main(String[] args) {
        String url = "jdbc:mysql://localhost:3306/hmdp?useUnicode=true&characterEncoding=utf-8&serverTimezone=GMT%2B8";
        String username = "root";
        String password = "1445413748";

            // 1. 加载JDBC驱动(Driver的静态代码块里面会注册JDBC驱动)
            //	实际上这行代码是可以省略的
            Class.forName("com.mysql.cj.jdbc.Driver");

            // 2. 建立数据库连接
            Connection connection = DriverManager.getConnection(url, username, password);

            // 3. 创建Statement对象
            Statement statement = connection.createStatement();

            // 4. 执行SQL查询
            String sql = "SELECT * FROM test";
            ResultSet resultSet = statement.executeQuery(sql);

            // 5. 处理查询结果
            while (resultSet.next()) {
                int id = resultSet.getInt("id");
                String name = resultSet.getString("value");
                System.out.println("ID: " + id + ", value: " + name);
            }
            //6. 关闭资源
                    connection.close();
        }

}

运行结果
在这里插入图片描述

可以知道JDBC在加载驱动后，节省了注册驱动这一步骤，这是因为在Driver类的静态代码块中已经注册了。

static {
    try {
    //注册驱动
        DriverManager.registerDriver(new Driver());
    } catch (SQLException var1) {
        throw new RuntimeException("Can't register driver!");
    }
}

除此之外，上面代码Class.forName(“com.mysql.cj.jdbc.Driver”)与SPI机制存在关联，会显示去加载Driver类，实际上这行代码是可以省略的，不写的话，下面的DriverManager的静态代码块就会通过ServiceLoader去加载配置文件下的Driver类。
DriverManager类的静态代码块

static {
        loadInitialDrivers();
        println("JDBC DriverManager initialized");
}

静态代码块就会执行loadInitialDrivers()方法，

private static void loadInitialDrivers() {
        String drivers;
        try {
            drivers = AccessController.doPrivileged(new PrivilegedAction<String>() {
                public String run() {
                    return System.getProperty("jdbc.drivers");
                }
            });
        } catch (Exception ex) {
            drivers = null;
        }
      
        AccessController.doPrivileged(new PrivilegedAction<Void>() {
            public Void run() {
							//通过SPI机制加载Driver类
                ServiceLoader<Driver> loadedDrivers = ServiceLoader.load(Driver.class);
                Iterator<Driver> driversIterator = loadedDrivers.iterator();
							//获取对应的实现类
                try{
                    while(driversIterator.hasNext()) {
                        driversIterator.next();
                    }
                } catch(Throwable t) {
                }
                return null;
            }
        });
    }

在不显示加载Driver类的情况下，ServiceLoader 会扫描类路径中的 META-INF/services 目录，查找 java.sql.Driver的配置文件，该配置文件中存在com.mysql.cj.jdbc.Driver这一行字符串，找到之后ServiceLoader通过反射的方式去加载Driver类。
在这里插入图片描述
对此我们可以进行验证JDBC的SPI机制，测试类如下

    public static void main(String[] args) {
        ServiceLoader<Driver> serviceLoader = ServiceLoader.load(Driver.class);
        Iterator<Driver> iterator = serviceLoader.iterator();
        while(iterator.hasNext()){ ;
            Driver driver = (Driver) iterator.next();
            System.out.println("驱动类的包:"+driver.getClass().getPackage()+"=======加载驱动类"+driver.getClass().getName());
        }
    }

运行结果
在这里插入图片描述由此可以得出结论JDBC确实是通过SPI机制去加载com.mysql.cj.jdbc.Driver类。

SPI机制源码

SPI主要是通过 ServiceLoader 类去解析配置文件，然后通过反射的方式创建对应的接口实现类。
ServiceLoader的主要成员

public final class ServiceLoader<S> implements Iterable<S>  
{  
	// 加载的默认配置文件目录
    private static final String PREFIX = "META-INF/services/";  
  
    // 需要被加载的 SPI 服务实现类
    private final Class<S> service;  
  
    // 该类加载器用于加载服务
    private final ClassLoader loader;  
  
    // 访问控制上下文，用于安全控制
    private final AccessControlContext acc;  
  
    // 按照实例化的顺序缓存服务实例
    private LinkedHashMap<String,S> providers = new LinkedHashMap<>();  
  
    // 懒查询迭代器
    private LazyIterator lookupIterator;

}

调用ServiceLoader.load 方法时，会根据接口和类加载器创建懒加载迭代器。

ServiceLoader<Service> loader = ServiceLoader.load(Service.class);
//源码如下
public static <S> ServiceLoader<S> load(Class<S> service, ClassLoader loader)  
{  
    return new ServiceLoader<>(service, loader);  
}


// 构造方法重新加载SPI服务
private ServiceLoader(Class<S> svc, ClassLoader cl) {  
    service = Objects.requireNonNull(svc, "Service interface cannot be null");
    // 获取系统类加载器
    loader = (cl == null) ? ClassLoader.getSystemClassLoader() : cl;  
    //安全访问控制
    acc = (System.getSecurityManager() != null) ? AccessController.getContext() : null;
    // 重新加载SPI的服务
    reload();  
}

public void reload() {
	// 清空服务提供者的缓存列表
    providers.clear();
	// 根据接口类型和类加载器创建懒加载迭代器，达到懒加载的目的，防止资源被浪费
    lookupIterator = new LazyIterator(service, loader);
}

private LazyIterator(Class<S> service, ClassLoader loader) {
    this.service = service;
    this.loader = loader;
}

获取ServiceLoader 的 iterator

ServiceLoader 类的主要成员包含有LinkedHashMap实现的 providers，providers 用于用于缓存被成功加载的服务实例，key 是接口实现类的全限定名，value 是对应实现类的实例对象。

Iterator<Service> iterator = loader.iterator();
//源码如下
public Iterator<S> iterator() {
		//返回自定义的迭代器
        return new Iterator<S>() {
            
            // 创建缓存
            Iterator<Map.Entry<String,S>> knownProviders = providers.entrySet().iterator();

            
            public boolean hasNext() {
   
                if (knownProviders.hasNext())
                    return true;
                  
                return lookupIterator.hasNext();
            }

            public S next() {
                if (knownProviders.hasNext())
                    return knownProviders.next().getValue();
                return lookupIterator.next();
            }

            public void remove() {
                throw new UnsupportedOperationException();
            }

        };
    }

3. 迭代器判断是否有数据

iterator.hasNext()
//源码如下
//判断是否还有数据
public boolean hasNext() {
    // 一开始缓存为空
    //（在调用next方法之后才会将服务对象实例放入该缓存，之后调用hasNext就会直接返回true）
    if (knownProviders.hasNext())
        return true;
    //一开始代码会执行到这
    return lookupIterator.hasNext();
}

public boolean hasNext() {
  	//acc访问控制默认为null，代码逻辑执行到这
    if (acc == null) {
        return hasNextService();
    } else {
        PrivilegedAction<Boolean> action = new PrivilegedAction<Boolean>() {
            public Boolean run() { return hasNextService(); }
        };
        return AccessController.doPrivileged(action, acc);
    }
}

//判断是否还有服务
private boolean hasNextService() {
    // 判断是否还有服务实现类，有则返回true
    if (nextName != null) {
        return true;
    }
    // 配置刚开始为空
    if (configs == null) {
        try {
            //配置文件目录拼接接口名称 META-INF/services + 接口名称
            // META-INF/services/com.xydp.SPI.Service
            String fullName = PREFIX + service.getName();
         		//根据服务实现类的绝对路径加载配置
            if (loader == null)
                configs = ClassLoader.getSystemResources(fullName);
            else
                configs = loader.getResources(fullName);
        } catch (IOException x) {
            fail(service, "Error locating configuration files", x);
        }
    }
    // 判断集合是否为空或者已经遍历完毕
    while ((pending == null) || !pending.hasNext()) {
        if (!configs.hasMoreElements()) {
            return false;
        }
        // 从配置文件解析以下的服务实现类
        //class com.xydp.SPI.Implementation1
        //class com.xydp.SPI.Implementation2
        pending = parse(service, configs.nextElement());
    }
    // 遍历集合的服务实现类信息
    //第一次返回class com.xydp.SPI.Implementation1
    nextName = pending.next();
    return true;
}

获取服务实现类的信息

System.out.println(iterator.next().getClass());
//源码如下
public S next() {
    // 刚开始缓存为空，所以为false1不执行
    if (knownProviders.hasNext())
        return knownProviders.next().getValue();
    //第一次执行到这
    return lookupIterator.next();
}

public S next() {
 		//控制权限默认为空，执行这段代码
    if (acc == null) {
        return nextService();
    } else {
        PrivilegedAction<S> action = new PrivilegedAction<S>() {
            public S run() { return nextService(); }
        };
        return AccessController.doPrivileged(action, acc);
    }
}
//通过反射获取服务实例
private S nextService() {
		//此时 cn = com.xydp.SPI.Implementation1
    String cn = nextName;
    nextName = null;
    Class<?> c = null;
    // 使用反射，通过类的全限定名和类加载器得到类
    c = Class.forName(cn, false, loader);
	
    // 创建类的实例对象 
    S p = service.cast(c.newInstance());
    // 将实例对象放入缓存
    // key:com.xydp.SPI.Implementation1
    // value:Implementation1@28d25987
    providers.put(cn, p);
    // 返回实例对象
    return p;
}

SPI弊端：从源码可以知道SPI不能按需加载，需要通过 Iterator 形式遍历所有的服务实现类，无法根据参数名称来获取具体的服务实现类。

SPI与类加载器

在加载 SPI 服务时，需要指定类加载器 ClassLoader，否则无法找到具体的服务实现类，这是受限于双亲委派机制，该机制规定子类加载器可以使用父类已经加载的类，但是父类加载器无法使用子类已经加载的类。
(1) SPI 接口属于 Java 的核心库，是由顶层父类启动类加载器 BootstrapClassLoader所加载的；
(2 )SPI 的具体实现类是由系统类加载器AppClassLoader 加载的，顶层的父类启动类加载器 BootstrapClassLoader 是无法找到具体实现类的，所以需要指定类加载器 ClassLoader来加载。
主要有以下四种类加载器:

1 启动类加载器(Bootstrap ClassLoader)：启动类加载器是最顶层的类加载器，它负责加载Java核心API和核心类库。启动类加载器是由JVM实现的，不是由Java类实现的。用来加载java核心类库，无法被java程序直接引用。

2 扩展类加载器(extensions class loader):扩展类加载器是启动类加载器的子类加载器，它用来加载 Java 的扩展库。Java 虚拟机的实现会提供一个扩展库目录。该类加载器在此目录里面查找并加载 Java 类。

3 系统类加载器（system class loader）：系统类加载器是扩展类加载器的子类加载器，加载路径主要包括应用程序的CLASSPATH环境变量指定的路径。可以通过ClassLoader.getSystemClassLoader()来获取它。

4 用户自定义类加载器，通过继承 java.lang.ClassLoader类重写findClass()方法的方式实现。

双亲委派机制

1.什么是双亲委派机制？

（1）当加载一个类时，当前类加载器先判断此类是否已经被加载，如果类已经被加载则返回；

（2）如果类没有被加载，则先委托父类加载（父类加载时会判断该类有没有被自己加载过），如果父类加载过则返回；如果没被加载过则继续向上委托；

（3）如果一直委托都无法加载，当前类加载器才会尝试自己加载。

2.双亲委派机制作用/优点

双亲委派机制是Java类加载器中的一个重要机制。它的主要作用有以下几点：

避免类的重复加载：Java中的类是由类加载器加载的，如果没有双亲委派机制，那么可能会出现多个类加载器加载同一个类的情况，造成资源的浪费。

保证Java核心API的类型安全：双亲委派机制保证了所有的Java应用都至少会使用java.* 开头的类库，而这些由系统类加载器所加载的类库在程序中有着至关重要的地位，比如java.lang.Object类，没有哪个类可以不使用Object类，所以为了防止用户自定义类篡改这些核心类。

例如：实现了自定义的String时，当应用程序通过系统类记载器加载核心类String时，它会首先委托给拓展类加载器，再委托给启动类加载器，启动类加载器就会加载核心String类，由于启动类加载器已经加载了正确的核心String类，所以应用程序不会加载到被篡改的String类。

3.为什么要打破双亲委派机制？

打破双亲委派机制的原因主要有以下几点：

灵活性：双亲委派机制虽然保证了类的唯一性和安全性，但也限制了Java类加载器的灵活性。有时候，我们需要自定义类加载器来实现一些特殊的功能，比如实现代码的热部署、动态加载第三方插件等。在这些场景下，打破双亲委派机制可以让我们更加灵活地控制类的加载过程。
隔离性：在某些场景下，**我们可能需要在同一个JVM中运行多个相互隔离的应用。这时候，我们可以使用自定义类加载器来实现类的隔离，从而避免类的冲突和安全问题。**打破双亲委派机制可以让我们更加灵活地控制类的加载过程，从而实现应用的隔离。
增加了类加载时间：在类加载的过程中，需要不断地查询并委托父类加载器，这意味着类加载所需要的时间可能会增加。在类数量庞大或类加载器层次比较深的情况下，这种时间延迟可能会变得更加明显。

4.如何打破双亲委派机制？

继承java.lang.ClassLoader类重写loadClass()方法来打破双亲委派机制，然后直接从自己的类路径中加载类，而不需要委托给父类加载器进行加载。

5.Tomcat是如何打破双亲委派机制的？

Tomcat是一个Java Web应用服务器，它可以运行多个Web应用。为了实现Web应用的隔离和独立部署，Tomcat使用了自定义类加载器来打破双亲委派机制。

在Tomcat中，每个Web应用都有一个对应的WebappClassLoader，它继承了java.lang.ClassLoader类。WebappClassLoader的主要作用是加载Web应用的类和资源。为了实现类的隔离，WebappClassLoader重写了loadClass方法，而不是findClass方法。在loadClass方法中，WebappClassLoader首先尝试从自己的类路径中加载类，如果找不到，再委托给父类加载器进行加载。这样，每个Web应用都可以使用自己的类加载器来加载类，从而实现了类的隔离。

6.如何自定义类加载器？