外掛的配置與使用
在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核心知識點總結！