前言
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进行缓存。配置如下（摘录重要部分）：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 |
@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从库中查找用户信息，示例代码如下：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 |
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的标注，示例代码如下：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
@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的列表：
|
1 |
private final list<beanpostprocessor> beanpostprocessors = new arraylist<beanpostprocessor>(); |
并实现了configurablebeanfactory定义的方法：
|
1 |
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：
|
1 2 |
beanfactory.addbeanpostprocessor( new webapplicationcontextservletcontextawareprocessor( this )); |
然后在invokebeanfactorypostprocessors方法中调用
复制代码 代码如下:
postprocessorregistrationdelegate.invokebeanfactorypostprocessors(beanfactory, getbeanfactorypostprocessors());
其中对已经注册的beanfactorypostprocessors挨个调用其postprocessbeanfactory方法，其中有一个configurationclasspostprocessor，其postprocessbeanfactory方法中注册了一个importawarebeanpostprocessor：
|
1 |
beanfactory.addbeanpostprocessor( new importawarebeanpostprocessor(beanfactory)); |
最后在registerbeanpostprocessors方法中调用
|
1 |
postprocessorregistrationdelegate.registerbeanpostprocessors(beanfactory, this ); |
在该方法中，首先注册beanpostprocessorchecker：
复制代码 代码如下:
beanfactory.addbeanpostprocessor(new beanpostprocessorchecker(beanfactory, beanprocessortargetcount));
该beanpostprocessorchecker就是输出上面那行信息的真凶，它会在bean创建完后检查可在当前bean上起作用的beanpostprocessor个数与总的beanpostprocessor个数，如果起作用的个数少于总数，则报出上面那句信息。
然后分成三个阶段依次实例化并注册实现了priorityordered的beanpostprocessor、实现了ordered的beanpostprocessor、没实现ordered的beanpostprocessor，代码如下：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 |
// 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方法时出现：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
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方法：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 |
@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));
...................... } |
其中，有一个重要的判断：
|
1 2 3 4 5 6 |
// 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
查看更多关于浅谈BeanPostProcessor加载次序及其对Bean造成的影响分析的详细内容...