AOP的内部是怎么实现的？深度讨论内部实现

[左大神在这]

AOP的内部是怎么实现的？我知道是动态代理机制，但是细节呢，我希望我们可以讨论得详细些，也可以贴图或代码，有兴趣的一起研究下。

[Aniao]

aspectJ好像是语言级的实现

[bobo364]

关于AOP的个人理解

AOP联盟定义的AOP体系结构把与AOP相关的概念大致分为了由高到低、从使用到实现的三个层次。关于这个体系结构，个人的理解是这样的，从上往下，最高层是语言和开发环境，在这个环境中可以看到几个重要的概念：base可以视为待增强对象，或者说目标对象；aspect指切面，通常包含对于base的增强应用；configuration可以看成是一种编织或者说配置，通过在AOP体系中提供这个configuration配置环境，可以把base和aspect结合起来，从而完成切面对目标对象的编织实现。

对Spring平台或者说生态系统来说，AOP是Spring框架的核心功能模块之一。AOP与IOC容器的结合使用, 为应用开发或者Spring自身功能的扩展都提供了许多便利。Spring AOP的实现和其他特性的实现一样，非常丰富，除了可以使用Spring本身提供的AOP实现之外，还封装了业界优秀的AOP解决方案AspectJ来让应用使用。在这里，主要对Spring自身的AOP实现原理做一些解析；在这个AOP实现中，Spring充分利用了IOC容器Proxy代理对象以及AOP拦截器的功能特性，通过这些对AOP基本功能的封装机制，为用户提供了AOP的实现框架。所以，要了解这些AOP的基本实现，需要我们对Java 的Proxy机制有一些基本了解。

AOP实现的基本线索

AOP实现中，可以看到三个主要的步骤，一个是代理对象的生成，然后是拦截器的作用，然后是Aspect编织的实现。AOP框架的丰富，很大程度体现在这三个具体实现中，所具有的丰富的技术选择，以及如何实现与IOC容器的无缝结合。毕竟这也是一个非常核心的模块，需要满足不同的应用需求带来的解决方案需求。
在Spring AOP的实现原理中，我们主要举ProxyFactoryBean的实现作为例子和实现的基本线索进行分析；很大一个原因，是因为ProxyFactoryBean是在Spring IoC环境中，创建AOP应用的最底层方法，从中，可以看到一条实现AOP的基本线索。在ProxyFactoryBean中，它的AOP实现需要依赖JDK或者CGLIB提供的Proxy特性。从FactoryBean中获取对象，是从getObject()方法作为入口完成的。然后为proxy代理对象配置advisor链，这个配置是在initializeAdvisorChain方法中完成的；然后就为生成AOP代理对象做好了准备，生成代理对象如下所示：

private synchronized Object getSingletonInstance() {   
    if (this.singletonInstance == null) {   
        this.targetSource = freshTargetSource();   
        if (this.autodetectInterfaces && getProxiedInterfaces().length == 0 && !isProxyTargetClass()) {   
            // Rely on AOP infrastructure to tell us what interfaces to proxy.   
            Class targetClass = getTargetClass();   
            if (targetClass == null) {   
                throw new FactoryBeanNotInitializedException("Cannot determine target class for proxy");   
            }   
 // 这里设置代理对象的接口     setInterfaces(ClassUtils.getAllInterfacesForClass(targetClass, this.proxyClassLoader));   
        }   
        // Initialize the shared singleton instance.   
        super.setFrozen(this.freezeProxy);   
        // 注意这里的方法会使用ProxyFactory来生成我们需要的Proxy   
        this.singletonInstance = getProxy(createAopProxy());   
    }   
    return this.singletonInstance;   
}   
//使用createAopProxy返回的AopProxy来得到代理对象   
protected Object getProxy(AopProxy aopProxy) {   
    return aopProxy.getProxy(this.proxyClassLoader);   
}  

	private synchronized Object getSingletonInstance() {
		if (this.singletonInstance == null) {
			this.targetSource = freshTargetSource();
			if (this.autodetectInterfaces && getProxiedInterfaces().length == 0 && !isProxyTargetClass()) {
				// Rely on AOP infrastructure to tell us what interfaces to proxy.
				Class targetClass = getTargetClass();
				if (targetClass == null) {
					throw new FactoryBeanNotInitializedException("Cannot determine target class for proxy");
				}
	 // 这里设置代理对象的接口		setInterfaces(ClassUtils.getAllInterfacesForClass(targetClass, this.proxyClassLoader));
			}
			// Initialize the shared singleton instance.
			super.setFrozen(this.freezeProxy);
			// 注意这里的方法会使用ProxyFactory来生成我们需要的Proxy
			this.singletonInstance = getProxy(createAopProxy());
		}
		return this.singletonInstance;
	}
	//使用createAopProxy返回的AopProxy来得到代理对象
	protected Object getProxy(AopProxy aopProxy) {
		return aopProxy.getProxy(this.proxyClassLoader);
	}



上面我们看到了在Spring中通过ProxyFactoryBean实现AOP功能的第一步，得到AopProxy代理对象的基本过程，下面我们看看AopProxy代理对象的拦截机制是怎样发挥作用，是怎样实现AOP功能的。我们知道，对代理对象的生成，有CGLIB和JDK两种生成方式，在CGLIB中，对拦截器设计是通过在Cglib2AopProxy的AopProxy代理对象生成的时候，在回调DynamicAdvisedInterceptor对象中实现的，这个回调的实现在intercept方法中完成。对于AOP是怎样完成对目标对象的增强的，这些实现是封装在AOP拦截器链中，由一个个具体的拦截器来完成的。具体拦截器的运行是在以下的代码实现中完成的，这些调用在ReflectiveMethodInvocation中。 
Java代码 
public Object proceed() throws Throwable {   
    //  We start with an index of -1 and increment early.   
    //如果拦截器链中的拦截器迭代调用完毕，这里开始调用target的函数，这个函数是通过反射机制完成的,具体实现在：AopUtils.invokeJoinpointUsingReflection方法里面。   
    if (this.currentInterceptorIndex == this.interceptorsAndDynamicMethodMatchers.size() - 1) {   
        return invokeJoinpoint();   
    }   
    //这里沿着定义好的 interceptorOrInterceptionAdvice链进行处理。   
    Object interceptorOrInterceptionAdvice =   
        this.interceptorsAndDynamicMethodMatchers.get(++this.currentInterceptorIndex);   
    if (interceptorOrInterceptionAdvice instanceof InterceptorAndDynamicMethodMatcher) {   
        // Evaluate dynamic method matcher here: static part will already have   
        // been evaluated and found to match.   
        //这里对拦截器进行动态匹配的的判断，还记得我们前面分析的pointcut吗？这里是触发进行匹配的地方，如果和定义的pointcut匹配，那么这个advice将会得到执行。   
        InterceptorAndDynamicMethodMatcher dm =   
            (InterceptorAndDynamicMethodMatcher) interceptorOrInterceptionAdvice;   
        if (dm.methodMatcher.matches(this.method, this.targetClass, this.arguments)) {   
            return dm.interceptor.invoke(this);   
        }   
        else {   
            // Dynamic matching failed.   
            // Skip this interceptor and invoke the next in the chain.   
            // //如果不匹配，那么这个proceed会被递归调用，直到所有的拦截器都被运行过为止。   
            return proceed();   
        }   
    }   
    else {   
        // It's an interceptor, so we just invoke it: The pointcut will have   
        // been evaluated statically before this object was constructed.   
        //如果是一个interceptor，直接调用这个interceptor对应的方法   
        return((MethodInterceptor) interceptorOrInterceptionAdvice).invoke(this);   
    }   
}  

	public Object proceed() throws Throwable {
		//	We start with an index of -1 and increment early.
		//如果拦截器链中的拦截器迭代调用完毕，这里开始调用target的函数，这个函数是通过反射机制完成的,具体实现在：AopUtils.invokeJoinpointUsingReflection方法里面。
		if (this.currentInterceptorIndex == this.interceptorsAndDynamicMethodMatchers.size() - 1) {
			return invokeJoinpoint();
		}
		//这里沿着定义好的 interceptorOrInterceptionAdvice链进行处理。
		Object interceptorOrInterceptionAdvice =
		    this.interceptorsAndDynamicMethodMatchers.get(++this.currentInterceptorIndex);
		if (interceptorOrInterceptionAdvice instanceof InterceptorAndDynamicMethodMatcher) {
			// Evaluate dynamic method matcher here: static part will already have
			// been evaluated and found to match.
			//这里对拦截器进行动态匹配的的判断，还记得我们前面分析的pointcut吗？这里是触发进行匹配的地方，如果和定义的pointcut匹配，那么这个advice将会得到执行。
			InterceptorAndDynamicMethodMatcher dm =
			    (InterceptorAndDynamicMethodMatcher) interceptorOrInterceptionAdvice;
			if (dm.methodMatcher.matches(this.method, this.targetClass, this.arguments)) {
				return dm.interceptor.invoke(this);
			}
			else {
				// Dynamic matching failed.
				// Skip this interceptor and invoke the next in the chain.
				// //如果不匹配，那么这个proceed会被递归调用，直到所有的拦截器都被运行过为止。
				return proceed();
			}
		}
		else {
			// It's an interceptor, so we just invoke it: The pointcut will have
			// been evaluated statically before this object was constructed.
			//如果是一个interceptor，直接调用这个interceptor对应的方法
			return((MethodInterceptor) interceptorOrInterceptionAdvice).invoke(this);
		}
	}

在调用拦截器的时候，我们接下去就可以看到对advice的通知的调用。而经过一系列的注册，适配的过程以后，拦截器在拦截的时候，会调用到预置好的一个通知适配器，设置通知拦截器，这是一系列Spring设计好为通知服务的类的一个，是最终完成通知拦截和实现的地方，非常的关键。比如，对MethodBeforeAdviceInterceptor的实现是这样的： 
Java代码 
public class MethodBeforeAdviceInterceptor implements MethodInterceptor, Serializable {   
  
    private MethodBeforeAdvice advice;   
  
  
    /**  
     * Create a new MethodBeforeAdviceInterceptor for the given advice.  
     * @param advice the MethodBeforeAdvice to wrap  
     */  
    public MethodBeforeAdviceInterceptor(MethodBeforeAdvice advice) {   
        Assert.notNull(advice, "Advice must not be null");   
        this.advice = advice;   
    }   
    //这个invoke方法是拦截器的回调方法，会在代理对象的方法被调用的时候触发回调。   
    public Object invoke(MethodInvocation mi) throws Throwable {   
        this.advice.before(mi.getMethod(), mi.getArguments(), mi.getThis() );   
        return mi.proceed();   
    }   
}  

public class MethodBeforeAdviceInterceptor implements MethodInterceptor, Serializable {

	private MethodBeforeAdvice advice;


	/**
	 * Create a new MethodBeforeAdviceInterceptor for the given advice.
	 * @param advice the MethodBeforeAdvice to wrap
	 */
	public MethodBeforeAdviceInterceptor(MethodBeforeAdvice advice) {
		Assert.notNull(advice, "Advice must not be null");
		this.advice = advice;
	}
	//这个invoke方法是拦截器的回调方法，会在代理对象的方法被调用的时候触发回调。
	public Object invoke(MethodInvocation mi) throws Throwable {
		this.advice.before(mi.getMethod(), mi.getArguments(), mi.getThis() );
		return mi.proceed();
	}
}

在代码中，可以看到，就是这里，会调用advice的before方法！这样就成功的完成了before通知的编织！

因为Spring AOP本身并不打算成为一个一统天下的AOP框架，秉持Spring的一贯设计理念，设想中的Spring设计目标应该是，致力于AOP框架与IOC容器的紧密集成，通过集成AOP技术为JavaEE应用开发中遇到的普遍问题提供解决方案，从而为AOP用户使用AOP技术提供最大的便利，从这个角度上为Java EE的应用开发人员服务。在没有使用第三方AOP解决方案的时候，Spring通过虚拟机的Proxy特性和CGLIB实现了AOP的基本功能，我想，如果有了Spring AOP实现原理的知识背景，再加上我们对源代码实现的认真解读，可以为我们了解其他AOP框架与IOC容器的集成原理，也打下了很好的基础，并真正了解一个AOP框架是在怎样实现的。

这还真是就是我们喜欢开源软件一个原因，有了源代码，软件就没有什么神秘的面纱了！本立而道生，多读源代码吧，或者找一本从源代码出发讲解软件实现的书来看看，就像以前我们学习操作系统，学习TCP/IP那样！一定会有长进的。

[左大神在这]

AOP，Aspect-Oriented Programming，面向切面编程，这个名词这几年非常流行，主要因为它是编程方法上的一个重大突破，或者说是一次巨大创新，当前流行的面向对象编程，通过其封装特性，将同类事物的共同属性和行为封装到一个类中，从而实现抽象对象共同行为的目的，但是当不同模块或不同类的对象具有某一共同的行为，而我们需要对这些对象的共同行为进行统一控制时，面向对象方法就显得无能为力，在AOP没有出现前，我们采取的方法只能是在需要的地方编写重复代码， 这样编写程序不利于代码的复用，也不方便对这些共同行为进行控制。
而AOP的出现正好解决了这一问题，可以说是面向对象的一个重要的补充。AOP利用其横切技术，剖开那些对象的内部，将那些代表共同行为的代码统一抽取出来，封装到一个可重用模块（最简单的情况也就是一个类，类中封装了那些行为代码）中，这个可重用模块就是“切面”。
这里说的具有共同行为代码，究竟是些什么代码呢？
大家都知道，一个复杂的系统一般可以看成由多个关注点组成的，而一个系统有多个方面的关注点，包括业务逻辑，性能，数据存储，日志信息，异常信息，安全，权限，线程，通信等多方面。但是总的来说，主要可以分为两个方面的关注点，核心关注点和非核心关注点。核心关注点就是系统的核心业务逻辑，这在每个模块都各不相同，都有自己不同的实现，而非核心关注点，像日志信息，权限控制，数据存储等有很多共同之处，这些都可以通过切面编程，这些就是具有共同行为的代码，这些关注点我们常称为横切关注点。
归纳总结一下，可以很清楚什么场合需要面向切面编程（AOP）: 那就是非核心关注点的地方。
总的来说AOP的好处是：
1.解耦。切面将非业务代码从各模块抽出来，降低了模块间的耦合度。
2.切面将不同模块共同的与业务无关的代码封装起来，减少了重复代码。
3.维护方便，将横切关注点统一到一个模块管理，修改更新方便，不影响其他业务模块。
4.开发分工合作方便，可安排一个人专门复杂横切模块的开发。
5.节约成本。AOP出现前，需要编写大量重复代码，无论编码和维护都需要付出不少人力成本。

[wfeng007]

AOP很早就流行了。但是在事实上，其作用还是有限。他本质上打破了OO的封装。所以，具体看你想干啥。。。

我最常见到的是用作 事务 以及 业务跟踪日至。。。但是其它的我个人感觉还不如直接用动态语言来做呢。。。。

[左大神在这]

引用 4 楼 wfeng007 的回复:

AOP很早就流行了。但是在事实上，其作用还是有限。他本质上打破了OO的封装。所以，具体看你想干啥。。。

我最常见到的是用作 事务 以及 业务跟踪日至。。。但是其它的我个人感觉还不如直接用动态语言来做呢。。。。

恩，我也觉得打破了面向对象的封装，因为可能最初设计方法时，不知道到什么时候被插入了新的功能，从OO的对象的封装性来说，其方法内部的实现是不能被外界知道的。从这个角度来说，AOP是打破了OO的封装。但是AOP让很多不同类的对象的重复代码集合在一起，可以说是从切面对那些重复代码进行了封装。

另外，你说的动态语言是什么语言？怎么实现，具体说说。