spring - Spring AOP中CGLIB代理相对于动态代理的缺点是什么？

Question

据我了解，Spring AOP一般涉及:

接口(interface)的动态代理

那些没有的 CGLIB 代理( final方法和类除外)

为什么不一直使用CGLIB代理？我希望获得以下 yield :

因为它是在编译期间完成的，所以应该比动态代理有性能提升

没有需要接口(interface)的限制因素

如果您在某些服务工厂中返回 impl 类，则可以绕过代理
以无需编译的可配置性为代价。

Answer 1

我不确定我是否理解您在问题中提出的 CGLIB 的 yield 。
动态代理和 CGLIB 都是在运行时创建的，它与编译时完全无关。
基本上，CGLIB 的主要缺点是性能。
根据领域的不同，性能的两个方面可能或多或少很重要:

创建代理对象的成本

代理上方法调用的成本。

现在，在这两种情况下，动态代理机制都比 CGLIB 代理更轻量级。这就是为什么升级到第 5 版(在问题标签中提到)尝试创建动态代理，如果有一个接口(interface)，并且只有当它不可能用 CGLIB 包装真实对象时。
这在 Spring 5 中已经改变，在任何情况下都支持使用 CGLIB，但仍然有一个标志可以恢复旧的行为。
有趣的是，CGLIB 有一种你没有提到的优势，它对 Spring 很重要(好吧，也许这就是 Spring 5 中行为改变的原因，我不能肯定地说):
许多公司不费心为服务创建接口(interface)并直接通过实现工作，或者即使他们这样做 - 他们不使用接口(interface)注入(inject):

public interface MyService {
   void foo();
}

@Component
public class MyServiceImpl implements MyService {
    public void foo() {... whatever...}
}

@Component
public class AnotherService {

 @Autowired // note, this is not an injection by inteface
 private MyServiceImpl service;

 public void bar() {
    // do something
    service.foo(); 
    // do something else

  }
}

现在，如果您将使用动态代理(通常可以在应用程序代码使用接口(interface)注入(inject)时使用)- 您将生成实现接口(interface) MyService 的内容。但不能注入(inject) AnotherService因为生成的代理没有扩展 MyServiceImpl类(class)。在这种情况下，CGLIB 是唯一可行的解​​决方案。