浅谈BeanPostProcessor加载次序及其对Bean造成的影响分析
作者：不动明王1984 发布时间：2022-05-02 19:52:29
前言
BeanPostProcessor是一个工厂钩子，允许Spring框架在新创建Bean实例时对其进行定制化修改。例如：通过检查其标注的接口或者使用代理对其进行包裹。应用上下文会从Bean定义中自动检测出BeanPostProcessor并将它们应用到随后创建的任何Bean上。
普通Bean对象的工厂允许在程序中注册post-processors，应用到随后在本工厂中创建的所有Bean上。典型的场景如：post-processors使用postProcessBeforeInitialization方法通过特征接口或其他类似的方式来填充Bean；而为创建好的Bean创建代理则一般使用postProcessAfterInitialization方法。
BeanPostProcessor本身也是一个Bean，一般而言其实例化时机要早过普通的Bean，但是BeanPostProcessor也会依赖一些Bean，这就导致了一些Bean的实例化早于BeanPostProcessor，由此会导致一些问题。最近在处理shiro和spring cache整合时就碰到了，导致的结果就是spring cache不起作用。现将问题场景、查找历程及解决方法展现一下。
1 问题场景
打算在项目中将shiro与spring cache整合，使用spring cache统一管理缓存，也包括shiro认证时的用户信息查询。项目中将service分层，outter层负责权限和session，inner层主打事务和缓存并与DAO交互，两层之间也可以较容易的扩展为RPC或微服务模式。因此在shiro的authRealm中依赖了innerUserService，并在innerUserService中配置了spring cache的标注，使用cache进行缓存。配置如下（摘录重要部分）：
@Bean(name="shiroFilter")
public ShiroFilterFactoryBean shiroFilter(
@Qualifier("securityManager") SecurityManager manager
) {
ShiroFilterFactoryBean bean=new ShiroFilterFactoryBean();
bean.setSecurityManager(manager);
..............
return bean;
}
//配置核心安全事务管理器
@Bean(name="securityManager")
public SecurityManager securityManager(@Qualifier("authRealm") AuthorizingRealm authRealm,
@Qualifier("sessionManager") SessionManager sessionManager,
@Qualifier("cookieRememberMeManager") RememberMeManager rememberMeManager,
@Qualifier("cacheManager") CacheManager cacheManager) {
System.err.println("--------------shiro已经加载----------------");
DefaultWebSecurityManager manager=new DefaultWebSecurityManager();
manager.setRealm(authRealm);
manager.setSessionManager(sessionManager);
manager.setRememberMeManager(rememberMeManager);
manager.setCacheManager(cacheManager);
return manager;
}
//配置自定义权限登录器
@Bean(name="authRealm")
public AuthorizingRealm authRealm(IInnerUserService userService) {
MyRealm myrealm = new MyRealm(IInnerUserService);
logger.info("authRealm myRealm initiated!");
return myrealm;
}
@Bean
public LifecycleBeanPostProcessor lifecycleBeanPostProcessor(){
return new LifecycleBeanPostProcessor(Ordered.LOWEST_PRECEDENCE);
}
其中MyRealm是自定义的shiro AuthorizingRealm，用于执行认证与授权，其实现依赖innerUserService从库中查找用户信息，示例代码如下：
public class MyRealm extends AuthorizingRealm {
IInnerUserService userService;
public MyRealm(){
super();
}
public MyRealm(IInnerUserService userService){
this.userService = userService;
}
public IInnerUserService getUserService() {
return userService;
}
public void setUserService(IInnerUserService userService) {
this.userService = userService;
}
@Override
protected AuthorizationInfo doGetAuthorizationInfo(
PrincipalCollection principals) {
//null usernames are invalid
if (principals == null) {
throw new AuthorizationException("PrincipalCollection method argument cannot be null.");
}
Set<String> roleNames = new HashSet<String>();
Set<String> permissions = new HashSet<String>();
User user = (User)getAvailablePrincipal(principals);
roleNames.add("role1");
roleNames.add("role2");
permissions.add("user:create");
permissions.add("user:update");
permissions.add("user:delete");
SimpleAuthorizationInfo info = new SimpleAuthorizationInfo(roleNames);
info.setStringPermissions(permissions);
return info;
}
@Override
protected AuthenticationInfo doGetAuthenticationInfo(
AuthenticationToken token) throws AuthenticationException {
String username = (String)token.getPrincipal(); //得到用户名
String password = new String((char[])token.getCredentials()); //得到密码
User user = userService.findByUsernameInner(username);
if(user==null){
throw new UnknownAccountException();
}else if(!password.equals(user.getPassword()))
{
throw new IncorrectCredentialsException();
}
else{
return new SimpleAuthenticationInfo(user, password, getName());
}
}
}
而在innerUserService中配置了spring cache的标注，示例代码如下：
@Service
public class IInnerUserServiceImpl implements IInnerUserService {
Logger logger = LoggerFactory.getLogger(IInnerUserServiceImpl.class);
@Autowired
IUserDao userDao;
@Override
@Cacheable(value = "mycache", key = "#username")
public User findByUsernameInner(String username) {
User user = userDao.findByUsername(username);
logger.info("Real execute find from database, username:{}", username);
return user;
}
}
并在配置文件上标注了@EnableCaching(mode=AdviceMode.PROXY)以启动spring cache。这里不过多解释具体shiro和spring cache的使用，有兴趣的同学请自行搜索相关资料。
按理说这样的配置在认证的时候应该可以直接使用到innerUserService中配置的spring cache缓存。
但，问题出现了，当authRealm中依赖了innerUserService以后，定义在innerUserService上的spring cache就神奇的失效了。而authRealm不依赖innerUserService的时候，cache却运行的好好的。
接下来是问题查找的路径。
2 解决问题之旅
2.1 spring cache失效的表象原因
首先要找到spring cache失效的表象/直接原因，我们知道spring cache使用Spring AOP和 * 的方式拦截定义了特定标注的方法，然后执行特定逻辑。因此其实现依赖于 * 机制auto-proxy，而经过初步调试发现，当被authRealm依赖以后，innerUserService就不会被代理了，因此无从进入AOP的pointcut，也就是说AOP切面失效了！
2.2 从spring cache的集成机制分析深层次原因
为何没有被代理呢，我们先来确认一下正常情况下什么时候进行代理封装，这时关于BeanPostProcessor的定义浮现脑海，据文档记载BeanPostProcessor允许在Bean实例化的前后对其做一些猥琐的事情，比如代理。我们在BeanPostProcessor的实现类中发现了InstantiationAwareBeanPostProcessor、SmartInstantiationAwareBeanPostProcessor、AbstractAutoProxyCreator、InfrastructureAdvisorAutoProxyCreator这一脉。而反观@enableCache标注在启动的时候会@import CachingConfigurationSelector，其selectImports方法会返回AutoProxyRegistrar和ProxyCachingConfiguration的全类名（我们定义了mode=AdviceMode.PROXY），也就是加载这两个类。第一个的作用就是注册InfrastructureAdvisorAutoProxyCreator到BeanDefinitionRegistry中。第二个的作用就是注册了BeanFactoryCacheOperationSourceAdvisor和CacheInterceptor。
因此，当正常情况下，一个添加了spring cache相关标注的bean会在创建后被InfrastructureAdvisorAutoProxyCreator基于advisor进行代理增强，代理后便可在 * CacheInterceptor中对其方法进行拦截，然后执行cache相关逻辑。此处省略具体处理逻辑，有兴趣请参考相关文档。
所以第一怀疑就是innerUserService没有经过InfrastructureAdvisorAutoProxyCreator的代理增强。果然调试发现，被authRealm依赖的情况下在InnerUserService的Bean实例化时，用于处理该Bean的PostBeanProcessor明显比没被authRealm依赖时少，并且不含有InfrastructureAdvisorAutoProxyCreator。
而且，被依赖时会多打出来一行信息：
...................
Bean 'IInnerUserServiceImpl' of type [shiro.web.inner.service.impl.IInnerUserServiceImpl] is not eligible for getting processed by all BeanPostProcessors (for example: not eligible for auto-proxying)
...................
据此推断，可能是innerUserService启动时机过早，导致的后面那些BeanPostProcessor们来没来得及实例化及注册呢。
2.3 BeanPostProcessor启动阶段对其依赖的Bean造成的影响
首先确认了authRealm也是受害者，因为shiroFilter->SecurityManager->authRealm的依赖关系导致其不得不提前实例化。表面上的罪魁祸首是shiroFilter，但是到底是谁导致的shiroFilter预料之外的提前启动呢。shiroFilter与InfrastructureAdvisorAutoProxyCreator的具体启动时机到底是什么时候呢。
又经过一番混天暗地的调试，终于了解了BeanPostProcessor的启动时机。在AbstractBeanFactory中维护了BeanPostProcessor的列表：
private final List<BeanPostProcessor> beanPostProcessors = new ArrayList<BeanPostProcessor>();
并实现了ConfigurableBeanFactory定义的方法：
void addBeanPostProcessor(BeanPostProcessor beanPostProcessor);
因此我们首先监控AbstractBeanFactory.addBeanPostProcessor()，看看启动过程中谁调用了该方法来注册BeanPostProcessor。发现实例化及注册PostBeanFactory的阶段分为四个：
第一阶段是在启动时调用过程会调用AbstractApplicationContext.refresh()，其中的prepareBeanFactory方法中注册了
ApplicationContextAwareProcessor、ApplicationListenerDetector：
........
beanFactory.addBeanPostProcessor(new ApplicationContextAwareProcessor(this));
........
beanFactory.addBeanPostProcessor(new ApplicationListenerDetector(this));
........
然后在postProcessBeanFactory方法中注册了WebApplicationContextServletContextAwareProcessor：
beanFactory.addBeanPostProcessor(
new WebApplicationContextServletContextAwareProcessor(this));
然后在invokeBeanFactoryPostProcessors方法中调用
PostProcessorRegistrationDelegate.invokeBeanFactoryPostProcessors(beanFactory, getBeanFactoryPostProcessors());
其中对已经注册的BeanFactoryPostProcessors挨个调用其postProcessBeanFactory方法，其中有一个ConfigurationClassPostProcessor，其postProcessBeanFactory方法中注册了一个ImportAwareBeanPostProcessor：
beanFactory.addBeanPostProcessor(new ImportAwareBeanPostProcessor(beanFactory));
最后在registerBeanPostProcessors方法中调用
PostProcessorRegistrationDelegate.registerBeanPostProcessors(beanFactory, this);
在该方法中，首先注册BeanPostProcessorChecker：
beanFactory.addBeanPostProcessor(new BeanPostProcessorChecker(beanFactory, beanProcessorTargetCount));
该BeanPostProcessorChecker就是输出上面那行信息的真凶，它会在Bean创建完后检查可在当前Bean上起作用的BeanPostProcessor个数与总的BeanPostProcessor个数，如果起作用的个数少于总数，则报出上面那句信息。
然后分成三个阶段依次实例化并注册实现了PriorityOrdered的BeanPostProcessor、实现了Ordered的BeanPostProcessor、没实现Ordered的BeanPostProcessor，代码如下：
// Separate between BeanPostProcessors that implement PriorityOrdered,
// Ordered, and the rest.
List<BeanPostProcessor> priorityOrderedPostProcessors = new ArrayList<BeanPostProcessor>();
List<BeanPostProcessor> internalPostProcessors = new ArrayList<BeanPostProcessor>();
List<String> orderedPostProcessorNames = new ArrayList<String>();
List<String> nonOrderedPostProcessorNames = new ArrayList<String>();
for (String ppName : postProcessorNames) {
if (beanFactory.isTypeMatch(ppName, PriorityOrdered.class)) {
BeanPostProcessor pp = beanFactory.getBean(ppName, BeanPostProcessor.class);
priorityOrderedPostProcessors.add(pp);
if (pp instanceof MergedBeanDefinitionPostProcessor) {
internalPostProcessors.add(pp);
}
}
else if (beanFactory.isTypeMatch(ppName, Ordered.class)) {
orderedPostProcessorNames.add(ppName);
}
else {
nonOrderedPostProcessorNames.add(ppName);
}
}
// First, register the BeanPostProcessors that implement PriorityOrdered.
sortPostProcessors(priorityOrderedPostProcessors, beanFactory);
registerBeanPostProcessors(beanFactory, priorityOrderedPostProcessors);
// Next, register the BeanPostProcessors that implement Ordered.
List<BeanPostProcessor> orderedPostProcessors = new ArrayList<BeanPostProcessor>();
for (String ppName : orderedPostProcessorNames) {
BeanPostProcessor pp = beanFactory.getBean(ppName, BeanPostProcessor.class);
orderedPostProcessors.add(pp);
if (pp instanceof MergedBeanDefinitionPostProcessor) {
internalPostProcessors.add(pp);
}
}
sortPostProcessors(orderedPostProcessors, beanFactory);
registerBeanPostProcessors(beanFactory, orderedPostProcessors);
// Now, register all regular BeanPostProcessors.
List<BeanPostProcessor> nonOrderedPostProcessors = new ArrayList<BeanPostProcessor>();
for (String ppName : nonOrderedPostProcessorNames) {
BeanPostProcessor pp = beanFactory.getBean(ppName, BeanPostProcessor.class);
nonOrderedPostProcessors.add(pp);
if (pp instanceof MergedBeanDefinitionPostProcessor) {
internalPostProcessors.add(pp);
}
}
registerBeanPostProcessors(beanFactory, nonOrderedPostProcessors);
// Finally, re-register all internal BeanPostProcessors.
sortPostProcessors(internalPostProcessors, beanFactory);
registerBeanPostProcessors(beanFactory, internalPostProcessors);
// Re-register post-processor for detecting inner beans as ApplicationListeners,
// moving it to the end of the processor chain (for picking up proxies etc).
beanFactory.addBeanPostProcessor(new ApplicationListenerDetector(applicationContext));
需要注意的是，除了第一个阶段，其他阶段同一个阶段的BeanPostProcessor是在全部实例化完成以后才会统一注册到beanFactory的，因此，同一个阶段的BeanPostProcessor及其依赖的Bean在实例化的时候是无法享受到相同阶段但是先实例化的BeanPostProcessor的“服务”的，因为它们还没有注册。
从上面调试与源代码分析，BeanPostProcessor的实例化与注册分为四个阶段，第一阶段applicationContext内置阶段、第二阶段priorityOrdered阶段、第三阶段Ordered阶段、第四阶段nonOrdered阶段。而BeanPostProcessor同时也是Bean，其注册之前一定先实例化。而且是分批实例化和注册，也就是属于同一批的BeanPostProcesser全部实例化完成后，再全部注册，不存在先实例化先注册的问题。而在实例化的时候其依赖的Bean同样要先实例化。
因此导致一个结果就是，被PriorityOrderedBeanPostProcessor所依赖的Bean其初始化时无法享受到PriorityOrdered、Ordered、和nonOrdered的BeanPostProcessor的服务。而被OrderedBeanPostProcessor所依赖的Bean无法享受Ordered、和nonOrdered的BeanPostProcessor的服务。最后被nonOrderedBeanPostProcessor所依赖的Bean无法享受到nonOrderedBeanPostProcessor的服务。
由于InfrastructureAdvisorAutoProxyCreator的启动阶段是Ordered，因此我们需要确保没有任何priorityOrdered和Ordered的BeanPostProcessor直接或间接的依赖到shiroFilter，也就是依赖到我们的innerUserService。
同时，在PriorityOrdered接口的注解中也提到了该情况：
Note: {@code PriorityOrdered} post-processor beans are initialized in
* a special phase, ahead of other post-processor beans. This subtly
* affects their autowiring behavior: they will only be autowired against
* beans which do not require eager initialization for type matching.
2.4 BeanPostProcessor在进行依赖的Bean注入时，根据Bean名称进行类型检查时导致的“误伤”
OK，问题貌似已查明，修改Configuration中所有PriorityOrdered和Ordered类型的PostBeanProcessor的Bean配置，使其不再依赖shiroFilter。再次启动，却发现仍然提前启动了shiroFilter->SecurityManager->authRealm->innerUserService。
百思不得其解，又是一轮昏天暗地的调试，查找shiroFilter具体的启动时机。发现在一个叫做dataSourceInitializerPostProcessor的BeanPostProcessor实例化的时候，在根据类型获得其依赖的参数时，对shiroFilter执行了初始化。导致后续SecurityManager->authRealm->innerUserService统统提前初始化。但是在dataSourceInitializerPostProcessor之前的BeanPostProcessor却没有。经调试它们是否会导致shiroFilter初始化的区别在调用AbstractBeanFactory.isTypeMatch方法时出现：
public boolean isTypeMatch(String name, ResolvableType typeToMatch) throws NoSuchBeanDefinitionException{
.....................
// Check bean class whether we're dealing with a FactoryBean.
if (FactoryBean.class.isAssignableFrom(beanType)) { //（1）判断名称对应的Bean是否是一个FactoryBean，若是FactoryBean才执行本句
if (!BeanFactoryUtils.isFactoryDereference(name)) {
// If it's a FactoryBean, we want to look at what it creates, not the factory class.
beanType = getTypeForFactoryBean(beanName, mbd);
if (beanType == null) {
return false;
}
}
}
.....................
}
然后进入AbstractAutowireCapableBeanFactory.getTypeForFactoryBean方法：
@Override
protected Class<?> getTypeForFactoryBean(String beanName, RootBeanDefinition mbd) {
String factoryBeanName = mbd.getFactoryBeanName();
String factoryMethodName = mbd.getFactoryMethodName();
if (factoryBeanName != null) {
if (factoryMethodName != null) {
// Try to obtain the FactoryBean's object type from its factory method declaration
// without instantiating the containing bean at all.
BeanDefinition fbDef = getBeanDefinition(factoryBeanName);
if (fbDef instanceof AbstractBeanDefinition) {
AbstractBeanDefinition afbDef = (AbstractBeanDefinition) fbDef;
if (afbDef.hasBeanClass()) {
Class<?> result = getTypeForFactoryBeanFromMethod(afbDef.getBeanClass(), factoryMethodName);
if (result != null) {
return result;
}
}
}
}
// If not resolvable above and the referenced factory bean doesn't exist yet,
// exit here - we don't want to force the creation of another bean just to
// obtain a FactoryBean's object type...
if (!isBeanEligibleForMetadataCaching(factoryBeanName)) { //（2）判断该bean对应的factoryBeanName是否已经初始化了，如果没有，就返回。如果有，则继续
return null;
}
}
// Let's obtain a shortcut instance for an early getObjectType() call...
FactoryBean<?> fb = (mbd.isSingleton() ?
getSingletonFactoryBeanForTypeCheck(beanName, mbd) :
getNonSingletonFactoryBeanForTypeCheck(beanName, mbd));
......................
}
其中，有一个重要的判断：
// If not resolvable above and the referenced factory bean doesn't exist yet,
// exit here - we don't want to force the creation of another bean just to
// obtain a FactoryBean's object type...
if (!isBeanEligibleForMetadataCaching(factoryBeanName)) {
return null;
}
注解说的很明确，如果名字对应的factoryBean所在的factoryBean工厂尚未解析并实例化，那就直接退出，不会强制创建该facotryBean工厂，也就是Configuration对应的Bean。再次调试，果然发现，在先前的BeanPostProcessor和dataSourceInitializerPostProcessor之间，存在一个lifecycleBeanPostProcessor，而lifecycleBeanPostProcessor是在我们的Configuration中显示定义的，因此，当lifecycleBeanPostProcessor启动时会导致Configuration实例化。
dataSourceInitializerPostProcessor和在它之前的BeanPostProcessor对shiroFilter行为的不同在这里得到了完美的解释。本质上说dataSourceInitializerPostProcessor并不重要，重要的是lifecycleBeanPostProcessor将Configuration初始化了。就算不是dataSourceInitializerPostProcessor，那另一个BeanPostProcessor实例化时同样会将shiroFilter初始化。
最终隐藏大BOSS查明，解决方案就简单了，将lifecycleBeanPostProcessor移出到一个单独的Configuration就好了。
3. 总结
3.1 BeanPostProcessor启动顺序，以及其对于依赖的Bean的影响
BeanPostProcessor的启动时机。分为四个阶段，第一阶段context内置阶段、第二阶段priorityOrdered阶段、第三阶段Ordered阶段、第四阶段nonOrdered阶段。
而BeanPostProcessor同时也是Bean，其注册之前一定先实例化。而且是分批实例化和注册，也就是属于同一批的BeanPostProcesser全部实例化完成后，再全部注册，不存在先实例化先注册的问题。而在实例化的时候其依赖的Bean同样要先实例化。
因此导致一个结果就是，被PriorityOrderedBeanPostProcessor所依赖的Bean其初始化以后无法享受到PriorityOrdered、Ordered、和nonOrdered的BeanPostProcessor的服务。而被OrderedBeanPostProcessor所依赖的Bean无法享受Ordered、和nonOrdered的BeanPostProcessor的服务。最后被nonOrderedBeanPostProcessor所依赖的Bean无法享受到nonOrderedBeanPostProcessor的服务。
3.2 注意避免BeanPostProcessor启动时的“误伤”陷阱
BeanPostProcessor实例化时，自动依赖注入根据类型获得需要注入的Bean时，会将某些符合条件的Bean（FactoryBean并且其FactoryBeanFactory已经实例化的）先实例化，如果此FacotryBean又依赖其他普通Bean，会导致该Bean提前启动，造成误伤（无法享受部分BeanPostProcessor的后处理，例如典型的auto-proxy）。
来源：https://blog.csdn.net/m0_37962779/article/details/78605478
0
投稿猜你喜欢
Scanner对象的输入结束标记最近开始复习java了，自己不知道或者需要注意的地方自己做个笔记package gt; impor- 前言SPI 全称为 Service Provider Interface，是一种服务发现机制。SPI 的本质是将接口实现类的全限定名配置在文
- 前言感觉Jpa的动态构建查询不好使用，然后mybatis-plus没有动态构建表的功能，有没有可能使两者混合使用，利用Jpa自动建表的优势
- 我们经常在项目中使用的线程池，但是是否关心过线程池的关闭呢，可能很多时候直接再项目中直接创建线程池让它一直运行当任务执行结束不在需要了也不去
- 下文笔者讲述SpringBoot配置log4j的方法分享,如下所示SpringBoot日志输出springboot框架中默认使用logbac
- 用途：IO工具类（将内容写到流中）使用场景IO工具类只是辅助流的读写，并不负责关闭流。原因是流可能被多次读写，读写关闭后容易造成问题。项目引
- 前言标签(Label)控件是最常用的控件，在任何Windows应用程序中都可以中都可以看到标签控件。标签控件用于显示用户不能编辑的文件或图像
- 返回值类型：System.Int64表示为 Windows 文件时间的当前 DateTime 对象的值。例如：DateTime.Now.To
- 1.try-catch异常处理说明Java提供try和catch块来处理异常，try块用于包含可能出错的代码。catch块用于处理try块中
- 本文实例为大家分享了Android匹配关键字标红的具体代码，供大家参考，具体内容如下1. 单关键字匹配若只需匹配 搜索内容 可以
- 在项目开发中，经常碰到map转实体对象或者对象转map的场景，工作中，很多时候我们可能比较喜欢使用第三方jar包的API对他们进行转化，而且
- Java类的加载说明Java类的编译代码都存在于它自己的独立文件中(class),该文件只在需要使用程序代码时才会被加载。类加载在创建类的第
- 最近要做一个网站，要求实现验证码程序，经过不断调试，终于成功实现功能。一、验证码生成类生成验证码的话需要用到java的Graphics类库，
- 本文实例讲述了java实现日期拆分的方法。分享给大家供大家参考。具体如下：如：计算6-1至6-5之间的日期天数及具体日期，预期的结果是得到：
- 分类1.简单工厂模式2.工厂方法模式3.抽象工厂模式案例需求根据蛋糕的不同口味，分别创建苹果味和香蕉味的蛋糕实例方案一:简单工厂模式定义蛋糕
- 1、先使用tiledmap编辑地图，图层用来刷图块，对象用来定义单个格子的数据2、为每个图块调属性 3、图块需要单独配置属性的就必
- 需求描述 今日需求是删除资源时同时删除与该资源绑定的角色数据,有两张表,资源表、
- Java中字符串对象创建有两种形式，一种为字面量形式，如String str = "hello";，另一种就是使用new
- Redis 简介Redis 是完全开源的，遵守 BSD 协议，是一个高性能的 key-value 数据库。Redis 与其他 key - v
- 1、点击【File】->【Project Structure】菜单（或使用Shift+Ctrl+Alt+S快捷键），打开【Projec
