前面花了大量篇幅讲解spring如何完成扫描注册的。注意，此时的注册是将业务类class所对应的BeanDefinition，要想使用业务类的功能，必须先实例化。spring肯定不会直接new一个业务对象来管理，spring是通过动态代理技术完成业务类的实例化。
什么是CGLIB
CGLIB（Code Generator Library）是一个强大的、高性能的代码生成库。其被广泛应用于AOP框架（Spring、dynaop）中，用以提供方法拦截操作。CGLIB代理主要通过对字节码的操作，为对象引入间接级别，以控制对象的访问。我们知道Java中有一个动态代理也是做这个事情的，那我们为什么不直接使用Java动态代理，而要使用CGLIB呢？答案是CGLIB相比于JDK动态代理更加强大，JDK动态代理虽然简单易用，但是其有一个致命缺陷是，只能对接口进行代理。如果要代理的类为一个普通类、没有接口，那么Java动态代理就没法使用了。
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返回的实例是单例的。
本篇讲的比较简单比较浅，估计读者也是明白个大概的原理，因为这里涉及到后续的知识，没关系，后面会再详细讲解的。
这里大家主要了解
- CGLIB的使用
- Spring是如何利用到CGLIB的
- 如何使用内置的代理回调类BeanMethodInterceptor、BeanFactoryAwareMethodInterceptor来增强我们的目标类方法的即可。
- BeanDefinition将对应的class用代理类替换掉业务类，后期实例化的是代理类