前言
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;}@beanpublic 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
|
@servicepublic 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方法中调用
其中对已经注册的beanfactorypostprocessors挨个调用其postprocessbeanfactory方法，其中有一个configurationclasspostprocessor，其postprocessbeanfactory方法中注册了一个importawarebeanpostprocessor：
|
1
|
beanfactory.addbeanpostprocessor(new importawarebeanpostprocessor(beanfactory)); |
最后在registerbeanpostprocessors方法中调用
|
1
|
postprocessorregistrationdelegate.registerbeanpostprocessors(beanfactory, this); |
在该方法中，首先注册beanpostprocessorchecker：
该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
|
@overrideprotected 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
