共计 5228 个字符，预计需要花费 14 分钟才能阅读完成。
插件的配置与应用
在 mybatis-config.xml 配置文件中配置 plugin 结点，比方配置一个自定义的日志插件 LogInterceptor 和一个开源的分页插件 PageInterceptor：
<plugins>
<plugin interceptor="com.crx.plugindemo.LogInterceptor"></plugin>
<plugin interceptor="com.github.pagehelper.PageInterceptor">
<property name="helperDialect" value="oracle" />
</plugin>
</plugins>插件的工作原理
借助责任链模式，定义一系列的过滤器，在查问等办法执行时进行过滤，从而达到控制参数、调整查问语句和管制查问后果等作用。上面从插件的加载（初始化）、注册和调用这三个方面论述插件的工作原理。
过滤器的加载（初始化）
和其余配置信息一样，过滤器的加载也会在 myBatis 读取配置文件创立 Configuration 对象时进行，相应的信息存储在 Configuration 的 interceptorChain 属性中，InterceptorChain 封装了一个蕴含 Interceptor 的 list：
private final List<Interceptor> interceptors = new ArrayList<>();在 XMLConfigBuilder 进行解析配置文件时执行 pluginElement 办法，生成过滤器实例，并增加到上述 list 中：
private void pluginElement(XNode parent) throws Exception {if (parent != null) {for (XNode child : parent.getChildren()) {String interceptor = child.getStringAttribute("interceptor");
Properties properties = child.getChildrenAsProperties();
Interceptor interceptorInstance = (Interceptor) resolveClass(interceptor).getDeclaredConstructor()
.newInstance();
interceptorInstance.setProperties(properties);
configuration.addInterceptor(interceptorInstance);
}
}
}过滤器的注册
能够为 Executor、ParameterHandler、ResultSetHandler 和 StatementHandler 四个接口注册过滤器，注册的机会也就是这四种接口的实现类的对象的生成机会，比方 Executor 的过滤器的注册产生在 SqlSessionFactory 应用 openSession 办法构建 SqlSession 的过程中（因为 SqlSession 依赖一个 Executor 实例），ParameterHandler 和 StatementHandler 的过滤器产生在 doQuery 等 sql 执行办法执行时注册，而 ResultHandler 的过滤器的注册则产生在查问后果返回给客户端的过程中。以 Executor 的过滤器的注册为例，通过了这样的过程：
当初具体的剖析一下 Plugin 的 wrap 这个动态的包装办法：
public static Object wrap(Object target, Interceptor interceptor) {
// 从定义的 Interceptor 实现类上的注解读取须要拦挡的类、办法
Map<Class<?>, Set<Method>> signatureMap = getSignatureMap(interceptor);
// Executor、ParameterHandler、ResultSetHandler、StatementHandler
Class<?> type = target.getClass();
// 从以后执行的指标类中进行匹配，过滤出合乎以后指标的的过滤器
Class<?>[] interfaces = getAllInterfaces(type, signatureMap);
if (interfaces.length > 0) {
// 动静代理生成 Executor 的代理实例
return Proxy.newProxyInstance(type.getClassLoader(), interfaces,
new Plugin(target, interceptor, signatureMap));
}
return target;
}上述代码中的 getSignatureMap 办法是解析 Interceptor 下面的注解的过程，从注解中读取出须要拦挡的办法，根据 @Signature 的三个变量类、办法 method 和参数 args 就能通过反射惟一的定位一个须要拦挡的办法。
private static Map<Class<?>, Set<Method>> getSignatureMap(Interceptor interceptor) {Intercepts interceptsAnnotation = interceptor.getClass().getAnnotation(Intercepts.class);
if (interceptsAnnotation == null) {
throw new PluginException("No @Intercepts annotation was found in interceptor" + interceptor.getClass().getName());
}
Signature[] sigs = interceptsAnnotation.value();
Map<Class<?>, Set<Method>> signatureMap = new HashMap<>();
for (Signature sig : sigs) {Set<Method> methods = signatureMap.computeIfAbsent(sig.type(), k -> new HashSet<>());
try {Method method = sig.type().getMethod(sig.method(), sig.args());
methods.add(method);
} catch (NoSuchMethodException e) {
throw new PluginException("Could not find method on" + sig.type() + "named" + sig.method() + ". Cause:" + e, e);
}
}
return signatureMap;
}而 getAllInterfaces 办法是根据不同的指标对象（Executor 等四种）进行过滤的过程，只给对应的指标进行注册：
private static Class<?>[] getAllInterfaces(Class<?> type, Map<Class<?>, Set<Method>> signatureMap) {Set<Class<?>> interfaces = new HashSet<>();
while (type != null) {for (Class<?> c : type.getInterfaces()) {if (signatureMap.containsKey(c)) {interfaces.add(c);
}
}
type = type.getSuperclass();}
return interfaces.toArray(new Class<?>[interfaces.size()]);
}至此，理论应用的 Executor 对象将是通过动静代理生成的 Plugin 实例。
过滤器的调用
在第二步中实现了过滤器的注册，在理论调用 Executor 时，将由实现了 InvocationHandler 接口的 Plugin 实例进行接管，对 Executor 相应办法办法的调用，将实际上调用动静代理体系下的 invoke 办法：
public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
try {Set<Method> methods = signatureMap.get(method.getDeclaringClass());
if (methods != null && methods.contains(method)) {Object result=interceptor.intercept(new Invocation(target, method, args));
return result;
}
return method.invoke(target, args);
} catch (Exception e) {throw ExceptionUtil.unwrapThrowable(e);
}
}如前所述，插件的工作原理是基于责任链模式，能够注册多个过滤器，层层包装，最终由内而外造成了一个近似装璜器模式的责任链，最外面的根本实现是 CachingExecutor：
从 InterceptorChain 的 pluginAll 办法能够看出这个构造的结构过程：
public Object pluginAll(Object target) {for (Interceptor interceptor : interceptors) {
// 从这能够看出过滤器的传递的过程：动静代理实例由内而外层层包装，相似于与装璜器的构造，根底 实现是一个 Executor
target = interceptor.plugin(target);
}
return target;
}这种由内而外的包装的栈构造从外向内层层代理调用，实现了责任链工作的逐级推送。从这个注册过程能够看到，在 list 中越后面的 Interceptor 越先被代理，在栈构造中越处于底层，执行的程序越靠后。造成了注册程序和执行程序相同的景象。
插件的典型案例：PageHelper
pagehelper 是一个实现物理分页成果的开源插件，并且在底层通过 Dialect 类适配了不同的数据库，其次要作用是拦挡 sql 查问，结构一个查问总数的新的以 ”_COUNT” 结尾的新 sql，最终再进行分页查问。
自定义插件
定义 Interceptor 接口的实现类并在其上应用 @Intercepts 和 @Signature 注解进行过滤的类和办法，比方定义一个打日志的插件：
@Intercepts({
@Signature(type = Executor.class, method = "query", args = { MappedStatement.class, Object.class,
RowBounds.class, ResultHandler.class }),
@Signature(type = Executor.class, method = "query", args = { MappedStatement.class, Object.class,
RowBounds.class, ResultHandler.class, CacheKey.class, BoundSql.class }), })
public class LogInterceptor implements Interceptor {
@Override
public Object intercept(Invocation invocation) throws Throwable {System.out.println("进入了自定义的插件过滤器！");
System.out.println("执行的指标是：" + invocation.getTarget());
System.out.println("执行的办法是：" + invocation.getMethod());
System.out.println("执行的参数是：" + invocation.getArgs());
return invocation.proceed();}
}@Intercepts 注解中蕴含了一个办法签名数组，即 @Signature 数组，@Signature 有三个属性，type、method 和 args 别离定义要拦挡的类、办法名和参数，这样就能够通过反射惟一的确定了要拦挡的办法。type 即为在工作原理剖析中提到的 Executor、ParameterHandler、ResultSetHandler 和 StatementHandler，method 配置对应接口中的办法。
最初
欢送关注公众号：前程有光，支付一线大厂 Java 面试题总结 + 各知识点学习思维导 + 一份 300 页 pdf 文档的 Java 外围知识点总结！
