逐行阅读Spring5.X源码(九)spring利用CGLIB实现动态代理原理剖析

前面花了大量篇幅讲解spring如何完成扫描注册的。注意,此时的注册是将业务类class所对应的BeanDefinition,要想使用业务类的功能,必须先实例化。spring肯定不会直接new一个业务对象来管理,spring是通过动态代理技术完成业务类的实例化。

什么是CGLIB

CGLIB(Code Generator Library)是一个强大的、高性能的代码生成库。其被广泛应用于AOP框架(Spring、dynaop)中,用以提供方法拦截操作。CGLIB代理主要通过对字节码的操作,为对象引入间接级别,以控制对象的访问。我们知道Java中有一个动态代理也是做这个事情的,那我们为什么不直接使用Java动态代理,而要使用CGLIB呢?答案是CGLIB相比于JDK动态代理更加强大,JDK动态代理虽然简单易用,但是其有一个致命缺陷是,只能对接口进行代理。如果要代理的类为一个普通类、没有接口,那么Java动态代理就没法使用了。


CGLIB组成结构

CGLIB底层使用了ASM(一个短小精悍的字节码操作框架)来操作字节码生成新的类。除了CGLIB库外,脚本语言(如Groovy何BeanShell)也使用ASM生成字节码。ASM使用类似SAX的解析器来实现高性能。我们不鼓励直接使用ASM,因为它需要对Java字节码的格式足够的了解

CGLIB的简单使用


     cglib
     cglib
     3.1



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

import java.lang.reflect.Method;

public class SampleClass {
    public void test(){
        System.out.println("hello world");
    }

    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 {
                System.out.println("before method run...");
                Object result = proxy.invokeSuper(obj, args);
                System.out.println("after method run...");
                return result;
            }
        });
        SampleClass sample = (SampleClass) enhancer.create();
        sample.test();
    }

}

在mian函数中,我们通过一个Enhancer和一个MethodInterceptor来实现对方法的拦截,运行程序后输出为:

before method run...
hello world
after method run...

Process finished with exit code 0

上面就是CGLIB的简单介绍及应用,CGLIB不是本文的重点,这里不再详述。Spring就是依靠CGLIB完成业务类的动态代理。

抛砖引玉

老规矩,首先祭出我们的配置类

@ComponentScan("com.app")
@Configuration
public class Config {
}

启动spring

public class SpringTest {
    public static void main(String[] args) {
        AnnotationConfigApplicationContext context = new AnnotationConfigApplicationContext();
        context.register(Config.class);
        context.refresh();
        System.out.println(context.getBean(Config.class));
    }
}

spring启动后,我们获取Config配置对象,打印结果如下:


com.config.Config$$EnhancerBySpringCGLIB$$efc56a4d@33e5ccce,不言而喻,Conifg被CGLIB动态代理成了另一个增强型的对象。

我们看,Config类上有个@Configuration注解,这个注解的作用前面文章讲过好多了,表示这是一个配置类,spring扫描注册的时候会解析这个类,但是如果把这个注解去掉,我们看一下打印结果:



此时,spring就没有对它进行动态代理了。其实,Configuration的作用远不止如此,我们继续测试。
首先生成两个业务类E和F

public class E {
}
public class F {
}

通过@Bean方式注入

@ComponentScan("com.app")
@Configuration
public class Config {

    @Bean
    public E getE(){
        System.out.println("get class E");
        return new E();
    }
    @Bean
    public F getF(){
        getE();
        System.out.println("get class F");
        return new F();
    }
}

getE方法会生成E类的实例对象,getF方法在生成F实例对象的同时,会再一次调用getE方法生成一个E实例对象,会吗?

public class SpringTest {
    public static void main(String[] args) {
        AnnotationConfigApplicationContext context = new AnnotationConfigApplicationContext();
        context.register(Config.class);
        context.refresh();
        System.out.println(context.getBean(E.class));
        System.out.println(context.getBean(F.class));
    }
}

打印结果:



getE在整个过程中,只被调用了一次,换句话讲,getE()方法在getF()中并没有起作用!好神奇!如果去掉@Configuration这个注解,情况就不一样了,读者可自行测试。

spring是怎么判断Config是否需要代理的呢?

context.refresh()完成了启动过程,跟进代码找到invokeBeanFactoryPostProcessors(beanFactory);,继续跟进,第一行PostProcessorRegistrationDelegate.invokeBeanFactoryPostProcessors(beanFactory, getBeanFactoryPostProcessors());,invokeBeanFactoryPostProcessors这个方法就是调用各种后置处理器的,前面博文也讲过太多了,这里不再详述,如果读者看到这里有点懵的话,建议按顺序阅读本专题。继续,ConfigurationClassPostProcessor完成了扫描注册,完事找到方法里这么一行代码

invokeBeanFactoryPostProcessors(registryProcessors, beanFactory);

这行代码跟进去,看下源码

    private static void invokeBeanFactoryPostProcessors(
            Collection postProcessors, ConfigurableListableBeanFactory beanFactory) {

        for (BeanFactoryPostProcessor postProcessor : postProcessors) {
            postProcessor.postProcessBeanFactory(beanFactory);
        }
    }

假设我们程序员没有提供后置处理器的话,这里的postProcessors只有一个,就是ConfigurationClassPostProcessor,怎么老是这个后置处理器,这个类实现了BeanDefinitionRegistryPostProcessor接口,而BeanDefinitionRegistryPostProcessor接口又继承了BeanFactoryPostProcessor接口,ConfigurationClassPostProcessor通过BeanDefinitionRegistryPostProcessor接口的postProcessBeanDefinitionRegistry方法完成了扫描注册,spring紧接着调用ConfigurationClassPostProcessor所实现BeanFactoryPostProcessor接口的postProcessBeanFactory方法完成后续处理,这个后续处理就是上面的源码啦!

源码很简单,就是调用了后置处理器的postProcessBeanFactory方法,在这里就是ConfigurationClassPostProcessor的postProcessBeanFactory方法,我们看下它的源码

    /**
     * Prepare the Configuration classes for servicing bean requests at runtime
     * by replacing them with CGLIB-enhanced subclasses.
     */
    @Override
    public void postProcessBeanFactory(ConfigurableListableBeanFactory beanFactory) {
        int factoryId = System.identityHashCode(beanFactory);
        if (this.factoriesPostProcessed.contains(factoryId)) {
            throw new IllegalStateException(
                    "postProcessBeanFactory already called on this post-processor against " + beanFactory);
        }
        this.factoriesPostProcessed.add(factoryId);
        if (!this.registriesPostProcessed.contains(factoryId)) {
            // BeanDefinitionRegistryPostProcessor hook apparently not supported...
            // Simply call processConfigurationClasses lazily at this point then.
            processConfigBeanDefinitions((BeanDefinitionRegistry) beanFactory);
        }

        enhanceConfigurationClasses(beanFactory);
        beanFactory.addBeanPostProcessor(new ImportAwareBeanPostProcessor(beanFactory));
    }

方法的注释的意思是,准备配置类以便在运行时为bean请求提供服务,方法是用cglib增强的子类替换它们,也就是使用cglib的代理的方式增强beanDefinition。

前面是对当前beanDefinitionRegister做判断,是否已经处理过和注册过,不出意外的话就会进入enhanceConfigurationClasses(beanFactory);这个方法,顾名思义,就是增强配置类的,这也解释了为什么前面的Config加上@Configuration就会被动态代理。那么下面的重点就是阅读enhanceConfigurationClasses的源码喽,源码首先找出所有的带有@Configuration注解的配置类并存放到LinkedHashMap集合中。在这里只有咱们的Config配置类符合,然后遍历集合进行增强处理:
首先,根据BeanDefinition获取对应的class对象
Class configClass = beanDef.resolveBeanClass(this.beanClassLoader);
然后就是增强处理:
Class enhancedClass = enhancer.enhance(configClass, this.beanClassLoader);

下一个分析enhance方法看如何增强的

    /**
     * Loads the specified class and generates a CGLIB subclass of it equipped with
     * container-aware callbacks capable of respecting scoping and other bean semantics.
     * @return the enhanced subclass
     */
    public Class enhance(Class configClass, @Nullable ClassLoader classLoader) {
        if (EnhancedConfiguration.class.isAssignableFrom(configClass)) {
            if (logger.isDebugEnabled()) {
                logger.debug(String.format("Ignoring request to enhance %s as it has " +
                        "already been enhanced. This usually indicates that more than one " +
                        "ConfigurationClassPostProcessor has been registered (e.g. via " +
                        "). This is harmless, but you may " +
                        "want check your configuration and remove one CCPP if possible",
                        configClass.getName()));
            }
            return configClass;
        }
        Class enhancedClass = createClass(newEnhancer(configClass, classLoader));
        if (logger.isTraceEnabled()) {
            logger.trace(String.format("Successfully enhanced %s; enhanced class name is: %s",
                    configClass.getName(), enhancedClass.getName()));
        }
        return enhancedClass;
    }

看这个方法的注释,加载指定的类并生成一个CGLIB代理的子类。源码最重要的一行
Class enhancedClass = createClass(newEnhancer(configClass, classLoader));
首先分析newEnhancer方法:

    /**
     * Creates a new CGLIB {@link Enhancer} instance.
     */
    private Enhancer newEnhancer(Class configSuperClass, @Nullable ClassLoader classLoader) {
        Enhancer enhancer = new Enhancer();
        //把业务类,这里是Config,设置成代理类的父类
        enhancer.setSuperclass(configSuperClass);
        //代理类实现EnhancedConfiguration接口
        enhancer.setInterfaces(new Class[] {EnhancedConfiguration.class});
        enhancer.setUseFactory(false);
        //设置代理类名称的生成策略
        enhancer.setNamingPolicy(SpringNamingPolicy.INSTANCE);
        enhancer.setStrategy(new BeanFactoryAwareGeneratorStrategy(classLoader));
        enhancer.setCallbackFilter(CALLBACK_FILTER);
        enhancer.setCallbackTypes(CALLBACK_FILTER.getCallbackTypes());
        return enhancer;
    }

看注释,生成一个CGLIB代理实例,里面用到了Enhancer ,不就是文章开头讲的那个小demo吧!
然后就是createClass方法:

    /**
     * Uses enhancer to generate a subclass of superclass,
     * ensuring that callbacks are registered for the new subclass.
     */
    private Class createClass(Enhancer enhancer) {
        Class subclass = enhancer.createClass();
        // Registering callbacks statically (as opposed to thread-local)
        // is critical for usage in an OSGi environment (SPR-5932)...
        Enhancer.registerStaticCallbacks(subclass, CALLBACKS);
        return subclass;
    }

通过Enhancer 生成一个所代理的类的子类。代理结束后返回,一直返回到enhanceConfigurationClasses方法的Class enhancedClass = enhancer.enhance(configClass, this.beanClassLoader);,这时候的enhancedClass 就是代理类了,OK,这行代码执行完后往下执行了beanDef.setBeanClass(enhancedClass);,意思很明朗,就是将Config的BeanDefinitino中的class替换成代理class。之后就会实例化代理类而不是Config类本身。

现在解释清楚了,为什么Config加上@Configuration注解后就会被spring动态代理。再解释上文getE()方法在getF()中并没有起作用!很明显,spring既然代理了Config,那么执行getF方法时不是真的执行Config里的getF方法,而是执行代理类的getF方法,在哪里执行的呢?

newEnhancer方法中,有一个过滤器的设置enhancer.setCallbackFilter(CALLBACK_FILTER);,CALLBACK_FILTER是一个变量:

    private static final Callback[] CALLBACKS = new Callback[] {
            new BeanMethodInterceptor(),
            new BeanFactoryAwareMethodInterceptor(),
            NoOp.INSTANCE
    };

    private static final ConditionalCallbackFilter CALLBACK_FILTER = new ConditionalCallbackFilter(CALLBACKS);

文章一开始举的CGLIB案例中,就是通过回调完成了方法的拦截对吧? 这里有两个回调类BeanMethodInterceptor和BeanFactoryAwareMethodInterceptor,他俩组成了一个回调链,依次调用而已。这两个回调其实是在bean的声明周期过程中调用的,这是后续章节的内容,这里我们简单讲下,后面会详细讲。

在实例化过程中,我们主要关注BeanMethodInterceptor这个回调。我们在调用getF方法时,会先执行回调BeanMethodInterceptor中的intercept方法。intercept方法很复杂很复杂,大概意思是,在执行getF中的getE方法时判断getE返回的bean是否已经实例化了,如果已经实例化了就不再调用该方法了。getF和getE调用的时候都是先调用回调函数的,都会判断是否已经实例化了。spring以此保证@Bean返回的实例是单例的。

本篇讲的比较简单比较浅,估计读者也是明白个大概的原理,因为这里涉及到后续的知识,没关系,后面会再详细讲解的。

这里大家主要了解

  1. CGLIB的使用
  2. Spring是如何利用到CGLIB的
  3. 如何使用内置的代理回调类BeanMethodInterceptor、BeanFactoryAwareMethodInterceptor来增强我们的目标类方法的即可。
  4. BeanDefinition将对应的class用代理类替换掉业务类,后期实例化的是代理类

你可能感兴趣的:(逐行阅读Spring5.X源码(九)spring利用CGLIB实现动态代理原理剖析)