一、事出有因

​ 最近有一個(gè)場(chǎng)景，因同一個(gè)項(xiàng)目中不同JAR包依賴同一個(gè)組件，但依賴組件的版本不同，導(dǎo)致無(wú)論使用哪個(gè)版本都報(bào)錯(cuò)（無(wú)法同時(shí)兼容兩個(gè)JAR包中所需的方法調(diào)用），經(jīng)過(guò)分析發(fā)現(xiàn)差異的部份是在一個(gè)BEAN中的方法出入?yún)⒉煌樱士紤]通過(guò)動(dòng)態(tài)替換掉這個(gè)存在兼容性的BEAN，換成我們自己繼承自該BEAN類并實(shí)現(xiàn)適配兼容方法，從而最終解決組件版本不兼容問(wèn)題；

二、解決方案困境

但在實(shí)現(xiàn)的編碼過(guò)程中發(fā)現(xiàn)，原依賴的那個(gè)BEAN并不是普通的通過(guò)標(biāo)注@Compent之類的注解實(shí)現(xiàn)的注冊(cè)的BEAN，而是由自定義的BeanDefinitionRegistryPostProcessor BEAN類中動(dòng)態(tài)注冊(cè)的BEAN，這樣BEAN的注冊(cè)順序是“無(wú)法確定”的，我原本想通過(guò)自定義一個(gè)BeanDefinitionRegistryPostProcessor BEAN類，在postProcessBeanDefinitionRegistry方法中通過(guò)找到原依賴BEAN的名字，然后移除該名稱對(duì)應(yīng)的BEAN定義信息（BeanDefinition），最后再以原BEAN的名字定義并注冊(cè)成為我自己的適配器的BEAN類，這樣就實(shí)現(xiàn)了“移花接木”的功能，然而想法是OK的但最終運(yùn)行起來(lái)，發(fā)現(xiàn)BEAN并沒(méi)有成功被替換，究其原因發(fā)現(xiàn)，原來(lái)我自己定義的BeanDefinitionRegistryPostProcessor BEAN類是優(yōu)先于原依賴的那個(gè)問(wèn)題BEAN所對(duì)應(yīng)的BeanDefinitionRegistryPostProcessor BEAN類之前執(zhí)行的，這樣就會(huì)導(dǎo)致在我的自定義BeanDefinitionRegistryPostProcessor BEAN類postProcessBeanDefinitionRegistry方法中并沒(méi)有找到原依賴BEAN名字對(duì)應(yīng)的BeanDefinition，也就無(wú)法進(jìn)行正常的替換了，如果說(shuō)文字難看懂，可以見(jiàn)如下圖所示：

三、柳暗花明，終級(jí)解決方案

既然問(wèn)題根源找到，那確保一個(gè)自定義的BeanDefinitionRegistryPostProcessor 類被最后定義為Bean、且被最后執(zhí)行成為關(guān)鍵（至少得比原依賴的那個(gè)問(wèn)題BEAN所對(duì)應(yīng)的BeanDefinitionRegistryPostProcessor BEAN類【如：OldBeanDefinitionRegistryPostProcessor】之后執(zhí)行才行），因?yàn)檫@樣我們才能獲得原依賴的問(wèn)題Bean的BeanDefinition,才能進(jìn)行正常的替換BeanDefinition，最終達(dá)到原來(lái)依賴問(wèn)題Bean的自動(dòng)都依賴到新的適配器Bean，從而可以控制修改問(wèn)題方法的中的邏輯（比如：兼容、降級(jí)）。當(dāng)然，我估計(jì)此時(shí)有人會(huì)想說(shuō)，何必這么麻煩，一個(gè)AOP切面不就搞定了嗎？通過(guò)實(shí)現(xiàn)@Around切面，把有問(wèn)題的方法攔截替換成自己的適配方法邏輯，這種確實(shí)也是一種有效手段，但我認(rèn)為不夠優(yōu)雅，而且代碼的可讀性不強(qiáng)且未必能覆蓋所有方法，比如：如果涉及問(wèn)題方法內(nèi)部依賴的內(nèi)部方法（如protected）過(guò)多或依賴的其它BEAN過(guò)多時(shí)，可能就會(huì)導(dǎo)致這個(gè)切面類里面要復(fù)制一堆的原問(wèn)題BEAN類中的內(nèi)部方法到切面類中，但這樣帶來(lái)的風(fēng)險(xiǎn)就是代碼重復(fù)及原代碼更新后導(dǎo)致的不一致等隱性問(wèn)題，故我的原則是：如果只是簡(jiǎn)單的替換原有方法且邏輯不復(fù)雜的可以使用AOP切面來(lái)解決，但如果涉及復(fù)雜的業(yè)務(wù)邏輯且內(nèi)部依賴過(guò)多，這時(shí)采取代理、適配或裝飾可能更為合適一些。

好了，如下就是我要分享的三種：確保一個(gè)自定義的BeanDefinitionRegistryPostProcessor 類被最后定義為Bean、且被最后執(zhí)行的實(shí)現(xiàn)方式。

第一種實(shí)現(xiàn)方案

第一種：通過(guò)嵌套注冊(cè)自定義的BeanDefinitionRegistryPostProcessor 類BEAN的方式，這種方式實(shí)現(xiàn)思路是：PostProcessorRegistrationDelegate.invokeBeanFactoryPostProcessors會(huì)先執(zhí)行已獲得BeanDefinitionRegistryPostProcessor BEAN集合，執(zhí)行完這些BEAN集合后（這里我稱為第一輪或第一層），會(huì)再次嘗試獲取第二輪、第三輪一直到獲取的BeanDefinitionRegistryPostProcessor BEAN集合全部處理完成為止，框架相關(guān)代碼片段如下：

boolean reiterate = true;while (reiterate) {reiterate = false;postProcessorNames = beanFactory.getBeanNamesForType(BeanDefinitionRegistryPostProcessor.class, true, false);for (String ppName : postProcessorNames) {if (!processedBeans.contains(ppName)) {currentRegistryProcessors.add(beanFactory.getBean(ppName, BeanDefinitionRegistryPostProcessor.class));processedBeans.add(ppName);reiterate = true;}}sortPostProcessors(currentRegistryProcessors, beanFactory);registryProcessors.addAll(currentRegistryProcessors);invokeBeanDefinitionRegistryPostProcessors(currentRegistryProcessors, registry);currentRegistryProcessors.clear();}

實(shí)現(xiàn)方式代碼如下：

//如下是第一層自定義的BeanDefinitionRegistryPostProcessor BEAN，內(nèi)部再注冊(cè)真正用于替換BEAN目的NewBeanDefinitionRegistryPostProcessor BEAN//author:zuowenjun@Componentpublic class FirstDynamicBeanPostProcessor implements BeanDefinitionRegistryPostProcessor { @Override public void postProcessBeanDefinitionRegistry(BeanDefinitionRegistry beanDefinitionRegistry) throws BeansException { BeanDefinitionBuilder beanDefinitionBuilder=BeanDefinitionBuilder.genericBeanDefinition(NewBeanDefinitionRegistryPostProcessor.class);beanDefinitionRegistry.registerBeanDefinition('newBeanDefinitionRegistryPostProcessor',beanDefinitionBuilder.getBeanDefinition()); System.out.printf('【%1$tF %1$tT.%1$tL】%s,FirstDynamicBeanPostProcessor.postProcessBeanDefinitionRegistry%n', new Date()); } @Override public void postProcessBeanFactory(ConfigurableListableBeanFactory configurableListableBeanFactory) throws BeansException { System.out.printf('【%1$tF %1$tT.%1$tL】%s,FirstDynamicBeanPostProcessor.postProcessBeanFactory%n', new Date()); }}//用于將原依賴的問(wèn)題Bean替換為同名的新的適配器Bean(下文中所有替換方式最終都要使用該類)public class NewBeanDefinitionRegistryPostProcessor implements BeanDefinitionRegistryPostProcessor { @Override public void postProcessBeanDefinitionRegistry(BeanDefinitionRegistry beanDefinitionRegistry) throws BeansException { System.out.printf('【%1$tF %1$tT.%1$tL】%s,NewBeanDefinitionRegistryPostProcessor.postProcessBeanDefinitionRegistry%n',new Date()); boolean isContainsSpecialBean = ((DefaultListableBeanFactory) beanDefinitionRegistry).containsBean('old問(wèn)題Bean名稱'); if (isContainsSpecialBean) { beanDefinitionRegistry.removeBeanDefinition('old問(wèn)題Bean名稱'); BeanDefinitionBuilder beanDefinitionBuilder = BeanDefinitionBuilder.genericBeanDefinition(DemoCompentB.class); beanDefinitionBuilder.addConstructorArgValue(((DefaultListableBeanFactory) beanDefinitionRegistry).getBean(NewBeanAdapter.class)); //NewBeanAdapter為繼承自old問(wèn)題Bean的裝飾者、適配器類 AbstractBeanDefinition beanDefinition = beanDefinitionBuilder.getBeanDefinition(); beanDefinition.setPrimary(true); beanDefinitionRegistry.registerBeanDefinition('old問(wèn)題Bean名稱', beanDefinition); } } @Override public void postProcessBeanFactory(ConfigurableListableBeanFactory configurableListableBeanFactory) throws BeansException { System.out.printf('【%1$tF %1$tT.%1$tL】%s,NewBeanDefinitionRegistryPostProcessor.postProcessBeanFactory%n',new Date()); }}

最終執(zhí)行的順序如下：(可以看到NewBeanDefinitionRegistryPostProcessor是在OldBeanDefinitionRegistryPostProcessor之后執(zhí)行的，這樣就可以正常替換Bean定義了)

FirstDynamicBeanPostProcessor.postProcessBeanDefinitionRegistry (第一輪)

OldBeanDefinitionRegistryPostProcessor.postProcessBeanDefinitionRegistry (第一輪)

NewBeanDefinitionRegistryPostProcessor.postProcessBeanDefinitionRegistry （第二輪）

FirstDynamicBeanPostProcessor.postProcessBeanFactory

OldBeanDefinitionRegistryPostProcessor.postProcessBeanFactory

NewBeanDefinitionRegistryPostProcessor.postProcessBeanFactory

第二種實(shí)現(xiàn)方案

第二種：通過(guò)額外定義一個(gè)BeanDefinitionRegistryPostProcessor BEAN并實(shí)現(xiàn)PriorityOrdered、BeanFactoryAware接口，確保該BEAN最先被執(zhí)行(Order=0)，然后在postProcessBeanDefinitionRegistry方法中通過(guò)applicationContext.setDependencyComparator設(shè)置自定義的排序器，達(dá)到排序BeanDefinitionRegistryPostProcessor BEAN集合的執(zhí)行順序，這種方式實(shí)現(xiàn)思路是：在執(zhí)行BeanDefinitionRegistryPostProcessor BEAN集合前會(huì)調(diào)用sortPostProcessors方法進(jìn)行排序，而排序規(guī)則又依賴于DependencyComparator，通過(guò)控制排序規(guī)則實(shí)現(xiàn)間接控制執(zhí)行順序，先看框架的代碼片段：

private static void sortPostProcessors(List<?> postProcessors, ConfigurableListableBeanFactory beanFactory) {Comparator<Object> comparatorToUse = null;if (beanFactory instanceof DefaultListableBeanFactory) {comparatorToUse = ((DefaultListableBeanFactory) beanFactory).getDependencyComparator();}if (comparatorToUse == null) {comparatorToUse = OrderComparator.INSTANCE;}postProcessors.sort(comparatorToUse);}//如下是invokeBeanFactoryPostProcessors方法片段：sortPostProcessors(currentRegistryProcessors, beanFactory);registryProcessors.addAll(currentRegistryProcessors);invokeBeanDefinitionRegistryPostProcessors(currentRegistryProcessors, registry);

實(shí)現(xiàn)方式代碼如下：

@Component public static class FirstBeanDefinitionRegistryPostProcessor implements BeanDefinitionRegistryPostProcessor, PriorityOrdered , BeanFactoryAware { private BeanFactory beanFactory; @Override public void setBeanFactory(BeanFactory beanFactory) throws BeansException { this.beanFactory=beanFactory; } @Override public void postProcessBeanDefinitionRegistry(BeanDefinitionRegistry beanDefinitionRegistry) throws BeansException { ((DefaultListableBeanFactory) beanFactory).setDependencyComparator(new OrderComparator(){ @Override protected int getOrder(Object obj) { if (obj instanceof NewBeanDefinitionRegistryPostProcessor){ //如果是NewBeanDefinitionRegistryPostProcessor則將它的排序序號(hào)設(shè)置為最大 return Integer.MAX_VALUE; } return super.getOrder(obj)-1; //其余的全部設(shè)為比它小1 } }); System.out.printf('【%1$tF %1$tT.%1$tL】%s,FirstBeanDefinitionRegistryPostProcessor.postProcessBeanDefinitionRegistry%n', new Date()); } @Override public void postProcessBeanFactory(ConfigurableListableBeanFactory configurableListableBeanFactory) throws BeansException { System.out.printf('【%1$tF %1$tT.%1$tL】%s,FirstBeanDefinitionRegistryPostProcessor.postProcessBeanFactory%n', new Date()); } @Override public int getOrder() { return 0;//確保 } }

最終執(zhí)行的順序如下：（NewBeanDefinitionRegistryPostProcessor在OldBeanDefinitionRegistryPostProcessor后面執(zhí)行）

FirstBeanDefinitionRegistryPostProcessor.postProcessBeanDefinitionRegistry （第1批：實(shí)現(xiàn)PriorityOrdered執(zhí)行）

OldBeanDefinitionRegistryPostProcessor.postProcessBeanDefinitionRegistry （第3批：普通BEAN執(zhí)行）

NewBeanDefinitionRegistryPostProcessor.postProcessBeanDefinitionRegistry （第3批：普通BEAN執(zhí)行）

FirstBeanDefinitionRegistryPostProcessor.postProcessBeanFactory

OldBeanDefinitionRegistryPostProcessor.postProcessBeanFactory

NewBeanDefinitionRegistryPostProcessor.postProcessBeanFactory

第三種實(shí)現(xiàn)方案

第三種：通過(guò)自定義DeferredImportSelector類并配合@Import注解，實(shí)現(xiàn)NewBeanDefinitionRegistryPostProcessor最后才被注冊(cè)成為BEAN，最后才有機(jī)會(huì)執(zhí)行，這種方式實(shí)現(xiàn)思路是：因?yàn)镈eferredImportSelector的執(zhí)行時(shí)機(jī)是在所有@Configuration類型bean解析之后。

實(shí)現(xiàn)方式代碼如下：

public static class BeansImportSelector implements DeferredImportSelector { @Override public String[] selectImports(AnnotationMetadata importingClassMetadata) { return new String[]{NewBeanDefinitionRegistryPostProcessor.class.getName()}; } }@Configuration@Import(BeansImportSelector.class)public class BeansConfig { }

最終執(zhí)行的順序如下：（NewBeanDefinitionRegistryPostProcessor在OldBeanDefinitionRegistryPostProcessor后面執(zhí)行）

OldBeanDefinitionRegistryPostProcessor.postProcessBeanDefinitionRegistry

NewBeanDefinitionRegistryPostProcessor.postProcessBeanDefinitionRegistry

OldBeanDefinitionRegistryPostProcessor.postProcessBeanFactory

NewBeanDefinitionRegistryPostProcessor.postProcessBeanFactory

四、引發(fā)的思考

如上就是三種實(shí)現(xiàn)方式，至于哪種方式最好，這要看具體的場(chǎng)景，第一種、第三種影響面相對(duì)較小，而第二種因?yàn)樯婕案鼡QDependencyComparator，可能影響的是全局。另外之所以會(huì)研究如上實(shí)現(xiàn)方式，主要原因還是因?yàn)槲覀兊捻?xiàng)目框架代碼沒(méi)有考慮擴(kuò)展性及規(guī)范性，比如要?jiǎng)討B(tài)注冊(cè)BEAN，至少應(yīng)實(shí)現(xiàn)PriorityOrdered或Order接口或指明@Order注解，這樣當(dāng)我們?cè)谀承┨囟▓?chǎng)景需要做一下優(yōu)化或替換時(shí)，則可以直接采取相同的方式但指定Order在前或在后即可，也就不用這么復(fù)雜了，比如：

@Componentpublic class OldBeanDefinitionRegistryPostProcessor implements BeanDefinitionRegistryPostProcessor,Order { @Override public int getOrder() { return 100; } ...}@Componentpublic class NewBeanDefinitionRegistryPostProcessor implements BeanDefinitionRegistryPostProcessor,Order { @Override public int getOrder() { return 101;//只需序號(hào)在OldBeanDefinitionRegistryPostProcessor.getOrder之后即可 } ...}

以上就是Java 確保某個(gè)BeanDefinitionRegistryPostProcessor Bean被最后執(zhí)行的幾種實(shí)現(xiàn)方式的詳細(xì)內(nèi)容，更多關(guān)于確保BeanDefinitionRegistryPostProcessor Bean執(zhí)行的資料請(qǐng)關(guān)注好吧啦網(wǎng)其它相關(guān)文章！