在SpringIOC中,我们熟知的BeanScope有单例(singleton)、原型(prototype), Bean的Scope影响了Bean的创建方式,例如创建Scope=singleton的Bean时,IOC会保存实例在一个Map中,保证这个Bean在一个IOC上下文有且仅有一个实例。SpringCloud新增了一个refresh范围的scope,同样用了一种独特的方式改变了Bean的创建方式,使得其可以通过外部化配置(.properties)的刷新,在应用不需要重启的情况下热加载新的外部化配置的值。
那么这个scope是如何做到热加载的呢?RefreshScope主要做了以下动作:
下面我们深入源码,来验证我们上述的讲法。
首先,若想要一个Bean可以自动热加载配置值,这个Bean要被打上@RefreshScope注解,那么就看看这个注解做了什么:
-
@Target({ ElementType.TYPE, ElementType.METHOD })
-
@Retention(RetentionPolicy.RUNTIME)
-
@Scope("refresh")
-
@Documented
-
public
@interface RefreshScope {
-
-
/**
-
* @see Scope#proxyMode()
-
* @return proxy mode
-
*/
-
ScopedProxyMode proxyMode() default ScopedProxyMode.TARGET_CLASS;
-
-
}
可以发现RefreshScope有一个属性 proxyMode=ScopedProxyMode.TARGET_CLASS,这个是AOP动态代理用,之后会再来提这个
可以看出其是一个复合注解,被标注了 @Scope("refresh")
,其将Bean的Scope变为refresh这个类型,在SpringBoot中BootStrap类上打上@SpringBootApplication注解(里面是一个@ComponentScan),就会扫描包中的注解驱动Bean,扫描到打上RefreshScope注解的Bean的时候,就会将其的BeanDefinition的scope变为refresh,这有什么用呢?
创建一个Bean的时候,会去BeanFactory的doGetBean方法创建Bean,不同scope有不同的创建方式:
-
protected
T doGetBean(final String name, @Nullable final Class requiredType,
-
@Nullable
final Object[] args,
boolean typeCheckOnly)
throws BeansException {
-
-
//....
-
-
// Create bean instance.
-
// 单例Bean的创建
-
if (mbd.isSingleton()) {
-
sharedInstance = getSingleton(beanName, () -> {
-
try {
-
return createBean(beanName, mbd, args);
-
}
-
//...
-
});
-
bean = getObjectForBeanInstance(sharedInstance, name, beanName, mbd);
-
}
-
-
// 原型Bean的创建
-
else
if (mbd.isPrototype()) {
-
// It's a prototype -> create a new instance.
-
// ...
-
try {
-
prototypeInstance = createBean(beanName, mbd, args);
-
}
-
//...
-
bean = getObjectForBeanInstance(prototypeInstance, name, beanName, mbd);
-
}
-
-
else {
-
// 由上面的RefreshScope注解可以知道,这里scopeName=refresh
-
String scopeName = mbd.getScope();
-
// 获取Refresh的Scope对象
-
final Scope scope =
this.scopes.get(scopeName);
-
if (scope ==
null) {
-
throw
new IllegalStateException(
"No Scope registered for scope name '" + scopeName +
"'");
-
}
-
try {
-
// 让Scope对象去管理Bean
-
Object scopedInstance = scope.get(beanName, () -> {
-
beforePrototypeCreation(beanName);
-
try {
-
return createBean(beanName, mbd, args);
-
}
-
finally {
-
afterPrototypeCreation(beanName);
-
}
-
});
-
bean = getObjectForBeanInstance(scopedInstance, name, beanName, mbd);
-
}
-
//...
-
}
-
}
-
//...
-
}
-
-
//...
-
}
这里可以看到几件事情:
这里scope.get获取的Scope对象为RefreshScope,可以看到,创建Bean还是由IOC来做(createBean方法),但是获取Bean,都由RefreshScope对象的get方法去获取,其get方法在父类GenericScope中实现:
-
public Object get(String name, ObjectFactory objectFactory) {
-
// 将Bean缓存下来
-
BeanLifecycleWrapper value =
this.cache.put(name,
-
new BeanLifecycleWrapper(name, objectFactory));
-
this.locks.putIfAbsent(name,
new ReentrantReadWriteLock());
-
try {
-
// 创建Bean,只会创建一次,后面直接返回创建好的Bean
-
return value.getBean();
-
}
-
catch (RuntimeException e) {
-
this.errors.put(name, e);
-
throw e;
-
}
-
}
首先这里将Bean包装起来缓存下来
-
private
final ScopeCache cache;
-
// 这里进入上面的 BeanLifecycleWrapper value = this.cache.put(name, new BeanLifecycleWrapper(name, objectFactory));
-
public BeanLifecycleWrapper put(String name, BeanLifecycleWrapper value) {
-
return (BeanLifecycleWrapper)
this.cache.put(name, value);
-
}
这里的ScopeCache对象其实就是一个HashMap:
-
public
class StandardScopeCache implements ScopeCache {
-
-
private
final ConcurrentMap
cache =
new ConcurrentHashMap();
-
-
//...
-
-
public Object get(String name) {
-
return
this.cache.get(name);
-
}
-
-
// 如果不存在,才会put进去
-
public Object put(String name, Object value) {
-
// result若不等于null,表示缓存存在了,不会进行put操作
-
Object result =
this.cache.putIfAbsent(name, value);
-
if (result !=
null) {
-
// 直接返回旧对象
-
return result;
-
}
-
// put成功,返回新对象
-
return value;
-
}
-
}
这里就是将Bean包装成一个对象,缓存在一个Map中,下次如果再GetBean,还是那个旧的BeanWrapper。回到Scope的get方法,接下来就是调用BeanWrapper的getBean方法:
-
// 实际Bean对象,缓存下来了
-
private Object bean;
-
-
public Object getBean() {
-
if (
this.bean ==
null) {
-
synchronized (
this.name) {
-
if (
this.bean ==
null) {
-
this.bean =
this.objectFactory.getObject();
-
}
-
}
-
}
-
return
this.bean;
-
}
可以看出来,BeanWrapper中的bean变量即为实际Bean,如果第一次get肯定为空,就会调用BeanFactory的createBean方法创建Bean,创建出来之后就会一直保存下来。
由此可见,RefreshScope管理了Scope=Refresh的Bean的生命周期。
当配置中心刷新配置之后,有两种方式可以动态刷新Bean的配置变量值,(SpringCloud-Bus还是Nacos差不多都是这么实现的):
/refresh
这个EndPoint不管是什么方式,最终都会调用ContextRefresher
这个类的refresh方法,那么我们由此为入口来分析一下,热加载配置的原理:
我们一般是使用@Value、@ConfigurationProperties去获取配置变量值,其底层在IOC中则是通过上下文的Environment对象去获取property值,然后依赖注入利用反射Set到Bean对象中去的。
那么如果我们更新Environment里的Property值,然后重新创建一次RefreshBean,再进行一次上述的依赖注入,是不是就能完成配置热加载了呢?@Value的变量值就可以加载为最新的了。
这里说的刷新Environment对象并重新依赖注入则为上述两个方法做的事情:
下面简单介绍一下如何刷新Environment里的Property值
-
public synchronized Set
refreshEnvironment() {
-
// 获取刷新配置前的配置信息,对比用
-
Map
before = extract(
-
this.context.getEnvironment().getPropertySources());
-
// 刷新Environment
-
addConfigFilesToEnvironment();
-
// 这里上下文的Environment已经是新的值了
-
// 进行新旧对比,结果返回有变化的值
-
Set
keys = changes(before,
-
extract(
this.context.getEnvironment().getPropertySources())).keySet();
-
this.context.publishEvent(
new EnvironmentChangeEvent(
this.context, keys));
-
return keys;
-
}
我们的重点在addConfigFilesToEnvironment方法,刷新Environment:
-
ConfigurableApplicationContext addConfigFilesToEnvironment() {
-
ConfigurableApplicationContext capture =
null;
-
try {
-
// 从上下文拿出Environment对象,copy一份
-
StandardEnvironment environment = copyEnvironment(
-
this.context.getEnvironment());
-
// SpringBoot启动类builder,准备新做一个Spring上下文启动
-
SpringApplicationBuilder builder =
new SpringApplicationBuilder(Empty.class)
-
// banner和web都关闭,因为只是想单纯利用新的Spring上下文构造一个新的Environment
-
.bannerMode(Mode.OFF).web(WebApplicationType.NONE)
-
// 传入我们刚刚copy的Environment实例
-
.environment(environment);
-
// 启动上下文
-
capture = builder.run();
-
// 这个时候,通过上下文SpringIOC的启动,刚刚Environment对象就变成带有最新配置值的Environment了
-
// 获取旧的外部化配置列表
-
MutablePropertySources target =
this.context.getEnvironment()
-
.getPropertySources();
-
String targetName =
null;
-
// 遍历这个最新的Environment外部化配置列表
-
for (PropertySource source : environment.getPropertySources()) {
-
String name = source.getName();
-
if (target.contains(name)) {
-
targetName = name;
-
}
-
// 某些配置源不做替换,读者自行查看源码
-
// 一般的配置源都会进入
if语句
-
if (!
this.standardSources.contains(name)) {
-
if (target.contains(name)) {
-
// 用新的配置替换旧的配置
-
target.replace(name, source);
-
}
-
else {
-
//....
-
}
-
}
-
}
-
}
-
//....
-
}
可以看到,这里归根结底就是SpringBoot启动上下文那种方法,新做了一个Spring上下文,因为Spring启动后会对上下文中的Environment进行初始化,获取最新配置,所以这里利用Spring的启动,达到了获取最新的Environment对象的目的。然后去替换旧的上下文中的Environment对象中的配置值即可。
经过上述刷新Environment对象的动作,此时上下文中的配置值已经是最新的了。思路回到ContextRefresher
的refresh方法,接下来会调用Scope对象的refreshAll方法:
-
public void refreshAll() {
-
// 销毁Bean
-
super.destroy();
-
this.context.publishEvent(
new RefreshScopeRefreshedEvent());
-
}
-
-
public void destroy() {
-
List
errors =
new ArrayList();
-
// 缓存清空
-
Collection
wrappers =
this.cache.clear();
-
// ...
-
}
还记得上面的管理RefreshBean生命周期那一节关于缓存的讨论吗,cache变量是一个Map保存着RefreshBean实例,这里直接就将Map清空了。
思路回到BeanFactory的doGetBean的流程中,从IOC容器中获取RefreshBean是交给RefreshScope的get方法做的:
-
public Object getBean() {
-
// 由于是新的BeanLifecycleWrapper实例,这里一定为null
-
if (
this.bean ==
null) {
-
synchronized (
this.name) {
-
if (
this.bean ==
null) {
-
// 调用IOC容器的createBean,再创建一个Bean出来
-
this.bean =
this.objectFactory.getObject();
-
}
-
}
-
}
-
return
this.bean;
-
}
可以看到,此时RefreshBean被IOC容器重新创建一个出来了,经过IOC的依赖注入功能,@Value的就是一个新的配置值了。到这里热加载功能实现基本结束。
根据以上分析,我们可以看出只要每次我们都从IOC容器中getBean,那么拿到的RefreshBean一定是带有最新配置值的Bean。
在我们正常使用@RefreshScope的时候,也没有做一些getBean的操作,为什么也可以动态刷新呢?因为Spring利用AOP动态代理了原先的Bean,在调用Bean的方法前,会拦截并从IOC容器中getBean,然后针对返回的新Bean做方法调用,这样就达到了使用的配置值一直是最新的效果了。下面我们来分析分析这AOP动态代理的过程。
在本人另一篇文章, SpringBoot自动装配的魔法 中有讲到,SpringBoot的注解驱动注册Bean是由ConfigurationClassPostProcessor类来做的,其中@ComponentScan会扫描并注册包下带有@Componet注解的类为Bean,达到一个注解驱动注册Bean的效果。而扫描Bean并注册为BeanDefinition这一过程是由ClassPathBeanDefinitionScanner类的doScan方法去做的,我们先来看看扫描Bean的时候,对于RefreshScope的Bean有什么特殊处理:
-
protected Set
doScan(String... basePackages) {
-
Assert.notEmpty(basePackages,
"At least one base package must be specified");
-
Set
beanDefinitions =
new LinkedHashSet<>();
-
// 扫描basePackages所在的包下的所有的类,带@Componet的类都会被注册为BeanDefinition
-
for (String basePackage : basePackages) {
-
//...
-
if (checkCandidate(beanName, candidate)) {
-
BeanDefinitionHolder definitionHolder =
new BeanDefinitionHolder(candidate, beanName);
-
// 这里就是Scope的Bean的统一处理,是一个改变BeanDefinition的回调机会
-
definitionHolder =
-
AnnotationConfigUtils.applyScopedProxyMode(scopeMetadata, definitionHolder,
this.registry);
-
beanDefinitions.add(definitionHolder);
-
// 注册BeanDefinition到IOC容器中
-
registerBeanDefinition(definitionHolder,
this.registry);
-
}
-
}
-
}
-
return beanDefinitions;
-
}
其中关键在于AnnotationConfigUtils的applyScopedProxyMode方法:
-
static BeanDefinitionHolder applyScopedProxyMode(
-
ScopeMetadata metadata, BeanDefinitionHolder definition, BeanDefinitionRegistry registry) {
-
// 获取Scope的代理模式
-
ScopedProxyMode scopedProxyMode = metadata.getScopedProxyMode();
-
// 如果代理模式为NO,就不进行代理了
-
if (scopedProxyMode.equals(ScopedProxyMode.NO)) {
-
return definition;
-
}
-
boolean proxyTargetClass = scopedProxyMode.equals(ScopedProxyMode.TARGET_CLASS);
-
// 进行代理
-
return ScopedProxyCreator.createScopedProxy(definition, registry, proxyTargetClass);
-
}
回顾开头分析的@RefreshScope注解,其proxyMode值为ScopedProxyMode.TARGET_CLASS
-
public
@interface RefreshScope {
-
-
/**
-
* @see Scope#proxyMode()
-
* @return proxy mode
-
*/
-
ScopedProxyMode proxyMode() default ScopedProxyMode.TARGET_CLASS;
-
}
所以这里被打上@RefreshScope的Bean类会进入接下来ScopedProxyCreator的createScopedProxy方法:
-
public static BeanDefinitionHolder createScopedProxy(
-
BeanDefinitionHolder definitionHolder, BeanDefinitionRegistry registry, boolean proxyTargetClass) {
-
-
return ScopedProxyUtils.createScopedProxy(definitionHolder, registry, proxyTargetClass);
-
}
-
public static BeanDefinitionHolder createScopedProxy(BeanDefinitionHolder definition,
-
BeanDefinitionRegistry registry, boolean proxyTargetClass) {
-
-
// ...
-
-
// Create a scoped proxy definition for the original bean name,
-
// "hiding" the target bean in an internal target definition.
-
// 重点,这里构造函数中将beanClass设置为了ScopedProxyFactoryBean.class
-
RootBeanDefinition proxyDefinition =
new RootBeanDefinition(ScopedProxyFactoryBean.class);
-
// targetDefinition是被代理的原生Bean
-
proxyDefinition.setDecoratedDefinition(
new BeanDefinitionHolder(targetDefinition, targetBeanName));
-
-
// ...
-
-
// Return the scoped proxy definition as primary bean definition
-
// (potentially an inner bean).
-
return
new BeanDefinitionHolder(proxyDefinition, originalBeanName, definition.getAliases());
-
}
这里一堆构建BeanDefinition的逻辑,先不看,只关注一件事,这里将BeanDefinition的beanClass设置为了ScopedProxyFactoryBean.class,而Scope的通用处理类GenericScope类是一个BeanDefinitionRegistryPostProcessor,其在postProcessBeanDefinitionRegistry回调方法中会针对刚刚那个beanClass为ScopedProxyFactoryBean.class的BeanDefinition做一个特殊的处理:
-
// GenericScope.class
-
public void postProcessBeanDefinitionRegistry(BeanDefinitionRegistry registry)
-
throws BeansException {
-
// 获取所有BeanDefinition的名称
-
for (String name : registry.getBeanDefinitionNames()) {
-
BeanDefinition definition = registry.getBeanDefinition(name);
-
// 针对RootBeanDefinition这个BeanDefinition来做,这和上面的逻辑吻合
-
if (definition
instanceof RootBeanDefinition) {
-
RootBeanDefinition root = (RootBeanDefinition) definition;
-
// 判断BeanClass == ScopedProxyFactoryBean.class
-
if (root.getDecoratedDefinition() !=
null && root.hasBeanClass()
-
&& root.getBeanClass() == ScopedProxyFactoryBean.class) {
-
if (getName().equals(root.getDecoratedDefinition().getBeanDefinition()
-
.getScope())) {
-
// 将BeanClass换为LockedScopedProxyFactoryBean
-
root.setBeanClass(LockedScopedProxyFactoryBean.class);
-
root.getConstructorArgumentValues().addGenericArgumentValue(
this);
-
// surprising that a scoped proxy bean definition is not already
-
// marked as synthetic?
-
root.setSynthetic(
true);
-
}
-
}
-
}
-
}
-
}
到这里可以知道,GenericScope将ScopeBean,变为LockedScopedProxyFactoryBean这个类
然而这个类又是一个FactoryBean,由其父类ScopedProxyFactoryBean的getObject方法实现FactoryBean接口,我们知道,创建一个FactoryBean,其实最终会调用其getObject方法,这个方法的返回值才是最终被创建出来的Bean实例,所以我们的重点就在getObject方法中:
-
public Object getObject() {
-
if (
this.proxy ==
null) {
-
throw
new FactoryBeanNotInitializedException();
-
}
-
return
this.proxy;
-
}
似乎早就被动态代理好了,全局搜索proxy变量在哪里被赋值。可以发现,ScopedProxyFactoryBean还是一个BeanFactoryAware,其setBeanFactory会在比较早的时机被回调:
-
public void setBeanFactory(BeanFactory beanFactory) {
-
-
// ...
-
-
// 这里是一个比较关键的点,scopedTargetSource变量是一个SimpleBeanTargetSource
-
// scopedTargetSource中保存了IOC容器
-
this.scopedTargetSource.setBeanFactory(beanFactory);
-
-
// 创建动态代理前,将动态代理的信息都保存到ProxyFactory中
-
ProxyFactory pf =
new ProxyFactory();
-
pf.copyFrom(
this);
-
// 注意,这里的TargetSource就是刚刚说的scopedTargetSource
-
pf.setTargetSource(
this.scopedTargetSource);
-
-
// ...
-
-
this.proxy = pf.getProxy(cbf.getBeanClassLoader());
-
}
这里先记住,scopedTargetSource是SimpleBeanTargetSource这个类就行,其保存了IOC容器。
接着调用pf的getProxy方法开始进行动态代理
下面就是AOP的一些逻辑了,不是本篇文章讨论的重点,一笔带过
-
private Callback[] getCallbacks(Class rootClass)
throws Exception {
-
-
// ...
-
-
// Choose an "aop" interceptor (used for AOP calls).
-
// 这里的MethodInterceptor实例是DynamicAdvisedInterceptor这个类
-
Callback aopInterceptor =
new DynamicAdvisedInterceptor(
this.advised);
-
-
// ...
-
return callbacks;
-
}
我们知道,CGLib动态代理都会实现一个MethodInterceptor,被代理的类的每一个方法调用实质上都是在调用MethodInterceptor的intercept方法,那么我们看看DynamicAdvisedInterceptor这个类的intercept方法:
-
public Object intercept(Object proxy, Method method, Object[] args, MethodProxy methodProxy) throws Throwable {
-
// 记得吗,刚刚我们反复强调的TargetSource
-
TargetSource targetSource =
this.advised.getTargetSource();
-
try {
-
// ...
-
// Get as late as possible to minimize the time we "own" the target, in case it comes from a pool...
-
// 重点,这里调用了targetSource的getTarget
-
// target变量就是被代理的类,调用实际方法的时候反射调用其对应方法
-
target = targetSource.getTarget();
-
// ...
-
if (chain.isEmpty() && Modifier.isPublic(method.getModifiers())) {
-
// ...
-
// target变量就是被代理的类,调用实际方法的时候反射调用其对应方法
-
retVal = methodProxy.invoke(target, argsToUse);
-
}
-
else {
-
// We need to create a method invocation...
-
// target变量就是被代理的类,调用实际方法的时候反射调用其对应方法
-
retVal =
new CglibMethodInvocation(proxy, target, method, args, targetClass, chain, methodProxy).proceed();
-
}
-
// target变量就是被代理的类,调用实际方法的时候反射调用其对应方法
-
retVal = processReturnType(proxy, target, method, retVal);
-
return retVal;
-
}
-
// ...
-
}
直接看重点,targetSource的getTarget()方法的返回值是被代理的类,那么这个getTarget做了什么逻辑呢?回顾上面来看我们知道这里TargetSource的实现类是SimpleBeanTargetSource:
-
public
class SimpleBeanTargetSource extends AbstractBeanFactoryBasedTargetSource {
-
-
@Override
-
public Object getTarget() throws Exception {
-
// 从IOC中getBean
-
return getBeanFactory().getBean(getTargetBeanName());
-
}
-
}
到这里就已经揭晓了答案,原来被打上@RefreshScope的Bean都会被Spring做AOP动态代理,每次调用方法之前,都会去IOC中调用getBean方法获取真正的原始Bean,而原始Bean又被存放在GenericScope对象中的Map里,在refresh刷新配置的时候会清空缓存Map,在刷新配置的时候,调用类方法前去IOC获取Bean,然后到GenericScope查看缓存,发现没有这个Bean缓存就会重新从IOC容器创建一份Bean,依赖注入配置属性值的时候注入的就是最新的值了,这样就能达到动态刷新的作用。
大部分场景下RefreshBean动态刷新是不会失效的,但是笔者在使用WebFlux的时候,用到WebFilter过滤器时出现了失效的问题。这里从现象看本质,如果你的应用Refresh也失效了,大概率也是跟我差不多问题,知道了原理,解决这个问题会变得十分简单。
这里重点要看你的Bean是如何被加载使用的,这里看看常见的两个方式是如何使用的:
-
@RestController
-
@RefreshScope
-
public
class TestController {
-
-
@Value("${test.refresh}")
-
private
boolean test;
-
-
@GetMapping("/get/refresh/test/value")
-
public boolean test() {
-
return test;
-
}
-
-
}
涉及一些SpringMVC的知识,这里默认读者具有SpringMVC的相关知识
我们写的Controller都会被DispatcherServlet进行路由,而这种路径的路由@RequestMapping这种方式则是由RequestMappingHandlerMapping这个类去找到对应的controller方法,通过反射调用方法从而调用我们上面的test方法,那么就肯定要拿到TestController这个类,这个操作是由其父类AbstractHandlerMethodMapping的getHandlerInternal方法做的:
-
protected HandlerMethod getHandlerInternal(HttpServletRequest request) throws Exception {
-
String lookupPath = getUrlPathHelper().getLookupPathForRequest(request);
-
this.mappingRegistry.acquireReadLock();
-
try {
-
// 根据请求拿到需要反射调用的方法
-
HandlerMethod handlerMethod = lookupHandlerMethod(lookupPath, request);
-
// 关键:handlerMethod.createWithResolvedBean()获取调用方法的类
-
return (handlerMethod !=
null ? handlerMethod.createWithResolvedBean() :
null);
-
}
-
finally {
-
this.mappingRegistry.releaseReadLock();
-
}
-
}
这里直接看handlerMethod的关键方法createWithResolvedBean:
-
public HandlerMethod createWithResolvedBean() {
-
Object handler =
this.bean;
-
if (
this.bean
instanceof String) {
-
Assert.state(
this.beanFactory !=
null,
"Cannot resolve bean name without BeanFactory");
-
String beanName = (String)
this.bean;
-
// 会使用testController这个beanName获取Bean
-
handler =
this.beanFactory.getBean(beanName);
-
}
-
return
new HandlerMethod(
this, handler);
-
}
如果Controller被打上@RefreshScope注解,这里getBean的返回值就是CGLib动态代理对象,根据以上流程走自然可以达到动态刷新的效果
-
@Component
-
public
class Test {
-
-
@Autowired
-
private PropertiesSource propertiesSource;
-
-
public boolean test(){
-
propertiesSource.getValue();
-
}
-
}
-
-
@Service
-
@RefreshScope
-
public
class PropertiesSource {
-
-
@Value("${test.refresh}")
-
private
boolean test;
-
-
public boolean getValue(){
-
return test;
-
}
-
}
这样使用也可以达到动态刷新的作用,Test类依赖注入PropertiesSource对象时会注入CGLib动态代理对象。
从上面两个使用场景来看,RefreshBean被正确加载为CGLib动态代理对象就能正常动态刷新,那么什么时候会不正常加载呢?这里举一个我在3.2小节开头举的例子,WebFilter。
在WebFlux中,组装WebFilter是在WebHttpHandlerBuilder类的applicationContext方法中:
-
public static WebHttpHandlerBuilder applicationContext(ApplicationContext context) {
-
WebHttpHandlerBuilder builder =
new WebHttpHandlerBuilder(
-
context.getBean(WEB_HANDLER_BEAN_NAME, WebHandler.class), context);
-
-
// 获取上下文中 Class为WebFilter的所有Bean
-
List
webFilters = context
-
.getBeanProvider(WebFilter.class)
-
.orderedStream()
-
.collect(Collectors.toList());
-
builder.filters(filters -> filters.addAll(webFilters));
-
-
//...
-
-
return builder;
-
}
这里组装加载WebFilter的时候会获取IOC中WebFilter类型的Bean,这里我Debug给大家看看这个List列表
怎么会有两个重复的呢?
思路回到第三节讨论的扫描并注册Bean入口doScan中的createScopedProxy方法,其中针对特定Scope做一个BeanDefinition的修改:
-
public
static BeanDefinitionHolder createScopedProxy(BeanDefinitionHolder definition,
-
BeanDefinitionRegistry registry,
boolean proxyTargetClass) {
-
-
// 原始Bean的名称
-
String originalBeanName = definition.getBeanName();
-
BeanDefinition targetDefinition = definition.getBeanDefinition();
-
// 加了前缀的Bean名称
-
String targetBeanName = getTargetBeanName(originalBeanName);
-
-
// ...
-
-
// Register the target bean as separate bean in the factory.
-
// 这里会注册原始Bean,以targetBeanName为beanName
-
registry.registerBeanDefinition(targetBeanName, targetDefinition);
-
-
// Return the scoped proxy definition as primary bean definition
-
// (potentially an inner bean).
-
// 注册会生成代理Bean的FactoryBean
-
return
new BeanDefinitionHolder(proxyDefinition, originalBeanName, definition.getAliases());
-
}
可以看到,其实这里依然会将原生Bean注册到IOC容器中,只不过beanName是被加了前缀的,这里我debug看看加了什么前缀(假设我的beanName是gatewayPropertiesSource)
可以看到,这里注册了两个Bean,一个是原始名称的FactoryBean,用于生成CGLib的动态代理Bean,一个是被加上 scopedTarget. 前缀的原生Bean,为什么要注册两个Bean呢?因为后面一个Bean是被Scope对象的Map缓存所管理的,后面那个Bean则是我们的Bean本尊,动态代理Bean调用方法要获取的Bean就是这个对象,从哪里可以看出来呢?回顾3.1节的最后,getObject关键方法:
-
public
class SimpleBeanTargetSource extends AbstractBeanFactoryBasedTargetSource {
-
-
@Override
-
public Object getTarget() throws Exception {
-
// getTargetBeanName,这里是加了前缀的名称
-
return getBeanFactory().getBean(getTargetBeanName());
-
}
-
}
到这里我们可以知道,其实这个加了前缀的Bean才是我们最终使用的Bean,配置动态刷新的时候变的不是CGLib动态代理的Bean,而是里面加了前缀的Bean,这个Bean被Scope对象的Map所管理,当配置刷新时Map清空,动态代理的Bean调用方法之前先去IOC中获取加了前缀的Bean,这个加了前缀的Bean又是refresh的scope,又会去Scope中的Map寻找,发现找不到,就又在IOC容器中创建一个新的加了前缀的Bean,供后续使用,达到动态刷新的效果。
回到我们3.2.3节开头讲的失效问题,这里组装WebFilter的时候由于会获取类型为WebFilter的所有Bean,所以会把动态代理的Bean和前缀Bean全组装起来,在我们Web应用里就会使用到前缀Bean本尊,由于这个Bean不像那个动态代理Bean一样,每一次方法调用都会去IOC容器getBean,所以这个Bean是一成不变的,就算配置刷新,这个Bean实例还是那个旧的值,导致失效问题。
我们知道,如果是@RefreshScope的话,每次都要去IOC获取一下Bean,感觉调用链路比较长,那么是否能不打@RefreshScope也能动态刷新属性值呢?这里还有一种方式达到动态刷新的目的,那就是@ConfigurationProperties注解,具体用法不过多赘述,这里详细讲讲ConfigurationProperties是如何做到动态刷新的。
思路回到我们第二节讲的,ContextRefresher这个类,当配置刷新的时候,这个类的refresh方法会被调用:
-
public synchronized Set
refresh() {
-
// 刷新环境
-
Set
keys = refreshEnvironment();
-
this.scope.refreshAll();
-
return keys;
-
}
关键在refreshEnvironment方法:
-
public synchronized Set
refreshEnvironment() {
-
Map
before = extract(
-
this.context.getEnvironment().getPropertySources());
-
addConfigFilesToEnvironment();
-
Set
keys = changes(before,
-
extract(
this.context.getEnvironment().getPropertySources())).keySet();
-
// 发布一个EnvironmentChangeEvent事件
-
this.context.publishEvent(
new EnvironmentChangeEvent(
this.context, keys));
-
return keys;
-
}
熟悉的方法,这里我们的关注点在于其最后会发布一个EnvironmentChangeEvent事件,这个事件是由ConfigurationPropertiesRebinder这个类来监听的,看名字就知道,这个类负责重新设置ConfigurationProperties值。重点关注这个类的onApplicationEvent方法:
-
public void onApplicationEvent(EnvironmentChangeEvent event) {
-
if (
this.applicationContext.equals(event.getSource())
-
// Backwards compatible
-
|| event.getKeys().equals(event.getSource())) {
-
// 重新设置值
-
rebind();
-
}
-
}
在这个方法消费EnvironmentChangeEvent这个事件,进入rebind方法:
-
public void rebind() {
-
this.errors.clear();
-
// beans保存着所有ConfigurationProperties实例
-
for (String name :
this.beans.getBeanNames()) {
-
rebind(name);
-
}
-
}
beans实则是一个Map,我们直接debug看看这个Map保存了什么
可以看到,这里保存了54个ConfigurationProperties类实例,其中我们的ConfigurationProperties类就是上面的greyProperties
继续往下走,看看rebind对这个实例做了什么:
-
public boolean rebind(String name) {
-
//...
-
if (
this.applicationContext !=
null) {
-
try {
-
// 从上下文中获取这个Bean
-
Object bean =
this.applicationContext.getBean(name);
-
if (AopUtils.isAopProxy(bean)) {
-
bean = ProxyUtils.getTargetObject(bean);
-
}
-
if (bean !=
null) {
-
// TODO: determine a more general approach to fix this.
-
// see https://github.com/spring-cloud/spring-cloud-commons/issues/571
-
if (getNeverRefreshable().contains(bean.getClass().getName())) {
-
return
false;
// ignore
-
}
-
// 调用这个Bean的destroy流程
-
this.applicationContext.getAutowireCapableBeanFactory()
-
.destroyBean(bean);
-
// 调用这个Bean的初始化流程
-
this.applicationContext.getAutowireCapableBeanFactory()
-
.initializeBean(bean, name);
-
return
true;
-
}
-
}
-
//...
-
}
-
return
false;
-
}
重点在于调用上下文的initializeBean方法初始化Bean:
-
protected Object initializeBean(final String beanName, final Object bean, @Nullable RootBeanDefinition mbd) {
-
-
//...
-
-
// 调用aware回调
-
invokeAwareMethods(beanName, bean);
-
-
Object wrappedBean = bean;
-
if (mbd ==
null || !mbd.isSynthetic()) {
-
// 重点,调用BeanPostProcessors回调
-
wrappedBean = applyBeanPostProcessorsBeforeInitialization(wrappedBean, beanName);
-
}
-
-
//...
-
-
return wrappedBean;
-
}
其中的重点在于applyBeanPostProcessorsBeforeInitialization方法:
-
public Object applyBeanPostProcessorsBeforeInitialization(Object existingBean, String beanName)
-
throws BeansException {
-
-
Object result = existingBean;
-
// BeanPostProcessor的回调
-
for (BeanPostProcessor processor : getBeanPostProcessors()) {
-
Object current = processor.postProcessBeforeInitialization(result, beanName);
-
if (current ==
null) {
-
return result;
-
}
-
result = current;
-
}
-
return result;
-
}
在BeanPostProcessor的回调中,会有一个ConfigurationPropertiesBindingPostProcessor这个BeanPostProcessor在postProcessBeforeInitialization方法中利用Binder对象,将最新的配置值反射调用set方法注入到ConfigurationProperties这样的Bean里,达到动态刷新的效果。这里限于篇幅问题,就不继续深入研究了,感兴趣的小伙伴可以跟着思路去看看源码。
这里我们看到,ConfigurationProperties这种方式不需要一直去IOC容器里getBean,也不需要动态代理,没有以上那样的失效问题,从始至终就只有一个Bean的单例,这种方式个人感觉比较优雅,建议最好使用这种方式去装配外部化配置信息。
但有些场景又需要@RefreshScope这种方式,因为@Value可以解析一些复杂的表达式,比如设置默认值,或者把配置值处理成一个List比较方便:
总之,@Value这种比较灵活,但如果配置值多了,比如外部化配置有几十个,ConfigurationProperties又比较好了,只需要写一个前缀就可以装配前缀下的所有外部化配置。两者各有好处,但建议最好优先考虑一下ConfigurationProperties,使用@RefreshScope也可以,知道原理也就能避免一些失效问题了。
我们总结一下,当不正常获取RefreshScope的Bean时,动态刷新会失效。例如直接从IOC容器中获取所有某类型的Bean,把beanName带前缀的那个Bean直接拿来使用了。到此,我们可以知道只有使用被动态代理增强过的那个Bean,才可以有动态刷新的效果。
3.2.3节这种WebFilter这种情况告诉我们,不要在这种方式加载使用Bean的地方用@RefreshScope,会导致Filter链重复,你会得到两个一摸一样的Filter并且还不知道,潜在影响性能。解决方法就是把要动态刷新的配置值抽出来变成一个类,在这个类上打上@RefreshScope注解,然后在WebFilter中使用@Autowired这种方式依赖注入刚刚那个配置值的专门类,很好的解决了失效问题。