为什么Spring-proxy使用委托模式而不是继承+超级？

Question

众所周知，如果没有AspectJ，bean方法的自调用在Spring中是行不通的。

例如，请看这个问题。

class MyClass {

    @Autowired
    private MyClass self; // actually a MyProxy instance

    @Transactional // or any other proxy magic
    public void myMethod() {}

    public void myOtherMethod() {
        this.myMethod(); // or self.myMethod() to avoid self-invokation problem
    }
}

class MyProxy extends MyClass { // or implements MyInterface if proxyMode is not TARGET_CLASS and MyClass also implements MyInterface

    private final MyClass delegate;

    @Override
    public void myMethod() {
        // some proxy magic: caching, transaction management etc
        delegate.myMethod();
        // some proxy magic: caching, transaction management etc
    }

    @Override
    public void myOtherMethod() {
        delegate.myOtherMethod();
    }
}

使用以下代码：

public void myOtherMethod() {
    this.myMethod();
}

this.mymethod()将绕过代理（所以所有@transactional或@cacheable魔术），因为它只是内部委托的调用...因此，我们应该在myclass中注入一个myclassbean（实际上是myproxy实例），并调用self.mymethod()。这是可以理解的。

但是为什么代理是以这种方式实现的呢？为什么它不只是扩展目标类，重写所有公共方法并调用super而不是delegate？像这样：

class MyProxy extends MyClass {
    // private final MyClass delegate; // no delegate
    @Override
    public void myMethod() {
        // some proxy magic: caching, transaction management etc
        super.myMethod();
        // some proxy magic: caching, transaction management etc
    }
    @Override
    public void myOtherMethod() {
        super.myOtherMethod();
    }
}

它应该可以解决自调用问题，即this.mymethod()绕过代理，因为在本例中，从MyClass.myothermethod()调用的this.mymethod()将调用overriden子方法(MyProxy.mymethod()()。

所以，我的主要问题是为什么不这样实施？

Answer 1

您认为Spring AOP对其代理使用委托是正确的。这也被记录在案。

使用CGLIB，理论上可以使用proxy.invokesuper()来实现您想要的效果，即自调用由代理的方法拦截器实现的方面注册（我在这里使用的是Spring的嵌入式CGLIB，因此是包名）：

package spring.aop;

import org.springframework.cglib.proxy.Enhancer;
import org.springframework.cglib.proxy.MethodInterceptor;
import org.springframework.cglib.proxy.MethodProxy;

import java.lang.reflect.Method;

class SampleClass {
  public void x() {
    System.out.println("x");
    y();
  }

  public void y() {
    System.out.println("y");
  }

  public static void main(String[] args) {
    Enhancer enhancer = new Enhancer();
    enhancer.setSuperclass(SampleClass.class);
    enhancer.setCallback(new MethodInterceptor() {
      @Override
      public Object intercept(Object obj, Method method, Object[] args, MethodProxy proxy)
        throws Throwable {
        if(method.getDeclaringClass() == Object.class)
          return proxy.invokeSuper(obj, args);
        System.out.println("Before proxy.invokeSuper " + method.getName());
        Object result = proxy.invokeSuper(obj, args);
        System.out.println("After proxy.invokeSuper " + method.getName());
        return result;
      }
    });
    SampleClass proxy = (SampleClass) enhancer.create();
    proxy.x();
  }
}

控制台日志：

Before proxy.invokeSuper x
x
Before proxy.invokeSuper y
y
After proxy.invokeSuper y
After proxy.invokeSuper x

>

选项1：每个方面都有自己的代理。除非您根据方面优先级将代理嵌套到彼此中，否则这显然是行不通的。但是将它们嵌套在一起意味着继承，即一个代理必须从另一个从外到内继承。尝试代理一个CGLIB代理，它不工作，你会得到异常。此外，CGLIB代理非常昂贵，并且使用perm-gen内存，请参见本CGLIB入门中的描述。

选项2：使用组合而不是继承。构图更加灵活。如果有一个代理，您可以根据需要向其注册方面，那么就可以解决继承问题，但也意味着委托：代理注册方面，并在运行时按照正确的顺序在实际对象的代码执行之前/之后调用它们的方法（如果@around建议从未调用procede())的话，则不调用这些方法）。请参阅Spring手册中关于将方面手动注册到代理的示例：

// create a factory that can generate a proxy for the given target object
AspectJProxyFactory factory = new AspectJProxyFactory(targetObject);

// add an aspect, the class must be an @AspectJ aspect
// you can call this as many times as you need with different aspects
factory.addAspect(SecurityManager.class);

// you can also add existing aspect instances, the type of the object supplied must be an @AspectJ aspect
factory.addAspect(usageTracker);

// now get the proxy object...
MyInterfaceType proxy = factory.getProxy();

至于Spring开发人员为什么选择这种方法，以及是否可以使用one-proxy方法，但仍然要确保自调用像上面我的小CGLIB示例“Logging Aspect”中那样工作，我只能猜测。您也许可以在开发人员邮件列表上询问他们，或者查看源代码。原因可能是CGLIB代理的行为应该与默认的Java动态代理相似，以便在两者之间无缝地切换接口类型。也许原因是另一个。

我在评论中无意粗鲁，只是直截了当，因为您的问题真的不适合StackOverflow，因为它不是一个可以有人找到解决方案的技术问题。这是一个历史上的设计问题，本质上是哲学问题，因为使用AspectJ，在实际问题之下已经存在一个技术问题（自调用）的解决方案。但是，也许您仍然想深入研究Spring源代码，将Spring AOP实现从deleration更改为proxy.invokesuper()并提交一个拉请求。不过，我不确定这样一个突破性的变化会被接受。