Spring AOP高級——源碼實現（1）動態代理技術

jdk1.8.0_144　　

　　在正式進入Spring AOP的源碼實現前，我們需要准備一定的基礎也就是面向切面編程的核心——動態代理。 動態代理實際上也是一種結構型的設計模式，JDK中已經為我們准備好了這種設計模式，不過這種JDK為我們提供的動態代理有2個缺點：

1. 只能代理實現了接口的目標對象；
2. 基於反射，效率低

　　鑒於以上2個缺點，於是就出現了第二種動態代理技術——CGLIB（Code Generation Library）。這種代理技術一是不需要目標對象實現接口（這大大擴展了使用范圍），二是它是基於字節碼實現（這比反射效率高）。當然它並不是完全沒有缺點，因為它不能代理final方法（因為它的動態代理實際是生成目標對象的子類）。

　　Spring AOP中生成代理對象時既可以使用JDK的動態代理技術，也可以使用CGLIB的動態代理技術，本章首先對這兩者動態代理技術做簡要了解，便於后續源碼的理解。

JDK動態代理技術

　　JDK動態代理技術首先要求我們目標對象需要實現一個接口：

package proxy;

/**
 * Created by Kevin on 2017/11/8.
 */
public interface Subject {
    void sayHello();
}

　　接下來就是我們需要代理的真實對象，即目標對象：

package proxy;

/**
 * 目標對象，即需要被代理的對象
 * Created by Kevin on 2017/11/8.
 */
public class RealSubject implements Subject{
    public void sayHello() {
        System.out.println("hello world");
    }
}

　　這是一個真實的對象，我們希望在不更改原有代碼邏輯的基礎上增強該類的sayHello方法，利用JDK動態代理技術需要我們實現InvocationHandler接口中的invoke方法：

package proxy;

import java.lang.reflect.InvocationHandler;
import java.lang.reflect.Method;

public class ProxySubject implements InvocationHandler {
    private Object target;

    public ProxySubject(Object target) {
        this.target = target;
    }

    public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
        System.out.println("調用前");
        Object object = method.invoke(target, args);
        System.out.println("調用后");
        return object;
    }
}

　　第15行，在invoke方法中可以看到，在調用目標對象的方法前后我們對方法進行了增加，這其實就是AOP中Before和After通知的奧義所在。

　　加入測試代碼：

package proxy;

import java.lang.reflect.Proxy;

/**
 * Created by Kevin on 2017/11/8.
 */
public class Test {
    public static void main(String[] args) {
        Subject subject = (Subject) Proxy.newProxyInstance(RealSubject.class.getClassLoader(), RealSubject.class.getInterfaces(), new ProxySubject(new RealSubject()));
        subject.sayHello();

        //查看subject對象的類型
        System.out.println(subject.getClass().getName());
    }
}

　　執行結果：

　　可以看到和AOP幾乎一樣，前面提到過，動態代理就是AOP的核心。同時我們可以看到被代理的類的類型是：com.sun.proxy.$Proxy0。等會深入JDK源碼時我們將會看到為什么。

　　回到上面的例子，我們通過Proxy. newProxyInstance生成了一個代理類，顯然這個類是在Run-Time（運行時）生成的，也就是說，JDK動態代理中代理類的生成來自於Java反射機制的支撐。

　　上面例子中我們將實現InvocationHandler的類取名為“ProxySubject”，這其實是不准確的，我們看到了最后代理類的類型並不是ProxySubject，這個類實際上是處理需要增強的方法，也就是在invoke中的實現邏輯，最后並不是生成這個類型的代理類，這也不是生成的代理類，所以取名這個是不准確的。

　　首先從Proxy.newProxyInstance開始，來研究JDK是如何生成代理類的。

public static Object newProxyInstance(ClassLoader loader, Class<?>[] interfaces, InvocationHandler h)

　　該方法有3個參數，了解JVM類加載的可能知道確定為同一個類需要有2個條件：

• 類的全限定名稱相同

• 加載類的類加載器相同

　　要想生成目標對象的代理首先就要確保其類加載器相同，所以需要將目標對象的類加載器作為參數傳遞；其次JDK動態代理技術需要代理類和目標對象都繼承自同一接口，所以需要將目標對象的接口作為參數傳遞；最后，傳遞InvocationHandler，這是主角，因為我們對目標對象的增強邏輯在這個實現類中，傳遞該對象使得代理類能夠對其進行調用。

　　在Proxy.newProxyInstance方法中創建代理類的過程主要有3步：

1.檢查

public static Object newProxyInstance(ClassLoader loader,
                                      Class<?>[] interfaces,
                                      InvocationHandler h)
    throws IllegalArgumentException
{
    Objects.requireNonNull(h);    //1.1檢查參數是否為空

    final Class<?>[] intfs = interfaces.clone();
    final SecurityManager sm = System.getSecurityManager();    //獲取安全管理器，安全管理器用於對外部資源的訪問控制
    if (sm != null) {
        checkProxyAccess(Reflection.getCallerClass(), loader, intfs);    //1.2檢查是否有訪問權限
    }

　　在上面源碼中有一個獲取安全管理器以及檢查是否具有訪問權限的過程。安全管理器可能在實際中不太常用，它是為了程序在某些敏感資源的訪問上做的權限控制，也就是起到保護程序的作用。在這里暫時不用仔細去探究，只需要大概了解即可。這里做的權限檢查實際上是對ClassLoader的檢查，例如：有的程序不允許你對類進行代理，此時加入安全管理器即可防止你對該類的代理。

2.獲取代理類型

Class<?> cl = getProxyClass0(loader, intfs);    //獲取代理類類型

　　這句話通過目標對象的類加載器，以及它所繼承的接口，即可獲取代理類的類型。

/**
 * Generate a proxy class.  Must call the checkProxyAccess method
 * to perform permission checks before calling this.
*從注釋中可以看到，這個方法用於生成代理類，在調用此方法前必須要確保
*已經做過權限檢查。
 */
private static Class<?> getProxyClass0(ClassLoader loader,
                                       Class<?>... interfaces) {
    if (interfaces.length > 65535) {        //一個類最多實現65535個接口
        throw new IllegalArgumentException("interface limit exceeded");
    }
    return proxyClassCache.get(loader, interfaces);    //先從緩存中獲取代理類，如果不存在則通過ProxyClassFactory創建，這其中會涉及到比較復雜的代理緩存機制，本篇主要講動態代理過程的源碼實現，對於動態代理的緩存機制在以后再研究。
}

　　上面的方法返回的是com.sun.proxy.$Proxy0代理類型，下面就會通過這個代理類型生成代理類。

 3.生成代理類

try {
    if (sm != null) {
        checkNewProxyPermission(Reflection.getCallerClass(), cl);    //這里還需要做一次檢查，檢查的是生成的代理類型做權限檢查，當然前提還是通過System.setSecurityManager設置安全管理類
    }

    final Constructor<?> cons = cl.getConstructor(constructorParams);    //通過反射獲取構造器，cl是代理類型其構造器的參數類型為InvocationHandler，所以參數傳入InvocationHandler
    final InvocationHandler ih = h;
    if (!Modifier.isPublic(cl.getModifiers())) {   //判斷目標對象的構造器修飾符是我否為public，如果不是則不能生成代理類，返回null
        AccessController.doPrivileged(new PrivilegedAction<Void>() {
            public Void run() {
                cons.setAccessible(true);
                return null;
            }
        });
    }
    return cons.newInstance(new Object[]{h});    //最后生成代理類
} catch (IllegalAccessException|InstantiationException e) {
    throw new InternalError(e.toString(), e);
} catch (InvocationTargetException e) {
    Throwable t = e.getCause();
    if (t instanceof RuntimeException) {
        throw (RuntimeException) t;
    } else {
        throw new InternalError(t.toString(), t);
    }
} catch (NoSuchMethodException e) {
    throw new InternalError(e.toString(), e);
}

　　以上就是通過JDK動態代理生成代理類的過程，其中會涉及到動態代理的緩存機制，以及代理類字節碼的生成過程，由於比較復雜，在本文暫不做介紹。由此可以清楚的看到，JDK的動態代理底層是通過Java反射機制實現的，並且需要目標對象繼承自一個接口才能生成它的代理類。

　　接下來探討另一種動態代理技術——CGLib。

CGLib動態代理技術

　　通過CGLib來創建一個代理需要引入jar包，其pom.xml依賴如下所示：

<dependency>
  <groupId>cglib</groupId>
  <artifactId>cglib</artifactId>
  <version>3.2.4</version>
</dependency>

　　前面提到了CGLib動態代理技術不需要目標對象實現自一個接口：

package cglibproxy;

/**
 * 目標對象（需要被代理的類）
 * Created by Kevin on 2017/11/6.
 */
public class RealSubject {
    public void sayHello() {
        System.out.println("hello");
    }
}

　　下面我們就使用CGLib代理這個類：

package cglibproxy;

import net.sf.cglib.proxy.Enhancer;
import net.sf.cglib.proxy.MethodInterceptor;
import net.sf.cglib.proxy.MethodProxy;

import java.lang.reflect.Method;

/**
 * 代理類
 * Created by Kevin on 2017/11/6.
 */
public class ProxySubject implements MethodInterceptor {
    private Enhancer enhancer = new Enhancer();

    public Object getProxy(Class clazz) {
        enhancer.setSuperclass(clazz);
        enhancer.setCallback(this);
        return enhancer.create();    //用於創建無參的目標對象代理類，對於有參構造器則調用Enhancer.create(Class[] argumentTypes, Object[] arguments)，第一個參數表示參數類型，第二個參數表示參數的值。
    }

    @Override
    public Object intercept(Object object, Method method, Object[] args, MethodProxy methodProxy) throws Throwable {
        System.out.println("調用前");
        Object result = methodProxy.invokeSuper(object, args);
        System.out.println("調用后");
        return result;
    }
}

　　可以看到同樣是需要實現一個接口——MethodIntercept，並且實現一個和invoke類似的方法——intercept。

　　加入測試代碼：

package cglibproxy;

/**
 * Created by Kevin on 2017/11/6.
 */
public class Main {
    public static void main(String[] args) {
        RealSubject subject = (RealSubject) new ProxySubject().getProxy(RealSubject.class);
        subject.sayHello();
        System.out.println(subject.getClass().getName());
    }
}

　　執行結果：

　　可以看到的執行結果和JDK動態代理的結果一樣，不同的是代理類的類型是cglibproxy.RealSubject$$EnhancerByCGLIB$$cb568e93。接着我們來看CGLib是如何生成代理類的。

　　生成代理類的是ProxySubject類中的getProxy方法，而其中又是傳入兩個參數：

enhancer.setSuperclass(clazz);    //設置需要代理的類
enhancer.setCallback(this);    //設置回調方法

　　參數設置好后就調用enhancer.create()方法創建代理類。

public Object create() {
    classOnly = false;    //這個字段設置為false表示返回的是具體的Object代理類，在createClass()方法中設置的是classOnly=true表示的返回class類型的代理類。
    argumentTypes = null;        //創建的是無參目標對象的代理類，故沒有參數，所以參數類型設置為null
    return createHelper();
}

　　看來還在調用一個叫createHelper的方法。

private Object createHelper() {
    preValidate();        //提前作一些校驗
   //
    ……
}

private void preValidate() {
    if (callbackTypes == null) {
        callbackTypes = CallbackInfo.determineTypes(callbacks, false);
        validateCallbackTypes = true;
    }    //檢查回調方法是否為空
    if (filter == null) {    //檢查是否設置過濾器，如果設置了多個回調方法就需要設置過濾器
        if (callbackTypes.length > 1) {
            throw new IllegalStateException("Multiple callback types possible but no filter specified");
        }
        filter = ALL_ZERO;
    }
}

　　接着查看createHelper的剩余代碼：

private Object createHelper() {
    preValidate();
    Object key = KEY_FACTORY.newInstance((superclass != null) ? superclass.getName() : null,
            ReflectUtils.getNames(interfaces),
            filter == ALL_ZERO ? null : new WeakCacheKey<CallbackFilter>(filter),
            callbackTypes,
            useFactory,
            interceptDuringConstruction,
            serialVersionUID);
    this.currentKey = key;        //在CGLib中也使用到了緩存機制，這段代碼也比較復雜，有關緩存的策略暫時也不做分析吧 
    Object result = super.create(key);    //利用字節實現並創建代理類對象
    return result;
}

　　馬馬虎虎地只能說是介紹了JDK與CGLib兩種動態代理技術，並沒有很深入地研究，特別是在兩者在緩存機制上的實現，略感遺憾。

　　另外，在開頭提到了CGLib的性能比JDK高，這實際上並不准確。或許這在特別條件下的確如此，因為在我實測發現JDK8的動態代理效率非常高，甚至略高於CGLib，但是在JDK6的環境下的效率就顯得比較低了。所以，通常所說的CGLib性能比JDK動態代理要高，是傳統的掛念，實際上Java一直都在不斷優化動態代理性能，在比較高版本的JDK條件下可以放行大膽的使用JDK原生的動態代理。

 

 

這是一個能給程序員加buff的公眾號